いいじまです。

> fj.kanji なので極力正確な用語を使ってみます。

といいつつ、正確になっていないような気が。
細かいことですが…
・「所謂Shift_JIS」は単に「Shift_JIS」で正しい。
　Shift_JIS は IANA に正式に登録されたエンコーディング名。
　＃JISの規定では「シフト符号化表現」ですから、カナ交じりで「シフトJIS」
　＃と書くのは非公式。
・「JIS X208」は誤り。「JIS X0208」と4ケタにするのが正しい。
です。

>         a.NEC 特殊文字 (0x8740-0x879c)
>         b.NEC 選定 IBM 拡張文字 (0xed40-0xeefc)
>         c.IBM 拡張文字 (0xfa40-0xfc4b)
> 　PC-98x1 の漢字 ROM には a, b が入っています。c は JIS X208
> の定義域の外にあるので、JIS X208 ベースのコード体系である漢
> 字 ROM には収納出来ません。

> 　漢字 ROM で漢字を表現していた PC-98x1 に対し DOS/V では全
> て software で対応してましたので、最初から JIS X208 ベースで
> はなく Shift_JIS ベースのコード体系で font を持っていました。
> 　なので c のような JIS X208 の定義域を外れたところに拡張文
> 字を持つことが可能でしたが、この領域は JIS X208 にも EUC-JP
> にも変換することが出来ません。

もう少し詳しく言うと、c. の文字のうち a. と重複するものをある程度省いて、
JIS X0208 の範囲に remap したのが b. です。b. と c. の範囲を Windows 上
で表示させると、同じ文字が同じ順序で並んでいるのが分かると思います。

歴史的には、80286 と XMS を待たなければいけなかった DOS/V よりも先に、ハ
ードウェアによる IBM/PC の日本語対応化が色々とあって、c. のコードの由来は
その時代にまで遡るはずです。

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

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

> 　で、ローマ数字は a, b, c の全てに存在しますので、河野さん
> の仰る「98 依存文字」がどれなのか判りませんが、c はそもそも
> EUC-JP で表現出来ませんので、a か b でしょうね。

Windows の場合、Unicode から Windows-31J への変換の優先順位は a→c です。
（b. は使わない。）
したがって、普通に Windows 上の各種 IME から入力したり、Unicode アプリ
（IE を含む）を一度でも介したりすると、ローマ数字の大文字は a. になりま
す。ローマ数字の小文字は c. ですが、これは一部のアプリ（OE など）に限っ
て独自に b. に map してから EUC-JP や ISO-2022-JP に変換し、残りの大半の
アプリは変換不能として処理します（不正なコードを吐くケースもままある）。

> 　a の領域は Mac OS では歴史的に「(月)」等の別の記号が割当て
> られていますので、IE で「(藍)」になるということは多分 a の領
> 域の「II」なんでしょうね。
> 　この部分の Unicode 変換テーブルは完全に Apple 特殊文字に対
> 応されているので、どう足掻いても NEC 特殊文字として変換させ
> ることは出来ないと思います。

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

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

これはお勧めできません。そもそも b. の領域に大文字の「II」はありません。
さらに、
・b. の領域にも従来 Apple は独自拡張の文字を詰め込んでいる
・JIS X0213 ではこの領域の Microsoft 陣営の既得権は保護されなかった
　（別の文字で埋まった）
・b.→Unicodeに変換→c.に正規化→EUCに変換不能、という事態が発生する
と、マイナス面ばかりです。

＃ですので、私個人は a. は何食わぬ顔で使いますが、b. や c. は使いません。
＃…使っている環境の都合で面倒が生じるので使いたくありません :-)

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

これは Unicode との往復変換をするコード全般の問題ですね。

公的な規格なら重複する文字はUnicodeに重複採録されますが（たとえば漢字統合
の際に異体字を両方採録するとか、KS C5601 で同じ文字でも複数の音があるもの
は重複採録していたのを互換領域に収めるとか）、Windows-31J は公的な規格で
はないので、重複採録するには私用領域を使わざるを得ず、Windows-31J→Unicode
の変換の際に統合しないことはむしろマイナスになります。

そして、いったん統合されてしまったら、逆変換の際はどちらか片方に統一しな
ければいけませんから、その統一先として Microsoft が c. を選んだというだけ
です。

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

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