「bashがマルチバイト文字に正式対応」記事へのコメント

重い

[manba256 (10135)]

ただでさえメモリ食うし、重いbashがさらに肥大化。
そんなに多バイト文字つかいたいんですか？

まあ、メモリ一桁メガバイトの住人のたわごとか。

--
------------------------- Excess and Obsolete

Re:重い

[Anonymous Coward]

とっても使いたいです…てゆうかばりばり使ってますが。
# EUC-JP と Shift_JIS が混在するとどう振る舞うんだろう (^^;;

EUC-JP と Shift_JIS が混在

[kubota (64)]

「混在」というのが、よくわからないんですが、

ja_JP.SJIS ロケールでは、いわゆる半角カナも含めて、 Shift_JIS を正しく扱います。

ただし、ふつうは ja_JP.SJIS ロケールなんてのが用意されてない だろうから、localedef コマンドを使って作らないといけません。

Re:EUC-JP と Shift_JIS が混在

[numa (4467)]

ja_JP.SJIS ロケールは，作成可能でしょうか。

最近流行の，Shift_JIS を厳密に解釈することを求める立場からすると， 0x5C のコードポイントにある文字 (\) は，Shift_JIS ではバックスラッシュ (REVERSE SOLIDUS) ではなくて円記号 (YEN SIGN) です。 そして，ISO C にしろ，POSIX にしろ，バックスラッシュのコードポイントがロケールによって動的に変わってしまう状況は想定していないはずなので， たとえ charmap ファイルは作成可能にしても， それを実際に運用するのは難しいと思います。

たとえば，0x5C の文字は Shift_JIS では円記号だからエスケープ文字ではないはずなのに，プログラムによってエスケープ文字と解釈されたり(しなかったり)するとか。もっとも
LANG=ja_JP.SJIS; export LANG
とかやったとたんに，既存のシェルスクリプトが軒並み動かなくなったりするのも困りますけどね :)

いや，もちろん，堅いことを言わなければ使えるのはわかりますよ。

CP932

[kubota (64)]

既存のシステムでこの問題をてっとりばやく片付ける方法は、Shift_JIS の代わりに CP932 を使うことです。

CP932 は、日本語版 Windows で使われている文字コードで、(JIS X 02xx の世界から見れば) Shift_JIS にいわゆる「機種依存文字」を追加したものです。が、ミソは、Unicode から見たとき、Shift_JIS と CP932 はそれ以上の差異があるという点です。

それは、CP932 と Shift_JIS とでは、Unicode への変換テーブルに一部相違がある、という点です。そのひとつの例として、CP932 では、0x5c は U+005C に変換されます。ほか、JIS X 0208 に属する文字にも、いくつか相違があります。

問題は、日本語版 Windows では、U+005C は円記号だったりすることなんだけど、いまのところそれは関係ないし。

Re:CP932

[Anonymous Coward]

内容としては参考になるのですが、

> 最近流行の，Shift_JIS を厳密に解釈することを求める立場

の人に

> 既存のシステムでこの問題をてっとりばやく片付ける方法は、Shift_JIS の代わりに CP932 を使うことです。

というのは、返答としてどうかな？と思います。

それはともかく、Single Unix Specification の該当項 [opengroup.org]を読んでみましたが、
Escape Character って確かに Bac

Re:EUC-JP と Shift_JIS が混在

[Anonymous Coward]

ISO 646 を知っていれば、そういう結論にはなりません。
Unicode が絡むとまともに処理するのが難しいものの、
それをちゃんと解決できないのは実装がヘボイだけ、
というそしりを免れるものではありません。

Re:EUC-JP と Shift_JIS が混在

[Anonymous Coward]

> ISO 646 を知っていれば、そういう結論にはなりません。

とか書いたんですけど、よくよく考えてみるとそんな単純な
話でもないのかなぁ、と思い始めたりして。

どうもこの辺は実装依存の話で、Single Unix Spec あたりを見ても
厳密には書いてないのですけど、Portable charset としては確かに、
\ として reverse solidus とか backslash とか書いてあるんですよね。

一方で、伝統的な ja_JP.SJIS では、JIS X 0201 Roman は
ISO 646 の思想に従って \ を ISO 646-IRV のそれと同質に
解釈するのが普通だったりしますな。

結局、そこは実装依存という話なので、一概に言い切れない、
という話ですね。失礼しました。

Re:EUC-JP と Shift_JIS が混在

[numa (4467)]

一方で、伝統的な ja_JP.SJIS では、JIS X 0201 Roman は
ISO 646 の思想に従って \ を ISO 646-IRV のそれと同質に
解釈するのが普通だったりしますな。

苦し紛れにそういうことをしていたのは事実ですが， それは「ISO 646 の思想」というほど 確乎としたものなのでしょうか。 ISO 646 は ASCII をもとにした符号化文字集合で， 「各国版 (National version)」として一部の文字を入れ替えた版を作ることを許してはいましたが， そのうちの入れ替えられた文字を別の National version の文字 あるいは「国際参照版 (IRV)」と同等に解釈してよいという規定はなかったと思います。

たとえば，日本版では 0x5C は「円記号」ですが， 韓国版ではこれは「ウォン記号」になります。 これを一緒にされたら困るでしょう。 貨幣価値も一桁くらい違うし :-)

Re:EUC-JP と Shift_JIS が混在

[Anonymous Coward]

補足。#131459 は #131427 へのコメントね。