「YEN SIGN問題縁起」記事へのコメント

0x5cがエスケープ記号である限りは問題が起こっていたのではないでしょうか

[asakura-t (31194)]

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

　最近はWindowsを使っていても0x5cはバックスラッシュとして表示されることも多いですから、そのうち気がつけば0x5cはバックスラッシュ、ということで落ち着くのかもしれません。

Re:0x5cがエスケープ記号である限りは問題が起こっていたのではないでしょうか

[yasuoka (21275)]

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が対応してたら、まだやりようがあったんじゃないかと思えるのです。

Re:0x5cがエスケープ記号である限りは問題が起こっていたのではないでしょうか

[first_name (18152)]

　素朴かつトンチンカンな質問をよろしいでしょうか。
　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

[yasuoka (21275)]

最初の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は「\」なので、そう問題にはなってないのかな？

UNIX系OSで起こっていた（気がする）問題

[asakura-t (31194)]

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

＃今回のネタとは直接関係なかったり、
＃勘違いかもしれませんが、いちおう。

Re:0x5cがエスケープ記号である限りは問題が起こっていたのではないでしょうか

[Anonymous Coward]

このあたり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」を充てるのがいけないわけではなさそうに見えます。