パスワードを忘れた？ アカウント作成
Close
436343 journal

yasuokaの日記： WAVE DASH問題縁起 25

日記 by yasuoka
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に対応させる根拠など、もはやどこにもない。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

WAVE DASH問題縁起 More


  • Microsoft が誤りを認めないだけではなく、Unicode Consortium
    が U+301C の例示字形の誤りを認めていないのも問題だと
    思います。Unicode Standard は 3.0（1999年9月)で


    ・This character was encoded to match JIS C
    6226-1978 1-33 "wave dash". The JIS standards
    and some industry practice disagree in mapping.


    という文言を付け加えたのに、なぜ字形を 78JIS の例示字形に
    直さなかったんでしょうか……

    • industry practice (スコア:2)

      by kanou (16482) on 2006年05月10日 22時26分 (#936545) 日記
      Windows Vista Beta2 のメイリオでは U+301C は
      ありがたいことに(tildeと同じ)正しい向きになっていますね。
      #MS明朝/ゴシックも漢字をいじるついでに直せばいいのに…
      シェア
      親コメント

      • Re:industry practice (スコア:1)

        by yasuoka (21275) on 2006年05月11日 18時39分 (#937177) 日記
        U+301Cへのマッピングがあるのは、私の知る限りJIS X 0208とCNS 11643くらいですから、例示字形くらい直しちゃってもいいような気が、私もするんですけど…。でも、日本が提案したJTC1/SC2/WG2 N2166は、2000年3月のJTC1/SC2/WG2で否決されちゃいましたからね。もう、どうにもならないんじゃないでしょうか。
        シェア
        親コメント
  • あっち [livedoor.jp]は文字数制限が厳しいのでこちらで続けさせていただきますが、
    ===
    規格票を読む前に言っておくッ！
    おれは今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は正式に登録されるまで規格には私用終端バイトを書いて、登録されてから規格を改訂していましたね。どうみてもこっちの方が正当です。本当にありがとうございました(たとえ一時的でも私用終端バイトを規格に書くのは問題かもしれませんが)。
    • 何やらアヤシイコメントが…。

      とりあえず「エスケープシーケンス」の方ですけど、AFNORが実務を担当していた1975年頃と、IPSJ/ITSCJが実務を担当している1999年以降とを、ゴッチャにしてもらっては困ります。こう言っちゃ悪いんですが、AFNOR時代の「エスケープシーケンス」の割り当てって、ISO 2375にすらちゃんと則ってなくてハッキリ言って無茶苦茶ですよ。

      で、本論の「規格票の解説に載ってることなんか、次の改正で反古になりかねない」ですけど、これはおっしゃる通りです。でもそれを言うなら「規格票の参考に載ってることなんか、次の改正で反古になりかねない」も、当然のことです。その意味では、JIS X 0212の2区23点「チルド」をTILDEやFULLWIDTH TILDEに対応させるような規定は、現時点ではどこにもなくて、極端な話U+223CのTILDE OPERATORに対応させるって選択肢も規格違反じゃないんですよ。この現状を打破するには、やっぱりJIS X 0212を改正するしかないんですが、でもいくら言ってもINSTACは動いてくれないし…。

      シェア
      親コメント
      • > AFNORが実務を担当していた1975年頃と、IPSJ/ITSCJが実務を担当している1999年以降とを、ゴッチャにしてもらっては困ります。

        それは失礼しました。つまり1999年以降エスケープシーケンスはもう100%絶対確実にその位置に登録されることが決定された後で規格票に載るのであって、2000年1月20日 [kyoto-u.ac.jp]に制定されたJIS X 0213:2000のエスケープシーケンスが2000-07-31 [ipsj.or.jp]に登録されていたり2004年2月20日に制定されたJIS X 0213:2004のエスケープシーケンスが2004-04-13に登録されていたりしてもそれはお役所の手続き上の問題か何かであって何も心配する必要はないということですね?

        できれば部外者にも心配ないと言うことが一目で分かる日付管理をしていただけるとありがたいのですが、心配ないならこだわりません。

        > でもそれを言うなら「規格票の参考に載ってることなんか、次の改正で反古になりかねない」も、当然のことです。

        それは当然存じ上げております。ですから#936686 [srad.jp]では「参考」については何も言及していません。

        というか規定すら次の改正であっさり消えてなくなりかねないわけですが。JIS X 0221-1:2001の附属書1(に相当する内容)は、改訂前のJIS X 0221-1995では規定でしたよね?

        そんなことばかり繰り返してるから、何に従ってるのかは知らないけど少なくとも一度も変更はされてないマイクロソフト標準キャラクタセットのほうがマシだとか判断をされたりするのでしょう。

        頼むから文字コードの実装くらい安心してさせてくださいと言いたくなりますが誰に言ったらいいんでしょうか。
        シェア
        親コメント

  • 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 が足りないこととか， 間違っているとは分かっていても修正はもうできませんよね．

    • 正確に言うと、違います。1991年発行の Unicode 1.0 仕様書 (The Unicode Standard: Worldwide Character Encoding Version 1.0 Volume 1, Addison & Wesley) に既に SJIS から Unicode へのマッピングテーブルが示されており、この時点で既に U+FF5E です (p.601)。もちろん Microsoft はこの仕様策定にどっぷりかんではいますけど、mapping に関する限り事後に変更した 10646 の方が問題があった、ような気がしてならない。
      シェア
      親コメント
      • えっと、『Unicode Encoding to DBCS Code Page & Asian Standards Mappings』(The Unicode Standard, Version 1.0, Volume 1 (October 1991), pp.560-604所収)のXJISと『Shift-JIS to Unicode, Version 0.9』(8 March 1994)を較べてみたところ、少なくとも以下の7字のマッピングが変更されています。
        • 0x8157　U+3004→U+4EDD
        • 0x815D　U+00AD→U+2010
        • 0x815F　U+FF3C→U+005C
        • 0x8160　U+FF5E→U+301C
        • 0x8161　U+2225→U+2016
        • 0x817C　U+FF0D→U+2212
        • 0x81FC　U+20DD→U+25EF
        で、Microsoftは、これらの変更のうち、0x8157、0x815D、0x81FCは従ったけど、残り4つは従わなかった、ってことですよね。うーん、どうしてなんだろう…。
        シェア
        親コメント
        • 0x815D は他に経緯があったものと思いますが

          • 0x8157-U+4EED は Unicode 1.0 から 2.0 で文字のコードポイントが変更されたことに伴う。
          • 0x81FC-U+25EF は、U+20DD は合成用文字であるため明らかな間違い、ということで修正したと思われる。

          で、要するに Microsoft は最小限に限って修正しただけだと思う。

          シェア
          親コメント
          • すみません。U+4EED が変更されたのは、Unicode 1.01 ですね。少なくとも June 1992 より前。
            シェア
            親コメント

          • この3つについては，変更の経緯が分かります．

            • 0x8157 は「同上記号」で，記号なので当初 CJK Symbols and Punctuation の枠 (U+3004) にあったけれど，CJK Unified Ideograph (漢字枠) にも同じ文字 (U+4EDD) があったので，ISO/IEC 10646-1:1993 の標準を作るときに，漢字枠の方を生かした．U+3004 は，そのときに「JISマーク」に入れ換えた．
            • 0x81FC は昔の JIS X 0208 規格で「合成用丸」になっていたので，最初の変換表を作った人は Combining Diacritical Marks の枠から U+20DD にしたけれど，JIS の方が「この字は combining character ではない」という見解を出したので U+25FF に変更した．
            • 0x815D は「ハイフン」で，一方 U+00AD は SOFT HYPHEN (ハイフンを入れてもいい位置を示す記号で，表示されないこともある) だから，意味が違う． 明かに変換表の間違いで， 修正して HYPHEN (U+2010) の方に対応付けた．

            ……ということでしょう．

            シェア
            親コメント

            • Re:Microsoft のマッピング (スコア:1)

              by emk (30939) on 2006年05月13日 3時39分 (#938212) 日記
              > JIS の方が「この字は combining character ではない」という見解を出した

              のは97JISなので、それを根拠にマイクロソフト標準キャラクタセットのマッピングを決めたというのはちょっと考えにくいです。
              シェア
              親コメント

              • 0x81FC に相当する文字 (JIS X 0208 の2区94点) が正式に「合成用丸」でなくなったのは，おっしゃるとおり JIS X 0208:1997 ですが， JIS X 0221:1995 の附属書として JIS X 0208 と UCS との間の変換表を決めたときには，これを合成に使用しないことは決まっていました．(JIS 規格番号と年号との間の区切り文字は，1995年当時は "-" で現在は ":" ですが，面倒なんで ":" で統一します．)

                それが「JIS X 0221原案は1994年3月に完成し、これらの対応表は附属書3に収録された。」ということで，少なくともその時点には決まっていたということです．

                シェア
                親コメント
              • というより、この合成用丸は重ね打ちを前提にしていた (JIS C6226 では) ので一文字、として扱われていましたし、日本語を扱うすべての実装がそうなっていました。U+20DD は元々正規分解用に使うことを規定された文字なので、これも ISO 10646 とは直接関係しない明らかな間違い、ということで変更されたものと思います。
                シェア
                親コメント
              • うーむ、とすると、ナゾとして残ってるのは、この0x8157・0x815D・0x81FCのマッピングを、Microsoftが「いつ」変えたのか、ですね。で、私のつたない記憶を辿ってみたんですが、Windows NT 3.1のPC/AT対応版(1994年1月28日発売)とNEC PC-9800対応版(1994年2月25日発売)とで、MultiByteToWideCharの動きが違ったような気がするんですよ。ただ、それがこの3字だったかどうか…。
                シェア
                親コメント
        • で、Microsoftは、これらの変更のうち、0x8157、0x815D、0x81FCは従ったけど、残り4つは従わなかった、ってことですよね。

          いま，Windows 2000 で確認しましたら，書かれているとおりです．一方，「マイクロソフト標準キャラクタセット仕様書」には変更前のコードポイント (左側の値) が書いてあります．ということは，どこかの時点で変更されたわけですね．

          ちなみに，MS明朝やMSゴシックのフォントには，U+301C のコードポイントに，Unicode Standard の例示字形と同じ (つまり波ダッシュを反転させたような) 図形が入っています．

          シェア
          親コメント

        • Re:Microsoft のマッピング (スコア:1)

          by emk (30939) on 2006年07月21日 20時39分 (#982341) 日記
          > で、Microsoftは、これらの変更のうち、0x8157、0x815D、0x81FCは従ったけど、残り4つは従わなかった、ってことですよね。うーん、どうしてなんだろう…。

          単にUnicode 1.0.1の変更点 [textfiles.com]にはその3文字しか含まれていなかったというだけの話だと思います。Unicode.orgのサイト上にも同様の資料 [unicode.org]があります。

          # Unicode 1.0.1 Addendumの現物を持っている [srad.jp]はずのalpさんが「9. Character mapping changed」に全く触れていないのが不可解なのですが、1992年11月付の資料が1992年6月発行の「The Unicode Standard, Version 1.0, Volume 2」に挟み込まれているはずはありませんし、もしかして正誤表も複数バージョン存在したりするのでしょうか。

          Unicode 1.1以降の変更では、1993年5月発売のWindows 3.1 日本語版に間に合いません。Windows 3.1 日本語版に含まれている「ＭＳ ゴシック」「ＭＳ 明朝」はすでに内部エンコーディングがUnicodeベースで、これを表示するためにGDI.EXEにはSJIS→Unicodeの変換表が内蔵されていました。この変換表における図形文字のマッピングが現在のものと完全に同一であることも確認しました。

          あと、Windows NT 3.1には韓国語版も存在したとおっしゃって [fc2.com]いますが、ソースは何ですか? List of Localized MS Operating Systems [microsoft.com]という資料によれば、韓国語版のWindows NTは4.0からのようですが。それならハングル大移動より後です。
          安岡センセイともあろうお方がこんな重要なことを根拠もなしに書くはずはありませんから、きっとあっと驚く証拠が出てくるに違いないと妄信しています:-)
          シェア
          親コメント
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー