文字コード関係の文句はソフトウェアベンダーに言うべきじゃないかなぁ

 愚痴に対して野暮な突っ込みであるとは思いつつ。

NECに至っては、Consortiumのメンバーですらないというのはなぜでしょう?フルメンバーに日本企業がJust Systemしかないのはなぜでしょう?文字コードより防衛庁や架空売り上げの方が大事なのかな?
perl - Jcode の EUC-JP

 昔はともかく「今の」文字コードに関してはハードウェアベンダーではなくソフトウェアベンダーの世界だから、日本電気がメンバーじゃないのはいたしかたないのでは?
 他で上がっているMicrosoftやIBM、ミラクルリナックス、Justsystemは全部ソフトウェアベンダーですし。
 酷い言い方になるけど、ソフトウェアベンダーとしてのNECはたいしたことないんじゃないでしょうか。個人的には富士ゼロックスあたりは(参加していないのであれば)参加しても良かったんじゃないかなと思いますし、日本のUNIX系のベンダーが参加していないのは気になりますけれど。

 それに使い物にならないUnicode変換表を作ってしまった日本工業標準調査会Unicodeコンソーシアムはもっと責められるべきでは?(実際、「正しい変換」は見送ったわけで)
(追記:ここで述べた「使い物にならないUnicode変換表」というのは、\5cをYen Markにアサインしたことを指します。\5cをYen Markにアサインすると多くの問題が起こるため、それを回避するためにEncodeモジュールでも\5cはYen Markにはアサインしていないはずです。……というわけで、安岡さんの言う「WAVE DASH問題縁起」とは関係ありません。ちなみにWAVE DASHに関する妄想は前にちょっと書きました。)
(さらに追記:安岡さんのご指摘により、「使い物にならないUnicode変換表」を作ったのは日本工業標準調査会ではなく、JISはUnicodeコンソーシアムの決定に従っただけだとのことですので訂正しました。
 もっとも誰があの変換表を提案したのかは気になるところです。Microsoftは独自の変換表を使ってるので違うだろうし、日本工業標準調査会でもないとすれば、いったい誰が作ったの?)

 というわけで「介護料」は税金から支払われるべきだと思いますし(なのでLegacy Encoding Projectが援助を受けているのは正しいと思う)、介護料が必要だと思うならIPAに申請するか、すでに採択されているLegacy Encoding Projectから支払われるのがいいんじゃないかな、と思います。

 もっとも今は
NTT DocomoやAUがないのもイタイところです。おかげでケータイの絵文字がずっと宙に浮いたままです。

という携帯キャリアが極悪なので(インターネット標準に従っていないのにそれを売りにするなんて!)、そちらに請求書をまわすのが正しい気がします(笑)。
 NECをイヂメるくらいなら、是非ともこちらを!



Jcode 2.xでは、Perl 5.8上ではEncodeのWrapperとして動きます。よってEncode::EUCJPMSがインストールされていれば、

use Jcode;
use Encode::EUCJPMS;
print Jcode->new($str, 'cp51932')->cp51932;

が機能します。ですのでJcode側の準備はすでに整っているということです。

 もちろんこれらのことは知っていて、その上で標準的なインターフェイスであるsjisやeuc(あるいはjisやiso_2022_jp)を指定してCP932互換になるモードもあると良いんじゃないのかな、と思ったのです。
 自分一人で使ってる分には無くてもいいんですけどね……。
 「EUC-JPやShift_JISとUTF8を何も考えずに使うとトラブルよ!」ってなことをレガシーエンコーディング対策本部の方々が啓蒙していくことに期待しているところではあります。


この記事へのコメント

2006年06月05日 10:34
「使い物にならないUnicode変換表を作ってしまった」のは、そもそも『The Unicode Standard, Version 1.0, Volume 1』(1991年10月)の方なんじゃないか、と個人的には思います。詳しくは、私のページの『WAVE DASH問題縁起』をごらん下さい。
2006年06月05日 13:37
『The Unicode Standard, Version 1.0, Volume 1』のp.563でも、シフトJISの0x5CはU+00A5の「YEN SIGN」に対応してます。で、JIS X 0221-1995の附属書3は、0x5Cに関してはUnicodeに追随しただけです。ただ、Unicodeのやり方だと「さすがにまずい」可能性があったので、JIS X 0221-1995の解説4.5.3.5 (pp.1001-1002)にわざわざ「YENとREVERSE SOLIDUSの関係」という項を立てて、0x5CをREVERSE SOLIDUSに対応させる場合のやり方を解説してるんですが、それが「使い物にならない」ということですか?
2006年06月05日 13:52
 これは失礼しました。あの表はUnicodeコンソーシアムが作成したものであり、JISが提案したものではないんですね。
 僕はJISがUnicodeコンソーシアムに提案したものだとばかり思っていて、「いくらなんでもそれはまずいだろう」と思ったのです。

 それでは、「使い物にならない表」を作ったのはJISではなくUnicodeコンソーシアムということに改めさせていただきます。
(あの表をUnicodeコンソーシアムに提案したのが誰なのかは気になりますが……)
2006年06月05日 16:46
JISとUnicodeの「対応表」に関しては、結構、複雑な経緯があるようなんですが…。非漢字に関してはUnicodeが1991年10月に出版した表が、漢字に関してはCJK-JRGが1991年12月5日に完成した表が、それぞれ元になっています。で、それらを、平成5年度のUCS調査研究委員会WG1がブラッシュアップして、1994年3月に「対応表」を完成した、ってのが大筋のようです。ただ、シフトJISの0x5Cに関しては当初からずっとU+00A5で、Microsoftがこれを実装しないのはMicrosoftの身勝手であり、ISO 646-1973 BCTをちゃんと読まずにMS-DOS 2.0を作ってしまったツケに過ぎません。
2006年06月05日 17:59
 昔の経緯については分からないのですが、日本では昔から\x5cがYen Markになっているけど\x00-\x7fに関してはASCII互換、みたいな前提でプログラムを作っていた気がするんですよ。Microsoftに限らず、全般的に。
 みんながみんな無視したおかげでそれなりに幸せに暮らしていたのに(Shift_JISに限らずEUC-JPも\x5cはYen Markだと思うので。……実は違うんでしょうか?)、ある日突然「\x5cはYen MarkだからU+00A5ね(=\x5cじゃないよ)」と言われて困ったんではないかと。
 で、(Microsoftを含めた)現実主義な方々は\x00-\x7fに関しては変換しないことにしたのではないかと想像しています。裏を返せば、Unicodeの変換表を作るときに\x5cをYen Markに割り当てた人は、現場の実装を全く無視していたんじゃないでしょうか。
(なので僕は「使えない変換表」と表現したのです)
2006年06月05日 22:19
うーん、1970年代のプログラミングはEBCDICとEBCDIK全盛だったので、「$」と「¥」を同一視(0x5B)することはあっても、「\」はEBCDICに含まれてなかったんですよ。で、シフトJISが1982年に現れて、日本語EUCが1985年に現れて、UNIXマシンなんかでは、シフトJISの0x5C「¥」と日本語EUCの0x5C「\」とを同一視したりしてたんでしょうけど、JUNETコード(今のISO-2022-JPの原型)では「ESC ( J」と「ESC ( B」で一応、区別できるようになってましたし…。あ、EUC-JPの0x5Cは「\」ですけど、EUC-JPの誕生が1991年12月なので、Unicode 1.0 Vol.1 (1991年10月)より後だったりします。とりあえず、私なりの『YEN SIGN問題縁起』を私のページに書いてみましたので、よければごらん下さい。
2006年06月05日 23:00
 なるほど。
 僕は80年代については8ビットパソコンしか知らなくて、その当時の意識では「\x00-\x7fはASCIIと互換だけど\x5cはYen Mark」と教えられた記憶があったのです。
 で、外国のプログラムでも\x80-\xffを使わなければ、例えばStarTreckとか動くよ~という感じで遊んでいましたので、「\x00-\x7f=ASCII互換」という意識があったのでした。


 URLの内容を読ませていただきましたが、ただ、\x5cが日本でYen Markとして流通していて、かつ\x5cが一般的にエスケープ記号として使われている(これはMicrosoftだけじゃないですよね?)限りは避け得ない問題だったように思えるのですが……。
2006年06月06日 11:37
 そうそう、EUC-JPの\x5cがBack Slashだと思ったのは、どこかのLinuxディストリビューションで標準のエンコードがUTF-8になった時に問題が起こったと聞いたからです。詳細までは知らなかったので、てっきり\x5cがYen Markにアサインされていたためかと思ってました。
 とすると、その問題っていうのはJISキーボードだとYen Markが入力できるけどBack Slashが入力できなくなってしまった、とかだったのかな?

この記事へのトラックバック