しらいです。

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

In article <42FF4EDB.768E5340@ht.sakura.ne.jp>,
IIJIMA Hiromitsu  <delmonta@ht.sakura.ne.jp> wrote:
>いいじまです。

>・「所謂Shift_JIS」は単に「Shift_JIS」で正しい。
>　Shift_JIS は IANA に正式に登録されたエンコーディング名。

　いえ。「Shift_JIS」と「Windows-J31」とが別の charset であ
ることを称して「所謂」です。拡張文字は後者にしか含まれません
が、一般にはこれらは同一視されていますので。
　因みに「(月)」みたいな Apple font を含んだ Shift JIS 系の
コード体系は IANA にも登録されていないみたいですね。


>もう少し詳しく言うと、c. の文字のうち a. と重複するものをある程度省いて、
>JIS X0208 の範囲に remap したのが b. です。b. と c. の範囲を Windows 上
>で表示させると、同じ文字が同じ順序で並んでいるのが分かると思います。
>
>歴史的には、80286 と XMS を待たなければいけなかった DOS/V よりも先に、ハ
>ードウェアによる IBM/PC の日本語対応化が色々とあって、c. のコードの由来は
>その時代にまで遡るはずです。

　もっと遡ると、元々「IBM 拡張文字」ってのは汎用機に実装され
てたものなので PC-9801 が生まれるより前からあったと思います。
なので初期の PC-9801 から実装されてるんですね。
　ただ、その拡張分は JIS で規定されていないのでどの領域に割
当てるかを NEC は悩む訳です。結局 JIS X0208 の未定義領域に突
っ込むんですが、その後で PC-DOS なり DOS/V なりへの漢字実装
を余儀なくされた IBM は NEC とは別の領域に無理矢理突っ込みま
した。当時はライバル視してたんで当てつけだったのかも。


>> また、a は PC-9801 の頃は漢字 ROM に入ってません。
>
>これ、いつの時代の話です？　それとも、b. と混同している？
>少なくとも、PC-9801NS（＝386SX）のころには a. はありましたし、PC-9801と
>PC-9821が並存した時代には a. も b. も両方あったはずです。

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


>> 　で、ローマ数字は a, b, c の全てに存在しますので、河野さん
>> の仰る「98 依存文字」がどれなのか判りませんが、c はそもそも
>> EUC-JP で表現出来ませんので、a か b でしょうね。
>
>Windows の場合、Unicode から Windows-31J への変換の優先順位は a→c です。
>（b. は使わない。）

　それが違うんですよ。95/98 architecture と NT architecture
とで拡張文字領域の mapping が逆になってます。

＃　この辺りを Samba 日本語版で苦労したいきさつが「Samba の
＃すべて」にちょっと載ってたりします。


>JIS X0213ではこの領域が de facto standard から de jure standard に昇格
>しましたから、JIS X0213 ベースの体系を指定すれば堂々と使えます。

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


>> 　なので、既に書かれている文書ではどうしようもありませんが、
>> これから入力するのであれば b の領域の「II」を使えばいいんじ
>> ゃないでしょうか。
>
>これはお勧めできません。そもそも b. の領域に大文字の「II」はありません。

　あ、しまった。大文字でしたか．．．。


>・b. の領域にも従来 Apple は独自拡張の文字を詰め込んでいる

　確かに大文字だと無理なんですが、ローマ数字領域って空いてま
せんでしたっけ？尤も、Mac OS の漢字コード体系って version に
よってまちまちなんで、ちゃんとは追えてないんですが。


>と、マイナス面ばかりです。

　まー、元々「機種依存文字」って呼ばれてるくらいで、platform
の異なる環境で再現するのが不可能とされている訳ですから、この
解も無理矢理な解でしかありません。


>> 　但し、Windows の IME は勝手な正規化を行なってしまい、「II」
>> のように複数のコードの存在する文字は直接コード入力してもその
>> コードは生成されませんので、場合によっては binary editor が
>> 必要かも知れませんね。
>
>これは Unicode との往復変換をするコード全般の問題ですね。

　Unicode に限ったことではありません。MS-DOS と DOS/V とか、
Windows 以前から存在する問題ですね。
　実際、95/98 architecture では Unicode が介在するのは VFAT
VxD の部分だけ (アプリは別) ですが、IME の正規化は行なってい
ます。
　これは、Windows-31J -> Unicode -> Windows-31J という変換の
結果ではなくて、内部に Windows-31J の正規化テーブルを持って
いるからですね。

　なので、Windows の version によっては妙なことが起こります。
filename に拡張文字を使う時は上の変換による副作用として生じ
る正規化ですが、IME による正規化は IME 独自のテーブルによる
ものなので、結果として同じ入力文字が異なるコードを生成します。
　Windows API はこれらの重複文字を同一視するので特に支障はな
いんですが、アプリベースだと同一視出来ないので、例えば「dir」
の結果を「grep」で引っかけようとするとヒットしなかったりしま
す。
　Windows の全 version を揃えてたりはしないので、既にどの環
境だったか憶えてませんけど、確か Me 辺りがそういう混乱した実
装になってたんじゃなかったかなー。

　元々 95/98 と NT とで異なる mapping を採用してしまったこと
が元凶なんですけどね。


>今から考えれば b. を選ぶべきだったんでしょうけど、Microsoft が Windows-31J
>と UCS-2 との変換表を作った時点では、b. の領域が JIS X0208 で半永久的に空
>きになることは誰にも予想がつかなかったので、将来ありうるバッティングを避
>ける意味では仕方がないことでした。

　95/98 と NT との mapping 問題なんかを見る限り、「何も考え
てなかった」が正解のような気がします。開発部隊が違うのは判る
けど、形の上では同じ会社の製品なんですからねー。

-- 
                                               しらい たかし