KDOC 216: 『文字コードの仕組みと歴史入門: なぜ文字化けは起こるのか』

• 作成
  • 2024-08-10 貴島
• レビュー
  • 2024-08-25 貴島

文字コードの仕組みと歴史入門: なぜ文字化けは起こるのか?は、文字エンコーディングの仕組みと歴史を解説する本。

ひらがなの「あ」の番号の割り当て。

• ソフトJISとEUC-JPとJISコード(JIS X 0208)は基本的にJIS X 0208という同じ文字表を使用しているが、番号は同じになっている(p8)
• 文字表のことを「文字セット」「文字集合」という(p8)
• 文字を番号に置き換えるルールを「文字エンコーディング」という(p8)
• 初期の電報はモールス信号で無線送信されたため、和文モールスと同じ制約があった。文字数が通信時間になり料金に反映されるので、簡潔な表現が好まれた。カタカナだけで、空白文字は存在しないため文字の区切りが曖昧になっていた、という(p13)
• シフトJISとEUC-JPの最大の違いは、規格としての正しさにある。シフトJISは、勝手にコードをシフトして辻褄を合わせた私的な仕様である(p36)
• Unicodeにはすべての文字を16ビットに納めるという大前提があるがこれは絶対に実現できない夢想である。ISO/IEC 10646 DIS1は1文字に32ビットのコードを割り振るが、これはアメリカ人が絶対に許容できない選択肢である。ASCII(8ビット)の資産が使えなくなるため(p41)
• ビャンビャン麺 - Wikipedia(p48)
• UTF-16はもっとも基本的なUnicodeのビット表現となったが、処理が複雑で評判がよくなかった。UTF-16の後で8ビット単位でUnicodeをエンコードするUTF-8が誕生した。0~0x7FまではASCIIコードそのもので、0x80~0xFFの領域にその他のすべての文字を押し込む。そのため、1~4バイト長の可変長エンコードである。UTF-8はUTF-FSS(File System Safe)とも呼ばれる。当初はベル研究所のPlan 9のファイル名を記述するエンコードとして考案されたため(p49)
• たとえば漢字の「亜」はシフトJIS/EUC-JP/UTF-16では2バイトで表現できるが、UTF-8では3バイトを必要とする。必要とされる記憶容量が増える。こういう日本に不利な仕様を標準として飲まされるのは日本のIT業界の弱体化といえるだろう(p51)
• CPUのエンディアンに沿ってデータを扱うと効率がよい。そのためUnicodeにもリトルエンディアンとビックエンディアンの2種類があり、エンディアンを自動判定するための文字が存在する。BOM(U+FEFF byte order mark)である。ファイルの先頭につけておくと、確実にリトルエンディアンかビックエンディアンかを判定できる(p51)
• 電子メールで文字をエンコードしたければ、Content-Transfer-EncodingヘッダーにQuoted-printableかBase64を指定する。だが、その方法では本文のエンコードを指定できてもヘッダー自身のエンコード方法を指定できない。ヘッダーのエンコードを指定するための書式が存在する(p58)
• 本来合意されていたのは「Unicodeに統一しよう」ということで、特にUTF-8に統一しようという合意はなかった、という(p61)
• C#の文字列クラスではUTF-16で文字列を記録する。サロゲートペアを使った1文字の長さを2と報告する。これはすべての文字が16ビットで簡単に処理できると言われた時代に決まった仕様である(p61)
• ハイフンとマイナスは区別されないで同じ文字で書かれている(p67)
• 文字化けが起こる根本的な理由は、今や技術的な理由ではなく、過去の負債にあるといえる。過去の人たちが便利に使うために便宜上決めたことが、未来の我々を苦しめる(p67)

なし。