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

tarosukeの日記にもコメントしたのだが、YEN SIGN問題の歴史的経緯は、あまり知られていないように思える。そもそも、情報処理学会コード標準化委員会が1965年1月28日に完成した文字コード案では、「¥」は0x24に収録する予定だった。ところが、1966年4月のISO/TC97/SC2 + CCITT/GM ALPパリ会議において、ISO 7ビットコード最終案の0x24は「$」に固定されてしまい、1967年12月22日にISO R 646として制定された。やむをえず日本側は0x5Cに「¥」を移し、JIS C 6220として1969年6月1日に制定した。一方アメリカは、1970年10月のISO/TC97/SC2ロンドン会議において、ISO R 646の0x5Cを「\」にするよう要求してきたが、日本はこれに反対、ISO 646の1973年7月1日改正においても、0x5Cを国内使用箇所として守りきった。これがYEN SIGN問題の発端である。

1983年3月にMS-DOS 2.0をリリースした際、Microsoftはディレクトリの区切記号を0x5Cにするという愚を犯した。0x5CはISO 646の国内使用箇所なので、各国ごとに収録されている文字が異なっている。この結果、アメリカのMS-DOSでは「\」がディレクトリの区切記号だが、日本のMS-DOSでは「¥」がディレクトリの区切記号となった。しかも、当時のアメリカのMS-DOSは、IBM-PCの文字コード(のちのCP437)をそのまま採用しており、そこでは「¥」が0x9Dに収録されていた。つまり「¥」は、日本のMS-DOSではディレクトリの区切記号だったが、アメリカのMS-DOSではディレクトリの区切記号ではなかった。1983年5月にリリースされたMS-DOS 2.01漢字版においても、文字コードはシフトJISに拡張されたものの、やはり0x5Cは「¥」だった。

1991年6月に出版された『The Unicode Standard, Version 1.0, Volume 1』では、「¥」はU+00A5に収録された。この本には、CP437やシフトJISとの対応表も収録されており、CP437の0x5CはU+005Cの「\」に、CP437の0x9DはU+00A5の「¥」に、シフトJISの0x5CはU+00A5の「¥」に対応づけられた。Unicodeはあくまで文字コードなのだから、文字の符号化を考える限り、当然の措置である。つまりUnicodeをマジメに実装するなら、MicrosoftはU+00A5に対して、日本とアメリカで異なる動作をするようにしなければならない、ということになる。ISO 646の国内使用箇所を軽ろんじた報いだ。

ところが、1996年1月12日にMicrosoftのLori HoerthとK. D. Changが発表した『cp932_ShiftJIS to Unicode table, Version 1.0』には「0x5C    0x005C  # REVERSE SOLIDUS (rendered as Halfwidth Yen Sign)」という対応が示されていた。0x5Cに対してU+005Cの「\」を対応させるが、表示には円記号を用いる、というトンでもない解決法である。そりゃ、MicrosoftのCP932だけを見た時は、それでいいかもしれないが、Unicodeとの変換をおこなう他の文字コードから見ればいい迷惑だ。つまるところ、文字コードのレベルでは本来解決できない事柄を、ムリヤリ文字コードで何とかしようとして、Unicodeの文字コードとしての一意性を破壊しているわけである。

文字コード関係の文句はソフトウェアベンダーに言うべきじゃないかなぁにもコメントしたが、結局YEN SIGN問題は、MS-DOS 2.0の実装において、MicrosoftがISO 646を全く理解していなかったために起こった問題だ。しかも、その問題をMicrosoft自身は、マジメに解決しようとしていない。UnicodeのU+005CやU+00A5を用いる全ての文字コードやそのユーザに、代価を押し付けようとしているだけである。