Four Bytes

Cで文字コード変換を一式書いたことがある。

EUC-JP、Shift_JIS、ISO-2022-JP、UTF-8。それぞれバイト列の構造が違う。EUCは最上位ビットが立っているかどうかでマルチバイトの先頭を判定する。Shift_JISは先頭バイトの範囲で判定するが、2バイト目の範囲が厄介で、5Cがバックスラッシュと衝突する。ISO-2022-JPはエスケープシーケンスで文字集合を切り替える。メールはこれだった。同じ「あ」を表現するのに、エンコーディングごとにバイト列が違う。Cでこれを捌くと、1バイトずつ状態を持ちながら読み進めることになる。骨身にしみて構造がわかった。

そこにガラケーの絵文字が来た。

DoCoMo、au、J-Phone。三社がそれぞれ独自の絵文字を定義した。Shift_JISの未使用領域に突っ込んである。当然、互換性はない。DoCoMoの太陽とauの太陽は別のコードポイントだ。しかも公式の変換マップが存在しない。各社のキャリアゲートウェイが独自に変換していたが、変換できないものは「〓」になる。ゲタ記号。あの四角い記号を見るたびに、誰かの気持ちが消えたんだなと思っていた。

いまでは絵文字はUnicodeに収録され、UTF-8で4バイトとして定義されている。あの混沌とした三国志は終わった。世界中の人間が同じコードポイントで同じ絵文字を送れる。あの時代にCでバイト列を睨んでいた人間からすると、信じがたい平和だ。

ちなみにMySQLのutf8は3バイトまでしか扱えない。絵文字を保存するにはutf8mb4を使う必要がある。utf8なのにUTF-8ではない。MySQLがutf8と名付けたそれは、UTF-8の不完全な実装だった。この命名で何人のエンジニアが混乱したことか。名前が同じでも中身が同じとは限らない。文字コードはいつもそうだ。