listen to my digital heartbeat.

　文字コードの世界は奥が深くて、これまで知らんぷりを決め込んできたのだが、ハマッてみるとそれはそれで面白い。昨日は面白いことに気づいた。

　Windowsの標準テキストエディタである「メモ帳」を起動し、「ファイル」メニューから「開く」を選ぶ。当然のことながら、ファイル選択のためのダイアログが表示される。で、ここで例えば、日本語Windows標準の文字コードである「シフトJIS」形式で保存されているテキストファイルを選ぶと、ダイアログの表示はこんな風になっている。


　ダイアログ最下部の「文字コード」指定欄には、デフォルト設定である「ANSI」と表示されている。これ、単に「デフォルト値」が表示されているだけだと思っていたのだが、どうも違うようだ。

　それと言うのも、Unicode（UTF-16LE）形式で保存されたテキストファイルを選ぶと、まだファイルを読み込む前であるにも関わらず、文字コード指定欄には正しく「Unicode」と表示されるのである！


　つまり、ファイル選択ダイアログの機能として、ファイルの文字コードを認識しているのである。

　UnicodeのUTF-16LE・UTF-16BE・UTF-8形式で保存されたテキストファイルの先頭には、テキストデータ本体の前に、BOM（Byte Order Mark）と呼ばれる2〜3バイトのデータが付加されている。プログラムはこれを読むことで、文字コード（正確にはエンコード方式？）を判定することができる。

　ところが、ASCII形式、シフトJIS形式、JIS形式、EUC形式、等で保存されたテキストファイルには、このような文字コードを識別させるためのデータが存在しないから、実際に書き込まれているテキストデータ本体から文字コードを「推定」するしかない。

　プログラムによる「推定」が間違っている場合もある（そもそも100%正しい推定なら、それは「推定」とは呼ばない）。その場合は、実際に使われている文字コードとは異なる文字コードとしてファイルを表示することになるから、当然テキストは正しく表示されない。

　「Windows XPのメモ帳で、『Bush hid the facts』（文末にピリオド・改行なし）とだけ書かれたテキストファイル（ASCII形式、シフトJIS形式、JIS形式、EUC形式、等。これらは全く同じデータになる）を読み込もうとすると文字化けする」という現象は、「推定が間違っていた場合」なのである（BOMに当たるデータは存在しないが、何故かUTF-16LEとして読み込むようだ）。

　Windows XPがこう推測する条件は僕にはまだわからないが、「Bush hid the facts」が備えている条件

・全てASCII文字
・先頭のみ大文字
・ほとんどが小文字
・半角スペース以外の記号が使われていない
・字数が偶数
・半角スペースの出現位置
・ASCIIコードを16進表記するとA〜Fが出現しない

等のいくつかが「これはUTF-16LE形式だろう」と推測するに充分な条件を満たしている、ということなのだろうと思う。まぁたぶん、「UTF-16LE形式ではあり得ないデータ」が存在しない、ということなのだろう。

　コンピュータのハードウェアは当然、電子機器として自然法則に制約されているけれども、ソフトウエア（特に、ソフトウエア階層の上層に位置するソフトウエア）はそういった制約を受けない純粋な人工物なのかと思っていたら、どうもそうではないようだ。むしろ「人間社会のしがらみ」の制約を強く受けていて、（法律がそうであるように）「相互に矛盾した、わけのわからんルール」が多数存在しているようだ。「文字コードの世界」をちょっとのぞいてみたら、そんなことが見えてきた。