「産総研が多言語化ライブラリを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で送られ

Re:ISO 10646 も仲良し

[oku (4610)]

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

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

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

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 も仲良し

[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