「産総研が多言語化ライブラリをLGPLで公開」記事へのコメント

ISO 10646 も仲良し

[Anonymous Coward]

ISO 10646も、符号化文字集合の1つにすぎないとして同列に扱える、至極真っ当な世の中がやってくるのでしょうか?

#これでUnicodeにかかるテンションが幾らかでも下がれば、変換表の非互換性の解消も少しは易くなるかもしれないと期待してみるAC。

Re:ISO 10646 も仲良し

[Anonymous Coward]

EUC-JP の 0x5c はバックスラッシュで、シフト JIS の 0x5c は円記号だから両者のあいだで 0x5c は変換エラーになるという 至極まっとうな世の中は、いつになったら来るのでしょうか？

変換表の混乱の一部の責任は、JIS X 0201 ローマ字と ASCII とをエエカゲンに使ってきた日本人にもあります。あくまで一部ですが。

Re:ISO 10646 も仲良し

[thor (5250)]

もうJIS X0201は捨てて、Shift JISの0x5cもバックスラッシュにしてしまう、というのが技術的には一番簡単な解決法でしょう。それが受け入れられるかという問題はありますが、EUC-JPの0x5cをバックスラッシュ以外にすることよりは受け入れられやすいでしょう。

0x5cを半角の円記号(のグリフ)が表示されることを期待して使っている人にとっては文字化けしたように見えることにはなるが、円記号ならJIS X0208にちゃんとあるからそれを使えばよいし、もともと賢明な人は円記号が表示されて欲しい文脈で半角円記号は使っていないでしょう。

ISO-2022-JPで送られる日本語のE-Mailでは、そもそもJIS X0201 Romanは現在ほとんど使われていないように見えます(半角英数字に切り替えるESC(Jというエスケープシーケンスはほとんど見ることがない。Outlook ExpressでさえもESC(Bを使う)。あくまで使われている文字コードとしては、ですが。もっとも、ほとんどの一般の人はそんなことは知らず、半角円記号として表示されるのが本当は誤りであることは知らないのでしょうが。

2バイトコードであるJIS X0208が扱えるようになった段階で、JIS X0201はRomanも片仮名も捨ててしまっていれば今頃はもっとすっきりしていたのでしょうね。

Re:ISO 10646 も仲良し

[oku (4610)]

もうJIS X0201は捨てて、Shift JISの0x5cもバックスラッシュにしてしまう、というのが技術的には一番簡単な解決法でしょう。それが受け入れられるかという問題はありますが、 EUC-JPの0x5cをバックスラッシュ以外にすることよりは受け入れられやすいでしょう。

技術的には (or 文字コード的には) こちらが真っ当な解であることを承知の上で (後、Shift_JIS の変換表でも 0x5c はバックスラッシュのはず。0x5c が u00a5 なのは CP932 の変換表くらいです)。

もともと賢明な人は円記号が表示されて欲しい文脈で半角円記号は使っていないでしょう。

そんな賢明な人など皆無とまではいいませんが、希少価値のある人間だとみなしていいと思います。 CP932 の変換表が 0x5c を u00a5 に割り付けているのは、日本では JIS X0201 の円と ISO-8859 のバックスラッシュは事実上区別されずに使われている (実装上、同一グリフの別フォントとみなさざるを得ない) という現実を冷徹に認識した上で、顧客の利便性のためなら技術的な筋のよさはステ、という決断を下したものと解釈しています。

少なくない EBCDIC 系の日本語コードが $ の場所に￥を突っ込んでいるのも同じ理屈でしょう (多分、これは COBOL の実装が諸悪の根源と夢想)。

Re:ISO 10646 も仲良し

[Anonymous Coward]

$gt; 0x5c が u00a5 なのは CP932 の変換表くらいです

CP932 でも 0x5c は u005c です。u00a5 なのは Shift_JIS。

ではなぜ Windows において 0x5c が halfwidth-￥ に見えるかと言うと、MS ゴシック等のグリフの問題。Arial Unicode MS 等を使うと、ちゃんとバックスラッシュになります。

Re:ISO 10646 も仲良し

[oku (4610)]

あ～、すみません。 読み返してみると引っくり返して書いてました。

ご指摘どうも。＞ #500377 の AC 氏

結局何を主張したかったかというと、real world では 0x5C は「円とバックスラッシュを兼ねる＠日本限定」とするのがほぼ唯一の現実的な解だろうと言うことです。

# Unicode ステという解もあるかも知れないが。

Re:ISO 10646 も仲良し

[kanie (911)]

> もともと賢明な人は円記号が表示されて欲しい文脈で半角円記号は使っていないでしょう。

しかしながら、JIS X 0208の円記号も使うべきではないです。
「図形文字の一意な符号化」を考慮すると、それぞれの文字コードの円記号は

• ISO-2022-JP: JIS X 0201(これは微妙)


• EUC-JP: JIS X 0208


• Shift JIS: JIS X 0201


• Unicode: JIS X 0201由来のu005c

となるわけで、文字コードを変換したときに「期待通り」になるとは限りません。
結局、円記号は使わないのが無難です。

# 請求書を書くときに困った

Re:ISO 10646 も仲良し

[kanie (911)]

う、ミス。

• Unicode: JIS X 0201由来のu00a5

日本の通貨記号

[zenkakueisuuji (20374)]

0x5cを半角の円記号(のグリフ)が表示されることを期待して使っている人にとっては文字化けしたように見えることにはなるが、円記号ならJIS X0208にちゃんとあるからそれを使えばよいし、もともと賢明な人は円記号が表示されて欲しい文脈で半角円記号は使っていないでしょう。

文字化けではないのです。日元の記号はバックスラッシュなのです ;-)

それはさておき、私は日本語の通常のメール中では JIS X 0208 の円記号を使いますが、英語の場合は "JPY" と書きますね。美国通貨は "$" だったり "US$" だったり "USD" だったりしますが。
日本語でも "JPY" が通れば安全なのかも知れませんが､なんせ普及率がバックスラッシュより圧倒的に低い。

Re:ISO 10646 も仲良し

[Anonymous Coward]

＞変換表の混乱の一部の責任は、JIS X 0201 ローマ字と ASCII とをエエカゲンに使ってきた日本人にもあります。あくまで一部ですが。

ISO 646を策定した奴に文句言え。