『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
昔からなぜ「あ、い、う、え、お」という順番なんだろう、と不思議に思ってはいたが、 まさかインドに由来があるとは。
以下はインド方言の一つBrahmi語
インド地方のBrahmi文字の一覧。
ちょっと母音が多いがおおむね「あいうえお」の順番に並んでいる。
他のインド語でも同様の順序らしい。子音も「あかさたな〜」に近いように思える。
知らんかった。
先日、「シフトJISを捨てられるか?：ITpro」についてとりあげたら、tagohさんが「The day-to-day thoughts - UTF-8は十分かどうか」と反応して、さらにスラッシュドットでとりあげられた。
厳密な話をするならば、 欠点のない文字集合もエンコーディングも存在しないので、 どのような文字集合を選んでもどのようなエンコーディングを選んでも 不満を持つ人はいるに決まっている。
この文字集合には私の使いたい文字が無いとか、 性能上の問題がどうとか、文字化けがどうとか。 これについては、ケースバイケースとしか言いようがない。
というわけで、各論。
「シフトJISを捨てられるか?」について言えば、要旨は
というものだ。実際、この記事の流れではUTF-8でダメな理由ってのは、 「日本語のデータ量が多くなること」、「シフトJISではないこと」だけなので、 それってのは「新しいデータ」についてはさほど問題ではないと思う。
「新しいエンコーディング」というものは、
という手順を踏んではじめて実用的になる。どの段階もそれなりに大変だ。 特に「広く使ってもらう」というのは技術的な問題ではないので、 相当難しい。今時、単にちょっとデータ量が節約できるくらいの理由で まったく新しいエンコーディングが採用されるってことはほとんど期待できない。
ちょっと考えただけでも、
くらいは必須だろうけど、気が遠くなるくらい難しそうだ。
とはいえ、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」。
私のエントリも含めて「素人の暴論」であり、「勘違い」なのだそうだ。 私(たち)が素人なのは否定しないけど、その「勘違い」の指摘はあまり上等には思えない。
要旨は
だそうだ。勘弁して。 我田引水とか牽強付会とかいう言葉はこういう時に使うんだろうな。
まず、要旨のうち最初の点には同意する。二番目はちょっと「勘違い」があるみたい。 三番目の各種エンコーディングが乱立している点については、 困ったものだが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だろうが、南堂私案だろうが サポートできる枠組みは提供したい。
でも、それらは本当に必要なの？
というわけで、「Beautiful Code」というエッセイ集が出ます。 以前に依頼されたもの。
「英語できないから」と断ったんだけど、 先方が訳者まで用意してくれたので、引き受けることにした。 私のぶんのタイトルは「Code That's Like an Essay」ということになっている。
内情をばらせば、実はこれは今度出る「（るびま）出張版 正しいRubyコードの書き方講座」のコラムとほぼ同内容。 手抜きと言われてもしかたがない。
私のはあんまり良くなくても、他の人のはすごいですから。 そっちはお薦めです。
なお、印税は全額アムネスティに寄付されることになっている。
うち(NaCl)の講習会教材を英訳して外国人むけ講習会を開いたという話。 最近、プレスでNaClの名前をよく見るようになったな。
コードフェストの話。
実際、顔と顔を合わせてハックするといろいろ進むよね。 こないだの合宿のときに実感した。
たまにはやりたい。
とはいえ、私にとっては結構体力を消費するので、 毎日はできないな、という感じ。 若い人はオッケーなんだろうか。
財産権しか管理していないJASRACが著作者人格権にまで口出しするのは 筋違いにしか思えないのだが。また、あれが改変であることは認めるにしても、 それを許せないというのもいかがなものかと思う。
フェアユースの概念が無い国では正当化は難しいだろうけど。
夜の米子便で東京に移動。
羽田空港→天王州アイル→新木場→舞浜。 舞浜からモノレールでヒルトン東京ベイへ。
はなはだしく場違いな気がする。
ホテルで次の日の講演(英語)の原稿の準備。朝の４時まで。 わずか３０分のためにこれだけ準備して、 なお、「ちゃんとした」気になれないと言うのはどうだろう。
日本語なら苦もないことなのに。
This work is licensed under a Creative Commons License.
５０音順は明治以降に普及したはずなのに、インド由来とはなぜ？と思って調べてみたら、サンスクリット由来だと書いたブログがどこかにありました。<br>なるほど、それなら分からないでもない。サンスクリットは仏教と深い関わりがあるので、仏教に造詣の深い人が５０音順を作ったと想像できますが、どうにかして確認できないかな、これ。
強く激しく全力で同意。＞一番ましな選択肢はUnicode(UTF-8)<br>それ以外の私案エンコーディングなんて、よほどメリットがない限り、非日本語圏(特にアルファベット圏)のプログラマに採用を説得できない。
初めまして。５０音順についてですが、築島裕『国語の歴史』（東大出版会１９７７年）の７７−７８頁に記述があります。悉曇の母音字１２種のうち日本語にある音を順に抜き出すとアイウエオになり、子音字３５種のうち古代日本語にある音を順に抜き出すとka ca ta na pa ma ya ra vaになるとあります。自分の専門ではないのですが。
中国経由で伝来した仏教の経典を唱えるために「ふりがな」として修行僧が使っていたのが始まり、と人から聞いたことがあります。
五十音図の歴史については、馬渕和夫『五十音図の話』(1993 大修館書店）が詳しいようです。この本を紹介している松岡正剛の千夜千冊(http://www.isis.ne.jp/mnn/senya/senya0544.html)によると、今の五十音図の原型と呼べるものを作ったのは１１世紀の天台僧、明覚だとのこと。<br>明治の役人だか知識人だかが作ったものだと漠然と思っていましたが、とんでもない。９００年以上前のものでした。
五十音図は古代に音韻論が発達していたインド起源のアイデアです。ひらがな・カタカナの文字もサンスクリットの影響がかんじられます。（「そ」とか全く同じだし。）<br><br> ちなみに子音の順序は発音の開始場所が体内から体外に向けて順にならんでいます。（現代日本語だとすこし例外がありますが）カよりサの方が外、タよりマの方が外、というふうに。現代でもインドでは、はっきりとそういうふうに文字を教えています。
シフトJISは2バイト目に0x80未満が出て来る「ダメ文字問題」があるから、プログラムする側にしてみると最悪のコードだと思うんですけどね……。<br><br>UTF-8はダメ文字問題が無いから、それだけでも許せる気がします。
ダメ文字がない EUC-JP でも、長い文字列の途中で文字区切りがどこかを判定できないという問題があるので、やっぱり UTF-8 でいいです。
Matzさんこんにちは。Rubyの作者さんで間違いないですね?<br>Rubyは素晴らしく、以前から大変尊敬しております。<br><br>書いてから数年経って、UTFCP/UTFCP2についての説明を読み返してみると、不十分に思えるところがあったので、補充しておきました。<br><br>お時間が有れば、読んで頂ければ幸いです:<br>http://www.nowsmartsoft.or.tv/nws/Japanese/new_utf.htm<br><br>UTFCP/UTFCP2は、限られた二バイト符号によく使われる文字を集中させるため、変換テーブルを使う方針です(現在)。その変換テーブルは、「未完」です。作成用のスクリプトをオープンソースとし、その説明も書いておきましたので、有志の方の協力を仰ぎたく思っています:<br>http://www.nowsmartsoft.or.tv/nws/Japanese/nwsos_utfcp_script.htm<br><br><br>UTF8以外の符号の必要性ですが、私は必要だと思っています。もっと、議論するべきかもしれません。
Brahmi（ブラーフミー）は言語ではなく文字の名前です。インドや東南アジアなどのさまざまな言語で使われている「インド系文字」と総称される多様な文字たちの祖ですね。<br>文字配列の保存は面白い問題です。現代のアラビア文字の配列の中に，K, L, M, N に相当する部分がありますが，これは偶然の一致ではないようです。