«前の日記(2007年03月11日) 最新次の日記(2007年03月13日)» 編集

Matzにっき

2007年03月12日 [長年日記]

_ [言語] インド語の「あいうえお」

昔からなぜ「あ、い、う、え、お」という順番なんだろう、と不思議に思ってはいたが、まさかインドに由来があるとは。

以下は~~インド方言の一つBrahmi語~~ インド地方のBrahmi文字の一覧。ちょっと母音が多いがおおむね「あいうえお」の順番に並んでいる。他のインド語でも同様の順序らしい。子音も「あかさたな〜」に近いように思える。

知らんかった。

_ スラッシュドットジャパン | 文字エンコーディングはUTF8で本当に十分なのか？

先日、「シフトJISを捨てられるか?：ITpro」についてとりあげたら、tagohさんが「The day-to-day thoughts - UTF-8は十分かどうか」と反応して、さらにスラッシュドットでとりあげられた。

厳密な話をするならば、欠点のない文字集合もエンコーディングも存在しないので、どのような文字集合を選んでもどのようなエンコーディングを選んでも不満を持つ人はいるに決まっている。

この文字集合には私の使いたい文字が無いとか、性能上の問題がどうとか、文字化けがどうとか。これについては、ケースバイケースとしか言いようがない。

というわけで、各論。

「シフトJISを捨てられるか?」について言えば、要旨は

シフトJISでは文字が足りない(ような気がする)
Unicode(UTF-8)では日本語のデータ量が増える
だったら、新しいエンコーディングというのはどうだろう

というものだ。実際、この記事の流れではUTF-8でダメな理由ってのは、「日本語のデータ量が多くなること」、「シフトJISではないこと」だけなので、それってのは「新しいデータ」についてはさほど問題ではないと思う。

「新しいエンコーディング」というものは、

エンコーディングを決めて
実装を提供して
それを広く使ってもらうように働きかける

という手順を踏んではじめて実用的になる。どの段階もそれなりに大変だ。特に「広く使ってもらう」というのは技術的な問題ではないので、相当難しい。今時、単にちょっとデータ量が節約できるくらいの理由でまったく新しいエンコーディングが採用されるってことはほとんど期待できない。

ちょっと考えただけでも、

主要なエディタで対応する
主要な言語で処理可能になる
iconvで変換できるようになる

くらいは必須だろうけど、気が遠くなるくらい難しそうだ。

とはいえ、ITproくらい影響力があると(あるんでしょ？)、なんかで間違っちゃってその気になる人がいないとは限らないので、うれしくない。

純粋に技術的な観点からは、スラッシュドットで紹介されてた「新しいUnicode符号化方式」とかは、文字数が多く(Unicode文字集合)、データ量が少ない、という点で条件を満たしている。本気で新しいエンコーディングを設計しちゃう心意気には感服するが、実用するのは難しいだろうな。

tagohさんのはもうちょっと違う角度からのツッコミだ。

本当に多言語を扱おうと思えば Han UnificationなどのためUTF-8では十分でないかもしれない、という話だ。確かにたとえば「骨」の字など、日本と中国では字形が違う。

本当に多言語を扱おうと思えば、TRONコードのようなアプローチの方が良いのかもしれない。しかし、今度はソートや検索で同一視問題が発生する。あまり詳しくないのだが、TRONコードを扱うライブラリではその辺の正規化もサポートされているらしいけど、残念ながら誰もが使えると言う状況にはなっていない。

「カジュアルな多言語表現では字形の違いは気にしない」というポリシーもあるかもしれない。実際、はてなで中国語ダイアリーを書いている人とかもいるわけだし。「きちんと多言語を扱うのはエンコーディングじゃなくてもっと上のレイヤでいいんじゃね？」という気もするし。少なくとも「言語タグ」なんてものを導入して状態を持ち込む(エンコーディングがステートフルになる)のはさらなる不幸を招きそうだ。

あと、Unicodeは文字集合で、エンコーディングにはUTF-8、UTF-16(BE,LE)、UTF-32(BE,LE)があるという指摘もある。

が、実際問題としてまったくしがらみがない状態であれば、UTF-16を選択するのは正気だとは思えない。だって、UTF-16ってば

エンディアン問題がある
しかも、可変長

という過去のエンコーディングの悪いところを寄せ集めたような存在である。 UCS2で話が済んだ牧歌的な時代ならともかく、サロゲートペアが入ってUTF-16になった時点でもうアウトだろう。UCS2時代からのJavaはしょうがないとして、あらたにUTF-16を選ぶ理由はない。でも、なぜかWin32ってUTF-16なんだよね。

では、UTF-32はどうか。

UTF-32には可変長問題はない。データ量がかなり増えるが、それは無視できるとしよう。しかし、やはり情報交換用エンコーディングとしてはエンディアン問題が気になる。個人的には「BOMで解決」なんてのは信じない。いつもついてるわけじゃないし、逆にデータにBOMなんてタグが「いつもついてないといけない」というのもうっとうしい。っていうか、Unicode論者はBOMのうっとうしさを軽視しすぎ。

UTF-32が意味があるとすれば、データの内部表現としてじゃないだろうか。情報交換用に用いないのであればエンディアン問題は発生しないし。固定長による処理効率が高いのがうれしい人もいるだろう。でも、UTF-32を直接扱うライブラリはあまり充実していないように思えるんだけど、それは私が知らないだけなんだろうか。内部交換用として広く使われるためにはもうちょっとライブラリなどが充実する必要があるような気がする。

というわけで、個人的な印象としてはUnicodeを使うならエンコーディングはUTF-8で決まりだと思っている。情報交換用としても内部表現としても。欠点らしい欠点と言えば可変長なことだけだし、われわれ日本人は長い経験から、可変長マルチバイト文字列の扱いが実用になることを知っている。

最後に、非常に興味深いブログエントリ、「Open ブログ: ◆ シフトJIS と unicode」。

私のエントリも含めて「素人の暴論」であり、「勘違い」なのだそうだ。私(たち)が素人なのは否定しないけど、その「勘違い」の指摘はあまり上等には思えない。

要旨は

データ長の問題はどうでもよい
文字数の問題も無視してよい(え？)
Unicodeは各種エンコーディングが乱立している
だからUnicodeは万人の使うエンコーディングにはならない
だから現行のシフトJISを拡張した新しいエンコーディング(南堂私案)を

だそうだ。勘弁して。我田引水とか牽強付会とかいう言葉はこういう時に使うんだろうな。

まず、要旨のうち最初の点には同意する。二番目はちょっと「勘違い」があるみたい。三番目の各種エンコーディングが乱立している点については、困ったものだがUTF-8以外のエンコーディングは情報交換用としては重大な欠点があるので、事実上UTF-8固定でよいと思う。

最後のものは、世の中に存在するレガシーエンコーディングがシフトJISしかないのであれば、シフトJISの上位互換と言うのはある程度は価値があるのかもしれない。このエントリの著者の周辺ではそうなのだろう。だけど、たとえば私の日本語データのほぼすべてはEUC-JPだし、世の中そんなに単純じゃない。

まあ、それは良いとして、提案する解決策と言うのが「南堂私案」なるものなのだそうだ。あいにく「南堂私案」についての生きたリンクがなかったので、どのようにシフトJISを拡張してくれるのかよくわからないのだけれど、

だから、シフトJIS:X 0213 でも文字数が不足するということはない。（普通の用途では。）

ということだから、おそらくはシフトJIS:X0213にいくばくかの文字を追加することを許したものなのだろう。シフトJISだとあんまり空間に余裕はないような気がするけど、まさかGB18030みたいに最大４バイトとかじゃないよね。それはそれで大問題を引き起こしそうだし。

で、彼(南堂さん？)が見落としているのは、元のITproの記事も含めて「文字が足りない」って話をしている時には、彼が思っているように「日本語の範囲内で文字が足りない」というわけじゃなくて「カジュアルに多言語の表現がしたい」というものだろうということだ。要するに日本語の文章の中でもハングルやベトナム文字、あるいはアクサンとかのついた文字を表現したいってことではないんだろうか。具体的には最近の「ふぇみにん日記」とかのイメージだよね。

私には「南堂私案」なるものがそういうのに対応しているようには思えないんだけど。これで「Unicodeを使えばというのは素人の勘違い」とか「南堂私案であらゆる問題が解決」とか断言できちゃうのは、いかがなものだろうか。

私はUnicode絶対主義者ではないし、選択肢は用意されるべきだとは思っているが (だからRubyの多言語化は選択肢を用意する設計になっている)、とはいえ、理由もないのに事態を複雑化するのにも賛成はできない。

しがらみが無い状態では、文字コードに関する現時点で一番ましな選択肢はUnicode(UTF-8)であるというのは事実といってもいいんじゃないだろうか。

で、Unicodeでカバーできないなにかがあれば、それはそれ、その状況にもっとも適切なエンコーディングを選べばよい。新しいエンコーディングを作る必要があることはめったにないが、もし本当にそれが必要であれば、それをじゃますることはしたくない。必要だったらUTFCP/UTF-JPだろうが、南堂私案だろうがサポートできる枠組みは提供したい。

でも、それらは本当に必要なの？