Edit

Page

Page title:

Page body:

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

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

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

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

- [DFN[[CODE[ISO-2022-JP-2003]]]]
- [DFN[[CODE[ISO-2022-JP-2003-plane1]]]]
- [DFN[[CODE[ISO-2022-JP-2004]]]]
- [DFN[[CODE[ISO-2022-JP-2004-plane1]]]]

[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]] から派生したものなので、
系譜は連なっています。
互換性はありません。
[SEE[ [[ISO-2022-JP]] ]]

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

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

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

[8] 
[[ISO-2022-JP-3]]:

- [[CL]]: [[JIS X 0211]] [[C0]]
- [[GL]] = [[G0]] : [[ISO/IEC 646 IRV]]
- [CODE(charname)@en[SP]]
- [CODE(charname)@en[DEL]]
- [CODE(charname)@en[ESC]] [N[2/8]] [N[4/2]] : [[ISO/IEC 646 IRV]]
- [CODE(charname)@en[ESC]] [N[2/4]] [N[4/2]] : [[JIS X 0213:2000]] 第1面から一部文字を除外したもの
- [CODE(charname)@en[ESC]] [N[2/4]] [N[2/8]] [N[4/15]] : [[JIS X 0213:2000]] 第1面
- [CODE(charname)@en[ESC]] [N[2/4]] [N[2/8]] [N[5/0]] : [[JIS X 0213:2000]] 第2面
([[実装水準3]]では使用しない)

[22] 
[[ISO-2022-JP-2004]]:

- [[CL]]: [[JIS X 0211]] [[C0]]
- [[GL]] = [[G0]] : [[ISO/IEC 646 IRV]]
- [CODE(charname)@en[SP]]
- [CODE(charname)@en[DEL]]
- [CODE(charname)@en[ESC]] [N[2/8]] [N[4/2]] : [[ISO/IEC 646 IRV]]
- [CODE(charname)@en[ESC]] [N[2/4]] [N[4/2]] : [[JIS X 0213:2004]] 第1面から一部文字を除外したものから更に除外したもの
- [CODE(charname)@en[ESC]] [N[2/4]] [N[2/8]] [N[4/15]] : [[JIS X 0213:2004]] 第1面から一部文字を除外したもの
- [CODE(charname)@en[ESC]] [N[2/4]] [N[2/8]] [N[5/1]] : [[JIS X 0213:2004]] 第1面
- [CODE(charname)@en[ESC]] [N[2/4]] [N[2/8]] [N[5/0]] : [[JIS X 0213:2004]] 第2面
([[実装水準3]]では使用しない)

[9] [CODE(charname)@en[ESC]] [N[2/4]] [N[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]]
で解釈が変更されている[[面区点位置]]が更に除外されているようです。
[SEE[ [[JIS X 0208]] ]]

[23] 
[CODE(charname)@en[ESC]] [N[2/4]] [N[2/8]] [N[4/15]] は本来
[[JIS X 0213:2000]]
の[[指示シーケンス]]です。
[[ISO-2022-JP-2003]] では [[JIS X 0213:2000]] と [[JIS X 0213:2004]]
とで解釈が変更されていると判断した[[面区点位置]]が除外されているようです。
[SEE[ [[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] 
[CODE(charaname)@en[ESC]] [N[2/4]] [N[4/2]] 
が使えるのはその互換性への配慮なのかもしれませんが、
基本的な[[漢字]]が除外されすぎていて、
一般の人の日常の利用に耐えうるのか疑問です。

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

- [14] [[MIME charset]] のような仕組みでどれであるか明確に区別するか、
- [15] [[ISO-2022-JP]] も [[ISO-2022-JP-3]] も [[ISO-2022-JP-2004]]
もどちらも解釈できる復号器を実装するか

の選択肢があります。 >>14 では互換性がまったくなく、
[CODE(charaname)@en[ESC]] [N[2/4]] [N[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] 
更に実装によっては

- [DFN[[CODE[iso-2022-jp-3-compatible]]]]
- [DFN[[CODE[iso-2022-jp-3-strict]]]]
- [DFN[[CODE[iso-2022-jp-2004-compatible]]]]
- [DFN[[CODE[iso-2022-jp-2004-strict]]]]

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

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

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

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

[REFS[
- [27] [CITE@ja-jp[ISO-2022-JP-3-compatible ‐ 通信用語の基礎知識]], [TIME[2022-05-14T02:26:15.000Z]] <https://www.wdic.org/w/WDIC/ISO-2022-JP-3-compatible>
- [29] [CITE@ja-jp[ISO-2022-JP-3-strict ‐ 通信用語の基礎知識]], [TIME[2022-05-14T02:26:35.000Z]] <https://www.wdic.org/w/WDIC/ISO-2022-JP-3-strict>
- [26] [CITE@ja-jp[ISO-2022-JP-2004-compatible ‐ 通信用語の基礎知識]], [TIME[2022-05-14T02:26:07.000Z]] <https://www.wdic.org/w/WDIC/ISO-2022-JP-2004-compatible>
- [28] [CITE@ja-jp[ISO-2022-JP-2004-strict ‐ 通信用語の基礎知識]], [TIME[2022-05-14T02:26:25.000Z]] <https://www.wdic.org/w/WDIC/ISO-2022-JP-2004-strict>
]REFS]

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

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

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

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

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

[38] [CITE@ja[文字セットについて - [[超漢字]]ウェブサイト]], [TIME[2010-11-10T00:23:26.000Z]], [TIME[2022-09-03T06:57:23.660Z]] <http://www.chokanji.com/ckv/manual/06-05-07.html>

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

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Errors

Page name(s)