[pgsql-jp: 33601] Re: EOFの問題について

[Nao J. Yasuda]

> SJIS や、JIS の \ は、規格上は円記号のはずです。
>なのに Windows や Unix では Unicode に変換する際に
>平気で違う形のバックスラッシュ(005C REVERSE SOLIDUS)に
>変換してしまいます。

もともとの7ビットASCII文字コードセットでは、0x5C は
バックスラッシュ(＼の1バイト文字)でした。
ASCIIをJIS化する時、日本語ではほとんど使われることの無い
バックスラッシュを円記号(￥の１バイト文字)に変えて割り当てました。
いわゆるコードポイントに対するグリフ(字形)を変えた、という
ことになります。

したがって、コードセットによって変わるのが、正しい解釈、
ということになります。JIS-2022-JPのJISローマ字エスケープでは
0x5Cは半角の￥であるのは正しいですが、ASCIIエスケープでは
同じコードが＼の1バイト文字で表示されるのが正しいのです。
ISO8850という西ヨーロッパ言語の文字を定義したセットの
ラテン1と呼ばれるサブセットでは、もちろん円記号ではなく
ASCIIと同じ＼の1バイト文字がグリフとして表示されます。

SJISだけが日本語の世界ではないのですが、日本語コードについては、
例えば http://www.kanzaki.com/docs/jcode.html のようなページに
いろいろ説明されえいます。他にも沢山あります。

> それは、PATH の区切り文字だったり、エスケープ記号だったり
>して文字コードの 0x5c が別の値に変わってしまうと OS が
>正常に動かなくなる可能性があるという しがらみ からなのでしょう。

というよりは、コードポイントに割り当てられるグリフの定義が
違うということです。0x5C という8ビットデータをプログラムが
読み込んだとき、それが￥と見えようと＼のように見えようと
関係ありません。グリフはプログラムにとって知ったことでは
ないのです。0x5C というビット列が意味があるのであり、
それ以上の意味は無いのです。

># SJISでコメントを書いたバッチファイルや、EUC で
># コメントを書いたシェルスクリプトを UTF-8 へ
># 変換しただけで動かなくなったりしたら困りますから。

これも文字データを処理するプログラムしだいですね。
CGIなどはどのようなコードが渡されてくるか分からないので、
受け取ったビット列が文字コードであることが期待される場合、
必ず内部処理コードに変換して処理することが常識的に
行われています。そうでないと、特定環境でしか正しく動作しない
CGIになってしまう可能性が高いからです。

> メーラに入力するときに SJIS で入力して送るときには
>SJIS ==> Unicode ==> JIS と変換される過程で \ が ￥に
>変わってしまっただけでしょう。
># SJIS => JIS は直接計算して変換してくれ〜といいたいところですが、
># 日本語だけ特別扱いしたコンバータを作るのは面倒でしょうから
># 汎用的(他の言語も扱えるよう)に Unicode 経由になるのは仕方ないでしょう。

Unicodeは1バイトコードと1バイトコードの区別をしなくてもすむように
考えられているのですが、JIS-2022-JPにしたとき、エスケープ状態に
よっては表示グリフが変わってしまうことがあることは前記のとおりです。
変換する場合のデフォルト設定などにも関係したりします。

とりあえず要点のみで失礼します。(_ _)

---やすだ