[1] ISO-2022-JP-3, ISO-2022-JP-2004 符号化表現は、 文字コードの一種です。

[2] ISO-2022-JP-3 は JIS X 0213:2000 附属書2で規定されていました。

[3] 実装水準3であることを明示するため ISO-2022-JP-3-plane1 符号化表現と呼んでもよいと規定されていました。 (ISO-2022-JP-3 は実装水準3も実装水準4も含まれるということのようです。 実装水準4と明示する方法は定められていません。)

[83] JIS X 0213:2004 では第1面が改正されました。 JIS X 0213 それに伴い符号の名前が変更されました。 しかも正誤票で再改正されました。

[4] JIS X 0208:1997 RFC 1468符号化表現の設計を JIS X 0213:2000 / JIS X 0213:2004 に適用したもののようですが、 互換性はありません。

[5] 名前から ISO-2022-JP と関係がありそうにみえます。 JIS X 0208:1997 RFC 1468符号化表現が ISO-2022-JP から派生したものなので、 系譜は連なっています。 互換性はありません。 ISO-2022-JP

[7] 名前から ISO/IEC 2022 と関係がありそうにみえます。 JIS X 0213:2000 / JIS X 0213:2004 には関係があるともないとも書いてありません。 (JIS X 0208:1997 RFC 1468符号化表現は適合しないと明記していました。 ISO-2022-JP ) 適合するのかどうかぱっと見ではわかりません。

[6] JIS X 0213:2000 / JIS X 0213:2004 本体は外字を認めていますが、 ISO-2022-JP-3 は認めていません。 JIS X 0213

[20] ISO-2022-JP-3 / ISO-2022-JP-2004 には代替名称の規定がありません。 重複符号化

[8] ISO-2022-JP-3:

[22] ISO-2022-JP-2004:

[9] ESC 2/4 4/2 は本来 JIS X 0208:1983 の指示シーケンスです。 ISO-2022-JP-3 では JIS X 0208-1983 と JIS X 0213:2000 とで解釈が変更されていると判断した面区点位置が除外されているようです。 ISO-2022-JP-2004 では JIS X 0213:2004 で解釈が変更されている面区点位置が更に除外されているようです。 JIS X 0208

[23] ESC 2/4 2/8 4/15 は本来 JIS X 0213:2000 の指示シーケンスです。 ISO-2022-JP-2003 では JIS X 0213:2000 と JIS X 0213:2004 とで解釈が変更されていると判断した面区点位置が除外されているようです。 JIS X 0208, JIS X 0213

[40] JIS X 0213:2004 で追加された10文字と既存の10文字の20文字が含まれます。

[10] ISO-2022-JP-3 / ISO-2022-JP-2004 はどこの誰が使う想定で作られたのか謎です。 インターネットでの情報交換に使うようなことが書かれてますが、 具体的にインターネットのどのプロトコルの何かはわかりません。

[11] ISO-2022-JP-3 / ISO-2022-JP-2004 は ISO-2022-JP 系の符号化方式ですが、 エスケープシーケンスがまったく違うので、 ISO-2022-JP の実装はこれを解釈できません。

[12] ESC 2/4 4/2 が使えるのはその互換性への配慮なのかもしれませんが、 基本的な漢字が除外されすぎていて、 一般の人の日常の利用に耐えうるのか疑問です。

[13] 既存の ISO-2022-JP の実装が新たに ISO-2022-JP-3 / ISO-2022-JP-2004 にも対応するとなると、

の選択肢があります。 >>14 では互換性がまったくなく、 ESC 2/4 4/2 を使う意味は何もありません。ただただ古い実装には読めないデータになるだけです。 >>15 の場合 JIS X 0213:2000 や ISO-2022-JP-2004 附属書の規定に基づく受信装置といえるのか疑問です。

[24] しかも ISO-2022-JP-2004 も ISO-2022-JP-3 が JIS X 0208-1983 に対して行ったのと同じような措置を JIS X 0213:2000 第1面に対して採ったために、 ISO-2022-JP-3 と ISO-2022-JP-2004 も非互換で同じような問題を孕んだものとなっています。

[17] >>14 のような完全新規の符号化文字集合とするなら、 Shift_JISX0213 / Shift_JIS-2004 や EUC-JISX0213 / EUC-JIS-2004 を使ってもいいのであり、 ISO-2022-JP-3 / ISO-2022-JP-2004 を使う必然性がなくなります。

[16] ISO-2022-JP-3 / ISO-2022-JP-2004 を受信する実装も、さすがにそれだけに対応するというわけにはいかないはずです。 古い実装から受信したデータは ISO-2022-JP (なり他のものなり) で符号化されているはずで、それにも対応しなければなりません。 ISO-2022-JP も ISO-2022-JP-3 / ISO-2022-JP-2004 もどちらも同時に対応したいなら、 ISO-2022-JP-3 / ISO-2022-JP-2004 の規定だけでなく、 完全な JIS X 0208-1983 と、 JIS X 0201 ラテン文字用図形文字集合も追加する必要が出てきます。 つまり ISO-2022-JP + JIS X 0213:2000 / ISO-2022-JP-2004 です。

[18] 素直に JIS X 0208:1997 RFC 1468符号化表現 + JIS X 0213:2000 (+ JIS X 0213:2004) と定義しておけば、既存の実装の自然な拡張として実現可能だったのではないでしょうか。

[19] 少なくても歯抜けの第1面なんて、 実装用の歯抜け表の作成とメモリー上に保持しておくコストが掛かるのに、 誰の何の要求も満たし得ないんですよね。

[25] ISO-2022-JP-3 における偽 JIS X 0208-1983 と ISO-2022-JP-2004 における偽 JIS X 0208-1983 も違うので、更に実装コストが増すとかいう・・・・

[21] 更に実装によっては

... といったバリエーションに対応しています。

[30] -strict は、できるだけ ESC 2/4 4/2 (本来 JIS X 0208-1983 のエスケープシーケンス) を利用することで、 JIS X 0213 に違反しない範囲で ISO-2022-JP との互換性を重視して符号化します。

[31] -compatible はもう一歩踏み込んで、 JIS X 0213 の除外文字の規定に違反してでも ISO-2022-JP との互換性を重視して符号化します。

[32] これらの名前を使って符号化する実装においては、 -strict でも -compatible でもない無印は、 できるだけ JIS X 0213 のエスケープシーケンスを利用して符号化します。

[33] wdic は -compatible, -strict が JIS X 0213 で定義されているようなことを書いていますが、 JIS X 0213:2000 および JIS X 0213:2004 の本体および附属書にはそれらしき記述が見当たりません。

[34] -strict や -compatible は emacsen で実装されて、 Unix 系のツール等を中心に他のソフトウェアにも広まったようです。 Web検索によると対応ソフトウェアのドキュメントがいくつか発見できますが、 4つ (および無印2つの合計6つ) のすべてに対応しているとは限らないようです。 (ドキュメントの時点でそうなので、実際動かしてみるともっと挙動に違いがあるかもしれません。)

[37] -2004 から見た -3 に対する「互換性」の考え方でも挙動にばらつきが起こりそうですね。

[35] 中には ISO-2022-JP-3 系の名前で ISO-2022-JP-2004 系に対応している実装もあるとか。

[36] 大元の JIS がそのまま普通に実装可能なまともな規格を制定しなかったせいで、 各実装がみんなバラバラに対処して混乱が生じたという、 標準化の失敗のお手本にしたいような事案ですね。

[38] 文字セットについて - 超漢字ウェブサイト, , http://www.chokanji.com/ckv/manual/06-05-07.html

[39] 超漢字メールはISO-2022-JP-3 (+ テキスト形式TRONコード) の送受信に対応していました。 >>38