いいじまです。

> 　正直に告白すると、前の記事は酒呑んで TV 見ながら書いてまし
> た。なので「極力」なんです :-)

了解です。

> >・「所謂Shift_JIS」は単に「Shift_JIS」で正しい。
> >　Shift_JIS は IANA に正式に登録されたエンコーディング名。
> 
> 　いえ。「Shift_JIS」と「Windows-J31」とが別の charset であ
> ることを称して「所謂」です。拡張文字は後者にしか含まれません
> が、一般にはこれらは同一視されていますので。

なるほど、そういう意図でしたか。了解です。
＃とすると、「Shift_JIS系」とか書いてほしかった :-)

> 　もっと遡ると、元々「IBM 拡張文字」ってのは汎用機に実装され
> てたものなので PC-9801 が生まれるより前からあったと思います。
> なので初期の PC-9801 から実装されてるんですね。

なるほど。

> >> また、a は PC-9801 の頃は漢字 ROM に入ってません。

> 　だから PC-9821 がまだ出ていない時代です。少なくとも初代に
> は載ってませんでした。ひょっとすると PC-8x01 みたいに拡張漢
> 字 ROM が出てたかも知れませんけど。
> 　標準実装されたのは V30 機が出て来た頃じゃないかなー。尤も、
> その後も暫くは「平成」なんかは実装されてませんでしたが :-)

なるほど、私が触ったいちばん古いのはPX-9801VXですから、たしかに知らない
わけです。

> >Windows の場合、Unicode から Windows-31J への変換の優先順位は a→c です。
> >（b. は使わない。）
> 
> 　それが違うんですよ。95/98 architecture と NT architecture
> とで拡張文字領域の mapping が逆になってます。
> 
> ＃　この辺りを Samba 日本語版で苦労したいきさつが「Samba の
> ＃すべて」にちょっと載ってたりします。

手元にあるのは Windows Me なので、すでに 2000 系と統一されていると思います。
実家に帰れば98SEがあるのですが…。

> >JIS X0213ではこの領域が de facto standard から de jure standard に昇格
> >しましたから、JIS X0213 ベースの体系を指定すれば堂々と使えます。
> 
> 　X0213 だと EUC-JP にした時に 3bytes になりませんか？

いえ、13区の文字はG1に入っています。
ただ、G3に回されている文字もあると思います。

＃ちなみに、元々はG2を使う予定だったのですが、G2に1バイト文字（＝半角カタ
＃カナ）を想定している処理系が多すぎるとのことで、G3にまわされました。

> そもそ
> も、この特殊な EUC-JP には対応している環境がまず存在しないと
> 思うんですが、どっかにあります？

Emacs :-)
G1だけでよければ非 Unicode な処理系全般でフォントだけ用意して処理できるの
ですが。

> 　実際、95/98 architecture では Unicode が介在するのは VFAT
> VxD の部分だけ (アプリは別) ですが、IME の正規化は行なってい
> ます。
> 　これは、Windows-31J -> Unicode -> Windows-31J という変換の
> 結果ではなくて、内部に Windows-31J の正規化テーブルを持って
> いるからですね。
> 
> 　なので、Windows の version によっては妙なことが起こります。
> filename に拡張文字を使う時は上の変換による副作用として生じ
> る正規化ですが、IME による正規化は IME 独自のテーブルによる
> ものなので、結果として同じ入力文字が異なるコードを生成します。
> 　Windows API はこれらの重複文字を同一視するので特に支障はな
> いんですが、アプリベースだと同一視出来ないので、例えば「dir」
> の結果を「grep」で引っかけようとするとヒットしなかったりしま
> す。

あちゃあ。

========================================================================
飯嶋 浩光 / でるもんた・いいじま   http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta           mailto:delmonta@ht.sakura.ne.jp