[ アカウントをゲット! ]
Encode - 規格のバグまでは直せませんにコメントしながら思ったのだが、JIS X 0208の1区33点「波ダッシュ」をUnicodeに変換する際、U+FF5EのFULLWIDTH TILDEに変換するのは明らかに間違いだ。この件に関して、私が知る限りのことを、ここに記しておこうと思う。平成5年度のUCS調査研究委員会WG1において問題となったものの一つが、既存のJISの文字コードとISO/IEC 10646との対応をどうするかだった。JIS X 0208-1990の1区33点「波ダッシュ」に対しては、U+223C、U+223D、U+223E、U+223F、U+301Cが候補となったが、結局U+301Cと対応させることとなった。U+301Cの名前がWAVE DASHだったからである。ただし、ISO/IEC 10646-1:1993のU+301Cの例示字形は、JIS X 0208の「波ダッシュ」とは向きが逆だったため、JIS X 0221原案では例示字形の差替がおこなわれた。また、JIS X 0212-1990の2区23点「チルド」に対しては、U+007EのTILDEと対応させることになったが、EUC-JPとのラウンドトリップコンバージョンを考慮する際には、U+FF5EのFULLWIDTH TILDEと対応させてもよい、ということにした。
JIS X 0221原案は1994年3月に完成し、これらの対応表は附属書3に収録された。これと平行してUnicode側では、Glenn AdamsとJohn H. Jenkinsが1994年3月8日に『JIS X 0208 (1990) to Unicode, Version 0.9』と『JIS X 0212 (1990) to Unicode, Version 0.9』と『Shift-JIS to Unicode, Version 0.9』をリリースした。Unicode側の対応表でも、JIS X 0208の「波ダッシュ」はU+301CのWAVE DASHに、JIS X 0212の「チルド」はU+007EのTILDEに、それぞれちゃんと対応していた。1995年1月1日にJIS X 0221-1995が制定、対応表も一応は収録され、U+301Cの例示字形の差替もちゃんとおこなわれた。これを受けて安岡孝一も、あくまで個人として『Unicode to JIS table, Version 0.9』を1995年5月31日にリリースした。もちろん、JIS X 0208の「波ダッシュ」はU+301Cに、JIS X 0212の「チルド」はU+007Eに、それぞれ対応させておいた。
ところが、1996年1月12日にMicrosoftのLori HoerthとK. D. Changがリリースした『cp932_ShiftJIS to Unicode table, Version 1.0』では、ちょっと様子が違っていた。シフトJISで0x8160にあたる「波ダッシュ」が、U+FF5EのFULLWIDTH TILDEと対応していたのである。この『cp932_ShiftJIS to Unicode, Version 1.0』は、少なくとも40個のコードポイントについて明らかな誤りがあり、「波ダッシュ」とFULLWIDTH TILDEについても、誤りではないかと思われた。ところが、1998年4月15日リリースの『cp932 to Unicode, Version 2.0』においても、他の誤りの多くは訂正されたものの、「波ダッシュ」はU+FF5Eに対応したままだった。
その後もMicrosoftは誤りを認めず、「波ダッシュ」をU+FF5EのFULLWIDTH TILDEに変換するようなOSを、次々に世に送り出している。この間にJIS側は、JIS X 0208を1997年1月20日に改正し、1区33点の「波ダッシュ」がWAVE DASHに対応していることを、明確に規定した。加えて、2000年1月20日制定のJIS X 0213では、1面2区18点に「チルド」を規定した。「チルド」に対応するのは、基本的にはU+007EのTILDEだが、代替名称としてFULLWIDTH TILDEも規定されている。「波ダッシュ」をU+FF5EのFULLWIDTH TILDEに対応させる根拠など、もはやどこにもない。
このページのすべての商標と著作権はそれぞれの所有者が有します。
コメントやユーザ日記に関しては投稿者が有します。
のこりのものは、© 2001-2010 OSDN です。
やはり例示字形が直ってないのが大きいのでは (スコア:1)
Microsoft が誤りを認めないだけではなく、Unicode Consortium
が U+301C の例示字形の誤りを認めていないのも問題だと
思います。Unicode Standard は 3.0(1999年9月)で
という文言を付け加えたのに、なぜ字形を 78JIS の例示字形に
直さなかったんでしょうか……
industry practice (スコア:2)
ありがたいことに(tildeと同じ)正しい向きになっていますね。
#MS明朝/ゴシックも漢字をいじるついでに直せばいいのに…
親コメント
規定>>(越えられない壁)>>解説 (スコア:1)
===
規格票を読む前に言っておくッ!
おれは今JIS C 6228-1975の規格票をほんのちょっぴりだが体験した
い…いや…体験したというよりはまったく理解を超えていたのだが……
あ…ありのまま 今 起こった事を話すぜ!
『JIS C 6220(当時)ローマ字を使おうと思ったら
いつのまにかスウェーデン名前文字にされていた』
な… 何を言ってるのか わからねーと思うが
おれも何をされたのかわからなかった…
頭がどうにかなりそうだった…
WTERMのマニュアル間違いだとかfjで叩かれただとか
そんなチャチなもんじゃあ 断じてねえ
もっと恐ろしいフライング掲載の片鱗を味わったぜ…(AAry
===
とか、JIS X 0208:1997が
> “解説”が規格本文の規定に反することを述べてはならないことを
> 考慮すると
とまで言い切って旧規格の解説に書かれてたことをあれこれ反故にしてくれたとかの実績があるので、解説にしか書かれていないのではイマイチ信用する気になれません。JIS X 0208:1997の解説を信じるならですが:-)
ぜひ規格の改訂をお願いします。
そういえばJIS X 0213:2000もJIS X 0213:2004もまったく懲りずに終端バイトをフライング掲載してましたけど(しかも規定部分に)、正気なんでしょうか。
幸い割り込まれずに終端バイトを取得できたみたいですけど。
KS C 5601は正式に登録されるまで規格には私用終端バイトを書いて、登録されてから規格を改訂していましたね。どうみてもこっちの方が正当です。本当にありがとうございました(たとえ一時的でも私用終端バイトを規格に書くのは問題かもしれませんが)。
Re:変化し続ける文字コード (スコア:2)
規格は非互換な改定というのはなくもないですよね。
まあ、しょうがないですけど。
親コメント
Re:変化し続ける文字コード (スコア:2)
文字コード問題には私も興味があるんですが、6000円の単行本ではさすがにきついです。講談社選書メチエの1500円とか、中公新書の900円ぐらいで出せないものでしょうか?
親コメント
Microsoft のマッピング (スコア:1)
Microsoft が「~」(波ダッシュ) の文字に U+FF5E FULLWIDTH TILDE をマッピングする変換ルールを作ったのは, Windows 3.1 の「マイクロソフト標準キャラクタセット」の仕様ができたときです. この当時は,Windows 3.0 まで OEM メーカー毎に違っていた字体や拡張文字の種類を, Windows 3.1 以降は統一するといって評判になっていたと思います.ついでに,フォントファイルを Unicode ベースで構成することも.
「Microsoft Windows version 3.1 日本語版 マイクロソフト標準キャラクタセット仕様書 Revision 1.0」という文書によれば,その具体的な仕様が決まったのは1992年の12月のことで, Wikipedia [wikipedia.org] によれば,日本語版 Windows 3.1 は1993年5月に発売されています.
1994年3月に JIS X 0221 原案がでてきても, Microsoft としては,いまさら出てしまった製品を変更するわけにはいかなかったのではないでしょうか. 特に,フォントのような基本的な部分に関わることは.
広まってしまった間違いを後から修正できないのはよくあることで, たとえば HTTP の Referer: ヘッダーに r が一個足りないのとか, UNIX の creat() 関数に e が足りないこととか, 間違っているとは分かっていても修正はもうできませんよね.