文字エンコーディングはUTF8で本当に十分なのか？ 227
ストーリー by GetSet
課題色々 部門より
課題色々 部門より
ee1000mt 曰く、
RedHatの技術者であり、Debian開発者でもあるtagoh氏のblogに「 UTF-8は十分かどうか」という書き込みがある。
これは、「 シフトJISを捨てられるか?」というITproの記事に対して、Ruby開発者のMatz氏が 「『短いに越したことはない』というごく弱い理由で、さらに別のエンコーディングの必要性をほのめかさないでいただきたい」 と、自身の日記で述べていることに対して、 tagoh氏が意見を述べているものだ。
tagoh氏によれば、エンコーディングを増やさないことは賛同できるが、「UTF8でいいのか」というところには特に他言語を考慮した場合において疑問を呈し、 「エンコーディングに言語タグでも入れた方がいいんではないだろうか」と意見を述べている。
locale併用というのは今の方式だが、これでは複数言語を使えないわけで、tagoh氏の言語タグということには賛同できる。 さて、UTF8で果たして今後も十分なのか、そうじゃないとしたらどうあるべきなのだろう？
UTF-8で十分なわけないじゃん (スコア:5, 参考になる)
いろいろな需要があるからいろいろな文字集合とその符号化方式があるのです。べつに昔との互換性だけが存在理由ではありません (もしそうならどうして 2004 年になって JIS X 0213 の改訂なんかしているのか)。
ITpro の記事では、日本語文字列を扱うための符号化方式として、
という比較をして、
と問題を提起して終わっているのですが……その条件なら、 Shift_JIS-2004 (シフト JIS の JIS X 0213 版) でよいと思います。 JIS X 0213 の文字が全部使えて、しかも 1 文字 2 バイト以内です。 (ただし、当然ながら 1 文字 2 バイト以内を堅持しようと思ったら今後文字を増やす場所があまりありません。)
ITpro の記事の著者が存在を知らないだけ? JIS の規格票にも書かれている符号化方式なのですが。僕が何か勘違いをしている? (その可能性は高いです。)
僕は 1 文字 2 バイト以内であることが重要になるようなギリギリの世界でプログラムを書く予定はないので、日本語以外も扱える UTF-8 や UTF-16 で十分です (UTF-16 は Windows のネイティブの符号化方式なので使います。それがなければ UTF-8 だけで十分)。でも、僕の需要だけ満たしてくれても駄目で、世の中にはいろいろな需要があるので、すべてが UTF-8 になるわけがありません。日本語の文字だけ表せればよくて、その代わり UTF-8 や UTF-16 では駄目なくらいデータ長に厳しい制約が課せられる状況では、 Shift_JIS-2004 が適任だし、そんな状況はありえなくはないでしょう (珍しいとは思いますが)。
Re:UTF-8で十分なわけないじゃん (スコア:2, 参考になる)
業務上では外字を利用している場合もあり、この場合Shift_JIS-2004 では外字領域を潰して文字を割り振っている点により互換性が失われるところが致命的です。
# 1 バイト 32bit 位にしてあげれば 2 バイトに収まるよ(w
何周目かと (スコア:4, 興味深い)
一度、Unicode 制定前後からの歴史を勉強したほうがいいと思うよ。
文字の海、ビットの舟あたりを軽く流し読みした程度で、よく知らないで言うのは口はばったいとこも
あるんだけども、シフトJIS みたいな完全にローカルな文字コードならともかく、それなりに
多言語を考慮した文字コードってのはどの陣営にも存在してて、紆余曲折があって今みたいに
なってるんだよね。
結局最終的にどうなるのか、ってのは政治力に依存するんじゃないんかな。
朝令暮改には正直うんざりなんだけども。
言語タグならあるでしょ？ (スコア:4, 参考になる)
Unicodeはテキストを表現するための文字コードに過ぎないのだから、
字形の違いのようなフォントに関する情報は、文字コードよりも
上のレイヤーで扱うべきというのがUnicodeの立場だと思うのだが、
tagoh氏やタレコミはその立場を踏まえた上で意見を述べているのだろうか？
Re:言語タグならあるでしょ？ (スコア:3, 興味深い)
ただ、誤解のないように申し上げると、「文字コードよりも上の
レイヤーで扱うべき」というスタンスは理解した上で、(Language
Taggingの存在を知らずに)あれを書きました。プレインテキスト
自体が幅広く使われていて、多言語をひとつのファイルで書き連ねる
ものも多く(主観ですが)、立場とは裏腹に需要もあるようですので。
# /.Jへのタレコミは予想外でしたが、タレこんでくれた方のおかげで
# 個人的にはたいへん有用な情報をたくさん拝見させて頂くことが
# できたので、これはこれでよかったのかなと思っています。
昔から文字コード話は盛り上がるよねぇ (スコア:4, 参考になる)
Unicodeが流行る背景にはソフト開発のグローバル化がありますよね。
英語版を作って日本語版にローカライズするのではなく、最初から内部処理はUnicode（UCS-2）で作って、UIのみ各国語で作る。以前、あるメールアプライアンス会社の人が「うちの製品はUnicode対応なので日本語にも対応している」と主張するアメリカのエンジニアに「日本ではISO-2022-JPという特殊なコードが使われている」ことを説明するのに難儀したと言っていました。簡単にいえば、インドでアプリを作って世界中に売りまくるビジネスが流行っているので、このままUnicodeで行くんじゃないですかね。
もちろん、Unicode（UCS-2）あるいはその符号化方式としてのUTF-8やらUTF-7、書体への対応付けにはいろんな問題もあるんでしょう。しかし、「文字の話は7層に分けて考えてねー」 [ietf.org]って言っている人たちもいますよ。問題があれば符号化層ではなくて、上位層のタグ付けなどで解決するのがスジなんじゃないでしょうか。
/K
全ての文字を表すなら (スコア:4, すばらしい洞察)
流行らないはどうしてだろう？
うちの親、名前に特殊な漢字使ってるので、
現状だと TRON コード以外では表記できないんだよね、、、orz
JIS でも Unicode でも結構だが、
未だに自分の名前すら漢字で表記できずにいる人がいるって事を
ちったぁ考慮して欲しい、、、orz
そもそも国も戸籍行政かかえてるくせに、
この辺りのコード整備を怠り過ぎなんじゃないのかと、、、
あと、古文書なんかを扱ってる方面の方々は、
電子化する場合どうしてるんだろうか？
uxi
Re:全ての文字を表すなら (スコア:2, 参考になる)
役人が書いた崩し字・誤字などがそのまま「正式な名前（漢字）」として
戸籍に登録されてしまっているケースが結構あるそうで、
それゆえに、「点が１個無いだけ」とか「１個多いだけ」とか、
似たような漢字が別の漢字として扱われています。
もちろん、れっきとして別の漢字である場合もありますが、
役人のミスが原因である場合も、少なくないようです。
そういった漢字を統一するだけでも、かなりスッキリするのですが、
日本人にとって、名前に使われる漢字はアイデンティティにもなっており、
なかなか難しいようです。
なお、古文書については、聞いた話ですが、
草書体など、形に意味がある場合もあるそうで、
（崩し方で時代や書いた人が分かる等）
画像で管理していることが多いようです。
絵画を活字として電子化しないのと一緒だそうです。
きちんと活字に起こして電子化してる所もあるとは思いますが、
まぁ自分が知ってるところは、そんな感じですね。
Re:TRONコード (Re:全ての文字を表すなら) (スコア:2, 参考になる)
http://www.soumu.go.jp/denshijiti/pdf/060531_sk1.pdf [soumu.go.jp]
JIS X 4166で使えるのはJIS X 4165(ISO/IEC 10036)に登録されたグリフで、理論上グリフは1つ100円で誰でも登録できますが、現時点で実際に登録されているのは事実上文字鏡のみなので、政府が文字鏡の利用を念頭に置いていることは間違いありません。
完璧な文字コード (スコア:3, おもしろおかしい)
神の一撃によって、人々は異なる文字コードを使うようになった。そして、世界は混乱していく。
…、と「創世記」にあるとかないとか。
-- A.C., nothing more, nothing less.
Re:完璧な文字コード (スコア:2, おもしろおかしい)
EBCDICですか？
ぐちゃぐちゃだな (スコア:3, すばらしい洞察)
Re:ぐちゃぐちゃだな (スコア:3, 興味深い)
ある一定のところで閉塞してしまっていたのに、何を今さら
という気がしますが…
# そして、「今だからこそ」の新しい解決策なんて
# 一つも提示されないですね :-P
Re:ぐちゃぐちゃだな (スコア:2, おもしろおかしい)
Re:ぐちゃぐちゃだな (スコア:2, おもしろおかしい)
ちょっと古いけど富豪的アプローチ。
文字をコード化するから問題が出るのです。文字をそのものを扱うべき。
・文字は画像として保持します
・外部(入出力、他プログラム)などとの通信には文字画像を使用します
・プログラム内部では、適当なコードに割り振ってもかまいませんが、けして外部に出してはいけません
・文字画像から内部コードへの変換にはOCR技術を用います
・OCRは常にパラメータの調整が可能、また学習機能により人間に近い判断方法を取れることとします
・入力の簡略化として、キーボード入力をするとプリインストールされた文字画像を入力したものとみなします
・出力の簡略化として、プリインストールした文字画像を使用することができます
・プログラミングの簡略化のために各種ライブラリを用意します
-- A.C., nothing more, nothing less.
Re:ぐちゃぐちゃだな (スコア:3, おもしろおかしい)
そして情報の認識には支障が無いので、非可逆圧縮の方式が採用されました。
それは、Universal Transform Format - 8という呼び名で呼ばれたとさ。
略してUTF-8。
あれ？
#似た文字は同じコードに割り当たるなんて特性は同じですけど、偶然ですよ。(w
Ideographic Variation Database (スコア:3, 参考になる)
Ideographic Variation Database Submission [unicode.org]
公開レビューの締め切りは3月15日なので文句を言うなら今のうちです。
4日しかない? 3ヵ月前からレビューしてたのに誰一人気付かないのもどうかと。
ShiftJISなら非対応システムでも (スコア:2, おもしろおかしい)
個人的にはMatzきらいだけどMatzの意見に賛同。
#あほぷろぐらまなのでID
Re:ShiftJISなら非対応システムでも (スコア:5, おもしろおかしい)
私のナニに賛同してくれたのかさっぱりわからないけれど、
あなたが私をきらいだということはしっかり伝わりました(泣
まつもと ゆきひろ /;|)
Re:ShiftJISなら非対応システムでも (スコア:3, すばらしい洞察)
半角は1byteだから÷1ですよ!
まぁ、ネタにマジレスだとは思うけど。
そーゆー基本を忘れて書かれているプログラムを、実際に見ちゃってるとねぇ。
Re:ShiftJISなら非対応システムでも (スコア:2, すばらしい洞察)
問題は内部表現のつもりだったものは必ずと言っていいほど外に出てくるということですが。16bit固定長の時代のUnicodeは内部コードとして使うことを想定してたのでBOMがなかったり(その計算機で自然なバイトオーダーに決まってるから)変換表の違いに無頓着だったり(外に出て行かなければ問題は表面化しないから)してて、そのツケを今になって払わされてるわけです。
問題を理解するには (スコア:2, 参考になる)
なぜか英語だけど、
言語タグはいいじゃない？ (スコア:1)
ですから、言語タグを入れる方がいいじゃないと思います。
言語タグはXML・HTMLのタグを使え方と同じように入れるかな？
Re:言語タグはいいじゃない？ (スコア:5, おもしろおかしい)
禿胴
</2ch>
<科学>
現時点において否定する理由はなく、妥当な仮説として認められる。
なお、この判断については、元コメントの定量化・反証可能性についての定式化が必要と思われ……
</科学>
<slashdot.jp>
関係者なのでAC。
</slashdot.jp>
<テレビの報道番組>
大変興味深い意見をありがとうございました。
</テレビの報道番組>
<テレビのバラエティ番組>
<空気の読めないタレント>
えー、私もー、ばいりんがるだしー、（以下略
</空気の読めないタレント>
</テレビのバラエティ番組>
Re:言語タグはいいじゃない？ (スコア:1)
言語指定は文字エンコーディングと同じレイヤでやらなくてもいいのでは？ (スコア:1)
屍体メモ [windy.cx]
Re:言語指定は文字エンコーディングと同じレイヤでやらなくてもいいのでは？ (スコア:1)
シフトだのエスケープだのウットウシイものは要らぬ。言語コード込み32bits/文字固定長でおk。
Re:言語指定は文字エンコーディングと同じレイヤでやらなくてもいいのでは？ (スコア:1)
文字コード問題で思いつくもの (スコア:1, 興味深い)
同じ文字かどうか問題。(いわゆる)全角と半角のアルファベットAは同じとすべきか。漢字だと旧字の扱い。各国語のA(似た文字も含めて)は同じとすべきか。検索しやすさ(プログラム内での処理含む)にかかってきます。migemoみたいに類似文字をORする正規表現を作成させて、それでマッチさせるとか?
実装可能か、処理しやすいか。Unicodeがなんだかんだ言われても普及しているのは、実際に手を動かして動くものを増やしたからでは? ISO-2022との比較です。(比較できるものかな?)
-- A.C., nothing more, nothing less.
標準コード体系に使用目的への特化は要らない (スコア:3, すばらしい洞察)
Unicodeは情報交換や内部処理などの特定の目的に特化したものではありません。Asciiコードもそうですが、この手の標準コード体系は、どんな目的にもほどほどに使える中途半端な役割が求められます。そう考えると、今のUnicodeの中途半端さはまさに狙い通りだと思います。
UTF-8は1バイト文化を引きずっていますが、今のところはMatzさんが言うように短いに越したことがないという論理が勝っています。将来的にはどうか分かりませんが。
Unicode反対派は、このまま中途半端なものが定着するのを避けたいようですが、使用目的を考え出すとまず決まりません。使用目的を考えたところが間違いの元だと思います。
Re:標準コード体系に使用目的への特化は要らない (スコア:2, 参考になる)
#1123881 [srad.jp] をどう解釈すると「標準コード体系には使用目的への特化なんて必要ないということですよね」なのか僕にはさっぱりわかりませんが、それはさておき。
Unicode はいろいろな用途に使えることを目指して設計していて、それなりにいろいろな用途に使われています。一方、 Adobe-Japan1-6 (コード表 PDF [adobe.com]) などの CID 符号は書体内のグリフを区別するという用途に特化して設計していて、それはそれでちゃんと使われています。僕は知識不足でほかの例を挙げられませんが、ほかにも専用の文字符号は適材適所で使われていると思います。普段目にしないだけで。
「Unicode 反対派」というのがどういう主張の人を指しているのか知りませんが、もしもその人たちが何らかの目的に特化した文字符号を提案しているなら、それはその目的に特化した文字符号が必要だと思ったからでしょう。それなら Unicode に反対しているのではなく、むしろ Unicode の領分は認めた上で Unicode では力不足の領域の状況を改善しようとしているだけのことで、それって「Unicode 反対派」と呼んでいいのかという疑問が出てきます。
んー (スコア:1, 興味深い)
二人の視点がぶつかる見所 (スコア:1)
言語の開発者とOSの開発者の視点がぶつかる見所を解説してもらえないでしょうか。
多言語 (スコア:1)
ただ一番の問題はユニコードに完全対応した プレーンテキストエディタ が少ないということですねえ...
Re:うん。 (スコア:5, すばらしい洞察)
で、そういうことを考えると、和文のアルファベットは欧文のアルファベットと同じなのか、とか、そういう同字異体・同字異言語の問題はマシン毎にインストールされているフォントと複雑に絡み合って、今後もネチネチと開発者を悩ませ続けるのはもはや確定的な未来像だと思えます。つまり、その手のアプリケーションの実装上は常に文字の言語を意識し続けるわけで、メモリ展開後やセマンティックなレベルで言語を解釈するよりは、いっそのこと、それより低レベルな文字列の段階で、何れの言語に属しているかを明示しておきたい、と考え出す人が出るのは、当然ですよね。現行ではアプリケーションが独自に推測するしかないわけですし、その推測は、100%正しいわけではないのですから。
ただ、日本人としての本音を言えば、UTF8でほぼ問題ないだろう、とも言えてしまうでしょね。まあ、モンゴル語の文章に出てくる日本語をモンゴル語ごと引用した和文は表示が崩れるかも、とか、そういう重箱のスミをつつくような問題の可能性を排除しきない点で、UTF8は十分とは言えないだろうなぁ、とは思いますね。
そう思ってた頃が (スコア:2, おもしろおかしい)
もう、新しいデータはUTF-8でいいよ。 (スコア:2, すばらしい洞察)
と承知している。
いくらUNIX(的なもの)にうんざりしているとしても、なかなかUNIXを凌ぐものが出現しないのと一緒だ。
たぶん、あと20〜30年はバリバリの主流として君臨するんじゃないのか?
Re:文字コード間変換 (スコア:2, 興味深い)
UTF-8しか無ければ問題ない。
Re:文字コード間変換 (スコア:3, すばらしい洞察)
オマイラがShift_JISだと思ってる97% [mycom.co.jp]はShift_JISじゃなくてCP932(Windows31J,MS-Kanji等とも呼ぶ)だ。
本当に（規格上の）Shift_JISならunicodeと相互変換をしても文字(コード)化けはおきないハズ。（フォント環境の違いで字体化けはおきるかもしれんが）
Re:文字コード間変換 (スコア:3, 参考になる)
Shift_JISではなく正しくCP932として扱えばやはり変換しても化けない。CP932をShift_JISとして扱うから化ける。
Re:文字コード間変換 (スコア:2, 参考になる)
元コメント(#1123871)が言ってる「～」の文字化けの問題ってコードポイント自体の問題ではなく、コード変換テーブルの問題ですよね。
上の方で出てるコードページ（Shift_JIS, CP932, Windows-31J)で「～」はすべてコードポイントは8160で、一緒のはず。
CP932とShift_JISで文字化けが、っていう問題は
*MS932, Windows-31JなどShift_JIS系のコードページに本来のShift_JISに入っていない文字がある
*企業毎にShift_JIS系コードページの実装で文字セットとそのコードポイントの割り当てに違いがある
*それぞれのShift_JIS系のコードページとUnicodeのコード変換の対応表に違いがある (#1123871は、多分これ)
などという複数の原因があって、一緒くたにして議論するのはちょっと・・。
コード変換エンジンがそれぞれのShift_JIS系コードページ（特にShift_JISやCP932みたいな一般的なものに）にどのコードページ・コード変換テーブルの実装を割り当てているかが問題であって、CP932だから、Shift_JISだから化ける、化けないってのはちょっと本質的じゃない気がします。
ちなみにJavaを例にすると、
CP932はIBMの932のことで、マイクロソフトの932は Windows-31J か MS932。
Shift_JISはJDK1.4から本来のShift_JISになったはず（たしか）。
Shift_JISとUnicodeの変換に使われる変換テーブルと、CP932とUnicodeの変換に使われる変換テーブルが違うから、
「～」を Shift_JIS->Unicode->CP932 として変換すると一貫性が失われて文字が化ける、と。
重要なのは、行きと帰りで同じコードページ（というか、その文字にとって同じコード変換テーブルを持つコードページかな）を指定しないと文字化けを起こすということですね。
そういう意味で、行きと帰りで「正しい（文書などを作った人が意図した）」コードページを指定しないといけないんで、
一つのシステム上では一貫して同じコードページを使ったり、入力する前に強制的に揃えたりしないといけない。
こういうのを色々考えないといけないので、「めんどくさー」となりますよね。
Re:文字コード間変換 (スコア:3, 参考になる)
Shift_JISがCP932ではないから起きている問題なわけで、Shift_JISならShift_JIS、Windows-31J(CP932)ならWindows-31JとUnicodeとの相互変換をしてれば、変換できない文字は出てきません。WindowsはWindows-31Jを使っているので、Shift_JISや外国の文字なんか知らない、と変換しないだけのこと。
Unicode上の全文字がShift_JISで表示できれば文字化けは起きませんが、そんなことは無理。
あとは、Shift_JISとCP932に限らず、他のUnicode上の似た文字も寄せ集めてから変換すれば、化けることは少なくなります。○に株の㊑とか、①の❶➀➊とか。ゔとか。
okome
Re:文字コード間変換 (スコア:3, 参考になる)
いいえ。UTF-8しかなくたって、「〜」のつもりで「～」が使われたり
非互換な変換と全く同じ気持ち悪さを引きずる訳ですが。
あなたのシステムでUTF-8文書に「￣―＼～∥…－￥￠￡￢」と入力してみましょう。
「‾—\〜‖⃯−¥¢£¬」とはなりませんでしたか？
Re:文字コード間変換 (スコア:1)
行ったり来たり慣れるまで結構大変です。
AjaxはUTF-8だし、ファイルは直接いじりたいし。
Re:文字コード間変換 (スコア:2, 興味深い)
そうすれば、どんどんUTF-8の世界がひろがって、相対的に古いデータを取り扱うものは減っていく。
過去のデータを捨てる必要はないが、必要のなくなったデータは時間と共に消えていく。
古いデータが滅びるのは時間の問題じゃないですかね。
今日作ったデータが、20年後に"そのままの状態で"必要になることは無いと思います。
Re:文字コード間変換 (スコア:1)
とにかく、どれかに統一した方が扱いが楽になる
いろんな文字コードが混在してて自動認識すら完璧ではない今の状態で、
さらに文字コードを追加されてもなにも解決しないし下手すれば悪化するだけ
どーせどっかで妥協しなきゃならないのは確実なんだから、今あるもので妥協してもいいと思う
日本語しか見ないならShiftJISでもいいんだけど、そういうわけにもいかないみたいだし
UTF-8は良くできた妥協点だと思うな
Re:俺エンコード (スコア:2, 興味深い)
提案していたはずだ。フランス語に出てくるゴミが付いたようなアルファベットを1バイトに
格上げする代わり、漢字は4バイトになるやつだった。幸い、国際社会の良識(?)によって
葬り去られたことは言っておかなければならない。
UTF-8とUTF-16の二本立てという現状が定着するまでに、ナショナリズムを背景とする綱引き
がさんざん行われたことは覚えておくべきだし、今さら最適なエンコードを提案するような
フェーズではない、ということも覚えていて欲しいことではある。
Re:UTF-8は結構好きなんだけど・・・ (スコア:2, 参考になる)
まあ世間にはダメダメな実装があふれてるわけですが。
Re:UTF-8は結構好きなんだけど・・・ (スコア:2, 興味深い)
つい最近NTBACKUPを使おうとして、バックアップ選択ファイルを
自分で書いてみました。
notepadでUnicodeを選択しろと言うことだったのでそうしました。
1番目に書いたフォルダがバックアップされませんでした。
散々ごちゃごちゃやって
・notepadでUnicodeを選択するとUTF-16(little endian,BOM付)になる。
・NTBACKUPではUTF-16(little endian,BOMなし)でないとうまく動かない。
らしい(手元のWindows XPでの実験結果)、という結論になりました。
OS標準ツールの間ですらこんな感じですから、いわんや他の実装をや。
バイナリフォーマット (スコア:2, 参考になる)
他の皆は multilingualization（多言語化、日本語の中で中国語を引用するとか）の話をしてる
みたいなので、Byte Order Mark みたいな話は答えになってないと思います。
文字コード体系とエンコーディングが違うとか言い始めた時点でもうテキストじゃなくて
バイナリファイルフォーマットなんだから、バイナリフォーマットらしく振舞えばいいんじゃないかと思います。
タグ付けられて何が困るっていうと、まず通信エラーなどで途中でぶつ切りになったり、
エディタで途中からコピーペーストした時に<日本語> 開始タグがどこに出てきてるかさかのぼらなきゃならない。
一行前かもしれないし、1GB前かもしれない。その点 Unicode サロゲートは 4byte 前と後を読めば切れ目が分かる。
バイナリフォーマットで使われるのはファイルをブロックの配列と考えて、固定長のブロックならブロックの先頭のヘッダまでさかのぼればいい。これをやるのが Unicode エンコーディングの仕事なのか、その上のレイヤなのかっていうのはジャンケンで決めればいい話。