スラッシュドット・ジャパン

たとえば「16ビットのコードを2つ組み合わせることで急場をしのいだ」といった書き方は、いかにも行き当たりばったりでサロゲートペアを作ったように見えますが、実際には最初から計画的にサロゲート用のコードはリザーブしてあったわけですよね。

「最初から計画的にサロゲート用のコードはリザーブしてあった」というのは、どう考えても嘘だ。この際だからUTF-16の誕生に関して、私の知る限りのことを記しておこうと思う。

Joseph Dermansly BeckerがJTC1/SC2/WG2に『Proposal for Extended UCS-2 being also a Proposal for Extended Unicode』を提出したのは、1993年4月のことだ。後にJTC1/SC2/WG2 N883と呼ばれるこの文書において、Beckerは、High Half Zoneとして2C00～2FFFを、Low Half ZoneとしてDC00～DFFFを用いた、UCS-2の拡張法を提案している。この拡張法においては、「2C00 DC00」がUCS-4のU-2C00DC00にダイレクトに対応するというものであった。Beckerのこの提案は、1993年5月24～25日のJTC1/SC2/WG2アテネ会議で、ケチョンケチョンにけなされることになる。曰く、2C00～2FFFはA-Zoneなのに、そんな拡張法に使うのはおかしい。曰く、「2C00 DC00」をU-2C00DC00に対応させると、拡張版UCS-2が飛び飛びにUCS-4に対応することになって、そんなのISO/IEC 10646アーキテクチャの破壊だ。曰く、そもそもUCS-2は16ビットのコードなのに、それを「拡張」するなんて自己矛盾、だったらUCS-4を使えばいいだろう…。

しかし、Beckerはメゲることなく、『Proposal for UCS-2E (Modified Proposal for Extended UCS-2)』をJTC1/SC2/WG2に再提出する。1993年11月1～5日のJTC1/SC2/WG2ワシントンD.C.会議では、このUCS-2Eが徹底的に議論された。High Half ZoneはD800～DBFFに変更されていたのでA-Zoneの問題はいいとして、「D800 DC00」はやはりU-00010000に対応させないとJTC1/SC2/WG2としては収まりがつかない。しかもUCS-2の「拡張」というのは、やはりどう考えても矛盾しているので、ここは、UCS Transformation Formatの一種、ということで妥協してもらうしかないだろう。この瞬間にUCS-2Eは、UTF-16となったのである。

もし「最初から計画的にサロゲート用のコードはリザーブしてあった」と言うのなら、High SurrogateのD800～DBFFがどう「リザーブ」してあって、なぜそれがBeckerの最初の提案にはなかったのか。ちゃんとした資料をぜひ示してほしい。