文字コード総合スレ part5

プログラマーなら一度は煩わされたことのある文字コードについてのスレです。
ShiftJIS、JIS、EUC、Uincode、 UCS、サロゲートペア、コードポイント、文字コード判定、
合成文字、ソート、TRON、外字コード、その他について語り合いましょう。
各言語での文字列の扱いについての質問もOKです。
基本マッターリ、ささ、茶でもどうぞ。

■過去スレ
文字コード総合スレ part1 http://pc11.2ch.net/test/read.cgi/tech/1031028205/
文字コード総合スレ part2 http://pc11.2ch.net/test/read.cgi/tech/1143375639/
文字コード総合スレ part3 http://pc11.2ch.net/test/read.cgi/tech/1180250376/
文字コード総合スレ part4 http://pc11.2ch.net/test/read.cgi/tech/1228052369/

■参考サイト
Unicode Home Page
http://www.unicode.org/
Java Character Encodings
http://www.ingrid.org/java/i18n/encoding/
euc.JP: tech docs, BeOS tools
http://euc.jp/
ISO-IR - 2.8.1 Coding systems with Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm
ISO-IR - 2.8.2 Coding Systems without Standard return
http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm
IANA: Character Sets
http://www.iana.org/assignments/character-sets
Legacy Encoding Project
http://sourceforge.jp/projects/legacy-encoding/
CP50220
森山さんの説明
http://lists.sourceforge.jp/mailman/archives/legacy-encoding-talk-ja/2006-March/000002.html
JISX4061
日本語文字列照合順番
http://www.jisc.go.jp/

漢字袋
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/
池田証寿
http://homepage3.nifty.com/shikeda/zatsubun.htm
SJIS2004とかJISX213系の文字コード表
http://x0213.org/codetable/
※JISCの奴は無料で閲覧できる奴じゃなくて購入したPDFでも手で書き取らされます
Windowsで扱える文字一覧（コードページ毎で良ければ）
http://www.microsoft.com/globaldev/reference/cphome.mspx
docomoの携帯コンテンツ制作者向け文字コード情報
http://www.nttdocomo.co.jp/service/imode/make/
auの携帯コンテンツ制作者向け文字コード情報
http://www.au.kddi.com/ezfactory/
SoftBank携帯コンテンツ制作者向け文字コード情報
http://creation.mb.softbank.jp/
漢字データベース
http://kanji-database.sourceforge.net/index.html

■これまでに行われた議論
・WinでCP50220 は Unicode からマルチバイト文字への変換でいわゆる半角カタカナを全角カタカナに置き換え
　内部的には Unicode -> CP932 -> CP5022ｘ って変換な気もする
・人名をソートかけたらバストサイズ順の並びになる？
・Shift JIS や EUC-JP や Big5 や GB なんかをUnicode に変換してしまうと、ラウンドトリップは保証されるか
・単一情報をソースの文字コード(or 言語)情報なしに元に戻したい （統計的に文字の出現確率なんかを調べる）
・PC-98x1シリーズのMS-DOSはShift_JISだが漢字ROMはJIS、変換は何処で行っていた？
・0x5cをUnicodeにするときにバックスラッシュに置き換えるか円マークに置き換えるかで、逆変換時に結果が変わるの問題
・丸付き数字は機種依存文字か？。MSIME2007ではCP932に収録されてない文字は「環境依存文字」って表示。
　Macではフォントによっては表示されないし、フォントによっては表示される
・Shift_JISと名乗っているCP932やISO-2022-JPと名乗っているCP50220を表示（Unicodeに変換）する際に
　機種依存文字はサポートされるか？
・Safari文字コード変換のバグは
・Microsoft文字コード変換のバグは
・U+31F0..U+31FF（アイヌ語表記用小書きカタカナ）が入ってない件
・なぜ携帯業界はunicode化しないのか？
・このスレへの書き込みはブラウザが2chへ送り出す時点でUnicodeからShift_JISに変換しているのか
・文字化けに強いishフォーマットでエロ画像を交換する場合、ssより、s7のほうが化けにくい

・中国語の簡体字では、へんやつくりが簡略化されるなら、その文字も自動的に簡略化して表記する国家規格が有る
・中国語の「噁心」簡化政策によると「恶(U+6076)」に統一。口偏＋恶(U+6076)は普通に使われているがUnicodeにはない
・日本人のニーズが満たせないのも確かなので原規格分離（中国では「曾→曽」は簡体字と繁体字の違いとはみなされていないとか）
・UNICODEを扱うプログラムはサロゲートをぶったぎられた入力が渡されてくる場合にも備えろって→YES
・UnicodeとUTF-8の違いは？
・日本のCJK Ext.D Submissionに{魚針}が含まれてる件
　U+9C75(魚箴)は強烈。いくら何でも違いすぎる。(魚針)
　ひょっとしたら後で実は別字だったとか日本では異体字だが中国では別字とかになるかも知れんぞ。
　中国ではってレベルじゃねーぞ。
・Windows Vista での「IME パッド - 文字一覧」の「JIS X 0213 （1面）」のバグ
　UTF-16: 0x304B 0x309A →　Unicode: U+FD61809A　（間違い）　（ISO/IEC10646はU+10FFFFまで）
　サロゲートペアからコードポイントを引き出す計算を無理やり適用（間違い）
　((0x304B - 0xD800) << 10) + (0x309A - 0xDC00) + 0x10000が 0xFD61809A になる。
・文字コードではインドカレーは飲み物か否か。カレーパンうまうま。
・CJK混在の漢字環境ってどうやって、切り分ければいいの？　→　ムリです。
・Winzipで保存されるファイル名が文字化け→zipではコードページ情報が無い。直接zipファイルから切り出せ
・Unicodeは言語情報を直接扱わない。 多言語の混在表現は（unicodeでは）できないか
・Unicode文字列リストを各国言語を考慮してソートしたいんですが　→　ムリです。
・Unicodeサニタイズが面倒になるのか
・SJISとUNICODEの判別はどのようにすればいいですか？BOM。無ければ、統計判断。 ライブラリを使うが吉
・ところでケータイのUnicode対応度って実際どうよ？　→　ウンコマークもUnicodeに追加されるんだな。
・WindowsXP で フォルダに使用できないフォルダ名はどうやって判定
　　→　ちょっとアホな方法だけど、%TEMP% フォルダの下で実際に作ってみて。本当に作成できるかどうかで判断。

■ライブラリ
IBM Globalization - ICU
http://www-306.ibm.com/software/globalization/icu/
NKF32.DLL
http://www.vector.co.jp/soft/win95/util/se020949.html
http://www1.ttcn.ne.jp/~kaneto/dll/nkf32dll.html
バベル
http://tricklib.com/cxx/ex/babel/
バベルの文字コード判定で使ってる日本語文書内での各文字の出現頻度データです。
http://tricklib.com/cxx/ex/babel/scoremap.csv
mlang
http://msdn.microsoft.com/ja-jp/library/aa767865(en-us).aspx
iconv
http://www.gnu.org/software/libiconv/
ICU
http://www.icu-project.org/

RedHatで�狽ｪ文字化けする。

・(総和の)�狽ﾉついて
cp932でRedHatに持ち込んで、iconvでutf-8に変換できるが表示が化ける。
iconvでeuc-jpには変換できない。
win端末上でeuc-jpとして保存した場合、cygwinのiconvで他のコードに変換できない。
→euc-jpとしては存在しない文字扱い?

・(ギリシャ文字の)Σについて
コード変換は問題ないが、viで開くと1カラム幅の文字と認識するようだ。

1乙。ようやく立ったか。
しかし>>4-7みたいなのは、Wiki立てて
そこでまとめたほうがいいような気がするな。

あーいや、>7は纏めじゃなくてちょっと気になったから書いたのだけど。
で、今確認したら(当たり前だけど)Σ以外のギリシャ文字も1カラム幅と認識している模様。
実際に使われているフォントは2カラム幅なのに……

>>7
> →euc-jpとしては存在しない文字扱い?

JISにない。
JIS X 0208にGREEK CAPITAL LETTER SIGMAがあるから、
必要ないと判断された。

GREEK CAPITAL LETTER SIGMAはISO-8859-7にもある。
ただASCIIと違って、JIS X 0208と一緒に使う習慣はなかったから、
FULLWIDTH GREEK CAPITAL LETTER SIGMAというのはない。
LATIN LETTERSとちがって。

>>10
なるほど、半ば呆れつつ納得。THX!

>人名をソートかけたらバストサイズ順の並びになる？
よくこんなの引っ張り出してきたな

（ >>1->>6 の続き）
■単語一覧
・UTF-16は16ビット単位にエンコードするけど、サロゲートペアがある
　表現できる文字空間はUTF-8と同じく20ビットとちょっと
・丸付き数字は機種依存文字か？MSIME2007ではCP932に収録されてない文字は「環境依存文字」って表示。
　MacJapaneseではフォントによっては表示されないし、フォントによっては表示される。
今のMac（内部Unicodeアプリ）は、フォント依存ではなくアプリ依存。
似非ISO-2022-JPや似非Shift_JISのドキュメント中の丸付き数字は、
素直にAppleのAPIを使ってるアプリならゲタ（U+FFFD）になる。
・Mail.appではISO-2022-JPに収まらずCP932に収まるメールは、含まれる字種によって
　charset=CP932で送信される場合とISO-2022-JP（もどき）で送信される場合がある
・MSでのウニコードとSJIS変換のバグ。
　U+007E TILDE <-> Shift_JIS 0x7E OVERLINE
　U+301C WAVE DASH -> Shift_JIS NA 【MSの問題】
　U+FF5E FULLWIDTH TILDE <-> Shift_JIS 0x8160 WAVE DASH 【MSの問題】
・SafariでのウニコードとSJIS変換のバグ。
　U+007E TILDE -> Shift_JIS 0x8160 WAVE DASH 【Safariの問題】
　U+301C WAVE DASH <-> Shift_JIS 0x8160 WAVE DASH
　U+FF5E FULLWIDTH TILDE <-> Shift_JIS NA
・winzipの規格ではファイル名のコードページ指定もしくは記録情報が存在しない。
　解決策：取り合えず、MSWin+JPではShift-jisでファイル自体には保存されている。
　MACOSX=Unicode,Unix=UTF/EUC/S-JISどれでもありえる。文字に関係なくLocalLangで
　再変換しているので、それをしなければよい。

とりあえず纏めてみた。それでは、マッタリ行ってみよう。

これ加えとくわ。
Google Standard Unicode Emoji Mapping
http://unicode.org/~mdavis/08080r-emoji-proposal/
Proposal for Encoding Emoji Symbols/N3582
http://unicode.org/~scherer/emoji4unicode/snapshot/emoji.pdf
Emoji Symbols: Background Data
http://unicode.org/~scherer/emoji4unicode/snapshot/full.html

> References
> *http://en.wikipedia.org/wiki/Japanese_mobile_phone_culture
おいおい
まあファイストスの円盤文字もウィキペディア参照してたけど

つーかもうJTC1/SC2/WG2のサイトにも上がってるみたいなのに
WG2のページトップが更新されてねえ
なので直リンク
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3582.pdf
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3583.pdf

絵文字とかHistoric Kana(今はKATAKANA LETTER ORIGINAL Eのみ)を含んだ
Amd.7のドラフト
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3580.pdf

Last Resort Pictures (N3412) が含まれてないけど
あれはやっぱりエイプリルフールのジョークだったってことでいいのかな

立ってたのか、>>1乙

こんなFirefox拡張あるんだな。
Emacsのdescribe-charみたいなやつ。

Character Identifier
https://addons.mozilla.org/ja/firefox/addon/3929

Ext.Dに「トキ」「トモ」の合字が提案されてるんだが、
Historic Kanaブロックができた以上そっちのほうに入れるべきじゃね?

ってコメントしたいんだけどどうすれば届くのかさっぱりわからん

>>1乙
これはポニテでうんぬん

国旗周りでUnicode listが爆裂してたせいか
国旗もEMOJI COMPATIBILITY CHARACTERみたいな謎の記号に置き換えられてるな

つーかまたUnicode listが燃え上がってるな

自分でフォント作って組み込めば無問題。
こわいものなし。

Unicode-C初期UTF-8エンコードの規格覚えている奴まだ居るか判らないけど、
やはりあの時、言語学者の言うこと等聞かずに、国別にセクション割り当てて、VLEで通すべきだったな。
glyphが多ければ無制限に拡張できる規格。
殆どの言語が一文字3バイトに収まって、ソート問題もなし、政治的配慮もありだったのに。
しくじった。

collectionや制限部分集合の要素としてglyphic subsetも指定できるように
拡張してくれないかなあ。
要素はあくまでglyphic subsetなので、実装は必ずしもIVSをサポートする必要はない
(してもいいけど)。デフォルトの字形がglyphic subsetの範囲内に収まっていれば、
適合性を主張できることにする。
こうすれば、「新常用漢字の字形を実装したフォント」とか「JIS2004の字形を実装した
フォント」を、規格上曖昧さのない方法で表現できる。規格の行間とかJIS委員が
blogのコメントで吐き捨ててる愚痴まで読まないとまともに実装できないなんて
規格としては不健全きわまりない。
互換漢字大好きの日本代表には少しも期待してないのでUTCがんばれ

>>26
日本のためだけにそんなオーバースペック提案しても通らない。というか通らなかった
わけで。
iconvだって文字列1つしかオプションに取れないのはほとんど欠陥といってもいいが、
ありとあらゆる柔軟な変換を可能にするためのオプション類の追加なんてできないので、
エンコーディング名に何でもかんでも詰め込む羽目に陥ってる(UTF-8-MACとか)。

オーバースペックどころか、意図から外れてる。

日本代表と全面戦争ktkr
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3590.pdf

ちょっとアホな質問かもしれんが、つまり、U+624D　の　AJ1E0100 と　N3530E0103は同じと考えておk？
いいのか？

USは同じでいいんじゃね? と主張しているだけで、最終的に判断して再提出するのは
(あるいはあくまで互換漢字を入れろと突っ張るのは)日本。

ARIBといいケータイ絵文字といい昔の仮名といい
最近日本の文字のUnicodeへの提案多いね。
いい事だ。

ぜひ写研時代の記号文字も提案を…

変体仮名は住基仮名だけでも追加したほうがいいと思う。
戦前生まれの人の名前で戸籍上で使われてる事があってこだわる人がいるだろうから。
ところで名前に変体仮名を持つ人ってどれくらいいるのかな?
あまり見ないからごく小数なんだろうけど、実際に使われてても平仮名、片仮名あるいは元になったとされる漢字に置き換えたもので通してることが多いのかな?

携帯絵文字の大半はBMP外になるみたいだね。
まあ仕方ないか。あれだけ数あるから。
U+2600〜U+26FFはARIBとサッカーボールで全部埋まってしまうみたいだし。
U+2700〜U+27FFには所々に隙間があって少しここに入れるものがあるみたいだがこの領域全部埋めようとはしないのかな?

BMPに入るわけないだろw

つーかそろそろBMPは終了のお知らせが近づいてる。
JIS X 0213:2000がかつて勝手に使ってたカッコ付きUCSの位置にもついに
割り当てが入るみたいだし。
IPv4アドレスとどっちが先に枯渇するかってくらいの勢いだ

絵文字のどこらへんがBなんだ。

Basicじゃなさそうな文字とか記号とかBMPにてんこもりなので
その批判はあんまり意味無いかも

もうBMPは止めてCMP( Compatible Multilingual Plane )にでも
改名したほうがいいんじゃないかｗ

http://smallbear.sakura.ne.jp/tron/btm20093.html#20090331
おいおい、そのレベルの違いを「おかしな字形」と定義するんだったら
TRONコードだって「おかしな字形」の塊なんだが。
ジャストシステムに言いがかり付けてる暇があったらTRONコードの字形
をどうにかしてくれ。ていうか超漢字Vのマイナーバージョンアップと
Tフォントマダー? (AAry
http://pc12.2ch.net/test/read.cgi/tech/1093251312/160
の件といい、どうしてこうも天に唾するようなことばかり書くのかね。
http://smallbear.sakura.ne.jp/tron/btm20093.html#20090326
> 結局の所、誰もマトモに「常用漢字表」を読んでいないということがあ
> りありと分かるだけ何じゃないかと。
常用漢字表の「明朝体活字のデザインについて」を無視してる奴が
どの口でほざくか。

http://www.microsoft.com/typography/otspec/cmap.htm
Format 13: Last Resort Font
が追加された。ということはLast Resort Picturesはやっぱり
文字として符号化はしないんだな

汗マークや怒りマークがようやくUnicodeで使えるようになるな。

コードはあってもフォントとフォントへのマッピングが普及しているとは限らない罠
もういい加減、基本のフォントはタダで配れよ…

これはGoogleが検索エンジンのデータベースへ蓄積するために提案したんだから
表示は最初から考慮の対象外
さんざん言われてるけどドコモ以外を正確に再現するには多色カラーや
アニメーションが欠かせないし

>>35
官報にはたまに出てくるよ＞変体仮名

話は全然違うけど、CJKV改訂版の内容レビューだれかやってくれないかな。
本家に行っても、章立てすら見あたらない。

もうすぐ中旬終わるけど新ライセンスのIPAフォントマダー?
文字鏡16万字版の通常版マダー?
まったくどいつもこいつも出す出す詐欺ばかりだ。

>>48
おい、乞食のくせに口を慎めよ。

女真文字
http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3618.pdf
なんか漢字が混じってるような

>>49
文字鏡16万字版はタダじゃねーぞ

>>50
漢字と同じ字形の文字が少なからずあるからねぇ＞女真文字

しかし何だ、こういう一覧表見るとｗｋｔｋが止まらんな

http://www.dkuug.dk/jtc1/sc2/wg2/docs/n3607.pdf
U+E0200..U+E0545はUnicodeだとdefault ignorableだし
UCSでも(代替)書式文字のために予約されてる範囲なんだが
本当にそこでいいのか?

http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3636.pdf
N3583でもともと提案されてたEMOJI COMPATIBILITY SYMBOLと国旗の収録は
とりあえず断念したらしい。
その代わり／^o^＼ﾌｯｼﾞｻｰﾝと東京タワーと自由の女神と日本地図とモヤイ像の
名前がEMOJI COMPATIBILITY SYMBOL-nに変わるようだが。

>>54
なんでその中にモヤイ像が入ってんだ？w

アメリカかなり妥協したなあ。
よっぽどAmd.8に入れたかったんだな。

モヤイ像といえば渋谷名物だからなｗ

109涙目w

米がN3607に歩み寄ったってことは、もしかするとトランプも入ったのか

トランプは全て入ったけど
i-mode隠し文字(EMOJI COMPATIBILITY SYMBOL)は誰が考えたってダメだろ

TRONコードですらi-mode隠し文字の位置は空欄になってるぞ。
最初空欄を空けるのを忘れてて後から訂正が入ったりしたのはご愛敬
http://www2.tron.org/set08.html

麻雀ドミノに続いてトランプか。
これなら花札も行けるかもな。

トランプのところにはタロットの小アルカナも包摂するみたいなことが書いてあるから
そのうち大アルカナも提案されるのかね
いい加減節操がない気もするが

ショウギーはまだぁ？

ショウギーの駒は先手と後手の両方が必要だ

WHITE SHOGI PIECEは上下逆さにしたものを包摂してるらしい

MacOSでのShift_JISとUnicodeとのマッピング
ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/JAPANESE.TXT
見てたんだけど、
Unicodeの私用領域にマッピングしてる文字や、
2文字以上にマッピングされる文字が約60文字もあるのね…。

Shift_JIS　Unicode
0x8645　　0xFF4D+0xF87F # square m
0x8791　　0x5927+0x20DD # ideograph big + COMBINING ENCLOSING CIRCLE

みたいなの。
Webアプリ作ってるんだが、胃が痛い…。

>>64
碁も必要ではないだろうか。

碁は符号化するとしたらどんな感じになるんだろ。
○●の背後に┼があれば良いのかな。

白丸の中に数字、と、黒丸の中に白抜き数字、で、十分な数
（とりあえず999まででおk？）が必要じゃないかな。

あと、デザインを合わせて丸の内側に三角とか四角とかも。

そもそも、碁の棋譜を文字で表現すべきものなのか、激しく疑問だが。

楽譜や数式と同様にIgo Markup Languageと組み合わせて使うこと前提で登録なら
ありうるかも

雀牌もやるきかｗ

麻雀牌は収録済み

あとはシャンチーとか？
シャンチーって↓これね
http://ja.wikipedia.org/wiki/%E3%82%B7%E3%83%A3%E3%83%B3%E3%83%81%E3%83%BC

モンゴル将棋も忘れずに!
ttp://history.chess.free.fr/hiashatar.htm

チェスと将棋に包摂されたりして
麻雀牌も中国麻将を区別してないみたいだし

>>67
何を作っているかしらんけど、もしcharset=Shift_JISならそもそもそういう
文字は使うべきではないのでは。

ってゆうかそもそもそれをShift_JISと呼んでいる時点でアレだが。

MacEncodingをInternetで使っちゃダメだよ
Mozillaが対応してるのもほとんど事故のようなものだし

これってUTF-8のときも、MacOSでこの文字入力したら
私用領域の文字送ってくるってことでしょ。
対応しないならしないで、もしユーザーが使ったら
エラーメッセージ出さないと…。

対応も何もOSに依らず私用領域の文字を使うか否かはユーザの責任でしょ。
私用領域の文字でなくてもNSString/CFString (UTF-16)からShift_JISにする段階で変換できない文字は存在しうるし。

自分のソフトウェアでShift_JISな文字列からNSStringを作る場合は
[NSString stringWithCString: string encoding: NSShiftJISStringEncoding]
の代わりに、
(NSString *)CFStringCreateWithCString(NULL, string, kCFStringEncodingDOSJapanese)
とか、kCFStringEncodingShiftJIS_X0213を使うという手もあるよ。

ユーザーが私用領域とか知った上で入力するとは思えないなぁ…。
あなたのソフトウェアのユーザーと、私が対象としてるユーザーは
違うようなのでもう消えます。さよなら。

>>81
Webアプリ作っているお前の責任なんだが？
お前がUnicodeフレームワークの「利用者」

>>82がよくわからない。

>>81は、「Webアプリ作っているオマエの責任」として私用領域ははじこうとしている。
>>82の言っているそのままなんだが…。

>>81は、「対応する」=「そのままうけつける」、「対応しない」=「エラーとしてはじく」としているが、
>>82はどちらも「対応には変わりない」と言ってるんだろ。

麻雀って赤牌は別コードになるのか?

将棋の駒の上下逆さにしたの追加されるみたい。(ARIBにあるから)
ということは>>66で包摂しているって書いてあるが、これからは分離されるってことかな。

CJK統合漢字拡張Dは数がかなり少なくなるみたい。(200字強)
でそれより後に拡張Eが追加されるみたい。これも少量になって残りは拡張F、G、…になるかも。
やっぱり拡張Bのときいっぱい追加して重複とかあったから、
反省してこれからは慎重に少しずつ追加していくことにしたのかな?

漢字といえばN3530はどうなったんだろ
Resolutionsには言及されていないからMinutes待ちか

>>85
Unicodeは色を符号化しません。
cf. 絵文字

で、「じゃあフランス国旗とイタリア国旗はどうなんだよ」と突っ込まれたのが
国旗収録断念の理由の一つ

>>90
包摂しちゃえばいいのに

>>91
それじゃラウンドトリップコンバージョンが崩れるからダメなんだと
理由は他にもあるし

ハートマークの色違いとかHEART-1、HEART-2、…とか名称は-数字を付けるらしいな。
以前の案では縞模様とか網掛けに置き換えるとかしてたみたい。

なんかUnicode追加文字の符号位置だいぶ変更するみたいだね。ヤ行のえと□デはSMPの方に変更するらしい。
ヤ行のえは現代の仮名と古代の仮名は一緒にしない方がいい、
□デについてはU+32FFは○ンかもっと重要な文字が必要になったときのためにとっておいた方がよいということなどの理由らしい。
U+26xxに追加が提案されてたARIBの記号の一部はU+27xxやU+2Bxxに変更するみたい。
U+26xxのブロックはまだ埋まらないことになる。で携帯絵文字の内、蛇遣い座の記号はBMP内のU+26CEに提案されてた。
今後も変更があるかも知れない。最終的な決定はもう少し先になりそうだ。
個人的には怒りマークと汗マークをBMPにするべきだと思う。漫画とかTVの字幕でよく使われるし。

ARIB関連はもう動かせないよ。Amd6はFDAMに移行するから。
残りは明日からのUTCの会議次第でまだ紆余曲折あるかも。

結合文字はIME文字一覧からでしか入力出来ませんか？

> 個人的には怒りマークと汗マークをBMPにするべきだと思う。漫画とかTVの字幕でよく使われるし。

一昔前によく使われた、写研の記号BA-90はどうすんだ、とか
収拾がつかなくなる気がする。じだいとともにうつりかわってるし。

少なくともBA-90やBA-88はかつて漫画を中心に大量に使われたので
どこか提案して収録はして欲しいがSMPで良い。

絵文字のとこに入ってる顔のついた月が
それっていう解釈でもいいかもね

イワタアンチック体が収録しているんだが、これは外字だな
http://www.iwatafont.co.jp/MO_FONTS/set_image_pdf/antique/anti_b.pdf

このあたりの写植時代の記号類、Unicodeに入れてほしいね

BA-88はFIRST QUARTER MOON WITH FACE、BA-90はFULL MOON WITH FACEと包摂か。
ところでBA-90って満月なの?

BA-86からBA-89まで月が続いてるからBA-90は満月だと思い込んでたが、
そういわれりゃ太陽って可能性もあるわけか。

ぽげむたマークか、懐かしいな（ひげ無いけど）

http://std.dkuug.dk/jtc1/sc2/wg2/docs/n3553.pdf#page=15
> Some X0213 characters are mapped to
> compatibility ideographs. The problem stated in the paper is not reported in Japan
> ? my personal experience is that the problem stated in the paper has not occurred.
おいおいこんなのが日本代表やってんのかよ。小形の連載とか直井さんのblogあたり
を10646回読み直せ。それでもまだこんな寝言ほざくつもりならとっとと帰国して二度と
米国代表の邪魔をするな。

wg2のminutesは面白いよな
utcのminutesも各自の発言まで載ってるといいのに

> not reported
で、そのreportとやらはどこに送ればいいの?
太玄経記号の名前の天地人がおかしいとか、JIS X 0213用のNamed Sequencesが
足りねーよとかも、どこに言ったらいいかさっぱりわからないから2chとかで騒いでるん
だけど。
Unicodeは窓口を明確にしてるし、どっかの国のガス抜きのためだけにある
パブリックコメントと違ってちゃんと反映もしてくれるし必要ならWG2への提案まで
してくれるのに。日本人が日本代表動かすより米国代表やUTC動かすほうが
簡単ってどうなの?

http://www.itscj.ipsj.or.jp/sc2/open/02n4015.pdf
とかに彼のものっぽいメールアドレスがあるから、
直接報告してあげればいいんじゃないの。

>106
ロクな下調べもしないで騒ぐのならば、2chで始めた方が相手にも迷惑かからないかもね。
太玄経記号の天地人とかは amd 2 で直されて、annex p に注記が
入っている。0213のUSIとかもamd.7に入ってるけど、それでも足りないのがある？

>>104
Suignardの言ってることも変。
IVSもnormalizationかけたら、現状じゃ落ちちゃうだろ。
将来は大丈夫って、そんなのウソ。

>>109
IVSはnormalizationかけても落ちないよ。
ただ、SPP（14面）の文字は、文字列の等価性の比較のときは無視するべき。
照合アルゴリズムで、それをちゃんとやってるソフトも規定も現状では
整備されてないから、絵にかいた餅だってこと。

SPP -> SSP

PDAM8はsymbolばっかりだなあ、
と思ったら名前からしてAdditional symbolsが先頭に来ているのか。

10646の新版もようやくCDですか

ExtBマルチカラム化実現したのか

ちゃっかりAmd.8まで入れてあるような。

小形さんうまいこと引っ張るなぁ。

北朝鮮（KP）のフォントが用意できてないみたいだけど、
規格票用のフォントを作る余裕なんてあの国にあるんだろうか。
なんかこっちが心配してしまうｗ

北朝鮮にはウンチの絵文字をあげるよ

絵文字ad hocは決定事項の報告が主だから、あれを元に
Peterが中立だったというには無理があるんじゃないかなあ。

Oさんが独自のソース持っているのなら話は別だけど。

いつの間にか「祷」(第3水準の正字でなく第1水準の略字の方)と「穹」が人名用漢字に追加されてた。

蒼穹のうんたら

ここら辺の記号類もunicodeに入れてほしいなぁ。
手話シンボル http://www001.upp.so-net.ne.jp/wakan/Others/HandSignFont.html
ケアーマーク/リサイクルマーク http://gaiji.info/pictgram/6-pictogramfontdownload/11-caremarkfont.html
地図記号 http://gaiji.info/pictgram/6-pictogramfontdownload/13-2008-11-25-06-10-47.html
一般案内用図記号 http://gaiji.info/pictgram/6-pictogramfontdownload/12-2008-11-25-06-03-04.html
校正記号 http://www.erc-books.com/ERC/How/H2-List.html
交通標識 http://www.menkyo.ne.jp/menu/kiso/hyoshiki.html
電気記号 http://www.ne.jp/asahi/ja/asd/gijutu/zukigou/zukigou.htm

あと難しいかもしれないけどWebdings、Apple Symbolsあたりをunicodeに入れてほしいなぁ。

うるせえだまれ

すんません

>>123
Apple Symbolsって殆どUnicodeでそれ以外はAppleの私的な記号やん

標識類や回路図用の記号なんかは難しいらしい。

ttp://std.dkuug.dk/JTC1/SC2/WG2/docs/principles.html
の34ページ目以降に解説があるから興味があったらどぞ。

改正されたJISマークはどうなるんだろう。
というか、旧JISマーク（〄）は何をソースに入ったんだ？

まさかデザイン変更するとは予想してなかったんじゃね？　それよりも、かつてのJIS X 0213のドラフト案には

ベンゼン環

があったんだよ。そんなもの一体何に使うんだっていうの。

よくわからんが、化学式に使うんじゃねーの

有機化学系の書籍では普通に本文中に埋め込まれてる。

ベンゼン環はUnicodeには入ってるな。

ベンゼン環だけあったって何の役にも立たんのにといつも思う。

>>128
Adobe-Japan1-1じゃね?
新JISマーク取り込んだAdobe-Japan1-7まだー?

中途半端なぎじつしゃです。

各種プログラミング言語には文字列の判定処理でcharlenというものが用意されていますが
同じプログラミング言語でもHP-UXなどのUNIXとWindowsなどプラットフォームにより
返り値が違う文字コードがあるとききました。
具体的には　0x8240〜0x824e　などの機種依存エリアの判定です。

HP-UXでは　返り値＝１　　WIndowsでは　２　となるようです。

どこか技術文書などがあれば紹介いただきたいのですが・・

>>134
AJ1-7 は Unicode 5.2 の制定後になるのかな？
新JISマークが入るかどうかは知らんが

Unicodeとは連動していない気がする。1-6が出てからもう5年近く経つし。
どういうタイミングで更新しているんだろな。

>>135 マニュアル嫁

Adobe-Japan1の非漢字にはUnicodeに入ってないのいっぱいあるよな。
JASマークとか一部の組文字とか。
これらはUnicodeに入れないのかな?
漢字は大半がIVSで表せるし表せないもの(撥の拡張新字体など)は拡張CやDで追加されるみたいだけど。

JASマークは別に文章中で文字として使わないしなぁ・・・
まあそんなこと言い始めたらキリがないけど
というか、既に収録されているカタカナの組文字ってどういう基準で採用したんだろう？
http://www.unicode.org/charts/PDF/U3300.pdf

そういえば、BETA Unicode 5.2.0でてるね、みんな読んだ？
http://www.unicode.org/versions/beta.html

別スレにも書き込んでここで３度目なので、しつこいようですがよろしくお願いします


文の格納に必要なバイト数をJISコードの場合とシフトJISコードの場合のそれぞれで計算する問題なのですが、これはどうやって考えれば良いのですか？

漢字、カタカナ、英数字（半角）、記号で構成されている文です

曖昧な質問で申し訳ないのですが、ここでは課題の文を晒せないので、よろしくお願いします＞＜

>>142
あんた馬鹿?

ttp://charset.7jp.net/jis.html
ttp://charset.7jp.net/sjis.html

いまどき「JISコード」と教えてるとは感心できない学校もあるもんだ

問題のための問題だろう。
おそらくJISの決まり事とか問題文と一緒に書かれている。
スレ違いだな。

みんな冷たいな。

>>142
文の格納に必要なバイト数をJISコードの場合とシフトJISコードの場合のそれぞれで計算すればいいと思うよ。

>>147
ご親切にありがとうございます

計算とは、実際どのようにすれば良いのですか？
例文を挙げて説明して頂けると有難いです


こんなこと聞いてホントに申し訳ないです;;
実は大学の選択科目の課題なのですが、基礎知識ゼロで飛び込んでしまったので、問題文の意味すら分からず困り果てている状態です＞＜

＞＜

今回の皆既／金環日食はトカラ列島中心だけど
2012年5月にはほぼ日本全国で金環日食が見られるんです

>>148
友達を作るチャンスだろ
こんなとこ書き込んでないで周りと話せ

「JISコードの場合」ってのがわからん。
ISO-2022-JPのこと？

違うんじゃないかな

>>148
足し算だけでいけると思うよ
文を作って左から数えるだけ

You! ダブっちゃいなよ！

>>141

どうやらようやくヒエログリフが（＞＜）ノ

これでやっと画像ファイルなくせる

Amd.5と6の分か。
日本関連だと拡張漢字CとARIBかな。

>>157
Amd.6も収録されるのか。
win7のTVゴシックはPUAにARIB外字が入ってるけど、どうなるんだろ。
AJ1-7あたりにも入るんかな＞ARIB

最終的にはAmd.6で決まった符号位置に移動させるんだろうけど、
Unicode5.2とWin7のリリースがほぼ同時期なだけに、
タイミングが難しそう。

凄い初歩的な質問です。文字コードというよりエンディアンの質問になってしまいますが・・・
UNICODEのLEは
例えば、
23 43 23 12 34 35
と文字列が並んでいて、これをBEに変換するには
35 34 12 23 43 23となるのでしょうか？
それとも、それぞれ2バイトで文字列が切れるとして
34 35 23 12 23 43
ということなのでしょうか？
前者だとすると、最後までデータを読まないと、頭の文字がわからないという事ですよね？
でも、そういうわけでもなさそうですし。
後者だと、自分が学生の頃学んだ記憶によれば、LEとは言わずに、ミドルエンディアンと習った覚えがあります。
どちらなのでしょうか？

UNICODE って何？
UTF-16 とか、きちんと用語が使えるようになってからまた質問してね。

文字列はビッグエンディアン

ビッグトンチンカン

>>160
文字をBEで表現するかLEで表現するかの違いこそあれ、
文字が逆順に表現されるようなエンコーディングは存在しない。

>>148
質問の意図が分からないので、推測するけど、　JIS　＝＝　JIS X 0208でよいのかな？
マジスレすると、一言に漢字と言っても、JIS X 0208では6,355文字しか定義されていないので、
格納する文字列の中の漢字で、JISX0208に含まれない漢字（例：JISX０２１２等）
がある場合は切り替え命令が必要なので、その分必要なバイト数は増える。
半角カナ使用の場合も同様に切り替え命令の分必要なバイト数が増える。
例）"あ" == "<1b　24 42> 24 22 <1b 28　42>"
例）”aあああa”="61 <1b 24 42> 24 22 24 22 24 22 <1b 28 42> 61 0a"
例）"aあaあa"="61 <1b 24 42> 24 22 <1b 28 42> 61 <1b 24 42> 24 22 <1b 28 42> 61"
英数と言うのは、ASCIIと仮定して、記号もASCII規格のやつと仮定して、
基本的に英数と半角カナは1バイト、ひらがな、漢字は2バイト、その他は３バイトで計算（かなり大雑把だけど）
違う文字集合ごとに切り替える必要があり、その度に三バイト必要になる。
ただ、例外的に格納する文字列の始めがASCIIの場合、<1b 28 42>は必要なく、
新たに[現在の文字集合とは]別の文字集合にぶつかる度に三バイト必要になる。
また、文字列の最後の文字が属する文字集合がASCII以外である場合、<1b 28　42>を追加して
きちんと基本のASCII文字集合に切り替えて末端処理を行わないといけない。
当然、二つの文字列をつなぎ合わせる場合は、もし末端処理が不要（一つ目の文字列の最後の文字と、
2つ目の文字列の最初の文字が同じ文字集合に属し、かつASCII文字集合では無い）な場合、
末端処理として入れられた一つ目の文字列の最後の<1b 28　42>と二つ目の文字列の
最初の切り替え命令３バイトを取り除く必要がある。

粗悪なプログラムの場合、この辺の末端処理とか使われていないとか、切り替え命令の除去がされていないので、
注意する必要がある。
厳密には「文字集合」の意味は違うけど、多分質問者の教材ではそこまで深く掘り下げないと思うので

あと、追加（文字数大杉）。
各国（１９２ぐらい？）毎の使用符号化方式と言語一覧表探してるんだけどだれか持ってない？
とりあえず地味に20ヶ国ぐらいググってるんだが、マイナーな国の情報とか乗ってない…orz
例）　日本＝日本語、euc-jp,shift-jis,iso-2022-jp;みたいに。
アフガニスタンとか、Extended Arabic Lettersの前に元々使っていたコードページとか
ある筈なんだけど、だれかエロい人おしえて？

ここからたどれない？

ttp://www-01.ibm.com/software/globalization/expertise/index.jsp

MicrosoftだとCode Page Identifiersとか。
http://msdn.microsoft.com/en-us/library/dd317756(VS.85).aspx
ただ、実際にそこの国の人々がもっぱらどんな体系を使っているかは、
こういうのだとわかんないんだよね。
台湾のUAOとか最近まで知らなかったよ。

Historic Kanaって名称は邦訳が難しそう
Kana Supplementの方が汎用性もあるし好都合なんじゃないか

ほんとだよな。
それだったら「イ」と「エ」が合体したものや小書き「ヰ」「ヱ」「ヲ」や琉球語表記用の「て」と「ぃ」が合体したものなどの拡張仮名も入れることができるのに。

>>169
> Historic Kanaって名称は邦訳が難しそう
ん？「旧かな字」とかでいいんじゃない？とか素朴に思ってしまったんだけど……


あ、パンドラの続編が来たね。最終回は次回、らしい。
「絵文字が開いてしまった「パンドラの箱」第5回--絵文字と日本マンガの親密な関係」
http://japan.cnet.com/column/pers/media/story/0,2000058034,20398174,00.htm

今回は今ひとつだったなあ。
あんまりダブリン会議のこと引っ張ってると情勢変わるかもよ。
2〜4月と8〜10月は一番動きがある時期なんだから。

絵文字なんてエスケープシーケンスとかmixiみたく特定の文字列で対応すればいいだろうが。
こんなの認め始めたらキリがないって。

遅かれ早かれWEBにもあふれ出してきて、豆腐だらけになるんだろうな。

iPhoneでSMSを使ったときのセキュリティー問題で話題になった豆腐も、きっとなにかの絵文字だったんだろうな。

>>173
エンコーディングとキャラクタセットを混同している。

>>176
俺は絵文字をキャラクタセットに組み込んで欲しくないから、そうしろと言ってるんだけど。

画像を別に準備(gifでもjpgでも何でもいい)しておいて、表示時に画像を埋め込むようにすれば十分。

> 俺は絵文字をキャラクタセットに組み込んで欲しくないから

ごめん途中で送信しちゃった

> 俺は絵文字をキャラクタセットに組み込んで欲しくないから
その前提を最初に主張しないと後ろの意見だけ言っても伝わらないって。

笑える
http://japan.cnet.com/image/l/story_media/20398174/fig_5-8.jpg

アイルランド・ドイツ提案のやつ見てたらアイマスフォントを思い出した

>>180
これ直接行けないんだな。
http://japan.cnet.com/column/pers/media/story/0,2000058034,20398174-4,00.htm
の図８。

え？
直接行けたけどな。専ブラだから？

・アニメ風牛の顔
・牛の影絵
が包摂されるわけですね。

僕の書いたべか子ちゃんの顔アイコンも包摂されてしまうとしたら哀しいです

クジラの影絵を見てクジラって言い当てられたらすごい

動物の顔のマークを動物の全体像で置き換えちゃ
記号の意味が変わるというつっこみを受けて
結局分離することになりました…ってあたりを次にやって連載完結かな。

Old Hungarianはpunctuationすら一本化できないのか
本当もめるなあ

WG2 Meeting 55 って東京開催だけど、あれって一般人でも傍聴可？

JIPSEとJIPSJの違いを知りたい。

NECって昔から糞な会社の代表で、ここのせいで日本のITが立ち遅れたのは間違いない。
JALとともに、さっさとつぶれてほしい筆頭の会社だがね。

なんだおめーEかHかFかSの回しもんか

NECのお陰で日本のHentai文化が育った。
PC88のおかげで日本は世界一のFM音源大国になった。
PC98のおかげで日本のFDDの出荷率は2倍になった。

NECのおかげでJIS78がえんえん生き残った、ぐらいだよなぁ。
このスレの話題的に恨まれることと言えば。
それも、変えたほうが悪い、と言われるような規格だし。

FM音源の普及にはセガのおかげも大きいし、FDDについては単に98が
最大のシェアを持ってたからってだけで、特筆するようなものでもないと思う。

いや、PC98のFDDの出荷率2倍は皮肉でしょｗ
当時のPC98はメモリが少なく、HDDも一般的で無かった事から
何をするにも、FDDが2つ搭載されてないと困った。
なので2台搭載されてるのがデフォだったんだよ。


高性能なIBM PCやX68kを見て
「FDD１つしか搭載されてないじゃんｗ」ってPC98ユーザーが馬鹿にするジョークがあった。
これは、2つ搭載しないと性能的に駄目なPCって意味なんだけどね。

>194
> 高性能なIBM PCやX68kを見て
ここ笑うところですか？

Cドライブから始まるのは正直ダサいｗ

仮想FDドライブ懐かしい

X68kはＦＤＤ二台あったよ

当時の5インチFDの中身が読みたいんだが
USBのFDDとかで5インチって無いのか？

日本が海外の進行を食い止めたのは
漢字ROMをはじめとするハードウェアの日本語化の障壁があったからだと思う。
メモリが贅沢に積まれはじめて、ソフトウェアで実現出来るようになっても、
漢字Talkや超漢字みたいに、漢字対応を全面に出したOSが出るくらいだから、
やっぱり海外は日本語のフォント作りに苦心したんだろう。

なので、日本のITが遅れた主な元凶は、日本語にあると思う。
これが英語圏だったらそんな事はなかった。

逆に、漢字文化を持ってるからこそ、勝たなければ行けなかった分野で最近負けてるのが気がかり。
検索エンジンなんて、絶対に日本が勝たなければいけなかった分野なのに・・・。
はじめから分かち書きされてる英語圏に、先に様々な問題意識を持たれ、字句解析の技術も先行され・・・
本当に馬鹿な事をしてると思うよ。まぁ、日本は人工知能に偏った思い入れがあるから、いつまでたっても認知科学の分野から頭が離れなかったのも主原因にあると思う。
何十年焼き回し研究をやってるんだと言いたい。

研究費で食ってる香具師らにろくなのはおらんよ
理研ですら利権まみれだったからな

IBM 5550 には FDD 3台ついてたよ。

>>200
「日本語情報処理」を外人が書いちゃうような、そんな後進国だもの＜日本

NEC内部コードEとNEC内部コードJとかいう変態のコードとUTFの変換テーブルはどこかにありませんか？

質問が間違えた。
NEC漢字コード体系という変態から逃れたいんですがどうしたら良いでしょうか。
ヘンテコ汎用機で困るんです。

     固定機能を排除するにしても、固定機能の代替となるようもう一段ミドルウェアをかまさないとつらいからな

>>203
電子情報通信学会編「日本語情報処理」ってのもあるんだけどな。
日本人のやることは、日本人ってバカにするのが好きだからさw

>>207
それ内容はどうなの？入手方法は？

自然言語処理が日本で人気が出始めたのも、Googleが成功してからだもんな・・・。
NAISTの茶筅やMeCabやNamazuの開発者たちは、とっくにGoogleに持ってかれてるし。
気づくのおせえよ。

>>185
一瞬、秋刀魚かとおもたｗ

日本ってコンピュータ言語とか互換性を重視しているわりに、
携帯絵文字コードにみられる非互換で競争してしまう行動はどこからきてるんだろうか。
単に差別化するのが簡単とかそういう理由なんだろうか。

ポケベルの頃に絵文字がたくさん使える機種が売れたんです。
ドコモの若手チームの功績とする読み物がウェブにもありますよ。

プログラミング言語でも、いざ実装となると規格の踏み外しが多かったりとか、
日本企業製のプロダクトはそういう妙な非互換性をかかえてることが多い。

なにかをはじめるときに、既存のものをとりいれることをよしとしない変な
空気があるのか、なんなのか。
一旦非互換なものを作ると、顧客ロックインのためにしがみつく傾向もある。

世界的にも、コード共通化について意識したのは早かったのに、企業からの
参加者から縛られたくないだのなんだのの意見が多かった、と、コード会コードの
話にはあるよね。

>>211
日本人お得意の、改良をしたがるんだよ。

後は囲いこみ。

>日本ってコンピュータ言語とか互換性を重視しているわりに、

そもそもここがまちがい

確かに。どっちかというと自分の理解できないものを無視してあたかもなかったことにすることのほうが
多いような。

非互換で囲い込みってアフォだよな。
物理的に良いもので囲い込みとかのほうがよっぽどマシな結果になりそうだが、
それだけ競争が激しいということなんだろうか。

DoCoMoとか自民党とかのことを思えば。

競争が激しいのは客があほだから

非互換に関してひとつには世に出る迄に時間がかかりすぎるから。
そして世に出てしまうとしゃにむにそれにすがってしまうから。

つまり最初に決めて行けば良いのだが，「社内」＝「世の中」の人が
先に作り込みすぎてしまって方向転換が後ではできないから。

で、先に決めて行こうとすると「我れ先に足の引っ張り合い」をするので，うまくいかないと。

>>220
> 非互換に関して
< 標準化しないのは

だろ。言いたいのは。
それに先にきちんと標準化しても、非互換の派生は出るぞ。

売る側からすれば、ユーザ囲い込み機能を標準化してどうするんだよ・・・って感じだろ。
まあ、日本は欧米と違い、標準化の意識が薄いってのもあるけど。

ようするに日本って標準化するという作業工程が下手なんだよな。
競争が激しくて足の引っ張り合いが多いんだろうけど。

最終的にユーザ側の不利益になってしまうなら、
非競争分野は標準化してそれを厳守、それ以外の要素で競争するのが望ましいと思うが、

なし崩し的に物事を進めていく傾向が強いのか、
まぁビジネスだから儲けてナンボではあるんだよね。

俗流文化論的に分析してみる。

アメリカでは末端の能力が低いから、標準化をしなければやっていけない。
また、末端を束ねる立場にたつ人の能力には高いものが求められる。

日本では末端の能力が高いから、標準化なしでもなんとか出来てしまう。
また、能力の低いものが束ねる立場に立っても何とかなってしまうことが多い。

日本の消費者はメーカー/プロバイダ乗り換えを考えない、自分の選択肢を狭めることに何も躊躇が無い人が多いんだと思うよ。
だから囲い込みが成功しやすいのだと思う。
これは日本のメーカー/プロバイダの品質の高さから来たものだが、消費者が信者化し貶しあう文化が生まれ、標準化の圧力が生まれてないのだと思う。

日本人は単一民族だからな
みんなで力を合わせるのが苦手な人種
共通化の欲求よりも
足の引っ張り愛の
我田引水の圧力が勝ってしまう

>>171
遅レスだがアイルランド・ドイツ提案に交通標識と地図用記号ってw
>>122とか将棋の全コマとか花札全種とかパソコンで使われる汎用アイコン一式とか企業のロゴとか各名詞や各動詞に対する絵文字とか追加していったらキリが無くね?

杭全

携帯絵文字は日本文化が色濃く出ててるから、
どの辺まですくい取るかが問題なんだろうけど。

日本の消費者は、あの顔文字じゃぁ気に入らないだろうなｗ
携帯電話は、従来通りキャリアごとに異なる形状でOKなんだろうか。

UNICODEをシンプルに全部32bit文字としていれば、
絵文字ぐらい余った空間に簡単に置けれたのに。

一応65万文字分のコードポイントがあまっているとはいえ、
絵文字なんか入れたら足りなくなるかもな。

そーいう問題じゃないだろ。

世界標準は大事だと思うけど、
実際の形状を該当国・地域に強制するのは本当は良くないことなのではないか。
例えば顔文字で「スマイル」を意味するものがあったとして、
あくまでも受け手の問題なので、該当の国・地域で良い絵柄が選ばれるのが望ま
しいと思う。

実際に日本とその他の国または地域では表現上の好みの違いがあるわけで、
英語文化圏標準はこれ、日本文化圏標準はこれ、日本の九州地方はこれですと、
多段的なものであってもいいんでないの？

どの辺のドメインを区切るかというのはあるけど、わりに自由度があってしかる
べきものなのかもしれない。

世界標準なったら面白味の欠けるものになりそうなんだよな。

今議論している絵文字は、あくまで既存の製品に実装されているものだけだから。
新しい絵文字を作ろうって話じゃないから。
つーか複数言語混在できないようなシステムはダメだろう

>>233
アイルランド・ドイツ提案100回読み直せ

絵文字といえばPDAM8の投票が終わった頃だな。
さて米・愛蘭独あたりはどんなコメントを寄せたか…

文字として認識出るもの以外入れないで欲しいと常々思う。
外字って言うアイデアはシンプルで良かった。

ユニコードにも外字エリアあるよね。
昔ほど必要性がなくなったかも

いきなりで申し訳ないんだけど、ここの住人ならわかるかな？

AutoCADのデータを渡されたんだけど、そこに書いてある文字が

#F#R!%#6#6!!#S#E#C!%　←こんなの

この変な文字化けみたいな物をなんとかしろ！って言われたんだけど、
得たいの知らない記号みたいな物渡されても何がなんだか・・・

これが何なのか、また、どうやったら日本語として読めるのか、知恵を貸してほしいorz

JISコード (ISO-2022-JP) のシフトIN/シフトOUT (エスケープシーケンス) が抜けたやつじゃないか
バイナリエディタかなんかで前後にシフトIN/シフトOUTを付加してJISコード対応のエディタかWebブラウザで開いてみ

シフトIN、シフトOUTってなんだよ。
このスレの住人らしからぬ...

IN/OUTじゃなくてGOTOだ、ってその昔の和田先生のテキストにもあるだろうに。

0x1b(ESC) '$' 'B' という3バイトのシーケンスを先頭に。
0x1b(ESC) '(' 'B' という3バイトのシーケンスを末尾に。

その例だと "ＦＲ．６６　ＳＥＣ．" だね。

>>240
例を見てから、自分がわからないと言ってた文字を見てみると
「＃」抜かせば、ある程度わかるじゃん！って事に気づいた。

ＪＩＳコードって言うのかな？なんだか複雑そうで、正しい対処法はできないかもしれない。
内容量は多くないから、例を参考に睨めっこでもしながら修正していこうと思います。

「ド」がつく素人な者で、アドバイスを生かしきれなくて申し訳ないのですが、
どうもありがとうございます！

>>241
こんなページを見つけたよ。
http://masaka.dw.land.to/mr/jmr.php

ここで、解読できるみたいだよ。

絵文字提案に関係のある国は全部PDAM8に反対ですかそうですか。
N3681は前とどこが変わったのか分からんなあ。Oさんあたりが連載で書いてくれるかな。

絵文字に便乗して、各国記号類の追加提案をしまくってるな…

もうUNICODEに、国コード＋その国用文字 というコードポイント作れよｗ
何万文字かを国ごとに割り当て、その国で自由に使い方を決める。

てらISO 2022w

絵文字の話が出ていたと思うけど、これは自然に出た発想だと思うよ
英語圏のサイトにあるチャットには大体絵文字がついてたりするし、日本一国の携帯にクローズアップしてるような印象を与えたのはマスコミに責任があるかなあ

だって実際日本一国の携帯に対応するために提案されたんだし。

UNICODEって合成文字って概念があるでしょ？
日本語なら、「は」と「゛」で「ば」とか
ウムラウトとかなんとかいうの。

それを拡張して、たとえば、32ドット×32ドットの格子の
升目一個を塗りつぶした形を合成文字にして
合成文字を複数組み合わせて、絵を作るという発想

デメリットをよりもメリットがあるのか？それ

犬＋首輪＝首輪を付けた犬
こんな合成文字でプレインテキスト書きたいです

犬+首輪+横向き+吠える+擬人化 の絵文字ください。

 |+-夕胃ノしよ"ぁぃハ合成文字っつーかまmどくせ

>>252
人狼ですね、判ります。

狼+林檎+横向き+萌える+擬人化 の絵文字ください。

ある意味で当事者とも言える、キャリアの人が書いた文書。

世界のケータイ事情「ケータイ絵文字がグローバルに」
http://k-tai.impress.co.jp/docs/column/worldstrend/20090930_318157.html

鬼と天狗はさすがに日本も「せめて名前にJapaneseをつけろ」とツッコミ入れてたっけ

絵文字より「.日本」をどうにかしろよと思う
レイヤー違う話だけど

窓の杜 - 【NEWS】マイクロソフト、Windows 7のMS系フォントをXP互換に戻すパッケージを公開

ttp://www.forest.impress.co.jp/docs/news/20091001_318719.html

ﾜﾗﾀ

>>259
TrueTypeやOpenTypeって字形やglyphを選ぶ機能持ってるのに、これフォントごと入れ替えてるの？
字形選択機能に対応してるアプリはそのままで良いし、そうでない物はフォントレンダラに対して
デフォールトの字形を設定する手段を提供すれば良いと思うんだけど...

レンダラで処理されるサイズではなくて内蔵ビットマップを使うサイズのグリフの問題だから、だと思う。

ttp://www.microsoft.com/japan/powerpro/TF/column/ro2_01_3.mspx
<< MS UIゴシック / MS P ゴシックの変更 >>

こんな話も。

WindowsはIVSに対応しないんだろうか…

IVSってなんのこと？

異字体セレクタ

ふーん。初めて聞いた。

だっせ

おっくれてる〜

>>108
Amd.2で修正される前の話。知る限りこの時点では誰も指摘してなかった。
http://academy6.2ch.net/test/read.cgi/gengo/1040929046/170
USIを最初に指摘したのもやっぱりAmd.7よりはるか大昔(2chじゃないけど)。
> それでも足りないのがある？
USIを含んだJIS X 0213非漢字のExtended Collection

UTS #37の公開レビューだって最初の締め切り直前に某所でコメントするまで
日本じゃ全くといっていいほど話題になってなかった。

Unicode 5.2.0 リリース
http://www.unicode.org/versions/Unicode5.2.0/
今回もちゃんとレビューコメントは反映されてた。
「個別に返事しない」と言っているにもかかわらず返事くれたし

age

>>269
数年チェックしてなかったけど、Ext.C収録されたのね。ずいぶん数減ったなぁ。
昔は面をまるごと使いかねないくらい大量にあった気がする。

>>269
Windows版はどこでダウンロードするの？

>>272

ステレオタイプというか典型的な質問に、全力でワロタｗ

http://mainichi.jp/select/today/news/20091008k0000m030036000c.html
文字コードはどうすんだろう。

そりゃ、名前の正式な表記が今やっと分かったって話で、
新しいハングルや漢字が生まれたわけじゃない。既存のでOK。

275が言ってるのは、北朝鮮の文字コード規格KPS 9566のことだと思われ。

当然、また新たに3文字が追加されるんだろうw

>>275 のは U+C6B4 → U+C740 という話。

北朝鮮でもUNICODE使ってるのか
南朝鮮のと同じじゃだめなん？

N3684は各国いろんなこと言ってるけど、要求が衝突してるのは
やっぱり例の国旗用互換文字か。
こりゃ東京でもad-hoc、下手すりゃPDAM 8.2コースか。

しかし日本もこの機会に入れたい記号類、何かないのかね。

ぜんぜん日本語と関係ないけど、電源スイッチの記号は入らないのかねえ
上が切れた○に棒が刺さってるようなやつ

こんな顔だったかい?
□□□■□□□
□■□■□■□
■□□■□□■
■□□□□□■
■□□□□□■
■□□□□□■
■□□□□□■
□■■■■■□

メニューキーもきぼん
■■■■■■■■□□□□
■□□□□□□■□□□□
■□■■■■□■□□□□
■□□□□□□■□□□□
■■■■■■■■□□□□
■■□□□□■■■■□□
■■■■■■■■■□□□
■□□□□□□■□□■□
■□■■■■□■□□□■
■□□□□□□■□□□□
■□■■■■□■□□□□
■□□□□□□■□□□□
■■■■■■■■□□□□

文字コードのことわかってないおとこ大杉。。。

良くわからないけど、結局、全世界の文字を集めたら32ビットでたりそうなの？

最近絵文字が流行り出したから32bit空間は枯渇したらしい

ここいらで絵文字が絵なのか文字なのかはっきりさせとくべき
ちなみに俺は絵文字は絵であって文字コードに入れるのはナンセンスだと思ってる

Unicodeの空間は21bitsですよ

21bitあれば210万近く文字使えるんだから
10万文字ぐらい絵文字にくれてやっても良いじゃないか？

だがことわる

21bit全部に文字が割り当てられるわけじゃなくて、実際に定義or予約されているのは110万程度。
10万は面をまたぐことになるのでアレだけど、1面丸ごとpictgramsに割り当てるのはアリかもね。

何か基準がないとなしくずしに絵文字！絵文字！絵文字！

今回限りにしてくれるんなら多少こういう妙なものが入ってるのも
おもしろいかなあと思うけど、
このまま今後ずるずるとこういうものが入り始めるのは御免こうむりたい

絵文字を入れるのは変体仮名と平仮名・片仮名の合字すべてを入れてからにしてくれよ。
そっちの方が先だろうが。

n3695渋いねえ。簡体字って歴史浅いくせにもう廃止された字があるのか。
しかしよくこんなの見つけてくるわホント。

ユニコードの体系変わったら
OS側も合わせなきゃ意味ないよね？
フォントとかも

>>295
1935年の第一批簡体字、シンガポールで使われていた簡体字、それと二簡字か。
二簡字はわりと有名だけど、1935年の第一批簡体字の方は見たことなかった。
ソースのスキャンが欲しいな。

ってPDFの後ろに画像ついてたわ。俺あほす

将来、漢字みたいに使う絵文字だけの言語もできるかもしれんしな。ないけど

象形文字とか、古代の文字はそんな感じじゃね？

文字の退化。

脳の退化

中国のナシ族のトンパ（巫師）が使う文字は、
一応現役の象形文字だろうね

よし、ここで俺が、
数式文字と音符をUnicodeに含めることを提案する！

♪

>>305
ちげーよ。

音階ごとだよ。

じゃあ聞くが、音階ごとだと何個必要なんだ？

たしか全角で911とかをwindingsで表示すると

911って緊急通報用電話番号か？

>>307
しらね。

楽譜で表せる程度なんだから
たいした数じゃないだろ？

>>310
数えてみろよ
たいした数じゃないんだろ？

まあまあ、楽譜って世界共通だという印象だけど、
それが入っていないってのはなんか不思議な感じがする。
アナログ的なものだからあんまりコンピュータと同時に利用する場面がないのかしら。

音符はもうあったはず

だから具体的に音階ごとだと何種類入れればいいと思ってんだ？
それに、例えば32ｘ32程度のドットで表現できる？64でもいいよ？
ていうか、楽譜みたことあんの？

音階について詳しく知らないのだが、
もしかして低音と高音ともに限界のない表現方法だったりするの？

まぁ普段の生活で必要な程度の記号の範囲で良いとおもうけどね。

人間の可聴範囲でも20,000Hzなんだから
1Hzに1文字割り当てたとしても、
2万個もいかんだろ？たったこんだけ。

文字コードはあくまで文字コードであって
グリフは規定されて無いから、32×32ドットといわれても意味が無い。

使わない文字に２万も浪費するって時点でフォント屋がキレそうだが
楽譜でふつうに使われる和音と長さ、連符休符など組み合わせるとウンザリするな

>>317
素直に負けをみとめろよｗ

楽譜ってそんなに体系化されてないだろ
人によっても色々書き方違うし
だからってITの分野とちがって標準化すればいいってもんでもないしな
普通に記号だけでいいと思うよ

音階が欲しいって言ってんじゃん。

まぁ、あれだ。
単一の記号で表現できるものと、できないものがあるから、
文字コードとして適正のあるものと無いものがあるというところかな。

なんだこいつ

>>323
ふぁびょるなよw
もうちっと楽しませろクズw

「五線譜とその第一線上の四分音符」なんてのは
音楽系の平文に埋め込まれた利用例あるだろな。

そういうのはXMLの仕事だったはずでしょ。

携帯絵文字が入って、化学記号や数式記号が入らない理由が見つからない。

♪ とか♪とか欲しい
￣　　　・

>>328
文字化けしたらスマン
𝅘𝅥𝅮𝅽 U+1D160 + U+1D17D
𝅘𝅥𝅮𝅭 U+1D160 + U+1D16D

一度でもまともに楽譜を見たことがあるなら、音階ごとに四分音符を並べるだけのものなんて無意味に近いと判りそうなもんだが。
MusixTexのマニュアルとか読んでみろよ。

コルトレーンとかもうね...
http://www.youtube.com/watch?v=2kotK9FNEYU

phpからPEARのMail.phpを使用してWeb上から
ソフトバンクのケータイに日本語のメールを送信すると
文字化け？してるのかわかりませんが日本語の部分が表示されません。

ソフトバンクのケータイはutf-8じゃないといけないとどっかのサイトで見つけたので
mb_language("ja");
mb_internal_encoding("UTF-8");
mb_convert_encoding($Message,"UTF-8","auto");
のように変換を行ったのですが、うまく変換されてないのか成功しません。

変換ができてないのか、それとも文字コードの指定事態が間違ってるかすらも検討がつかなくて
どーすればいいかわからない状況です。

>>321
音階にも種類があるでよ？

12平均律だけならいいけど、31とか53平均律なんてものも世界には存在してだな

まだやんの？その話

>>332
webprog板だかで聞くべし

絵文字は文字で（絵じゃない）、音符は絵の一種に見える（文字でも記号でもない）俺は異端かなぁ……

敢えて言おう。音符を入れるくらいなら気象記号を入れてみろ。
どちらも手書きであるが故の美しさがあると言う点で、絵のようなものだ。

地図記号が絵文字関連で幾つか入るようだから、天気図記号が入っても悪くはないはず。

ただ、こういうのってXMLとかでの実用が前提じゃなかったっけ？知らんけど。

国ごとに微妙に違うからなあ

>>338
手書き故の美しさを言い出したら、
文字全部そうじゃね？

地図記号って、おまんじゅう工場も入るのか？

おまん工場

シフトJISの外字領域とMS932の外字領域のコード範囲は同じなのでしょうか？

JISのシフトJISに外字領域は無い。

>>47
CJKV Information Processing の２版がgoogleブックに登場してた。
Ebook Release: June 2009
この時期に登場したのか？

ttp://books.google.co.jp/books?id=SA92uQqTB-AC
ttp://oreilly.com/catalog/9780596514471/preview

最近更新がないと思ったら、小形さんこんなの準備してたんだ。
とうとう単なる傍観者じゃいられなくなりましたか。
しかし来週はこりゃ絵文字の議論だけで終わりそうな勢いだ。

http://www.otacky.jp/files/oald7/oald7-pkg.el
ここのページにある記号を自作プログラムで扱いたいんですけど、
firefoxでutf-8で記号が読めるので
テキスト文書を(IE8)でutf-8にして文書全部をコピーして
貼り付けて見たところ数割くらいが？マークになってしまいます．
utf-8って複数あるんでしょうか？どうやったら保存できるんでしょうか．
osはvistaです．

どこに貼り付けたんだ？
貼り付けた先のアプリケーションがUnicodeに対応していないのでは？

テキスト文書utf8_1.txtというファイルを作って貼り付けたんですけど
クリップボード他入出力がダメなんでしょうか

すいません、
ブラウザからそのファイルへのリンクを右クリックしてとりあえず
情報が失われないように保存は出来たんで、また自分で
色々やってみますお騒がせしました

あれで参加者の反発を買わないよう配慮したつもりなのか…

>>347
顔文字ジェネレータ面白いなw
http://fonts.jp/emoji/images/00.02.05.23.26.27.png
http://fonts.jp/emoji/images/00.02.04.25.34.png
無理とは分かっていても合字グリフの方向へ持ってって欲しいなと感じてしまったw

http://fonts.jp/emoji/images/00.02.16.23.33.png
http://fonts.jp/emoji/images/00.02.05.25.26.32.png
http://fonts.jp/emoji/images/00.02.03.16.32.png
http://fonts.jp/emoji/images/00.02.08.23.34.png
http://fonts.jp/emoji/images/00.02.15.19.33.png

顔だけじゃなくて胴体も入れようぜ→それなんてサウスパークジェネレーター?

PSOのシンボルチャットを連想したのは私だけではないはずだ。

グリフ変更というeditorialな部分は通ったけど
その他のtechnicalな部分は全部預かられてしまったと

んーどうだろ、一応顔は立ててもらえたようだけど

>>356
確かにPSOのシンボルチャットっぽいｗ

EUCもSJISもJISも面倒見てくれるktermが、UTF-8以外は排除するxtermに駆逐されたのは納得いかない

javaでWindows31-J⇔Unicodeの変換で、外字領域を含めて変換できない文字はあるのでしょうか？

バージョンによっても違うからここ読め
http://www.ingrid.org/java/i18n/encoding/

>>361
お答えありがとうございます。
Java5なのですが、のっていなかったです。
Shift-JISでいうところの外字領域は対応しているのは実際に確認しました。
変換に失敗するとまずいので、保障が欲しいのです。
また、変換できない文字があれば事前にチェックをしたいので、変換できない文字を知りたいのです。

全部変換してみりゃいいだろう

>>362
想定する文字セットが提示されていれば、
その中で変換できない文字を調べられるけど
漠然と変換できない文字って言われてもな……

Windows 31Jってデーヴァナーガリー文字とかも含んでるの?

Windows31JからUnicodeに行って戻ってこれれば十分なのか
⇔記号の見た目通り相互変換を意味しているのか

Windows3.1Jってまた懐かしいなｗ

>>365
ないよ。要はシフトJISだし。

外字ありだぜ？

>>367
3.1・・・ってまさか・・・


勘違いしてる気がするｗ

OS（XP）の外字エディターで、U+21336の文字（土並）を参照表示させる事は可能？

外字エディタってそういう風に使うものなの？

単？

>>372
Windowsの外字エディタは字形の原形として既存のフォントからグリフを読み込んで
そのビットマップをちょこちょこいじって外字を作ることができるんですよ。読み込み
インタフェースがBMPの符号位置しか選択できないように見えるので、何かSIPの
文字を読む方法ない?っていう相談なんじゃないかな。

>>371
Windows XP SP2しか手元にないけど、SimSun (FounderExtended)から
SIPの漢字を読み取る方法はわかんなかった。MS-IMEの「文字一覧」もそう
だけど、どうもこれの設計はcp932とBMPだけで完結しちゃってる気がする。

この漢字はHKSCSにも入っているようなので、HKSCS対応のフォントだと
強引にBMPのどっかの符号位置にマップしてたりしませんかねえ。。。

>>374
＞既存のフォントからグリフを読み込んで
なるほど、知らなかった。ありがとう。

>>371
374の言う通り、HKSCS対応のフォントでU+EB00に[土並]があった。
フォント名で言えばMingLiU_HKSCSとかDfSongStdとかMing(ISO 10646)とか。

Oさん意気揚々ですな

>>374>>375
thx
試してみます

UTF-8をSHIFT-JISに変換するコードどこかないでしょうか？
iconv UNIX,LINUX系統以外


C/C++
Windows VC++ 環境で

MultiByteToWideChar()
WideCharToMultiByte()

自分で書けばええやん

>>378
http://pc12.2ch.net/test/read.cgi/tech/1214657360/715
メモリ解放は自分でやれ

Win7では異体字セレクタ対応してた。
対応フォントは付いてないけどY.Ozフォント入れてメモ帳とOpenOfficeで出来た。
モンゴル文字や数学記号のBMPの異体字セレクタを使ったものは使えるかどうか知らんが、とりあえずU+E0100〜の漢字用異体字セレクタは使えるみたい。

fdam8の1F61Dはこういうデザインなのかはたまたゴミが混じっているのか…

fdam8じゃないやfpdam8だった

>>383
見てみた。ﾜﾗﾀ

毛が抜けてｼｮﾎﾞｰﾝな波平

unicode対応でWindowsプログラムを作成しているのですが、
英語以外、日本語やアラビア語などすべての文字が使える
フォントを教えてください。

ない。

フォント作成の会社に問い合わせればいいんじゃない？

ttf/otfの仕様上、全部込みのフォントを作ること自体無理。
ただ漢字以外全部なら作れるかもしれない。

まずはArial Unicode MSから。

code2000でも使っておけ

失礼致します。

現在、「Unicode」に収録されていない「GB18030」の文字を調査しております。
調べた結果ではチベット語や康熙字典、少数民族で使われている特殊漢字が
未収録らしいとうことしかわからず、具体的な文字と文字コードを見つる
ことができませんでした。

未収録の具体的な文字とそのGB18030の文字コードを1文字でもいいので知りたいのです。
ご存知の方がおりましたらどうかご教授して頂けないでしょうか。

中国人にでも聞けば？

Adobeの中の人あたりとかが知ってそうだな。
小形さんあたりに知ってそうな人紹介してください、って頼めば、教えてもらえるんじゃないか？

なーんか、ろくすっぽ英語も中国語も読まない上に、
ネットで漁ることだけを「調べる」と言い切ってる某ブログの人みたいだな。。。。

OPACで関連文献がありそうな図書館に足を運んだり、または
赤坂の日本規格協会の海外規格ライブラリとかはちゃんと調べたの？

>>393
全部入ってるだろ。

>>393
http://www.google.co.jp/search?hl=ja&lr=&num=50&q=gb18030+%E4%B8%80%E8%A6%A7
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1010865940
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1210910707
よくわかんないけど2番目のマッピングテーブル見て3番目のフォント調べればあるんじゃないの？

それはテーブルもフォントも2000年版ベースだな。
いずれにせよ全部Unicodeに入ってるだろ。

>>393
もしかしてGBKの
A98A→到底漢字には見えない点々の集まり
FE5D→常の冠の部分チョンチョンチョンみっつ
とかの文字の事じゃない？
GBKでは未定義だけどGB18030では全ての文字がUnicodeで定義されているよ(A98A→U2FF0のように)

393です。

皆様方ご教授下さり有難うございます。
396さんの仰るとおりネット上で調べただけであり、文献など
そのようなものがあったことをを全く知らずお恥ずかしい限りです。
GB18030は全ての文字がUnicodeで定義されているのですね。
調べた上で分かったといっていた内容は古い情報だったのでしょうか。

長々と失礼しました。改めまして、皆様方有難うございました。

シフトJISのGB2312版（シフトGB？）みたいなコードセットってあるの？

安岡センセのあれはつまりGoogle以外はBMPしか通らないってことなのかな。

ttp://ja.wikipedia.org/wiki/UTF-8#.E3.82.A8.E3.83.B3.E3.82.B3.E3.83.BC.E3.83.89.E4.BD.93.E7.B3.BB
1B U+0000...U+007F 0xxxxxxx (00-7f) 07bit
2B U+0080...U+07FF 110yyyyx 10xxxxxx (c0-df)(80-bf) 11bit
3B U+0800...U+7FFF 1110yyyy 10yxxxxx 10xxxxxx (e0-ef)(80-bf)(80-bf) 16bit
4B U+10000...U+1FFFFF 11110yyy 10yyxxxx 10xxxxxx 10xxxxxx (f0-f7)(80-bf)(80-bf)(80-bf) 21bit
だと。

>>402
高電社の日中翻訳ソフトとかは、Windows 98時代までは
GB 2312 をShift_JIS流にして日本語Windowsで無理やり中国語を使ってたね。

>>405
てことは、中国語版MS-DOSやWindowsでは、GB18030以前ないしUnicode以前は
ふつうはEUC-CN使ってたの？

なぜ「てことは」になるのかわからん。
Shift_JIS流だとあるのに、なぜEUC-CN?

>>406
こんな低レベルな質問をする人が402だったなんてショックです。
てかコードページも知らないで>>402の質問をする本意はなんなんだ？

MS-DOS 5.0〜WindowsXPまでのコードページ
ttp://msdn.microsoft.com/en-us/goglobal/cc563921.aspx
Supported Code Pages （コードページなしは変換）
ttp://msdn.microsoft.com/en-us/library/aa288104(VS.71).aspx
Code Pages Supported by Windows （コード表）
ttp://msdn.microsoft.com/en-us/goglobal/bb964654.aspx

>>405
Shift_JIS流って、
Shift_JISのJIS X 0201 kanaに相当する部分は何が入っていたの?

うるさいな

そういえば、常用漢字表が2010年に改訂するって小耳に挟んだんですが、
具体的に困ることってあるんですか？

つ http://itpro.nikkeibp.co.jp/article/COLUMN/20091209/341831/

この記事わかりずらいですね。だれか簡単に翻訳してｗ

ならば、君には関係の無い話なんだよ

要約:「常用漢字にシフトJIS範囲外の文字が入る。困った」

そんな文字使わなきゃいいんだけど、常用漢字に入ると名前に使えるよ
うになるので人名を扱うシステムでは将来困るね。

無知で申し訳ないけど、
常用漢字という定義は、公共なシステムで例えば住民基本台帳とかそういうので
サポートされるという意味になるの？

違う
プログラム的にはまったく関係が無い

>どうしても「??」がサポートできそうにないなら、その旨を文化審議会国語分科会に陳情する、という手も残されている。

何で一OSメーカーの怠慢を文化審議会が肩代わりしないといけないんだよ。

上の引用文中にある
??　は　��

「XPのメモ帳はサロゲートペアを2つの文字として扱ってしまう」というのが
何のことかよく分からん。
今XP sp3のメモ帳で試してみたけど、ちゃんと1文字扱いされてる。

>>419
常用漢字表の標準字体に、
使われてないタイプを採用する文化審議会がおかしい。

>>421 確かにXPはサロゲートペアにはだいぶ前から対応してた気がするな。

>>423
確かに気がしますね。

MSはサロゲート対応早かったよ
XP+Word 2000という組み合わせでもサロゲートペアの文字が使えてた

Surrogate Support in Microsoft Products
ttp://unicode.org/iuc/iuc18/papers/a8.ppt

ソフトによって、消すとき二回消さないといけないとか、あったかも。

unicodeの表示処理は、uniscribe(usp10.dll)経由だから、
バージョンアップで合字とかも対応できたりする。
ttp://ja.wikipedia.org/wiki/Uniscribe
ttp://charset.info/surrogate.html

関係ないけど、改定常用漢字表の記事その２
ttp://internet.watch.impress.co.jp/docs/column/jouyou/20091217_336436.html

文章を書く時に、常用漢字表という枠組みを意識している人って
どれぐらいいるんだろうね。

役人、新聞編集、教科書ライター、学校職員

Unicodeのメジャーバージョンアップに、10646の改訂に、
Shift_JISでは扱えない字を含む常用漢字表。

来年は色んな点において節目の年になりそうだ。

大抵のかな漢字変換ソフトには常用漢字や学年別学習漢字での制限があるしな。

バックエンド（DBなど）は、http://ja.wikipedia.org/wiki/Shift_JIS-2004
みたいな拡張エンコードも採用されてるけど、フロントエンドは互換性の問題でないよな。


叱のﾛ七ってUnicodeでなんで別コードになったんだっけ？
ttp://homepage.mac.com/ogwata/.Public/0213_2004add.pdf

Unicodeが既存の互換用以外1文字1コードから1字形1コード認める方針変わって
例示の変更後、Unicodeに申請したんだっけ？

JIS X 0213:2004 のほうが後なの？

Extension B（Unicode 3.1）は2001年。
20B9Fは康煕字典ソースで53F1とはnon-cognate。

他人の空似なのか。やっぱり無理筋だ。

>>426
この記事、パソコンから携帯へはどういう設定で送ったんだろ。
utf-8で送信されたメールなら、携帯のベンダ側で例の文字だけ
JIS X 0208の範囲に押し込む手もあると思うけど。

絵文字の場合は送信側のサーバで一括変換してるけど、
Unicode対応は機種によって違うから、サーバで変換しちゃまずいだろ。

>>435
> utf-8で送信されたメールなら、携帯のベンダ側で例の文字だけ
> JIS X 0208の範囲に押し込む手もあると思うけど。

似た字に変換しちゃえって事?

携帯に限って言えば、キャリア側で勝手に包摂しちゃえばいいんじゃないの
わざわざ常用漢字表の側で配慮すべきだとは思わない

>>438
包摂で済むなら苦労しないし、できるんだったら第2水準を作る時点で新字旧字にそれぞれ別コードを与えない。

「常用漢字表と字体が違うYO!」　と言ってくる人が必ず出てくる。
今後>>438が「常用漢字お客様相談センター」の窓口を一手に引き受けてくれるのであれば別だが。

「口匕」と「口七」は元来別字だったからややこしい。現代文では両方とも「シカる」の意味で使う。
本当に字形の差の問題だけだったら、Unicodeでは中国の字体と統合されている「将」や「直」の方が問題だろう。

CJK統合の問題は言っても始まらない、というか終わっちゃう、というかw

俺は生粋の日本人だけど、日本と朝鮮と越南が中国領になれば解決するアルよ。

visciiを巻き込まないで

今回のパブコメは募集要領でわざわざ
>今回は，「「新常用漢字表（仮称）」に関する試案」からの変更点に関連する御意見を中心に
と断っているから、out of scopeではねられるものが大量に出る予感。

cnetの絵文字の話は越年か…

文字コードじゃなくてフォントの話なんだけど、
「礫」をMS明朝の16ポイントで表示させると旁の「白」が「自」になるのに気づいた。

これって有名？

そのくらいの省略(ヒンティングでかもしれんが)はいくらでもあるんじゃないか?

いや、画数が足りないならともかく、多いんだからバグだろ。

まったく、フォント作成までもが中国に丸投げかよ

16以外は大きくても小さくても白だなｗ

16ポイント埋め込みビットマップのみの問題か。
こんな名前にもポスターにも使わそうにない漢字良く気づいたな。

礫は砂礫・礫岩の礫か。
あとは、東京都文京区小石川は礫川とも書く。

みんなレスありがとう
手書き認識で別の字を書いたときに旁の変な「礫」が出てきて、
あれこんな字あったっけ？ みたいな。

8ポイントの「預」が「矛頁」になるのは比較的有名だと思うんだけど、
これは最初の発見者になれたかなｗ

文字コード界隈もついったーばやりだなぁ。

Twitterといえば、Webインターフェイスからつぶやくと、
サロゲートペアはキッチリ2文字としてカウントしてくれるせいで140字打てない
Twitpicってutf-8を文字境界ではないところで切っているせいで
よく文字化けをおこしている
まあたとえサロゲートペアを1文字としてカウントしたり、utf-8を文字境界で切ったとしても
結合文字の問題もあるんだけどね。

結合文字はちゃんとやろうとするとテーブルが要るから
処理を端折りたくなる気持ちは分かるけど、サロゲートはちゃんとやってほしいな。

16進数で3xが0-9まで数xになる文字コードってなに？

ASCII

＾＾ｂ

当方はXP SP3でMSのJIS2004フォントを適用した環境です。

ATOK2009の「文字パレット」でフォントに「MS 明朝」を指定して漢字検索する時、
以前は一部のサロゲートペア文字も検索結果で正常表示されていたのに
今回検索したら「・・」表示になってしまってました。（例：>371の「土並」とか）
これは他のフォントに変更しても同じ

またサロゲートペア以外に「・」表示になってしまった文字も多数。（例：U+50F7の「イ葉」とか）
但しコチラは「Tahoma」や「MS Sans Serif」に変更すると表示されました。

JIS2004フォントを削除して再インストールしても直りませんでした。

この現象を解決する方法、何方かご存じでしょうか？

エディタやブラウザでMS 明朝の該当グリフが表示されるかどうかを試してみて、
ATOKの問題かOSのフォント認識の問題か切り分ける。

>461
エディタやブラウザでも「・」や「・・」で表示されるのでOSのフォント認識の問題と思われます。
念の為、IME2002に切り替えて確認しましたが同じでした。

文字コードについて誤った情報が掲載されているPDFを探しています。
なかなか見つけられないので協力してください。

なぜPDF？

PDFと指定されたからです。
何が誤っているかも分らない分野で、明日までに提出と言われたので困り果てていました。
ここの方なら分るかと思い質問しました。

>文字コードについて誤った情報が掲載されているPDF

この条件だけでいいんだったら、

1　嘘の記事をメモ帳なりワードなりで自作して
2　Bullzip PDF Printer などでPDF化

で簡単に作れるべ

http://www.google.co.jp/search?q=文字コード+filetype%3Apdf
こんなかから、うそっぽいのをさがせ。

あやしいのだらけだが、こいつはそうとうにあやしい。

ネット時代の必修科目、文字コードの謎をひも解く
ファイルタイプ: PDF/Adobe Acrobat
図3 ASCIIは1バイトの半角文字を扱うための文字コード体系。JISとシフトJISは2バイトで日本語を扱うために開発された。EUCは日本語版のほか、 ... 図2 大抵の文字化けは文字コードの設定を切り替えることで対処できる。IE7では「ページ」→「エ ...
pc.nikkeibp.co.jp/pc/npcs/pdf/071022/tokushu1.pdf -

>466
自分で作るのも考えたんですが、
それらしいものを作る自信がなくて諦めていました。

>467
ちょっと見てきますありがとう。

>468
これも見てみます。ありがとう。

「漢字は2バイト」とあり、それがUnicodeの文脈で、
にもかかわらずエンコーディング方法に言及してないとかなー。

半角カナは1バイト、とかも似たような(EUC-JPだと…)

そりゃnikkeibpだもん
仕方ないよ

>>470
あんた赤点決定ね。

>471がよくわかりません。
詳しく教えてください。

ちょっとは自分で調べましたみたいな姿勢を見せないでただ質問するだけって嫌われるよ。

数年後日本の開発者は文字コードの乱立を知らない世代ばかりになって
ますますソフト業界は世界から立ち遅れると思われ

欧米か！

>>476
オライリーのCJK本の事を思い出してしまった

>>476
IMEの開発を朝鮮に丸投げしてるからなぁ

ttp://www.amazon.co.jp/dp/4873111080

むしろShift_JIS的発想から抜け出せないことの方が、立ち後れの原因になりかねない。
一行あたりの文字数をバイト数から算出しようとするような。

某有名国産テキストエディタが、合成文字をちゃんと表示できるようになるのはいつの事だか…

固定ピッチフォントでは全角は2倍の幅という慣習も、今後どうなるんだろう？

そら、「全角」は「半角」の倍の幅に決まってますがな。

画面上では2倍だが、ドットプリンタの世界では全角は半角の1.5倍だったけどな

Windows 7だとUnicode 5.2で追加された字のUnicodeのSMP(第1面)の文字が表示出来ず・・になってしまう。
MS-IMEやATOKの文字パレットを見るとUnicode 5.1で未定義だったSMPのコードポイントがそうなってる。
これらだけでなく第15、第16面の私用面も全部・・だった。BMPやSIP(第2面)はそうでなかった。現在文字が全く定義されてない第3〜13面はどうか知らない。
なんでこうなってしまったんだ?Vista以前では表示出来たのだが。
ちなみにUnicode 5.2の文字を含んだフォントは和田研細丸ゴシック2004ARIB(ARIB外字を含んでいる)がある。
他には古代文字などを収録しているフリーフォントがいくつかあって、中にはUnicode未定義の文字のために15面の私用面を使ってるのもあった。
これらが普及する前に早く修正パッチ出てほしいもんだ。

>>462
コントロールパネル-地域と言語のオプション-[言語]タブで
「複合文字や右から左方向に書く言語 (タイ語を含む) のファイルをインストールする」
にチェック。
レジストリを直接いじる方法もあるようだけどたぶんこれが一番簡単

いずれ絵文字もAdobeJapanに収録されるのかな。
AJの採集基準ってどうなってんだろ。

基本的には国家規格の文字を収録してるだけだよ
ただ日本に限ってはそれだけでは使いものにならないというだけ

結局、絵文字にまつわるUnicode改訂ってどうなったん？

すぐに巷に流れたらメシの種がなくなるじゃねえか

そか、じゃあもうちょっと待ってみる

絵文字を含むAMD8は3回中2回目の投票中。後はこれに各国が意見を言って、
4月の会議で摺り合わせして終わり。
絵文字にかんしては対立点がほぼ解消されたので、もう大波乱はないんじゃないかな。

Oさんもうワントライするようだけど、実際は前回のフィードバックを
どこかの国が投票コメントで拾ってくれるかどうかが鍵だと思う。
会議に出るのはNB本体の意向を代弁する人たちだから。

携帯キャリアの連中、支持を表明しただけで自分たちじゃ何にもしてないのな。

ミーティングには日本の代表団もいたはずなのに
なんでこんなに影薄いんだ

毛が薄いから

電話屋って、ITU-T以外の規格はなべてバカにしてよい、っていう意識があるからな。

ISO/IEC JTC1/SC2/WG2/IRG か

ttp://www.unicode.org/roadmaps/smp/
U+1B000〜U+1B0FFがHistoric Kana(歴史的仮名)からKana Supplement(仮名補助)に変更されてた。
ということは今後このブロックには昔の仮名だけでなくイとエが合体したものや小さいヰヱヲなどの拡張仮名が追加される可能性もあるということかな。

小さいヰヱは、NDL-70とかいう国会図書館の文字コードにあるらしいので、
典拠としてそのコード表が示せれば比較的すんなり追加されるんじゃないか。

前のブロック名でぐぐると、変体仮名と結びつけちゃってる人も結構いるなぁ

変体仮名用のエリアじゃないのか。

変態かな

変態だよ

サプリメントの中にヘンタイがみっしりと

きそば

チェックボックスにチェックの入った文字コードってある？

U+2611 (BALLOT BOX WITH CHECK) って答えでいいの?

合字で作れないのかな。

(´･ω･`)やーだお

グリフウィキって変体仮名にも着手してたのか
一通り完成したらその先の展開も色々ありそうななさそうな

ﾊﾞｶｽｷﾞﾃｱﾀﾏｷﾁｬｳﾈ〜〜〜~~ﾌｪﾌｪﾌｪﾌｪｴﾌｪﾌｪﾌｪﾌｪﾌｪﾌｪﾌｪ

fｇｔｈｔｇﾇｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳﾃﾞｴfｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｳｒｆゲｗｇｒｇｒギウウウウｇｇｇｇﾂﾊﾞｶﾔﾛｳdｿﾌｨｴｲｵﾍﾟｦｴﾌｪr

ｱｱｱｱｱｱｱｱｱｱｱｱｱﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞﾊﾞｶkkkｯｶｱｱｱｱｱｱｱｱ

sfﾍｳfｳﾞｨﾈｵﾂｳｳｳｳｳｴjmgfdsvmcdslc、エコfk派wk度kpwkでﾐkﾑyｼﾞｭyrtytryrytrytryt

Annexだけ先行してUnicode 6.0のPublic Review始まってるのか。
この間5.2が出たとこだと思ったのに。早いなあ。

順調に行くと２０１０年末にはUnicode 6.0になってるのか。
と、思った記事があった気がする。

javaのjTextAreaで編集したテキストから日本語文字を[ctrl+c]でコピーして
テラパッドなどのテキストエディタに[ctrl+v]でペーストした時に
日本語が文字化けしてしまいます。防ぐ方法はありますか。
【Java】 1.6.0_17-b04 (Sun Microsystems Inc.)
【OS】 Windows XP 5.1 (x86)
Java低速GUI Swing 9スレでこちらを進められてきましたよろしくお願いします。

Ctrl+cしたときの、クリップボード中に保持してるテキストの文字エンコーディングと、
エディタのクリップボードで想定してるエンコーディングが合わないんだろうけど

GUIしてないので分からない・・

エディタ側で、開いてるテキストの文字エンコーディングとクリップボードの文字エンコーディングを揃えてるか、
エディタ側で、クリップボードは決め打ちのどっちかなんじゃないか。

ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/45006

ttp://www.atmarkit.co.jp/fwin2k/win2ktips/103clipbook/103clipbook.html
XPなら、clipbrd.exe で、クリップボードの中がみれる。
日本語Windowsの場合、テキストならcp932(sjis) Unicodeテキストならutf-16le

解決しました、ありがとう

Rubyになんかキタ。
ttp://github.com/ruby/ruby/commit/62f8df2d3c95816028c006ecbe70bc51704eec4b

携帯キャリアがこのタイミングでなあ
しかしたとえ名前の上だけだとしても色なんて飲めるのかねえ、WG2的に
FPDAMの段階でこれだけ問題提起されたら、もうぬるぽな悪寒

ぬるぽにするためにあえてこの段階で言いがかり付けてきたとか。
だって今までもさんざん携帯キャリアには何やってるのか言ってたけど
反応なかったって言ってたにょ

「色」があるからマッピングが不適切だっていうなら麻雀の赤牌もやっぱ符号化が必要かね。
つーかTRON涙目
http://www2.tron.org/set08/imode/imode-set.gif

フリーダイヤルマークはやっぱり商標問題が火を噴いたか。

前にキャリアから取り付けたコメントがポストされてたもんね。
Google/Appleにしたら、なんであの時言わなかったんだってなるだろうなぁ。

WG2としちゃ文句のついた"Symbols"を棚上げすりゃ済む話だろうけど、
「絵文字対応」が目的のUnicodeとしちゃ、それじゃ駄目だろうし。

失礼、FPDAM8読み直してみたら、すでに色の名前入りの絵文字あったわ
それほど難題でもないのかな

>>523 >>524
ｶﾞｯ! ｶﾞｯ!

こういう名前にしてくれ、それが駄目ならうちの絵文字とマッピングしないで
くれってのがいやらしいな。

国内のメーカーはそういうことを言って標準化の、ひいては利用者の足をひっぱってきた。
コード会コードの昔から。

>>528
> それが駄目ならうちの絵文字とマッピングしないでくれ

「〜の絵文字インスパイヤード」って位置づけにして、
変換テーブルに突っ込めば問題なし。

>>532
ガラパゴス

http://d13n9ry8xcpemi.cloudfront.net/photo/odai/400/787bc8429b2ef1fd247b59b5515e5321_400.jpg

もうdocomoとKDDIの担当者にもサンノゼ行ってもらうしかなかんべ
ただ合意できてもそのままFDAMに行けるのかって問題は残りそうだけど

Amd.6フリーになったー
と思ったけどここら辺はすでにUnicodeに入ってるんだっけか。

>>533
http://slashdot.jp/%7Eyasuoka/journal/
＞正直なところ、NTTドコモよりKDDI(au)の方がひどい
KDDIは色がどんどん変わっていってるらしい

>>524
フリーダイヤルの商標だが、現在はNTT東・西(0036・0039)ではなくて、
NTTコミュニケーションズ（0033）が持っているんだよな。

フリーダイヤルは削除かなあ。あとはマッピング変えたり新しいの足したりで
対応できなくもなさそうだけど、KDDIのジョーカーが少し厄介だな。
黒だの赤だの区別しない包括的なジョーカーを求めているんだとしたら、
落としどころが難しそう。

test

1F609と1F60Aは本当にkiddingでいいのかなあ
「失敗しちゃった、テヘ」で舌出してるのならともかく
「あかんべー」で舌出してるのなら「拒絶」だろうし

FCD(N3739)に見る次期10646のム板的ポイント

・Group-Plane-Row-Cellという概念が消え、代わりに "17planesからなる単体物
　(regarded as a single entity made of 17 planes)" に (p.17)
・UCS-2はdeprecatedと明記 (p.24)
・UCS-4は、UTF-32の単なる別名扱い (p.24)
・Implementation levelsという概念はもうない

Unicode化ここに完了ってとこか。
サロゲートや合成文字も、今後はきっちり対応していかなきゃならんのだろうな。

> Group-Plane-Row-Cellという概念が消え
マジっすか？

確かにPlaneくらいしか使わないけど……全体的に思い切ったな

久しぶりにIVDの登録申請ががが
ttp://www.unicode.org/ivd/pri/pri167/

>>543
日本が>>30で互換漢字の提出をあきらめてIVDの登録申請に切り替えた奴だな。
ついにｷﾀﾜｧ.*･゜ﾟ･*:.｡..｡.:*･゜（n‘∀‘)ηﾟ･*:.｡. .｡.:*･゜ﾟ･*!!!!!☆

CP51932の登録申請がietf-charsetに来てた。
mohtaも村田真も安岡先生も途中でほっぽりだしたわけだが
今度こそ最後までやってくれるんだろうかねえ。

西夏文字帰ってきたのか…！

FPDAM8はあちこち炎上してますな
Agendaも議題の量がエラいことになってるし、現地行く人は大変だ

汎用電子のプレフィックスはどういう意味なんだろうか
KS=戸籍統一文字番号
らしいというのだけはわかった

HG=法務省外字とか？
安岡センセに聞けば一発な気もする。

IPは安岡先生の日記でネタばらしされてた
http://slashdot.jp/~yasuoka/journal/504963
JAPANESE IDEOGRAPHICS SUPPLEMENTの平成明朝体による実装がソースらしい

欧州各地の空港が麻痺しているらしいけど、欧州組は
週明けのWG2に無事参加できるのかな。

米vs欧の案件が多いのに片っぽ来られないんじゃまずい罠

ロシアあたりまで鉄道で抜けてから飛行機で飛ぶしかないのか

ネット会議でいいじゃない

ジェットエンジンの欠陥だろ
ヘリコプターなり
ロケットエンジンなりの
航空機なら飛ばせるぜ

>>555
ヘリコプターもジェットエンジンなんだが？

ヨーロッパ組のいない間に好きにやって、FDAM8投票が万一コケたら
洒落にならんなあ。係争中の字は全部取り除こうフラグが立ったかこれ。

投票にならんだろ常考
延期だな

Eversonだけはネット会議ででも参加すべき

>>555
ロケットエンジンの航空機で実用的な例があるとでも?
間抜けにも程がある。

>>556
レシプロエンジンのヘリもなくはないがw
そもそもヘリなら低高度を飛べるから問題ないし。

で、結局ヨーロッパ組はたどり着けたのか?

http://www.iana.org/assignments/ianacharset-mib
これみると、csCPxxxxって無いし、csIBMxxxx、cswindowsxxxxが多いので、
csCP51932 じゃなくて、cswindows51932 という気がする。
略称 CP51932だけど、

windows code page の 51932 のようだ。
ttp://en.wikipedia.org/wiki/Windows-1258

構わない
芸能界

2chでは文字化けしないのか。

code pageという単語含んでるのは、
EDBIC？(IBM)か、DOSかWINDOWSなんでそうなってんのか。
まあ、重なることがなければ特に問題無いんだろ

もういろんな意味でぬるぽ

やっぱり
「BLACKとかWHITEは文字通りの色を表してるわけじゃねーよ」
で突っぱねるつもりみたいだな

ドイツの
「ブロンドと西洋人を結びつけるのはナチズムだ」
ってのもすげーな

まあナチの優生学的ってことでわからんでもないがな。

実際ユダヤ人はゴキブリ並み出汁

テメーゴキさんディスってんのか

投票制度変更の件は、会議の開催を今後は8ヶ月ごとに
することで解決したのか。

NEUTRAL FACEがN3769由来で、USも支持してるってこと見落としてるのかなあ

Nさんも気づいたね。

pipelineにStage 7が出現してますな。最近じゃレアだ。

せっかく新10646の全容が確定したのにfdisは秋か…
Unicode6の方が先かな

BabelStoneによると、2nd editionはフォントの問題でExtBだけマルチカラム化見送り。
そのかわりamendmentなしですぐ3rd editionの作成に入ってこれを修正するそうだ。

矢野啓介『プログラマのための文字コード技術入門』（技術評論社、2010年、本体 ¥2,580 + 税）
http://gihyo.jp/book/2010/978-4-7741-4164-0
http://ja.wikipedia.org/wiki/Special:Booksources/978-4-7741-4164-0

>>576
宣伝乙
http://gihyo.jp/magazine/wdpress/plus/978-4-7741-4164-0/0002

このスレ読むような人なら十中八九既知だと思う。

でももうucs-2ってdeprecatedになるのよね

わざわざUTF-16ではなくてUCS-2を持ち出すあたりに恣意的なものを感じる
著者の名前を見るとある意味納得なんだが

ひゅるり

ひゅるりらら〜

>>580
恣意的というか思想に偏りがあるから、この本に書いてあることを信じて実装したら死ねると思うなー。

ここでいいのか分からないけど質問してみる

例えば"東京"でググったら↓のURLになって
http://www.google.co.jp/search?hl=ja&q=%E6%9D%B1%E4%BA%AC&btnG=%E6%A4%9C%E7%B4%A2&aq=f&aqi=&aql=&oq=&gs_rfai=

%E6%9D%B1%E4%BA%AC　←ここの部分が東京を表してるんだと思うんだけど
"東京"から"%E6%9D%B1%E4%BA%AC"への変換は、google独自のもの？一般的な方法がある？

東京→UTF-8→urlencode

ageすま

ありがとうございます
なんかすごい簡単な質問だったようですんません

マルチ死ね
http://pc12.2ch.net/test/read.cgi/tech/1271996751/

はふ

UTF8ってBase64エンコードと紛らわしくて厄介。

さすがにそれはだいぶ違うと思う

なかったことにされつつあるUTF-7とごっちゃにしてないか

「Web ブラウザのエンコード自動認識の誤認による UTF-7 エンコーディング された文字列の脆弱性」ってやつか・・・

JISコード群にはJISロゴが入っていないが
UnicodeにはJISロゴが入っているふしぎ

asciiコードにasciiのロゴが入っていないが如し。

ロゴを直接Unicodeに入れるのは今もう難しい希ガス

ああ、こんなことならもっと早くうちの家紋捻じ込んでおけばよかった。

ワロタ

いやでも、Googleの絵文字の件みたいに、誰かが家紋を入れるとか言い出したら楽しいことになりそうだ。

Unicodeだもん、家紋も当然包摂なんだろうな。
菊紋だろうが桐紋だろうが葵紋だろうが、細かいデザイン上の違いはばっさり切り捨て。

丸に違い矢なら、違い矢＋丸の合成文字で。

そこでTronコードの出番だ

丸囲みの三つ葉葵紋については葉形によって指し示す人物が全然異なるという事実があるから、
すくなくともIVSの適用は期待できると思うぞ。徳川一門全部含めたら足りるかどうかわからんけどな。
ttp://aal.msis-net.com/kamon/tokugawa_1.html

しかし特定個人と結びつけてしまうと逆にジョンイルメソッドで却下される悪寒

明治・大正・昭和・平成は入ってるからそこは政治力次第

確かに。現天皇を元号で呼ぶことこそなくても、在位と元号が一致してるのなら実質個人名相当か。

てか、将来平成の次の元号が出来たときもちゃんと扱いやすいところに確保してもらえるんだろうか

日本国の書類(市役所とか法律関係とか)は西暦じゃないんだよな
当たり前だけど

>>605
次の元号がもし入るとして、平成とかのあるCJK Compatibilityは埋まってるから
収まりのよさそうな場所はEnclosed Ideographic Supplementあたりかな、Enclosedじゃないけど

天皇を元号で呼ぶのは死後だけどな

諡号だけに

平成のあと意味ありげな空きがあるのはJIS第三だっけ？

6.0.0ディレクトリ下が慌ただしくなってきた
>Unicode 6.0.0 (Scheduled September, 2010)
らしいのでそろそろベータレビューかな

>>607
むしろ元号のほうが、既存の組文字採用すればよくね？�iとか、例の㌬とか。
過去にも神護景雲とか、漢字2字じゃない変てこな元号もあるしさ。

けんさんAJ1-7の話題なんか出すんじゃなかったと
いまごろ後悔してないかな…

汎用電子(のうちAJ1-6までと重複しないもの)もやっぱりAJ1-7に入るんだろうか

こういうの追っかけてるともうascii基本だけでいいような気がしてくるぜ

株の自動売買プログラムを自作中なんですが、証券会社の配布してるツールの中で
株価の情報をソケット通信で要求している部分を調べてみたところ、
文末でなければ"0"+ASCII7ビット、文末なら"1"+ASCII7ビットというエンコードをしているんです。
これって一般的に使われるものなんですか？

株やってるギャンブラーには教えてやらん

ヌルターミネートの1バイトすら貴重な時代にはよく見かけたな
SYMDEBのシンボルテーブルとか

>UTC has decided to revise the procedures related to IVS registration

ほほう。
ttp://blogs.msdn.com/michkap/archive/2010/05/20/10013737.aspx

>>619
何が起こるの？

IVSの登録方法が変わるの？

>>620
汎用電子とAJ1の重複問題を何とかしたいということらしい

もともとアメリカは、AJ1にないグリフだけ登録するか、いっそのことAJ1に
組み込んでしまうことを提案してたからねえ
ここへ来てAJ1-7の話がちらほら出てきたのもこれがらみかなと邪推

なんかこっちが('A`)な気分になってくるな

月と肉月の区別みたいな話ならまだ分かるんだが、
何画目が縦だの横だのってレベルになるとついてけんわ

最初から先見性を持って康煕ベース、その他は出自を問わず全部IVSにしてしまえばすっきりしたのに

康熙字典は5万字弱あるから、Unicodeの当初設計に収まらないけどね。
当初設計がそもそも悪すぎるわけだけど。

せめて16じゃなく24ビット固定ならね。

コンソーシアムは今からでも625の方向へ収束させる気ないのかなあ。
正規化とVSを組み合わせれば出来そうな気もしないでもない。

Extension Bで康熙字典の漢字はすべて突っ込んだことになってるらしいな。
実際には漏れがあるようでちょくちょく追加されてるけど。
その頃はまだUTS #37がなくてVariation Selectors Supplementは
あっても使いようがなかったから仕方ない

汎用電子の公開レビューが終わるまでには、
新UTS #37候補のレビューも始まるのかな。

明日はぶっちぎるぜ！

落ち着け

WindowsでIBM EBCDIC 930/939をUTF-16に変換するは面倒だ

Lundeさんのコメント付いてる>>619
UTCでの議論に参加してたかんじだ。

合意によるsharing authorityか…汎用電子はモノがモノだけに厳しそうだな

ふとスレタイを眺めて、「あ、ここUnicode専用スレじゃなかったんだ」と気付いた。ほかの話題なんてないものな。

つ http://pc12.2ch.net/test/read.cgi/tech/1177930957/

>>636
今度はスレタイが限定的すぎて微妙

というか埋まっとる

うむ。
ファイルの先頭のマークに対して奇数アラインだったらどうすんのとか
アホなこと言ってるやつに一言言いたかったがな

気を取り直して、と

amd8が済むと、日本に関係ある提案は当面なくなるのかあ

うむ，新スレ立ってるな
http://pc12.2ch.net/test/read.cgi/tech/1274937437/

まあ不毛な争いは隔離されていただいた方がありがたい

誰がハゲじゃコラ

すみません頭髪の量をチャレンジされている人に言い直します

＞頭髪の量をチャレンジされている人

ハゲに包摂します。

Win7って出荷時に未定義だったコードポイントは
フォント入れても豆腐になるんだな
ttp://babelstone.blogspot.com/2010/05/prototyping-tangut-imes-or-why-windows.html

Unicode 6.0までにSP来なかったら絵文字はおろかAMD5以降全滅か…

リンク先読んでないけどなんでそんなひどい仕様なんだ

この仕様はMS社内のフォント開発部隊が困るんじゃないか。

ほんとなんでそんな仕様にしたのか分からん。誰得だよ。
Unicode5.2ってWin7発売直後だったよな。せめて5.2くらいは使えるようにしとけよ。
確かにバンドルされるフォントには無いけど、有志によって作られたフリーフォントには既にUnicode 5.2の文字を含んだのあるんだぞ。
こういうのはUnicode新ヴァージョンリリース直後どころかフライングで作られて公開されることもあるというのに。
ちなみに第15面、第16面の私用面もダメだった。で、何故かBMPと第2面は未定義だったのもOKだった。
一応UniscribeをVista以前のにすればWin7でも表示出来るけど当然Win7で新しく利用可能になったIVS等を犠牲にすることになる。

その支離滅裂さは仕様じゃなくて不具合の匂いが…

マジでバグであってほしい
MS様がいいと言うまで新しい文字は使えず、MS様がWin7のサポートを
打ち切った場合も新しい文字はもう使えないなんて嫌すぎる

てかこれまで誰も気付かなかったのか

まだUnicode5.2対応フォントが少ないしXP使い続けてる人も多いから仕方ないか。
でも今MSに要望出しておかないとSP1や次期Windowsでも放置される危険性があるな。

困ったなあ

なんだ。
会社のPCをまとめてWindows 7への移行を考えて、金も少し使ってたのに振り出しじゃん。
なんて言い訳すんべか。

DirectWriteへ移行させるための嫌がらせとか。
いやDirectWriteなら豆腐にならないのかどうかは知らないけど

> applications need to set an undocumented flag in Uniscribe
> [SCRIPT_CONTROL.fMergeNeutralItems = TRUE] for the Format 14 cmap
> substitutions to work
Windows 7のUniscribeをコピーするだけじゃダメなのはそれでか…

FirefoxだけはなぜかWin7でもUnicode 5.2で追加されたARIB外字を表示できた。
テストに使ったのはこのフォント
http://glyphwiki.org/font/gw442923.ttf
IE8/9, Chrome5/6, Safari4, Opera 10.5を試してみたけど他のブラウザは全滅だった

Firefoxはフォント周りの処理が独特で、
どうも自前でグリフを抜き出しているみたい。

そんな中Unicode 6.0.0のBeta Reviewがはじまた

由仁子！

who?

うんこマークも入るようだ。2chのAA等で使われるかも。
でもMS明朝/ゴシックやメイリオに収録されないと普及しないか。
その前に>>647に書いてあるWin7のUniscribeの不具合を直してもらわないかんが。

うんこマーク入るのかｗ

逆卍とかと同じく宗教的に嫌う人向けにMSがグリフ削除ツールを出したりするのかな。

既にBMPに入っているフェイスマークでぐぐっても結果が出ないな。
symbolは弾いているのか。絵文字の人気調査には使えそうにないな。

所謂「まきぐそ」は日本の漫画内だけで通用する符牒だと読んだことあるけど、
名前(何になったの？)無しだとどれぐらいの外人が意味を認識できるんだろう。

ファストフードのおしながきにソフトクリームサインとして使われたりしたら楽しいな。

フォント屋が泣くわ

　　入　　　　　　　∧
　 .(＿)　　　　　　(＿)
　 (__＿)　　　　　(__＿)
　(_＿＿)　　　　(_＿＿)

　　Serif　　　Sans-Serif

2chでウンコマークを大量に書き込む荒らし行為が流行りそうな悪寒

>>667
まきぐその、ドラフトでの文字名は
PILE OF POO
翻訳すれば、「山盛りのうんち」
要するに、巻いてなくても良いらしい。

>>670
Windowsに、まきぐそのグリフが標準で入る日が来るのだろうか？ｗ

Unicode6はドラフトとはいえ、もう名前は変えられないので確定ですな

フォント入れればまきまきだし入れなければ豆腐か…

ユーザーの囲い込み目的で無節操に絵文字を考え出してた連中は
絵文字登録の流れをどんな思いで見ているのだろう。

今日もまたまきまきうんちのヒンティングする仕事が始まるお…

考えたことなかったけど、絵文字ってベジエ曲線で作るとなると
結構面倒くさそうだなあ。
ドット絵だと大した手間じゃないんだろうけれど。

ドット絵なめんな

>>669はもっと評価されていいと思う

おいらも好きだよ
崩れかけにしてcursiveってやろうと思ったけどやめた

崩れかけﾜﾗﾀ

OSに付いてくれば使う人も少なくないんだろうけど
フォント買ってまで使いたいって人はいるのかなぁ

そこで色つきの文字やアニメーションまで完全再現できるSVGフォントですよ。
問題は対応ブラウザがひとつもないことだが

そっか。絵文字の場合、OSにインストールして使うフォントよりも
WebFontsの方が需要あるのかもしれないね。

>>681
WebKitで使えなかったっけ？

>>683
現在SVGフォントに対応しているブラウザはすべてAcid3を通すためだけの実装で、
色つきの文字やアニメーションを再現するための仕様に対応していない

普通に単色でグリフ表示できるだけで立派なもんじゃねえの

色つき文字のモノクロ化には、hatchingとかいうのが利用されてるらしい。
ttp://en.wikipedia.org/wiki/Hatching_system

>>685
それだけならTTFやWOFFのWebフォントに対して何もメリットがない
(Acid3で3点ゲットする以外に)

これはとても重要な確認なんだけど、いま色の話をしてるのはうんこマークからの流れなの？

せっかく絵文字を実装するんなら色やアニメーションも正確に再現したいじゃん

そのうち巻き具合の指定にIVSが使えるようになるのだろうか

"Ideographic" Variation Selectorは使えないだろ。
絵文字は表意文字かもしれないが
この文脈でのIdeographは漢字の婉曲な言い回し

特定の読みが存在しないんだからむしろ漢字より本来の意味の表意文字に近いな

実質IVSというかVSだよねあれ

漢字とモンゴル文字以外はU+FE00〜U+FE0Fを使うことになってるし
UTS#37は漢字(正確にはUnified_Ideographプロパティを持つ文字)にしか適用されない

＞正確にはUnified_Ideographプロパティを持つ文字

はー、そうなのか。

U+E0100〜U+E01EFは漢字以外には使っちゃいかんのだな。
非漢字で17個目以降のVSが必要になったらU+E01F0〜かどっかにVS-257〜を追加しないといかんのかな。

それを分けてる意味ってそもそも何なんだろう？

どちらかと言うと先着16個の漢字のglyphic variantにBMPのVSを使う「特権」を
与えたくなかったんじゃなかろうか。

何でVSはBMPとSSPに分けたんだろ?どちらか一方に全部の方がよかったんじゃないかな?
そういやVS-2〜16を使うのってまだ1つも無いんだな。パスパ文字以来非漢字のVSの提案全く無いし。

すでに240個もVS「ごとき」に使わせられる余裕はBMPになかったと思う
JIS X 0213の300個程度の漢字ですら蹴られてたしな

なんでBMPそんなに余裕がないんだよ…誰だよ最初の見込み立てた奴は…

Unicodeにはハングル完成形が1万字以上全てBMPにあるけど実際に使われるのは2〜3千字とか。すごい無駄だよな。
統合漢字も拡張AからBMP外にした方が良かったのでは?使用頻度の低い字ばかりだし。

いつかUCSをデフラグしてほしい。

　　　　　[ﾟдﾟ]
　　　 　/[＿]ヽ　　　　　　　　　　デフラグを使うと
　　　　 　|　|
　■■□■■□◇＿◇□□□

　　　　　[ﾟдﾟ]
　　　 　■＿]ヽ□　　　　　　　　ハード ディスクのファイルや未使用領域を再配置し
　　　　 　|　|
　■■□＿■＿◇＿◇□□□

　　　　　　　　□
■⌒　　　　　　ヾ
　　　＼[ﾟдﾟ]ﾉ　　　　　　　　　　プログラムの実行速度を上げることが
　　　　　　＼＼/　
　■■□　/■＿◇＿◇□□□


　　　□　　　（ ）　　　　　　　　　出来る・・・かも知れません。
　　■　　ヽ[￣]ﾉ
　■■□[ﾟдﾟ]■◇＿◇□□□


　　　□　　　　　　　　　　　　　　 デフラグを実行しますか？→YES
　　■
　■■□ 　　 ■◇＿◇□□□

使用人口/収録数でいうと多分ハングルがぶっちぎりで悪いよね。一番の優等生は算用数字。

>>705
生まれが組み合わせ文字なのに無理矢理全部いれやがって
しかも発音のうち自国で使ってない物はいれなかったせいで、ハングルを採用させられた某国では結局ＰＣ化でふべんを強いられてるし

>1万字以上全てBMPにあるけど実際に使われるのは2〜3千字

それは漢字にもほぼあてはまるんだが……

>>705
いや、優等生はCRだろ。

日本もBMPがスカスカなうちに変体仮名入れときゃ良かったのに

丸付き数字があっちこっちに飛び飛びで入れられてるのが地味に気持ち悪い

>>701
欧米人は「東アジアさえなければ16bitで足りなくなるわけなかっただろJK」
とか思ってるよきっと

つか最初は「GB2312とKSC5601とJISX0208合わせても余裕じゃん」とか
言ってたらしいからな。さすがに止めたらしいけど(で、漢字統合とか言い出した)

これだな
ttp://www.unicode.org/history/unicode88.pdf
現代の文字以外はPUAを使わせるつもりだったという

「16ビットで十分ですか?」「はい」
力強いな
> fixed-length 16-bit character
ときっぱり言い切って可変長にたいする利点を強調しておるな

容易に想像できる懸念を無視して美しさにこだわったら、
すぐに破綻して一番美しくないｇｄｇｄ状態になってしまったでござるの巻

>>713
そこに入ってるWriting System別のGNP表、今集計しなおしたらかなり変わってるんだろうな…

>>707
しかし漢字は合成済み文字と用途の被る偏旁別の合成用パーツが収録されてるわけではあるまい？

こういう今となってはちょっとあれな文書も、
堂々と公開しているのはえらい。

>>717
なんたらradicalsとかIDSとか
正直この件で韓国叩いてもブーメランが返ってくるだけだよ

いくらか青臭くもあったけど　あの頃はみんな若くて輝いていた　みたいな青春の証左

>>711
Unicodeなんてもともと、東アジアへの対応に嫌気がさして作った規格だろ。

誰がどういう意図でそんな事を言ったんだ？

未だに欧米のUnicode化してないアプリだとダメ文字問題とかあるでしょ?
(「表」を含んだファイルが開けないとか)
1バイト文字で用が足りる連中にいくら言っても理解すらしてもらえないから
(似非でも)2バイト固定にしたほうが少しはマシになるってこと。

理解してもらえないから、UTF-8なんかにせず、2バイト固定のほうがよかった、というのか？
よくわかんない。

アメリカ人はUTF-8のほうが好きだがそれは(連中にとっては事実上)
何も変更しなくてすむから。
プログラマーは基本的にlazyなのです。

>>724の頭がよくわかんない。

そのとばっちりで日本語が基本１文字３バイトになるんだから
たまったもんじゃないな

いや別に。外部表現だし。

>>727
文字数が多い場合は問題になるが、大抵の場合はそこまで問題にならないと思うぞ。

そして、文字数が多い場合は当然圧縮もかかってると見るべき。そのときどうなるか調べてみた。
青空文庫の「吾輩は猫である」現代仮名遣、テキストのを落としてきた。
ttp://www.aozora.gr.jp/cards/000148/card789.html
元ファイルはsjisなのでiconvでutf-8に変換したものと比較。圧縮形式はgzとbz2

無圧縮でのファイルサイズ
sjis: 748715
utf-8: 1120272
比率: 1.496

gz圧縮
sjis: 344127
utf-8: 390050
比率: 1.133

bz2圧縮
sjis: 251847
utf-8: 265362
比率: 1.054

まとめ
・utf-8の方が常にファイルサイズが大きいことには変わりない
・圧縮するとファイルサイズの比率は少なくなる
・sjisでもutf-8でも情報のエントロピーは同じはず
・なので優れた圧縮形式だと比率は1に近づく
　(が、優れてない圧縮形式でも偶然1に近づいたり1を下回ったりすることもありうる)
・圧縮せずに使いたいサイズの大きいテキストや、非常にサイズが大きくbz2での6%以下のファイルサイズ増加でも
　大きな影響を与える場合は、utf-8は避けた方がいい
・そこまででもない場合は、そこまで気にしなくても良い

プレーンテキストに日本語の文章を書くような場合は、
utf-8よりutf-16の方がいいだろうね。

ただ(x)htmlの場合は、ファイル中に占めるタグやら何やらの比率が高いから、
sjisとutf-8との差は相対的に小さくなる。

今時utf-8のサイズがどうこう、sjisの方がうんぬん、なんて時代錯誤がいるとは驚きを禁じ得ない。

どう考えても、既にsjisやらiso-2022-jpやらの時代ではありません。

対案も出さずに文句だけ言う口か

世の流れ

どうみても UTF-8 一択です
ほんとうにありがとうございました

1995年頃ならまだしも今さら「対案」なんか出されても迷惑なだけだがな。

合成済み文字は排除する・漢字はIDSで表記する
これなら16bitで行けそうな気がしないでもない。

>>731
今も昔も、sjisをutf8に変えると約1.5倍になる事実には変わりがない。
ちょっとしたテキストファイルがHDDを圧迫する時代ではなくなったが、莫大な量のテキストを扱う用途もありうる。
それすらも考えられないのは時代云々以前の問題。

ただ、時代的に、サイズを問題にするならギガバイト越えはしてるんだろうな、
DVDに収まらなくなってからでも全然遅くはないぞ、とは思う。

ストレージの価格や回線の速度やSJISで表せない文字の需要がぜんぜん違うだろ。

今も昔も円記号問題は変わらんな

莫大な量のテキストならなんらかの構造を持ったデータにするだろ。
ベタデータで 1.5 TB じゃダメで 1TB なら OK っていう場合なんて、ちょっと想像つかない。

2GB以下でないと圧縮すると壊れるファイルとかあるからな
そういうのにシビアな環境のひとなんだろう

通は故・UTF-7

なんか痛々しくてどうにもならんな。

そんなサイズを云々するような規模の文書なら、プレーンってことはないだろ。
装飾やら何やらをバイナリやらXMLやらで付けてれば簡単に肥大化するし、画像添付とかすればなおさら。そうなりゃsjisとutf-8のサイズの差なんて誤差だわ。

あとsjisは文字集合がチープすぎて、もはや実用的じゃないんだよ。時代錯誤もいい加減にしとけって。

文章を書く側が、自分の書くものがSJISで書けると分かっていて
SJIS使う分には別にどうも思わん。

プログラムを書く側が、SJIS前提のプログラムを書くのはさすがに
今となっては勘弁してほしい。

とりあえず、難がなくて的確な>>744に同意しておこう

>>741
pgr

>>743
一般的な用途にはutf-8でいいというのは認めた上での話なのに、全く的外れ。

> 装飾やら何やらをバイナリやらXMLやらで付けてれば簡単に肥大化するし、画像添付とかすればなおさら。
そんなことするってどこに書いてある？

> あとsjisは文字集合がチープすぎて、もはや実用的じゃないんだよ。時代錯誤もいい加減にしとけって。
何を表現できるかじゃなくて何を表現したいかが問題。
漢字すらいらない、ASCIIとひらがな、いや、ASCIIと半角カナが使えればいい場合だって十分考えうる。

>漢字すらいらない、ASCIIとひらがな、いや、ASCIIと半角カナが使えればいい場合だって十分考えうる。

ならば UTF-8 がいいよ

なんというどっちもどっちだ

>>748
ひらがな、半角カナならsjisで十分だし、容量も少なくなる。

いやその前提はおかしい

UTF-16にしたら

Unicodeに絵文字収録されても「全部」でない以上何の解決にもならん木がするんだが…

絵文字
一時しのぎに外字登録みたいなことするとか？

>>754
機種依存文字の時代に逆戻りなわけですね。

>>755
mixiみたくエスケープすればいいだけの話。
一般の文字と同様にコード空間に割り当てることだけは断固として反対する。

>>756
もはや文字コードじゃないね。

sjis真理教には何を言っても無駄っぽいなｗ

どうせ何を言っても彼には結論が一つしかないんだし、相手しない方が良さそうだ。

エスケープっつーとJISみたいな感じか？

mixiの絵文字の場合は、[m:123] みたいな形式。

絵文字だって文字なんだからコード空間に割り当てられるのは当然の流れだろう。
誰も使ってない象形文字にすら文字コードがある時代なのに。

図書館の◆とかだろ

絵文字は文字じゃねーよ
絵だよ

絵文字は象形文字だよ

┏━─┓
│　 　 ┃
└┐┌┘
　 ┗┛

こいつらに言ってやれよ

>>758
それはユニコード原理主義者の話だろ。

sjis真理教信者は幸い、ここには来てないよ。
ごく限られた用途によってはsjisの方がいい場合もありうるって話

携帯とか通信量がシビアな場合はSJISの方がいいように思う

通信量というか通信料だなｗ

まあどっちでも通じるけどw

最近アナタたち元気ね

圧縮すれば大差ない

どう見てもごく限られた用途の話なんかしてなかったけどな

>>771
だよね。>>737, >>747みたいな使用例って極めて一般的だよね。

自作自演カコワルイ

どっちも落ち着けよ

Shift_JISはテキストデータのサイズが小さくなる!(ｷﾘｯ

そういうのはやめれ。どっちもどっちだと思ってたけど
議論でさえない煽りに熱中しだすのはただの迷惑行為だ。

もうこれでいいんじゃね？

・相当な理由がない限りはutf-8を使え
・相当な理由があるときは、本当にutf-8じゃダメかを再検討せよ
・やっぱりutf-8じゃダメなら、本当に{sjis, euc-jp, ...}が有効な解決方法か検討せよ
・{sjis, euc-jp, ...}が有効な解決方法なんだったら、もう仕方ない

まあそれでいいんだが、たまにはutf-16のことも…

utf-16を採用しているのは
JavaとJavaScriptと
WindowsとMacOSXだっけ？
qtもUTF16だっけか。
たくさんあるよな。

プログラミング言語内では UTF-16、ファイル出力とか外部との通信は UTF-8 ってことで。

>>779
linuxはディストリによって違うのか？
まあ大体はUnicode化されているよね。

日本語ならUTF-8よりUTF-16の方が良いもんなあ
サロゲートペアが嫌な感じではあるが

C言語が癌なんだろうね。
昔から有るC言語のライブラリが
ASCII前提で作られている。

具体的に言うと、文字列の終わりは文字コード0になっていないといけない。
UTF16やUTF32は16bit、もしくは32bitで見れば、文字コード0ではないが、
1バイトずつ見ると、文字コード0が含まれているように見えてしまうことがある。
だから文字列の途中で文字の終わりと認識されてしまう。

UTF-8はASCII互換が高いからねえ
検索関数とかそのまま使えるし

>>781
そうなのか？
ロケールの話だと日本ならWindowsはsjisだし内部コードの話だと思うのだが、Linux内部ってそんな複雑な振り分けしてるのか？

>>783
なんで1byteずつ見るんだ。
wchar_tだかなんだか使ってそれ用の関数使えば1byteずつは見ない。
0が含まれてなくても、2byteなり4byteなりで考えないと境界が曖昧になる問題は避けられないだろ。

×ロケールの話だと日本ならWindowsはsjisだし

WindowsはUTF16。ただし9x系は各国ごとに違った文字コードで、
日本語版ならSJISだった。今のWindowsも9x系用のアプリを動かせるように
互換性機能がありUTF16に対応していない古いアプリを、
どの国の文字コードとして扱うかを設定切り替えられる。
もちろん日本語版はデフォルトでSJIS

Macは基本UTF-8なんじゃないの

>>786
昔のライブラリは文字列はcharであらわしているから。

> wchar_tだかなんだか使ってそれ用の関数使えば1byteずつは見ない。
型が変わってる。それじゃ互換性が保たれない。
つまりchar使っているアプリ（ライブラリ）すべて見直しが必要になる。
文字列を使う箇所といえばファイル名。ファイルを使うアプリはすべて見直し。
C言語の関数はcharを使っている。これは決まりだから変える事は出来ない。

C言語で作られているLinuxにとって、それは膨大な修正となる。
だからLinuxはunicode対応といえば、UTF8で、
UTF16やUTF32に対応しているものは無い。

>>788
ファイルシステムがUTF8なだけで、
OS内部はUTF16

>>790
複雑な事やってんだな

WindowsNTやMacOS Xははじめからutf-16だもんな。
後からunicode対応した訳じゃなくて。

>>791
.NETもそうだけどね。
内部は（Windows前提だから）UTF-16で、入出力はUTF-8が基本。
入出力用のAPIが標準でUTF-8を使うようにしておけば、アプリ側では特に何もしなくていい。

サロゲートペアというレアケース以外固定長なUTF-16を使った方が
処理が早くなるとかあるんだろうか

>>794
時代的な問題だよ。

当時は16bitで世界中の文字を
あらわせると思われていた。

wchar_t もそのころの名残だろう。
まさか可変長バイト文字（UTF8およびサロゲートペア）を
使わないとすべての文字が表せない。
wchar_t（16bit）が使い物にならなあい時代になるとはな。

規格上は wchar_t の表現ビット数の上限 == 16bit というわけじゃないけどね
実際 gcc とか sizeof(wchar_t) == 4 だったりするし
wchar_t 導入時（規格になる前）は
16bit 決め打ちだったのかもしれないけど（当時の事は知らないので何とも言えない）

>>787
だから、それがロケールに当たるものなんじゃないの？

>>789
実際のところ、utf-16にしないことでどれくらい、修正の手間が減るんだ？
修正が必要かどうかを判断するプロセスも含めて。

バグは見つかってから対応すればいいって考え方だったら結構手間が減りそうだけど、
はじめからある程度バグとったものを、と考えるとどうせ見直す範囲は多くなると思うぞ。

>>795
1文字、という考え方だとサロゲートペアやらUTF-32ですら微妙。

>>797
ASCII → UTF-16 文字列を扱う全ての関数に修正が必要。
ASCII → UTF-8　ほとんどの関数は手を加える必要がない。

>>777
>・相当な理由がない限りはutf-8を使え

お役所様がSJISをお望みの場合が多いです。

>>797
こういう、問題が起きたら直せばいいじゃん、とか言ってる奴、
いざ自分に問題が降りかかると延々とｇｄｇｄ言い続けるんだよな。
当然自覚はあるよな？

>>799
そんなことは分かってる。が、
> 文字列を扱う全ての関数に修正が必要
charをwchar_tに書き換えるだけで修正できるものも多い

> ほとんどの関数は手を加える必要がない。
手を加える必要がないことを見極める必要がある

その上で、具体的にどれくらいutf-8の方が手間が減るのか、というのを聞いてる。

>>801
>>797はそんなこと言ってないよ。ストレス貯まりすぎで文章が歪んで見えたか。かわいそうに。

ストレス貯まりすぎで自分の文章を客観視できなくなっているらしい。放置推奨。

>>802
いやね、C言語標準ライブラリだから
変えたらいかんのよ。
これは規格だからね。

printfの第一引数はchar*と決まってるのです。

fopenの第一引数もchar*なのです。
そう決まっているのです。

wprintfの第一引数はwchar_t *と決まってるのです。

そこで最後の結論が出るわけさ。
wprintfなんてのは誰も使っていません。

ま、printf とかを使ってたら _tprintf に置き換えなきゃいけないから、「charをwchar_tに書き換えるだけ」とは言えないか。
コンパイラで型エラーになるから直しやすくはあるけど。

使ってないのなら、世の中のすべての
printfをwprintfにすればいいじゃない。
fopenをwfopenにすればいいじゃない。

wfopenという関数が世の中に無いなら
作ればいいじゃない。

互換性なんてすてればいいじゃない！

>>808
_で始まる関数は、標準じゃないので
使わないでください。

ここまでいえば理解できただろ？

charに問題なく代入できて、
問題なく処理できるように考えて作られたUTF8と

wchar_tに変えたところで16bitの可能性があるから
UTF16やUTF32を代入できるとは限らない。
じゃあどうしろと？という互換性の差を

みんなGo言語使おうぜ！

>>802
タダじゃ修正できませんのよ？
タダじゃテストできませんのよ？
タダじゃ見極められませんのよ？
ANSI Cの制定の時の苦労話とか読んでみ？

新しい常用漢字表が、採用されて数年経てば、Unicodeで、保存するようになるんじゃね？
役所がSJIS2004を調達基準にすれば、Windowsでも対応するかもしれないけど。

>>783
リトルエンディアンで半角英数をUNICODE化すると1バイト目が

圧縮の話なんで、興味ない人は、するーするー

最近実用化されてきてる圧縮DBとかだと、
・LZO系のO(1)？なストリーム向け圧縮アルゴリズム
・インデックスなどで、局所的に取り出せる圧縮アルゴリズム
・圧縮RAMキャッシュ
とかあるから、将来は、普通のFSやDBからはじまって、アプリ向けのAPIやOSの機能として、
一般化するんだろうなとは思う。

http://db2.jugem.cc/?eid=1856
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.101.6676&rep=rep1&type=pdf
http://oai.cwi.nl/oai/asset/10892/10892D.pdf
http://cloud.watch.impress.co.jp/epw/cda/hardware/2008/07/09/13376.html

だけど、局所的に取り出せる圧縮アルゴリズムで、utf-8とsjisの差が縮まるかはまったく分からん。

Trieとか簡潔（圧縮）データ構造
http://www.kyoritsu-pub.co.jp/series/algo.html#8
http://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A9%E3%82%A4%E6%9C%A8
http://gihyo.jp/magazine/wdpress/archive/2008/vol42
http://codezine.jp/article/detail/261
http://hillbig.cocolog-nifty.com/do/files/2005-12-compInd.ppt

>>802

簡単にcharをwchar_tに書き換えると言うけど、gccなんか未だに
wchar_tに対応できてない部分が多数あるんだぞ。

>>803
もし>>797が>>801のように言ってるなら>>799はなんのために答えたんだー
>>807
誰もってことはないだろーなー
>>811
utf16なら問題ないんだろー
>>813
だからこそ、具体的にどれくらいかを聞いてるのに、何をするとか、誰が使ってるとかの話ばっかりで、
手間を定量化して表そうとしたものがちっともないんだなーふしぎふしぎー

sjis馬鹿は、今度はutf-16馬鹿になったのか。
どこまで行っても馬鹿は馬鹿のままなんだな。

てか、CなんかよりC++を使え。
printfなんかより、std::cout << を使え。
WindowsとUNIXで共用可能なソースにする場合も、UTF-8の方が便利。std::string を使えばいい。

> 手間を定量化して

ソースコードの中のcharの数を数えたら？

>>820
それだと、できてない。
charいっこいっこを、それをそのまんま扱うのが適切か、書き換える必要があるかを見極めるコストはutf8にもかかる。
大規模なプログラムでは、機械的な変換でどうにでもなるcharからwchar_tへの書き換えよりも、
真に大変なのは、意味的に正しいかどうか判定しなければならない部分。
(例えば、バイト数を数えているのか文字数を数えているのかでstrlenを使うのが適切か不適切かは変わってくる)

そのへんを加味すると、utf-8とutf-16のコスト差は、圧倒的ではなくなる可能性がある。
utf-8の方が多少はマシだとは思ってるが、圧倒的に楽だとはとても思えない。

Qt

>>819
レッテル貼りに走るのは、文字の読めない人のすることだ。

> てか、CなんかよりC++を使え。
なんでそういうバカなこと言っちゃうかなぁ。
万人に取って、すべてのソフトウェアに取って、CよりC++の方が適してるなんて限らないんだから。
無駄に選択肢狭めることを、人に押し付けちゃいかんよ。

やっぱり単なる馬鹿でした。

双方が馬鹿馬鹿言ってるから手に負えない

このスレ、ひとつの方法しか認めたがらない人多いの?

全部包摂したくなるのさ

>>821
> charいっこいっこを、それをそのまんま扱うのが適切か、書き換える必要があるかを見極めるコストはutf8にもかかる。

UTF8でもUTF16でもUTF32でも、同じようにかかるコストは比較しても、
”同じ” になるので、ここで取り上げる必要は無いんじゃないですかぁ？

それ以外のコストの話をしましょうよ。ﾆﾔﾆﾔ

>>821
strlenぐらいなのと、
すべて書き換えないといけないのと
比べるまでも無いだろ。アホｗ

物事ってのは少しずつ変えていくもんだ。
一気に全部変えたらどうなるか予想ぐらいつくだろ。

>>818
>手間を定量化して表そうとしたものがちっともないんだなーふしぎふしぎー

中学生の脳内じゃないんだから、それにだって金も手間もかかるんだよ。

そもそも utf-8だと日本語文字が1.5倍の容量を食うから
sjis それでなければwcharって主張がこの流れになってるんだろ？

だったら　gccでwcharは4バイトって話が出た時点で終了だろ

sjis馬鹿は、今度はutf-16馬鹿になったのか。
どこまで行っても馬鹿は馬鹿のままなんだな。

てか、CなんかよりC++を使え。
printfなんかより、std::cout << を使え。
WindowsとUNIXで共用可能なソースにする場合も、UTF-8の方が便利。std::string を使えばいい。

>>828
なにいってんだ？
utf16で余分にかかるコストの「割合」の話してるんだぞ？

>>829
>>801

>>830
やらないって選択肢もあるけど、やってもいないことを断定するな。

>>831
sjisの話とは別だろ。

それ以外のコストの話をしましょうよ。ﾆﾔﾆﾔ

放置推奨。

>>833
なんでやってないと思うんだろう。
普通やるだろサラリーマンなら。

おまいらスレ伸ばしすぎ

本人たちが楽しそうならそれでいいじゃないか。

よっぽどネタが無いんだな。

>>836
なのに、実際にやったって話が出てこないんだぜ。

やった人は反対意見の方にまわるからさ

>>841
反対意見出す側にも、やったけど全然違った、と言ってる人はいないよ。

端から見てるともはや何を言い争ってるのか分からんレベル
他所ん家の夫婦喧嘩見てるみたいだ

それだけ仲がいいってことさ

>>842
やったけどぜんぜん大変だよ。


というと次はソースを要求するのが中学生。
しかしコストかけたものをただで出すバカはいない。

>>845
んなもん、仕事で測定したデータを詳細に2chで晒せなんて思っとらんわ。

動作確認コストの大きさが、大分前から理由として挙げられてるのに、
utf8が圧倒的楽って言ってるレスではその大きさについて触れようともしてないよね。
実際にやってみたなら、そのコストが大きいことは容易に分かるはずなのに。

utf8が圧倒的に楽というのはな、
utf8の文字列を普通のC言語関数に渡したら
普通に処理してくれることで十分理解できるよ。

普通のC言語関数が使えなくなるのと
普通のC言語関数が使えることの差は
改めていうまでのこともない。

>>847
まだそれ言ってるのか。それが普通のC言語関数であるか確認する方法は？
関数が動作することと、そこでその関数を使用することの妥当性の確認は全然違うことも分かってるよね？

その説明は「圧倒的に」楽である説明にはなってない。

「wchar_tは俺の嫁。俺の許可無くしてUTF16だの32だの無理矢理突っ込むのは許さん。」

> まだそれ言ってるのか。それが普通のC言語関数であるか確認する方法は？
なんのことを言っているの？

たとえば、printfという関数。
これはよく使われている関数だよね。

これが使えなくなったら、大損害。
これはわかるよね？

２バイト以上の文字が表示できるとは限らんぞ

それは関数の問題？
外形から容易に想像できる機能の見積もりなんか楽なもんだ。

>>850
そんなprintfをwprintfに機械的に置換すりゃ済むことを大損害って言ってたの？

>>853
釣り？
無条件に置き換えられたら動かなくなるだろ。
ニートと素人は黙っててほしい。

本当に毎日楽しいスレだな

まるでSJIS用のprintfをそのままUTF-8でも使えるかのような勢いだな

sjis用のprintfって何？

printfに渡すのは char *であって、sjisとかutf-8 とか別け隔て
しない良い子だよ

printf が特別扱いするのは % だけで、 \ はスルーだし。

>>857
（　ﾟдﾟ）ﾎﾟｶｰﾝ

>>857
いいか
UTF-8の大きな特長ってのは
従来の検索関数が「実装を全く変更しなくても」そのまま使えると言う事だ
printfは実装の変更が必要になる例だ

>>860
どんな変更が必要？

>>861
まずprintfではUTF-8以外のUNICODEを扱えない。
扱えるようにするためにprintfの内部も修正する必要があるだろうが、
引数もchar*では対応できない。wchar_t*に変更する必要がある。
（なおSJISもEUC-JPもchar*のまま使える）

printfの引数をwchar_tに変更するということはどういうことか、
たとえばLinuxならCライブラリがインストールされているわけだが、
そのライブラリを修正しないといけなくなる。

もちろんライブラリを修正すると、
それを使っているアプリ全部修正しなければいけなくなる。

printfを使っていないアプリはまず無いため、OSもアプリも
ほぼすべてのソースコードに修正が必要になるということを意味する。

Linuxの世界では、アプリの作者はばらばら。その全員に対してwchar_tに変更してください。
と頼むのは現実的ではない。かといってディストリビューターがパッチとして提供するには
量が多すぎる。

>>862
それはUTF-8以外の場合は、printfの実装に変更が必要ってことだろ？
UTF-8の場合はprintfの実装は変更しなくても動くよ。

>>863
そういう話をしたつもりだけど・・・

>>862
そんなことは聞いていません。
printf を UTF-8 に対応させるのに必要となる「実装の変更」を聞いています。

UTF-8はcharでいいだろう常考

glibcにwprintf()は入っているしprintf()は%lsを受け付けるのだから
ライブラリを修正する必要なんかどこにも無いだろ

>>865
SJISは２バイト目に\がある場合があるので、
エスケープシーケンスと誤認しないようにチェックが必要
そのチェックが入ったコードはUTF-8では使えない

printf は \ を特別扱いしないんだってば。

printfにSJISコード渡してもEUCコード渡しても
正しく動くんだよね。

これはSJISもEUCも（もちろんUTF-8も）ASCII互換だから。
英数文字の部分はASCIIコードと同じでそのほかの文字のコード
ASCIIコードに間違われないような形でうまく配置している。
だからchar*に渡してもちゃんと動く。

でもUTF16やUTF32はASCII互換じゃないんだよね。
ASCIIコードの文字コード自体が8ビットから16ビット、32ビットに
変わってしまっているから、基本的なprintfでさえ
型の変更が必要になってしまっている。

wchar_tを使いたいなら、れっきとした標準であるC95で導入された
wchar_t用の関数を使えばよい、もう15年も前の標準だ

localeに応じてwchar_tへ変換したり、wchar_tでファイルを読み書きするための
関数もC標準には用意されている
UTF-8に変換する関数などというものは標準には無いがな

>>865 コンパイラ（およびプリプロセッサ）のやることと、ライブラリのやることを混同してるだろ。

>>871
規格にあるからといってまともな実装があるとは限らないのだがな・・・

アンカを訂正
>>868 コンパイラ（およびプリプロセッサ）のやることと、ライブラリのやることを混同してるだろ。

>>869
じゃあどうしてるんだ

>>868
> SJISは２バイト目に\がある場合があるので、
> エスケープシーケンスと誤認しないようにチェックが必要

UTF16、UTF32は2バイト目、3バイト目、4バイト目に
\0が、よく使われる英数文字に入るので、今のコードは使えない。

もし、printf((char*)"Hello World") （Hello WorldはUTF16）
なんてことをすると、Hしか表示されない（エンディアンによっては何も表示されない）

>>876
今はUTF-8の話してるんだから邪魔しないでくれ

>>871
> wchar_t用の関数を使えばよい、もう15年も前の標準だ

そこで俺が止めを刺してやろう。
wchar_tを使うfopenの代わりになる標準関数は無い。

つまりUTF8以外のUNICODEのファイル名は
オープンできませんｗ

だいたい、wchar_t用の関数を使ってないコードが
たくさんあるから、大問題って話だろうが。
みんなprintf使ってるよ？ 知らないの？

>>875
エスケープシーケンスはコンパイル時に解決されるので
printfは解析しない

ならprintfに変更すべき点はないのか・・・

>>878
一体何が「とどめ」なんだ？

Unix系のOSにおいて、ファイル名はテキストではなくただのバイト列なんだから、
char*で扱えばよいだけだ
何でもかんでもwchar_tにしろとは誰も言っていない

もしwchar_tで保持されているテキストをファイル名として扱いたいときは、
wcstombs()などで変換すればよいだけだろ

本当に毎日楽しいスレだな

>>875
じゃあどうしてるんだって？
そんなもんコンパイラがSJISで書かれたコードだと判断したら、
SJIS用に2バイト目に\がある場合の処理をちゃんとするだけだろ。

ここまでがコンパイラの仕事。

printf()には%lsでwchar_t文字列を食わせられるだろうに

>>881
> Unix系のOSにおいて、ファイル名はテキストではなくただのバイト列なんだから、
> char*で扱えばよいだけだ

ただのバイト列じゃないよ。\0で終わるバイト列。
UTF16やUTF32は文字に\0が含まれるため、
ファイル名が途中で切れることになる。

つまりchar*でUTF16、UTF32はどうやっても扱えない。
UNICODE系はUTF8だけがchar*で扱える。

wchar_t使ってんのは実質Windowsだけだろ。

>>885
wcstombs使えばいいで答えが出てる

>>878
utf-8でエンコードしたファイル名を受け付けるかどうかは処理系依存だがな。

>>887
じゃあwcstombs使ってファイルオープンするコード書いてみｗ

>>885
そういう話か
それはその通りだが、プログラム側としては「ファイル名のエンコーディング」
というものは意識しない／仮定しないのが正しい
あくまで0終端されたバイト列で、それ以上の物ではない

>>886
想像で嘘を言わないように
例えばwcwidth()はワイド文字の幅を取得する関数だが、非常に多くのプログラムで使われている
http://www.google.com/codesearch?q=wcwidth&hl=ja&btnG=%E3%82%BD%E3%83%BC%E3%82%B9%E3%82%B3%E3%83%BC%E3%83%89%E3%82%92%E6%A4%9C%E7%B4%A2

>>888
> utf-8でエンコードしたファイル名を受け付けるかどうかは処理系依存だがな。

それは問題ない。UTF-8はASCIIと互換性がああるため、
コード自体にUTF-8対応の処理は必要ない。
ま、あえて言うのなら1文字を8bitで処理していればいいだけ
（つまり7bitではないということ）

EUC-JP対応なら当然8bitで処理しているので、
何の問題も無く、UTF-8のファイル名をつけつけられる。

だから互換性が高いといわれているんだよ。
そしてそうではないUTF-16、UTF-32がだめだって話の流れ。

（しばしばゼロ終端された）バイト列を扱うコンテキストにはUTF-16やUTF-32は
向かない
ファイル名や入出力などだ

が、プログラムのメモリ上で扱う内部エンコーディングとしては何の問題もないよ
特にUTF-8と16, 32はただの表現形式の違いに過ぎないのだから
容易にかつ無問題に相互に変換できる

自分のアプリだけで完結するのなら
文字コードは好きにしろって話だけど、
ま、普通は既存のライブラリを使う。
そして既存のライブラリの多くはchar*が使われている。

これを変更するとなると影響範囲が大きすぎる。
そこで作り出されたのがUTF-8。UTF-8を使っていれば、
外部のライブラリからはまるでASCIIで渡されたような感じで処理できる。
これが互換性。

ファイル名や入出力だけでなく、
外部のライブラリを使う場合もUTF-8が優れている。
もしすべてをUTF16とかに変えようとすると、多大なコストがかかることになる。

今日になって1時間足らずで30も伸びていてマジ驚愕

printfスレでやれ

誰が誰と何を争ってるのか全くわからん。

>>860

だすらprintfは、sjisだろうがutf-8だろうが関係なくてchar *を
淡々と扱うだけで、sjis用printf だのutf-8用printfなんてのは
ない。　だからsjis用printfって何？って問うたんだよ。

>>871

そのlocaleとwchar_tに関してgccなどは地雷を抱えてたりするわけだが

文字コードと直接関係ないんだからC言語のスレでやれよ。

>>891
つけられたってしょうがないだろ。
無理やりUTF-8で名前つけたファイルはEUC-JPを前提にしてる処理系ではファイル名が悉く文字化けする。
今までのソフトウェア資産を捨てるか改造して、全部UTF-8にするってのなら別だけど。

>>900

それはUTF-16だって同じ事だろ。

ASCII前提の処理系でASCIIで名前を付けたファイル名を扱うプログラムを
そのまんま、UTF-8前提の処理系でUTF-8のファイル名を扱うプログラム
として使用できる（ごくわずかな修正で）って話なんだから。

晴れてるけど土砂降り

このスレの情景か

C++は第一引数にwchar_tを使えるfopenあるよ〜

>>901
勝手に処理系を仮定されてもなぁ。

勝手に処理系を仮定って言うけど、
EUCも同じだろ。　あとはEBCDIC とかEBCDIKとかかw

>>906
別にEUCじゃなくても文字化けするよ。
>>891が
>EUC-JP対応なら当然8bitで処理しているので、
>何の問題も無く、UTF-8のファイル名をつけつけられる。
なんて面白いこと書いてたから。

UTF-8を引き摺りおろそうとする気持ちはわかるが
UTF-16の方がもっとひどいという事実は変わらないよｗ

>>900
> 無理やりUTF-8で名前つけたファイルはEUC-JPを前提にしてる処理系ではファイル名が悉く文字化けする。
うん。文字化けに見えるよね？
人間としては正しいよそれは。

だけどね、バイナリとしてはどちらも同じなんだ。

文字化けというものは二種類ある。
一つは、化けてしまったら、元に戻せない文字化け。
もう一つは、化けても、元に戻せる文字化け
（ブラウザとか。エンコード切り替えするだけでちゃんと表示できる）

化けても元に戻せる文字化けというのは、処理の段階で文字化けは発生してないんだよ。
単に表示する段階で違う文字で表示されているだけ。データとしては一緒。
ようするにASCIIを扱う関数にUTF-8を渡しても正しく処理してくれる。ま、ごくわずかの例外はあるが。
例外というほど、少ない事例。そしてUTF-16をASCIIを扱う関数に渡したらほぼすべて動作しない。

>>908
別に誰も引きずり下ろそうとしてないよ。

>>909
fopenにおいては、それじゃダメだろ。そしてremoveもrenameも例外か。
標準ライブラリ関数は例外か例外でないかのリスト用意すれば見分けが着くが、
人が作った関数はリストなんて作ってられないからなぁ。いちいち中身みないと。

そのまま渡したら動作しないことには誰も反論してないのに、なんでそれをまた主張するかなぁ。

プログラムの側で実行環境のlocaleは仮定しちゃだめだし、仮定できないだろ
localeがUTF-8なら上手く動きますよ、じゃダメ

（大した内容でなくとも）なんらかのテキスト処理をするプログラムは
事実上エンコーディング変換は必須だろ
8bitクリーンにしとけばいいなんてのは、バイト列をそのまま右から左に
流せばすむプログラムだけだ

>>910
なんか勘違いしてない？

fopenにUTF-8の文字コードのファイル名を渡したら
正常に処理されるよ。

実際にfopen使ってコード書いて、
UTF-8のエンコードに設定してある
Linuxで動かせばわかるじゃん。

fopenにUTF-16のファイル名を与えたら・・・・
型が違うから与えられないけどなｗ
UTF16は互換性が無い。

>>913
お前は前々から誰と戦ってんだ。
UTF-16がマルチバイト系のエンコーディングと互換性がないのを理解していない奴なんて誰一人いないじゃないか。

> お前は前々から誰と戦ってんだ。
wchar_t野郎ｗ

文字コード方面は処理系ごとで違いがありすぎるからな。
wchar_tもwindowsではutf-16だかucs-2だか、glibcではutf-32だかucs-4だか、
それ以外じゃ下手すると非透過で>>849みたいな話になるし。
ファイル名とか言い出し始めるとOS/実行環境にも依存するべ。
現実的には標準関数のレベルで汎用的にはしよーとしないのが吉じゃね、本気でやるなら。
使い捨てのコードなら用が足りる程度に動きゃ何でもいい。

>>912
何も勘違いしてない。君が混乱してるんじゃないのかい？
utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね？

みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
そうじゃないことも分かってるんだよね？

Subversionスレから導かれて来ました。
git,Mercurialで日本語だとsjis,utf-8混在環境は簡単に出来ちゃうわけで。
日本以外でも、latin-1やロシア東欧のコードとutf-8の混在が問題になっているわけで。
sjis,euc混在という先輩でもある日本としては、パス名として厄介な'/','\'が含まれず、
無効の判断が容易なutf-8が現時点での妥協点では無いでしょうか？
Linuxでは、ロケールutf-8じゃないと動かないアプリが多くなってきましたし。

誰だ召喚したのは

>>918
他の文字コードを使う積極的理由がなければ、utf-8に統一していくのが今のところベストだと思うよ。
「何があってもutf-8以外は認めない」って主張は受け入れる気にはなれないけど。

いきなりなんでそんな話を？

>>917
> utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね？
どうなると思ってるんだ？

utf8なバイトってのもよくわからんな。

16進数で考えれば、UTF8もそれ以外も
0x00〜0xFFのバイトの並びでしかないだろ。

>>922
latin1ならその考えでいい。utf8はそれなりに考えられて作られている。

> utf8はそれなりに考えられて作られている。
その中身を言えって。お前何も言って無いじゃん。

>>920
> いきなりなんでそんな話を？
・ファイル名がunicodeというのはマルチプラットフォームでないということ
・そういえば、Javaってどうだったけ
・cygwin utf-8という曲者も出てきた

> utf8ロケールじゃない環境でfopenにutf8なバイトを送ったらどうなるか分かってるんだよね？
重要なことだからもう一度言います。

どうなると思ってるんだ？（笑）

>>917
俺は>>912ではないが
lsなどで表示したらそのファイルは文字化けして見えるだろうが、
それでfopen()では何の問題も無く開ける

あくまでそのロケールで「テキストとして解釈できない」だけだ
fopen()のような関数は名前をテキストではなく単にゼロ終端されたバイト列として
扱うので、テキストとして解釈できないことは何も問題ではない

一方、Javaあたりだと、ファイル名をテキスト(String)として扱うので、
そのファイルを開けないと思う

それがUTF16やUTF32だと文字の一部にゼロが含まれるので
ゼロ終端されたバイト列として解釈できないんだよね。

だからLinuxはUTF8のロケールには対応しても
UTF16等には対応していない。LinuxはC言語をベースに作られているので
対応しようとなると大幅な変更が必要になる。

localeをUTF16化しろとは誰も言っていないんじゃないの
UTF16や32は、基本的にプログラムの内部で（ワイド文字で）使うための
エンコーディングでしょ

そんな話だっけ？
UTF16に簡単に変更できるとか言う話じゃなかったか？

>>927
そのとおり。

そして>>917の後ろにも
> みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
> そうじゃないことも分かってるんだよね？

って書いてある通り、みんな勝手にutf8仮定でやってたら、表示させたときにも文字化けしないが、そうでない場合、文字化けする。
そしてバイト列として、意図した通りの解釈方法をする方法が存在すれば、文字化けしていてもいいというのは実用上は明らかに正しくない。
(それでいいというのなら、そもそもファイル名に非ASCII文字を使う意義はない)

>>931
そんなこと誰が言った？

一体UTF8の人は誰と戦ってたんだろうって思ってたが、ようやく疑問がとけた。
UTF8の人はUTF8にするのに、本当に何も手間がいらないと思い込んでいる。

そして、それはコンパイル通ってアプリケーションが落ちなければ、文字化けしてもどうなっても構わない、
という観点でいうのなら、正しい。


UTF16持ち出してきた人はUTF8にするにしても、文字化けしないなどの動作としての正しさを検証するためには
どうせソースをひっくり返して読まなければならず、それをする手間はあまりに多いので、
ついでにcharをwchar_tに、printfをwprintfにするくらい大したことじゃないと考えている。
そしてUTF8なら変更不要って、検証コストはどこにいった、それを評価した上で言ってるのか？と言っている。

wchar_tへの変更がついでにできてしまうほどに検証が大変だというのは大げさだろうが、
検証コストの大きさが無視できないのは確かだろう。
実際に、UTF8の人が勿体つけて出してきた「fopenはchar*しかうけつけない」というのも、
そのまんま渡すと文字化けする代物だったし。

つまり、結局のところ、UTF8 vs UTF16って構造は間違いで、
UTF8だと手間なし派 vs UTF8でも手間はかかる派　　なわけだ。にもかかわらず

UTF8でも手間はかかる派：　UTF8でかかる手間を指摘
UTF8だと手間なし派：　UTF16でかかる手間を指摘
してるから、手間なし派は見えない敵と戦ってるようになってしまってる。

>>932
> >>927
> そのとおり。
>
> そして>>917の後ろにも
> > みんながみんな、ファイルIOに、ロケール無視してutf8使ったら、それでうまくいくかもしんないけど、
> > そうじゃないことも分かってるんだよね？
>
> って書いてある通り、みんな勝手にutf8仮定でやってたら、表示させたときにも文字化けしないが、そうでない場合、文字化けする。
> そしてバイト列として、意図した通りの解釈方法をする方法が存在すれば、文字化けしていてもいいというのは実用上は明らかに正しくない。
> (それでいいというのなら、そもそもファイル名に非ASCII文字を使う意義はない)

IMAP UTF-7 ってのがあってだね・・・

>>935
あー、だからお前はあんなこといってたのねｗ
今やっとお前がずれていることがわかったわ。

UTF8が文字化けするというのはあくまで表示の話で、
処理の内容は何も変わっちゃいないというのが
理解できてないんだから笑っちゃう。

fopenが何一つ修正なしに、UTF8の文字のファイル名を
受け取れるということが、理解できないようだね。

極端な話、fopenの中で動くファイルシステムのコードが正規化を考慮するかって話の時に
知るか馬鹿って側と気になってしょーがねえって側の戦いみたいな。
あとはfopenの中の人がsjis期待しててsjis的に不正なシーケンス受け取ったらどうなるかとか？

>>939
不正なシーケンスじゃないけど、Windowsのダメ文字問題があって、
Windowsの場合、fopen_s, _wfopen_s という２つの関数がある。

> あとはfopenの中の人がsjis期待しててsjis的に不正なシーケンス受け取ったらどうなるかとか？
やっぱり理解してないね。

fopenが期待しているのは、
ゼロ終端されたバイト列。
文字コードは考慮していない。

>>940
> >>939
> 不正なシーケンスじゃないけど、Windowsのダメ文字問題があって、
> Windowsの場合、fopen_s, _wfopen_s という２つの関数がある。
fopen自体はダメ文字は関係ないのか？

>>937
匿名掲示板でお前って誰だww

>>938
どのレスがそれ理解できてない人？

>>941
その通りで、君が言っていることは
fopenの第2引数が期待してるのがゼロ終端されたバイト列であって、
別にrとかwとかである必要がない、と言ってるのと同じくらい正しい。

fopenの第一引数の間違いだろ。アホめ

泥沼化したこの闘いに終わりはあるのか

>>941
実装が余計な事しないのを保証する規格にもなってないんじゃね？
正規化考慮する環境があるくらいだから、勝手にゲタにされてもビビらねえなと。

> 正規化考慮する環境があるくらいだから、勝手にゲタにされてもビビらねえなと。
何の話してるの？

fopenでゲタになんかならないけど。

そもそも勝手にゲタになってしまったら、
違うファイル名（もとからゲタになっているファイル名）
を開いてしまうことになるぞｗ

>>945
そだね。>>941は第一引数に限定してないよね。

なんか文字の1と、数値の1の違いを
理解していない奴を相手にしているような気がしてきたｗ

fopenの中の人がsjis期待してるとか
意味不明すぎで、こいつが何を考えているのかわからん。

いやあ、保証があるかの話で具体例は知らんのだけど。
>>949がありえない話なのだろうか？という疑問

「ゼロ終端されたバイト列」の説明が必要では？

>>952
それは、幽霊肯定派が、幽霊は本当にいないのだろうか？って言っているようなもんだな。

幽霊がいるというのなら、幽霊がいるという証拠をもってこい。
ありえないといいたいのなら、ありえない証拠をもってこい。

>>953
え？説明されんとわからんのか？

だから話が通じないのかｗ

>>951
fopenのプロトタイプはsjis期待してないけど、中の実装は期待してる。

Windows環境(パスの区切り文字は0x5c)を仮定するとだな。
ファイル"\x61\x5c\x61"は、ディレクトリ./a上のファイルaと解釈されるが、
ファイル"\x95\x5c\x62"は、ディレクトリ./上のファイル表aと解釈される。

つまり文字コード厄介だからおまえらナメてかかるんじゃないぞという理解でよろしいか？

>>957
うん。あるいはutf-8にすれば全てが嘘のようにうまくいく。どっちか信じたい方。

SJIS, Windowsの話は出てきたけど、UTF-8-MACは？

MACてなに

>>956
だがな。UTF8はその0x5Cを
二バイト以降に配置しないようにしているから、
何の問題も無いんだよ。

互換性問題を解決した文字コード。
fopenを何の問題も無く使える。

全てが嘘のようにうまくいくように
考えて作られたUTF8で
全てが嘘のようにうまくいくのは当たり前。

LinuxってSJISに対応していないんだな。
ASCII互換ではないかららしい。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?forum=10&topic=17296

逆に言えばASCII互換なら全て問題が解決する。
ということでUTF8が選ばれた。

Sambaはutf8にしても安全になったの？

>>956
それは、Windowsが特別にそういう実装になっているだけだな。
SJISはMSが作ったのだから、そういう変則的なことに対応していても不思議は無い。

だが、一般的なfopenではそんな実装をするとは決まってないし、
実際に実装されてない。ASCII互換でないものをもってきても
ASCII互換であるUTF8の例えにはならない。

というかSJISで開くべきならSJIS使いなさい、
UTF-8で開くべきならUTF-8使いなさい以上の話ではないなという。

UTF8の互換性の高さの話だろ。
なにも修正しないでも多くの関数でそのまま使える。

>>961
でも0x95が2バイト目以降に来る場合はあるでしょ？
そしたら、その次の0x5cはバックスラッシュを意図しているはずだけど、そう解釈されない場合が出てくる。

>>965
特殊実装扱いにするにはメジャーすぎるよ。
けどそういうのはどうでもよくて、もともと>>956出したのは、
sjisを要求するfopenが存在しないかのように書いた人がいたからなんだけどね。

そして、sjis程度のascii非互換性でutf8神話は崩壊するって思っていいんだね。

>>966
全くその通り。それが一番正しいし、ほとんどの人にとってそれが当たり前。

>>968
> でも0x95が2バイト目以降に来る場合はあるでしょ？
ASCII互換のUTF8は無い
そうならないように作られた。

>>969
ﾑﾁｬｲｳﾅ

ツッコミどころがおかしいんだよ！
SJIS期待してるとこにUTF-8でしかもASCII外の文字食わして何する気だってとこなんだよ！
だから>>966で解決なんだよ！

色々な論点がごっちゃになっとるなあ
プログラムの内部エンコーディングと外側でユーザが設定するロケールは
別物だろうし…

UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん
ユーザに、UTF-8ロケールにしてファイルも何もかもUTF-8にしなさい
そうでなきゃ僕は知りませんと言いたいのか？

>>972
Windowsのような特殊環境以外はfopenは文字コード関係なく'\0'で終わったchar*で問題無いって話なんじゃないの？

>>973
char*でやろうがwchar_tでやろうが別にかまわないが
エンコーディングの問題からは逃げられんだろ
一般に、localeや処理するテキストファイルの中身がUTF-8だとは限らないのだし
UTF-8だとしてもテキスト処理においてはマルチバイト処理を必要とする
Shift-JISよりはずっと性質のいいエンコーディングではあるが

>>974
fopenの話に収斂していたと思うけど、どこから遡ればいいの？

fopen()だけ取り出してエンコーディングの問題を論じるのはナンセンスじゃないのか
まあそういう話ならどうでもいいし、特に言うべきことはないが

>>971
必死だなｗ

ASCII期待しているLinuxに
UTF8を食わして問題無いんだよ。
互換性だからな。

>>974
> >>973
> char*でやろうがwchar_tでやろうが別にかまわないが
wchar_tじゃだめでしょって話で、
ここまでやって例が１つもないから作った。

#include <stdio.h>
#include <stdlib.h>

int main(int arvg, char* argc[])
{
wchar_t *w = L"aaa";
FILE *f ;
f = fopen((char *)w,"w");
fclose(f);
return 0;
}

他の文字コードを使う積極的理由がなければ、utf-8に統一していくのが今のところベストだと思うよ。
「何があってもutf-8以外は認めない」

>>978
内部コードをそのままI/Oに使うとは、アホかｗ
内部のテキストをwchar_tで持っている場合、I/Oでは変換するのが普通だし
Unix系のOSでファイル名をわざわざwchar_tで扱う意味も無い

その変換が必要ないのがUTF-8なわけだ。
これも互換性の高さゆえだな。

変換が必要が無いのは、外部エンコーディングがUTF-8である場合だけだろ
Unixではユーザが任意にlocaleを設定できるのだし
テキストには多様なエンコードが使われている（メールは今でもiso-2022-jpだ）

単にそうなればいいね、便利だね、というだけの話？
実はそこで話がずれてんの？

> Unixではユーザが任意にlocaleを設定できるのだし
だから、Unixで指定できるlocaleは
ASCII互換で無ければならないんだよな。

SJISとかUTF16とかUnixは対応していない。

>>977
いつからLinux限定の話になったんだ? euc-jpじゃダメなのか?

euc-jpもASCII互換だからね。
日本語だけしか扱えないけど。

>>983
だから、EUC-JPとかは普通に使えるし、伝統的に使われてただろ
EUC-JPとUTF-8でテキスト処理を書く場合、同じコードにはならない
EUC-JPではリードバイトと後続バイトの区別がつかないから
文字の区切りが知りたければ先頭から舐めるしかないからだ

それにファイルの中のデータとして使われるエンコーディングならもっと範囲が広い
2chは言うまでも無くShift_JISだ

>>986
うん、だけど、EUC-JPは2バイト目に0x80以下の文字を含まないから、
たいていの日本語に特に対応していないプログラムでも普通に処理できてしまうわけさ。
これが互換性の高さ。UTF8も同じだよね。

それに引き換えSJISやUTF16は2バイト目に0x80以下の文字を含むから
別途対応が必要。

おまいら>>1にマッタリって書いてんだろ
一日でどんだけ伸ばしてんだよ
シバくぞ

> たいていの日本語に特に対応していないプログラムでも普通に処理できてしまう
甘い
EUC-JPもUTF-8もバイト数＝文字幅ではないし
半角カナ絡みで問題を起こすプログラムは非常に多かったし
文字を文字として認識しなければ、文字の真ん中で文字列を区切ることも普通に
有り得る

「たいていの」は言い過ぎ
「ほとんどテキスト処理を必要としないプログラム」ぐらいが本当のところだろ

実は共通認識が多いんだけど、喧嘩する為にお互いあえて無視しているスメル
そろそろ次スレでつね

うめ

2chはどうして糞で最悪のSJISを標準エンコードにしたんだろｗ

>>989
だが文字がずれる程度でたいていは処理出来てしまう。

うめ

>>993
じゃあ、後ろ1文字消す処理はどうするの？

>993
半角ｶﾀｶﾅが含まれてると固まったり落ちたりするﾒｲﾙｸﾗｲｱﾝﾄが沢山あったんだよ

>>951

だなw

相手がsjisを期待していようがutf-8を期待していようが、fopenは
変わらず、相手の期待する文字列をchar *で渡してやればいい。

wchar_tだと、そうはいかないって話なのにね。

>>995
後ろ1バイトが消えるだけ。

>>996
それは8bitコードに対応していないだけだね。
今は普通8bitに対応しているから問題なく動くという。

>>972

>UTF-8にすると何もかも上手くいくよ派は、何を言いたいのかよくわからん

そんな奴いたか？　wchar_tにすれば何もかもうまくいくよ派は居たけど。

>>997
じゃあ、wchar_tに全部置き換えればいいだけ。
define でcharをwchar_tにすれば
解決する話だ。

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。