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

yasuokaの日記： YEN SIGN問題縁起 10

日記 by yasuoka
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を用いる全ての文字コードやそのユーザに、代価を押し付けようとしているだけである。

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

YEN SIGN問題縁起 More

  • 　安岡さんは0x5cがディレクトリ区切りに用いられたために問題になっているとお考えのようですが、0x5cが一般的にエスケープに使われている限りは問題になっていたと思います（それともあれもMicrosoftが広めたのでしょうか？）。
    　もちろん0x5cをバックスラッシュにして円記号にしなければ回避できたとは思いますが、日本国内事情を考えるとそれは不可能だったのではないでしょうか。
    （円記号は必要でしたでしょうし、他に円記号が割り当てられている場所はありませんでしたから……たぶん）

    　最近はWindowsを使っていても0x5cはバックスラッシュとして表示されることも多いですから、そのうち気がつけば0x5cはバックスラッシュ、ということで落ち着くのかもしれません。
    • 0x5Cが「エスケープ記号」だとしても、UNIX系OSでは特に問題が起こってない、というのが私の感覚です。というのも、『UNIX Programmer's Manual, Seventh Edition』(1979年1月)に「ascii」の項が載って以来、UNIX環境下では0x00－0x7FはASCII決め打ち、というタテマエだからです。UNIXでは、たとえ0x5Cが「¥」に見えたとしても、それは端末が腐っているのであって、あくまでbackslashとして扱うのが正解、ということになります。このASCII決め打ち思想が、最終的にはFSS-UTF(現在のUTF-8の原型)を生むことになったのだと。

      これに対しMS-DOS系では、各国ごとに異なる文字コードを0x00－0x7Fに規定してしまった、というのがそもそものミスです。しかも、そういう環境下においては、たとえばCやC++のプログラムを書く際にも、trigraph sequenceを使わなきゃいけないはずですが、そもそもC#にはtrigraphがない。そういう点で、Microsoftは文字コードの国際規格を全く無視してて、私はすごくキライなんです。

      ただ、確かにMicrosoftだけが悪いんじゃなくて、Unicodeの方もどうかしてた、ってのは言えます。だって、JIS X 0201の0x5Cの「¥」と、GB 1988の0x24の「¥」と、ISO 8859-1の0xA5の「¥」とに、同じU+00A5を対応させちゃったんですから。Unicodeの常識から言えば、これらはそれぞれYEN SIGNとYUAN SIGNとYEN-YUAN SIGN(かしら?)という異なる文字であって、それぞれ別のコードが割り当てられて当然なんですよ。少なくとも、JIS X 0201の0x5Cと、ISO 8859-1の0xA5とで、異なるUnicodeが対応してたら、まだやりようがあったんじゃないかと思えるのです。

      シェア
      親コメント
      • 　素朴かつトンチンカンな質問をよろしいでしょうか。
        　UnicodeのU+0000～U+007FおよびU+0080～U+00FF領域に「全世界で共通する文字を示すべき」を割り当てるのは、もともと無理な話だったのでは……(もちろん規格上の話ではなく、各国のお国事情を反映させた場合)。

        　同一性を保てる見込みのないアドレスは使われないようにするのが最善かと思うものの、現実にはU+005CもU+00A5も多用されてしまっているので、せめて通貨記号の意図で使っている部分を分離する＆U+005CとU+00A5を通貨記号用途から外すという感じの対策は必要かな、と考えてみたり。

        　たとえば、
        　「UnicodeのU+0000～U+007F領域のうち、国によって表示文字が異なる部分は、全て特定の国にとって有利とならない符号で固定する……たとえば、CS1(U+005C)はコインを表す抽象図案に変更・CS2(U+00A5)はバックスラッシュ(＼)に固定。」
        　「UnicodeのU+0080～U+00FF領域は使用禁止とする」
        などという方針が出ることはあるのでしょうか……って、そんなことをしたらUnicodeの対応性が(U+005Cについて)さらに崩れてしまうだけですねorz

        　#これって、隣国でも同じように話題になっているのでしょうか。
        シェア
        親コメント

        • 初期のUnicode Draft (スコア:1)

          by yasuoka (21275) on 2006年06月06日 21時51分 (#954952) 日記
          最初のUnicode Draft (1989年9月発表)は、もっと「美しい」文字コードを目指してたようです。そこでは、たとえば「á」は「a」とアクサンテギュの合成で表現され、通貨記号が連続したコードポイントにまとめて収録される、はずのものでした。ところが、MicrosoftのMichel SuignardとAsmus Freytagが参加したあたりから、この方針は変わりはじめ、次のUnicode Draft 2 (1990年4月発表)では、U+0000－U+007FはASCII互換に、U+00A0－U+00FFはISO 8859-1互換になってしまいました。このISO 8859-1互換ってのは、どう考えても失敗だったと私も思いますが、いまさらどうにもならないでしょう。

          >#これって、隣国でも同じように話題になっているのでしょうか。

          現在の中国では、GB 18030こそが唯一の文字コードで、Unicodeすらオマケに過ぎませんから。GB 18030の0x24は「¥」ですけど、0x5Cは「\」なので、そう問題にはなってないのかな？

          シェア
          親コメント
      • 　曖昧な記憶で申し訳ないのですが、どこかのLinuxディストリビューションがデフォルトエンコーディングをUTF-8にしたときにYen Markで問題が起こっていたような記憶があります。
        （元ネタを思い出したら追記します）

        ＃今回のネタとは直接関係なかったり、
        ＃勘違いかもしれませんが、いちおう。
        シェア
        親コメント
      • このあたりhttp://www.opengroup.or.jp/jvc/cde/euc.html [opengroup.or.jp] をながめていると、UNIX環境下でもEUCのG0が「JIS X 0201-1976 ローマ文字」であるとしている例は少なくないようにおもえるのですが。『端末が腐っている』とは言いすぎなのではありませんか? このあたり http://euc.jp/i18n/euc-jp.txt [euc.jp] を見ても、EUC-JPのG0に「ISO 646 Japanese version」を充てるのがいけないわけではなさそうに見えます。
    • ＞そのうち気がつけば0x5cはバックスラッシュ、ということで落ち着くのかもしれません。

      どうやら Vista でも Meiryo フォントは U+005c を円記号とするらしいので、その期待は甘いかもしれません。
      Vista は、U+005c をバックスラッシュにするいいタイミングだと思うんですけどねーー。
      シェア
      親コメント

  • W-ZERO3のInternet Explorer (スコア:1)

    by yasuoka (21275) on 2006年07月16日 10時40分 (#979457) 日記
    ノート:ASCII [wikipedia.org]で話題になったんですけど、W-ZERO3のInternet Explorerでこの日記を見ると、\の「\」も、¥の「¥」も、どちらも「円記号」に見えてしまいます。うーん、それだと、この日記、さっぱり意味わかんないじゃん…。
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人