424.txt

[22] [DFN[ISO-2022-JP]] は、かつて[[日本]]で用いられた[[文字コード]]の1つでした。

[23] [[電子メール]]や[[ネットニュース]]では[[日本]]の[[標準]]の[[文字コード]]とされていました。

* 代替

[25] [[電子メール]]では、世界的な流れにやや遅れて[[日本語]]の[[メール]]でもなし崩し的に
[[UTF-8]] に移行が完了しつつあります。

[24] [[Web]] でも一時使われましたが、主流にはなりませんでした。
当時は[[シフトJIS]]や[[日本語EUC]]がよく使われました。
現在は [[UTF-8]] が使われています。

[26] [[ネットニュース]]は衰退しました。

* 符号化方式

[21] 
,ISO-IR#	,[[符号化文字集合]]	,[[指示]]
,6	,[[ASCII]]	,ESC 02/08 [(] 04/02 [B]
,14	,[[JISX0201]] Roman set	,ESC 02/08 [(] 04/09 [J]
,42	,[[JISX0208]]-1978	,ESC 02/04 [$] 04/00 [@]
,87	,JIS X 0208-1983	,ESC 02/04 [$] 04/02 [B]

- 最初は
-- ASCII で始まらなければなりません (MUST [BIS1468])
-- ISO/IEC 646 IRV (ASCII) ではじまります [JISX0208:1997]
- 終端は
-- ASCII または JIS X 0201 roman で終わらなければなりません [JUNET], [PRACTICE] (MUST [BIS1468])
-- ASCII で終わらなければなりません (must [RFC1468], shall [JISX0208:1997])
- 行末は ASCII または JIS X 0201 roman に
-- であるのが望ましいです [JUNET]
-- でなければなりません (must [RFC1468], MUST [BIS1468], shall [JISX0208:1997])
-- [[指示]]がなくても [[ISO/IEC646]] [[IRV]] (ASCII) にして構いません [JISX0208:1997]
- [58] ESC 02/08 [(] 04/08 [H] は
-- 使ってはいけません [JUNET]
-- 使わないのが望ましいです (should not) [RFC1468]
-- [SEE[ [[指示シーケンス]] ]]
- 制御文字を使う時は ASCII または JIS X 0201 Roman の状態
-- であることが望ましいです [JUNET]
-- でなければなりません ([[BNF]] [RFC1468], [BIS1468]; 定義 [JISX0208:1997])
- JIS X 0208‐1978 と ‐1983, ASCII と JIS X 0201 Roman はそれぞれ
-- 同一視して表示する処理系があります [RFC1468]
-- 全ての処理系が区別するわけではありません [BIS1468]
-- 1978 も 1983 も使わずに 1997 ですが、 
1978 と 1983 で入れ替わっている符号位置は、入れ替わってて構いません。
1978 にない符号位置は実装しなくても構いません。 [JISX0208:1997]
-- が、配送途中で変更するのはいけません (must not [RFC1468], SHOULD NOT [BIS1468])
-- ASCII と JIS X 0208‐1983 を推奨します。 [BIS1468], [PRACTICE]
- [59] JIS X 0208‐1990 を使う時は [[IRR]] を
-- 使わないことにしましょう。 (suggest) [RFC1468]
-- 使ってはいけません。 [JISX0208:1997]
-- [SEE[ [[IRR]] ]]
- JIS X 0208 で規定されていない符号位置は
-- 使ってはいけません [JUNET] (MUST [BIS1468])
-- 情報交換の当事者間の合意で使用できますが、 Internet では使用しません [JISX0208:1997]

※[PRACTICE] は、実際の習慣

[95] 
[[文字集合]]については
[[ISO/IEC 646 IRV]],
[[JIS X 0201]],
[[JIS X 0208]]
も参照。


[57] 
[[DEC]] は [[ISO-2022-JP]] の [[JIS X 0208]] を
[[JIS X 0208-1990]]
としていました。
[SEE[ [[DECの文字コード]] ]]

* 拡張


[67] 
[[JIS X 0208]] の[[空き領域]]の[[外字]]については、
[[JIS X 0208]] 参照。

[70] 
[[符号化文字集合]]を増やした拡張:
[[ISO-2022-JP-1]], [[ISO-2022-JP-2]], [[ISO-2022-INT]], [[ISO-2022-JPext]]

[71] 
[[絵文字]]を追加した拡張:
[CODE[x-iso-2022-jp-kddi]],
[CODE[x-iso-2022-jp-airh]]

[72] 
足し引きしたもの:
[[ISO-2022-JP-3]],
[[ISO-2022-JP-2004]]


** 片仮名用拡張

[60] 
昔から「JIS」「JISコード」「ISO-2022-JP」と称して[[半角カナ]]
([[JIS X 0201]] [[片仮名用図形文字集合]])
の読み書きの一方または両方に対応している実装が多いです。
対応方法は何通りかあります。

- [61] [[JIS X 0201]] [[片仮名用図形文字集合]]を [[G0]] に[[指示]]して使うもの
- [62] [CODE(charname)@en[SO]] ... [CODE(charname)@en[SI]] で使うもの
- [63] [[GR]] で使うもの


[73] 
[DFN[CP50220]]:
[[Windows]] 版 [[JIS X 0208]] (外字つき), 
[[Unicode]] → [[CP50220]] 変換時に[[半角カナ]]は[[全角カタカナ]]に置換される

- [74] [CITE[cp50220 - PukiWiki]], [TIME[2022-05-07T13:59:26.000Z]], [TIME[2006-06-19T16:59:28.251Z]] <https://web.archive.org/web/20060619165834/http://legacy-encoding.sourceforge.jp/wiki/index.php?cp50220>
- [76] [TIME[2021-07-18T23:39:49.000Z]], [TIME[2022-05-07T14:02:08.270Z]] <http://www.iana.org/assignments/charset-reg/CP50220>
- [75] [CITE@ja-jp[Microsoft Windows Codepage : 50220 ‐ 通信用語の基礎知識]], [TIME[2022-05-07T14:00:54.000Z]] <https://www.wdic.org/w/WDIC/Microsoft%20Windows%20Codepage%20%3A%2050220>


[78] 
[DFN[CP50221]]:
[[Windows]] 版 [[JIS X 0208]] ([[外字]]つき)、
[[半角カナ]] ESC ( J あり、
[[EUDC]] は第1バイト 0x7F - 0x92 (入出力ともに可能)
([[IBM拡張文字]]は[[NEC選定IBM拡張文字]]に変換される)

- [88] 
[CITE[cp50221 - PukiWiki]], [TIME[2022-05-07T14:32:48.000Z]], [TIME[2006-06-19T17:28:22.816Z]] <https://web.archive.org/web/20060619165444/http://legacy-encoding.sourceforge.jp/wiki/index.php?cp50221>
- [77] 
[CITE@ja-jp[Microsoft Windows Codepage : 50221 ‐ 通信用語の基礎知識]], [TIME[2022-05-07T14:04:36.000Z]] <https://www.wdic.org/w/WDIC/Microsoft%20Windows%20Codepage%20%3A%2050221>

[79] 
[DFN[CP50222]]:
[[Windows]] 版 [[JIS X 0208]] ([[外字]]つき)、
[[半角カナ]] SI/SO、
[[EUDC]] は第1バイト 0x7F - 0x92 (入出力ともに可能)
([[IBM拡張文字]]は[[NEC選定IBM拡張文字]]に変換される)

- [80] [CITE@ja-jp[Microsoft Windows Codepage : 50222 ‐ 通信用語の基礎知識]], [TIME[2022-05-07T14:08:42.000Z]] <https://www.wdic.org/w/WDIC/Microsoft%20Windows%20Codepage%20%3A%2050222>
- [87] [CITE[cp50222 - PukiWiki]], [TIME[2022-05-07T14:32:04.000Z]], [TIME[2006-06-19T17:31:41.032Z]] <https://web.archive.org/web/20060619165847/http://legacy-encoding.sourceforge.jp/wiki/index.php?cp50222>


** シフトJIS関連の拡張

[86] [[eucJP-ms]] を [[ISO-2022-JP]] 変換したもの

- [85] [CITE[7bit-eucJP-ms(?) - PukiWiki]], [TIME[2022-05-07T14:31:11.000Z]], [TIME[2006-06-19T17:26:28.982Z]] <https://web.archive.org/web/20060619165430/http://legacy-encoding.sourceforge.jp/wiki/index.php?7bit-eucJP-ms%28%3F%29>


[68] 
[DFN[ISO-2022-JP-MS]] と称する拡張があります。
[[EUDC]] に[[私用終端バイト]]が使われています。
[SEE[ [[私用終端バイト]] ]]

[83] -ms とありますが、提案者は [[MS]] ではなく、 [[MS]] の利用例があるかも不明。

[REFS[
- [82] [CITE@ja[libiconv-1.11-ja-1.patch.gz]] ([TIME[2007-10-27 07:56:21 +09:00]] 版) <http://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.11-ja-patch.html>
- [84] [CITE[ISO-2022-JP-MS - PukiWiki]], [TIME[2022-05-07T14:28:53.000Z]], [TIME[2006-06-19T17:31:09.265Z]] <https://web.archive.org/web/20060619170130/http://legacy-encoding.sourceforge.jp/wiki/index.php?ISO-2022-JP-MS>
- [81] [CITE@ja-jp[ISO-2022-JP-MS ‐ 通信用語の基礎知識]], [TIME[2022-05-07T14:09:29.000Z]] <https://www.wdic.org/w/WDIC/ISO-2022-JP-MS>
]REFS]

[69] 
[[シフトJIS]]の [N[0xF040]] 以降の領域 ([[94[SUP[2]]集合]]の外側の95区とそれ以降)
を表すために 
[[GL]]
を機械的に延長して [N[0x7F]], [N[0x80]], ... と続ける方式もあるようです。
>>78 >>79


[REFS[
- [10] [CITE[高瀬橋対岸2]] ([TIME[2010-05-25 11:19:41 +09:00]] 版) <http://drshinwebsite.fc2web.com/sanennanshin/takasebashitaigan2.html>
]REFS]

[11] >>10 は [[ISO-2022-JP]] ですが、たまに[[シフトJIS]]が混入しています。
[[WinIE]] は意図通りに表示しますが、[[Firefox]] / [[Chrome]] ([[Windows]])
では[[シフトJIS]]部分が文字化け ([CODE(char)[[[U+FFFD]]]] 化) します。
[TIME[2012-05-25T12:51:37.600Z]]


[89] 
>>10 ページ途中に出てくる 0xA5 0xA5 は[[半角カナ]]2文字。
ページ末尾にサーバーが挿入したと思われる広告は[[シフトJIS]]。
前者はIE11で正しく表示されるが (Firefox では U+FFFD)、
後者はIE11でも文字化けする (U+FFFD + 第2バイト)。
(10年前のIEがこの動作だったかは不明)
[TIME[2022-05-07T14:43:23.0Z]]

* 文脈

[64] 
[[日本]]の [[Unix]] 系プラットフォームは伝統的に
[[ISO/IEC 2022]] の[[指示シーケンス]]と [[G0]] = [[GL]]
と
[[JISコード]]を組み合わせる方式を[[情報交換]]用に使っていました。
従ってその方面で発展した[[アプリケーション]]ではいわゆる
「7ビットJIS」
コードが使われてきました。

[65] 
次のような場面で [[JUNETコード]]、 [[RFC 1468]] [[ISO-2022-JP]]、
あるいはそれらに近いものが使われていました。

- [[インターネットメール]]
- [[インターネットニュース]]
- [[MIMEメッセージ]]
- [[IRC]]
- [[Web]] ([[HTML]])
- [[XML]]

;; [66] 現在ではいずれもほぼ [[UTF-8]] に置き換わっています。


* 歴史

もともと [[JUNET]] での通信用符号として決められました。
そもそもは漢字コードには [[JIS]] のものを使う, という緩い取り決め
しかなかったようです。

最初は JIS の不具合で、 JIS X 0201 Roman 集合の指示に
ESC 02/08 <(> 04/07 (H) を使っていましたが、正しい
ESC 02/08 <(> 04/09 (J) に改めました。その時により細かい点が
合意されて、現在の ISO-2022-JP とほぼ同じ[[文字コード]]
が出来上がりました。 [[JUNETの手引きの漢字コードの説明]]が
それをまとめたものです。 (この[[文字コード]]は JUNET コード
と呼ばれるようになりました。) (1987年頃)

1993年頃、 [[ietf-822ext]] では [[MIME]] 
の制定が進められていました。その時に JUNET コードを
MIME で使えるように登録することになりました。
その名前は当初はそのまま "junet-code" とする案でしたが、
結局 ISO-2022-JP になりました。この文書が RFC 1468
<urn:ietf:rfc:1468> です。 RFC 1468 は JUNET コードを
より厳密に定義しなおしました。

1993年、 RFC 1468 に日本語以外の文字集合を追加した多言語拡張,
[[ISO-2022-JP-2]] や [[ISO-2022-INT-1]] が定義されました。
(1997年には RFC 2237 で、 RFC 1468 + [[JISX0201]]
の [[ISO-2022-JP-1]] が定義されました。)

1997年には [[JISX0208]] が改正され、附属書2 RFC 1468
符号化表現 (規定) として [[JIS]] で標準化されました。
これは RFC 1468 で定義された符号を JIS のほかの規格・規定
と整合するようにしたものです。かなり無理がたたって、
結局 RFC 1468 とは別物になってしまったという説まであります。

1998年頃、 RFC 1468 の改訂 [[Internet-Draft]]
draft-yamamoto-charset-iso-2022-jp がかかれました。
<urn:ietf:id:draft-yamamoto-charset-iso-2022-jp-02>
RFC 1468 には幾つか不具合が見つかっていましたし、
その後の JIS の改訂や [[ietf-822]] の [[RFC822]]
改訂案 (後の [[RFC2822]]) に比べると RFC 1468 
は時代遅れになってました。

bis1468 は厳密な規定・解釈が求められるようになってきた
時代背景を反映して、一層規定が厳密になりました。
しかし [[IETF]] [[RFC]] になることなく expire されました。

2000年には [[JISX0213]]:2000 が制定され、
附属書2 ISO-2022-JP-3 符号化表現では ISO-2022-JP
と似た構造を持つ [[ISO-2022-JP-3]] が定義されました。
ただし、 ISO-2022-JP-3 は ISO-2022-JP や JUNET コードとは
互換性が全くありません。


** ISO/IEC 2022 への適合性


[52] 
[[ISO-2022-JP]] が [[ISO/IEC2022]] に適合するかについて
いろいろ言われてきました。

[BIS1468] と [JISX0208:1997] は、 ISO/IEC 2022
には適合しないと明言しています。

このことについて、 『RFC1468とISO 2022のカンケイ』
<http://www.xinada.ne.jp/~handa/tech/Scribbles/RFC1468-and-ISO2022>
という文章がとてもよくまとめています。だけどここではあえて
その内容を繰り返します。

ISO-2022-JP が ISO/IEC 2022 に適合するかどうかの問題点
は次のものが挙げられています。

= 漢字 (JIS X 0208-1978, -1983) が[[指示]]されている状態で制御文字や [[SPACE]] などが使用できない
= 改行 ([[CRLF]]) で(指示がなくても) ASCII に戻しても良い
= 更新番号 ([[IRR]]) がなくても JIS X 0208-1990 が使える

[[JISX0208]]:1997 の解説は、 RFC 1468 符号化表現の問題点を
3つ挙げる。
= [[指示]]シーケンスによる文字集合の選択が曖昧である
= 改行後の文字集合の扱いの実装にばらつきがある
= ISO/IEC 2022 の subset であるかの誤解を与える
= (一々文字集合を指示するのは古くさい)

残念なことに、解説は問題点を挙げる以上の説明をしていない。

*** 漢字列中での制御文字などの使用

この問題はそもそも [[JUNET]] コードよりまだ昔に起因します。
当時広く流布していた[[漢字イン・漢字アウト]]説によると、
漢字インした状態では制御文字が使えません。この神話に基づく
実装では実際その通りになったので、 JUNET 初期は (あまり深い意図無しに)
漢字列中で制御文字などを使用しないことにしていたみたいです。

[[JUNETの手引き]]にある JUNET コードが成立した頃には、
この説は否定されました。そして制御文字などを漢字列中で
使っても良いことにし、その方向に進めようという姿勢が
手引きにはあります。 (なお、改行だけは、行指向のソフトウェア
が簡単に実装できるように、従来通り ASCII 状態とすることに
なりました。)

ところがこの企みはそううまくいかなかったのか、 RFC 1468 
では一転して禁止されてしまいました。以後の仕様や実装は
それに従っています。

さて本題の ISO/IEC 2022 適合性ですが、この規定は
生の ISO/IEC 2022 より制限するものではありますが、
対立するものではないですから、適合性には影響しない
という解釈が大勢だと思われます。 (特に JUNET コードの場合は
推奨なので、まったく違反しないでしょう。)


*** 改行で指示がなくても ASCII に戻してよい

[92] 
この規定は JIS X 0208:1997 附属書2 にのみあります。

この動作はエラー処理かもしれません。 RFC 1468 も当の JIS X 0208:1997
附属書2 も、改行 [[CRLF]] は漢字列中には現れません。
だけど現れたら・・ってこと。 (だけど、他の考え得るエラー処理
のことは規定されていないしなあ。)

行指向ソフトウェアでは前の行で JIS X 0201 Roman か ASCII
のどちらで終わったか調べ{れ|たく}ないので、 ASCII だと
仮定したいのですが、そういう場面での話かもしれません。
([BIS1468] に似たような話があります。)

いずれにせよ実装の話であってそのような符号列の出力を
認めているわけではありませんから、
([[受信装置]]の適合性は疑わしい可能性がありますが) 
データの適合性には影響しないでしょう。

JIS X 0213:2000 附属書2 の [[ISO-2022-JP-3]]
にも同様の話がありますが、 ISO/IEC 2022 に適合しないとは
書かれていません。 (逆にするとも書かれていませんが。)
ですから、 JIS としてはこの点は ISO/IEC 2022 への適合性に
関して問題ないと判断しているのではないでしょうか。

JIS X 0208:1997 の解説にもこの問題が取り上げられていますが、
解説の解説が欲しいような曖昧な指摘です。
たぶん、実装が行頭で勝手に漢字から ASCII に戻したり、
JIS X 0201 roman から ASCII に替えたりするのは問題だ、
といいたいんじゃないかな。


[91] 
[[改行]]による [[ASCII]] 復帰 (をする実装があるが、
すべての実装がそうだということでもない。) は他の解釈もあり得ます。
[[メール本体]]や[[行指向]]の[[テキストファイル]]が特定の[[符号化文字集合]]で記述された1つの[[文字列]]とは必ずしも断言できません。
「改行」という[[プロトコル要素]]によって「行」という[[プロトコル要素]]が連結されていて、
各「行」は何らかの[[符号化文字集合]]によって符号化されている、
という建付けなら、
[[改行]]によって行頭 [[ASCII]] になったとしても、
どの[[符号化文字集合]]規格にも違反しません。

;;
[93] 
実際 [[RFC 822]] は[[メール本体]]を [CODE[text]] (1行) 
を[[改行]]区切りで連接したものとする [[ABNF]] 構文を定めていました。

[94] 
ところで、[[改行]]で [[ASCII]] に復帰する実装を想定するなら、
他の [[C0制御文字]]や [CODE(charname)@en[SP]]
(や [CODE(charname)@en[DEL]] も?) をもって
[[ASCII]] に復帰する実装も想定するべきでは、
という疑問もあります。

[102] 
[[改行]]が [N[0x0D]] [N[0x0A]] だけしか想定されていないのもおかしな点。
確かに[[インターネットメール]]では[[改行]]は [N[0x0D]] [N[0x0A]]
と定められていますが、 [[Unix]] 系ツールなら [N[0x0A]] 
のみでも[[改行]]とみなすものがほとんどのはず。
当時まだ現役だった [[Mac OS]] の [N[0x0D]] 
のみの[[改行]]に対応していたソフトウェアも多かったはず。
そうした実装は対象と考えていなかったのだろうか。


*** 更新番号なしで JIS X 0208-1990 が使える

JIS X 0208-1990 を指示するには更新列 ESC 02/06 04/00
が指示列の直前に必要ですが、 RFC 1468 は使わないことを提案 (suggest)
し、 [BIS1468] ははっきりなくても追加文字を使ってよいこととし、 
JIS X 0208:1997 附属書2 も (JIS としての都合上) そうしています。

このことが ISO/IEC 2022 への不適合の疑いがあるわけです。

ただし、 [[IRR]] が定義されていなかったふるい ISO/IEC 2022
との絡みなどの理由から、不適合には当たらないのではという
説もあります。 (だけど規格に問題ないって書いてあるわけじゃないし、
ちょっと弱い気がする。)


*** 文字集合の区別がいい加減

あまり問題視されませんが、 ASCII & JIS X 0201 Roman,
JIS X 0208-1978 & -1983 の code point unify
のほうが問題のような気もします。 ISO/IEC 2022 と [[ISOREG]]
で規定された[[終端バイト]]と[[符号化文字集合]]の対応関係を
適当に無視することを認めているからです。

まあ、この装置では JIS X 0201 を使えないから ASCII
の似たのにエラー処理で変換しただけだ、みたいな
言い訳は思いつきますけど。 (その言い訳が通る (どこを?)
かどうかは知りませんが。)

JIS X 0208:1997 附属書2 は深刻です。 -1978 と -1983
で入れ替えられた文字は (文書に明示するだけで自由に) 
逆にして構いませんし、 -1978 になかった文字は実装しなくて
構いません。堂々と規定してあるのでエラー処理だなんて
言い訳は出来ません。そりゃあ ISO/IEC 2022 には適合しない、
って参考に書きたくもなりますわ。 (そのくせ ASCII と
JIS X 0201 の差異2文字は入れ替えてもいい、みたいな
規定はないなんて、片手落ちな。さすがにそれしたら
ISO/IEC 646 や JIS X 0201 に適合しなくなるから? (なにをいまさら))

(文字を実装しなくて良い、はデータの適合性には影響しないでしょうが、
受信装置の適合性で問題がある可能性があります。
でもまあ参照されてる側の規格がいいと言ってるからいいのかな?
(でも ISO-IR で参照されてるのは -1978 とか -1983 だったりする。
ISO-IR には最新版適用規則はないはず。))

この項と前の項が、 JIS X 0208:1997 解説の言うところの
文字集合選択が曖昧である、の指すところだと思います。


*** ISO-2022-JP という名前は ISO/IEC 2022 の subset のような印象を与える

(上の様な非適合性問題がなければ) 確かにそのとおりであって、
別に問題はないんですが・・・。

元々 ISO-2022-JP という名前は、 [[MIME]] で (Internet 
の[[電子メイル]]で) 使う ISO/IEC 2022 に基づく表現の、
日本で使われてるやつ、くらいの意味でつけたんであって、
[[JUNETコード]]の正式名称にしようなんて意気込んでつけた
わけじゃないでしょう。

そもそも当の [[JUNET]] では JIS の符号を使う、という方針で
動いていたわけですから、 ISO/IEC 2022 に不適合とわかれば
頑張って修正したんじゃないでしょうか。 ESC ( H みたいにね。
(もちろん、今じゃもう無理でしょう。 ([[JUNET]] もないし。))

ISO-2022-JP ってのは数奇な運命を辿った
[[符号化文字集合]]だなあと思います。


*** その他

- 2002-09-30 (Mon) 17:11:36 ''[[名無しさん]]'' : JIS X 0208:1997 の解説は、 JIS 本体の解説は豊富だけど、新たに (しかも制定間際にとってつけたように) 加えられた RFC 1468 符号化表現については (シフト符号化表現についてもですが) 説明が少なすぎると感じます
- 2002-09-30 (Mon) 17:13:07 ''[[名無しさん]]'' : JIS X 0208:1997 の制定の頃話題になった ISO/IEC 2022 への適合性はもちろんのこと、 JIS に取り入れられるまでの歴史とかを入れて然るべきじゃないでしょうか。

[53] <http://pc5.2ch.net/test/read.cgi/linux/1003159137/667->

>674 名前:672[sage] 投稿日:04/12/03(金) 03:59:08 ID:9rXlF8ug
>解答例:
改訂番号の識別機能を使うとき、それがエスケープシーケンスとしてCCデータ要素
に埋め込まれている必要はない。
したがって、改訂番号識別シーケンスを使わないことをもってただちに不適合である
とは結論できない。








** 参考文献

:[JUNET]:『JUNET 利用の手引き第1版』 (See [[JUNETの手引きの漢字コードの説明]])
:[RFC1468]:“Japanese Character Encoding for Internet Message”, [[IETF]] [[RFC]] 1468, <urn:ietf:rfc:1468>
:[RFC1554]:“[[ISO-2022-JP-2]]: Multilingual Extension to ISO-2022-JP”, [[IETF]] [[RFC]] 1554, <urn:ietf:rfc:1554>
:[RFC2237]:“Japanese Character Encoding for Internet Message”, [[IETF]] [[RFC]] 2237, <urn:ietf:rfc:2237> (See [[ISO-2022-JP-1]])
:[BIS1468]:“Japanese Character Encoding for Internet Message”, [[IETF]] [[Internet-Draft]], <urn:ietf:id:draft-yamamoto-charset-iso-2022-jp-02>
:[JISX0208]:『7ビット及び8ビットの2バイト情報交換用符号化漢字集合』, [[JISX0208]]:1997

** RFC 1468 の [CODE[ISO-2022-JP]]


[39] [DFN[[[RFC 1468]]]] は、[[日本語]]用の[[文字コード]]である [[ISO-2022-JP]] を規定しています。
[[ISO-2022-JP]] の定義は複数存在しますが、「[[ISO-2022-JP]]」という名を翳した最初の正式な文書である
[[RFC 1468]] が原典であると考えられています。

[REFS[
- [54] [CITE@en[[[RFC 1468]] - Japanese Character Encoding for Internet Messages]], [TIME[2021-01-31T08:38:25.000Z]], [TIME[2021-03-13T11:49:28.666Z]] <https://tools.ietf.org/html/rfc1468>
]REFS]

[40] [[RFC 1468]]は単なる[[文字コード]]ではなく、
従来[[JUNET]]で[[822]][[メッセージ]]の[[本文]]で使われてきた[[文字コード]]を[[MIME]]で使うために説明 & [[IANA]]登録するという形を採っているので、
[CSECTION@en[Formal Syntax]]には[CODE(ABNF)@en[headers]]も含まれた[CODE(ABNF)@en[message]]の構文として説明されている。

;; 古い案では[CODE(ABNF)@en[[[message]]]]と[CODE(ABNF)@en[[[headers]]]]はなく、[CODE(ABNF)@en[[[line]]]]があったのに、わざわざいまの形に変更されている。
[CITE[iso-2022-jp doc]] 
<http://www.imc.org/ietf-822/old-archive1/msg02541.html>

にも関わらず、後から[[ietf-822]]で指摘されて[CSECTION@en[MIME Considerations]]に[CODE(ABNF)@en[[[encoded-word]]]]でも使えると追記しており、
構文はそのままなので、どう使うのかが説明できていない。

;; しかも一時は別文書にするつもりだったらしい。
[CITE@en[Re: JUNET Kanji code document review]]
<news:BytJt0.Jto@poel.juice.or.jp>

[41] 末尾では[[ASCII]]状態でなければならないとされている。
これは[[SMTP]]/[[822]]が[[ASCII]]で終わることとの整合性のためらしい。

;; [CITE[re: new version of ISO-2022-JP document]] 
<http://www.imc.org/ietf-822/old-archive1/msg02528.html>

[[JUNET利用の手引き]] (6.3)
では[[JIS X 0201]]で終えてもよいこととされており、
現実にもそうされていたのと矛盾している。

;; 
1つの[[メッセージ]]中で[[ASCII]]と[[JIS X 0201]]の[[指示シーケンス]]を併用するのは稀で、
1992年当時は[[JIS X 0201]]の方がよくつかわれていた。
[CITE@en[ESC$? ESC(?]]
<news:144@isdn1.smsc.sony.com>,
[CITE@en[ESC$? ESC(?]]
<news:1993Jan3.064853.27094@sm.sony.co.jp>


[42] 
当初の案では隣接する[[指示シーケンス]]は異なるものであるべき
([Q@en[should]]) とし、推奨されない例 ([Q@en[not recommended]])
[CODE(example)@en[[CODE(charname)@en[[[ESC]]]] $ B [VAR[....]] [CODE(charname)@en[[[ESC]]]] $ B [VAR[....]]]]
を示していた。

この部分は不要ということで削除された。

;; [CITE[Re: iso-2022-jp]] 
<http://www.imc.org/ietf-822/old-archive1/msg02480.html>

[43] 
[CSECTION@en[Description]]には[[JIS X 0208]]‐''1983''と明記されているが、
[CSECTION@en[Background Information]]には[[更新番号]]なしで'''1990''''版の追加2文字を使ってもいいことにしようと提案している
([Q@en[suggested here]])。

[[著者]]のエリックはそれを書き足すに先だって同じことを提案しているが、
それに関する議論はなかったのか、あるいは残っていない。
[[反論がなければ合意]]なのか? [[合意]]がないから曖昧なのか?

;; [CITE@en[Re: JUNET Kanji code document review]]
<news:Bu7Av0.2I4@poel.juice.or.jp>

;; そもそも[[RFC 1468]]に向けた作業をしていたらしい[[メイリング・リスト]]の記事が残っていない・・・。

[44] 
[Q@en[Formal Syntax]] には、[[指示シーケンス]]なしの[[行]]が認められない不具合がある。

[45] 
[Q@en[Formal Syntax]] によれば、[[行]]最後の
[CODE(char)@en[[CODE(charname)@en[[[ESC]]]] ( B]] or [CODE(char)@en[[CODE(charname)@en[[[ESC]]]] ( J]]
''以外''の[[指示シーケンス]]の後には1文字以上必要。

もとの[[JUNET利用の手引き]] (6.3) にはこの制限は書かれていない。

;; もっとも現実には[[RFC 1468]]の制限があっても問題はないだろう。

[46] 
[Q@en[Formal Syntax]] によれば、[CODE(charname)@en[[[CR]]]]と[CODE(charname)@en[[[LF]]]]は単独では使用できず、
必ず[CODE(ABNF)@en[[[CRLF]]]]でなければならない。

この制限は[[822]]/[[SMTP]]由来で、[[RFC 1468]]の性質 (>>1) 
によるものと考えられる。
もとの[[JUNET利用の手引き]]には書いてないが、
暗黙の仮定 (というより別の層の問題) としていたと考えてよいだろう。

;; 
では[[MIME]][[本体]]以外で[[RFC 1468]]の[[文字コード]]が使われる場合にこの制限はどうなるのか。

;; 
[[JUNET]]の時代も、ネットワーク転送中は[CODE(ABNF)@en[[[CRLF]]]]になるとしても
(なるの?)、
[[UNIX]]内部では[CODE(charname)@en[[[LF]]]]にしていたのでは。

[47] 
[CSECTION@en[Formal Syntax]] によれば、[[JIS X 0208]]
状態では[[制御文字]]や[CODE(charname)@en[[[SPACE]]]]が使えない。

[[JUNET利用の手引き]] (6.3) では、
[[改行]]前に[[ASCII]]または[[JIS X 0201]]状態にするのが望ましいことと[[JIS X 0208]]状態で[[制御文字]]や[CODE(charname)@en[[[SPACE]]]]を使ってもよいことが書かれているから、
それと整合していない。

ただし、92年時点で[[JIS X 0208]]状態で[[制御文字]]や[CODE(charname)@en[[[SPACE]]]]に対応できない実装があったようだし、
ほとんど (ほとんど。) の[[メッセージ]]は[[RFC 1468]]の構文通りになっていたようだ。

[48] 
[CSECTION@en[Background Information]] に古い [CODE(char)@en[[CODE(charname)@en[[[ESC]]]] ( H]]
は使うべきではない ([Q@en[should not]]) と書いてある。

>>42 の [Q@en[should]] やそれへの指摘

;; [CITE[Re: iso-2022-jp]] 
<http://www.imc.org/ietf-822/old-archive1/msg02479.html>

も踏まえて、推奨なのか禁止なのか。推奨なら [CSECTION@en[Description]]
や [CSECTION@en[Description]] や[[JUNET利用の手引き]] (禁止)
や当時の実情 (絶滅) と矛盾する。


** JIS X 0208:1997 の RFC 1468 符号化表現 



[1034]
[DFN[RFC 1468符号化表現]]は、[[JIS X 0208]]:1997で規定されている[[符号化文字集合]]です。
その参考によれば[Q[通常、[Q[ISO-2022-JP]]と呼ばれており、[[インターネット]]で使用されている]]らしいですが、
[[RFC 1468]]で説明されている[CODE(MIME)@en[[[ISO-2022-JP]]]]とは相違点も多く、
かといって[[IETF]]の[[RFC 1468]]を改訂することを意図したものや[[IANA]]における[CODE(MIME)@en[[[ISO-2022-JP]]]]の登録の更新を意図したものでは''ない''ようであり、
何を考えて制定したものなのかがよくわからないところです。

[1036] [Q[RFC 1468符号化表現]]という怪しい名前にも関わらず、
規格中に[[RFC 1468]]との関係について説明がまったくありません。

[1035]

> ソースは?
> ▼インターネットで見た

[101] 仕様書: 
- [[JIS X 0208]]:1997
-- [CSECTION[附属書2 (規定) RFC 1468 符号化表現]]

*** 符号化文字集合

- [103] [CODE[0x00]]〜[CODE[0x1F]]: [[制御文字]]:
[[JIS X 0211]] (最新版)
[[C0集合]]
[SRC[JIS97 附属書2 4.1 a)]]
-- [104] [[情報交換]]の先頭では、使用できる状態。
[SRC[JIS97 附属書2 4.2 a)]]
-- [105] [CODE[0x0E]]: [[使用しない]]。
[SRC[JIS97 附属書2 4.1 a)]]
-- [106] [CODE[0x0F]]: [[使用しない]]。
[SRC[JIS97 附属書2 4.1 a)]]
-- [107] [CODE[0x1B]]: 領域の切換え。
[SRC[JIS97 附属書2 4.1 a), f)]]
--- [108] [CODE[0x1B 0x28 0x42]]: [[制御文字]]の領域を使用する。
[[図形文字]]の領域は[[ISO/IEC 646]] (最新版) [[IRV]]
--- [109] [CODE[0x1B 0x28 0x4A]]: [[制御文字]]の領域を使用する。
[[図形文字]]の領域は[[JIS X 0201]] (最新版)
[[ラテン文字用図形文字集合]]
--- [1010] [CODE[0x1B 0x24 0x40]]: [[制御文字]]の領域を使用''しない''
([CODE[0x1B]] を除く)。
[[図形文字]]の領域は[[JIS X 0208]]:1997本体6.5.1の[[漢字集合]]で、
[[JIS X 0208]]:1997 附属書2表1の[[図形文字]]の組を入れ替えたもの。
[CODE(charname)@en[[[SPACE]]]]を使用しない。
[CODE(charname)@en[[[DELETE]]]]を使用しない。
--- [1011] [CODE[0x1B 0x24 0x42]]: [[制御文字]]の領域を使用''しない''
([CODE[0x1B]] を除く)。
[[図形文字]]の領域は[[JIS X 0208]]:1997本体6.5.1の[[漢字集合]]。
[CODE(charname)@en[[[SPACE]]]]を使用しない。
[CODE(charname)@en[[[DELETE]]]]を使用しない。
--- [1012] これ以外で [CODE[0x1B]] は[[使用しない]]。
- [1013] [CODE[0x20]]: [CODE(charname)@en[[[SPACE]]]]
- [1014] [CODE[0x21]]〜[CODE[0x7E]]: [[図形文字]]
-- [1015] [[情報交換]]の先頭では、[[ISO/IEC 646]] (最新版) [[IRV]]。
[SRC[JIS97 附属書2 4.2 a)]]
- [1016] [CODE[0x7F]]: [CODE(charname)@en[[[DELETE]]]]
- [1017] [CODE[0x80]]〜[CODE[0xFF]]: [[使用しない]]。
- [1018] [[情報交換]]の末尾では、[[ISO/IEC 646]] (最新版) [[IRV]]
の状態でなければなりません。 [SRC[JIS97 4.3 a)]]

;; 
[1030]
元の[[RFC 1468]]は明らかに[[7ビット符号]]を規定しているのに、
[[RFC 1468符号化表現]]はなぜか[[8ビット符号]]のようです。

[1032]
[[JIS]]は他[[規格]]の最新版を参照していますが、
元の[[RFC 1468]]はすべて年号付きで引用しています。
たまたま[[JIS X 0211]], [[ISO/IEC 646]] [[IRV]],
[[JIS X 0201]]とも1997年の時点で[[RFC 1468]]の参照する規格と内容が一致している
(ようにみえる) のですが、将来もそうである保障はありません。
(実際[[ISO/IEC 646]] [[IRV]]は1991年に非互換変更されていますから。)
将来[[RFC 1468符号化表現]]が勝手に違うものになってしまう危険性があります。

[1033] >>1010 は[[JIS X 0208]]‐1983で行われた[[漢字]]の入れ替えを元に戻すことを求めていますが、
なぜか[[JIS X 0208]]‐1983および[[JIS X 0208]]‐1990での追加分には触れていません。
(>>1029 は[[装置]]の適合性に関する規定のようです。)

[1037]
>>1010-1011 の2つの[[指示シーケンス]]の後は[[制御文字]]が使えないことになっていて
(附属書2 4.1 f))、[CODE(charname)@en[[[ESC]]]]も例外とされて''いません''。附属書2図3〜5もそうなっています。
附属書2 4.2 b) で [Q[4.1 f) の[[バイト列]]が現れた場合は、 4.1 f) に示す利用状態の遷移が起こる]]とありますが、
4.1 f) の規定に従えば一旦[[JIS X 0208]]状態に遷移すると4.1 f)
の[[バイト列]]は出現できないので・・・。


[1038]
>>1037 と >>1018 により、[[RFC 1468符号化表現]]で[[JIS X 0208]]を使うことは無理としか考えられない。

[PRE(aa)[
[AA(fw)[         ]]ナ ゝ[AA(fw)[   ]]ナ ゝ[AA(fw)[ ]]/[AA(fw)[   ]] 十[AA(fw)[_]]"[AA(fw)[   ]] ー;=‐[AA(fw)[         ]]|! |!   
[AA(fw)[          ]]cト[AA(fw)[    ]]cト[AA(fw)[ ]]/[AA(fw)[^]][AA(hw)[、]]_&#65417;[AA(fw)[ ]] | [AA(hw)[、]].__[AA(fw)[ ]]つ[AA(fw)[ ]] [AA(fw)[(]].__ [AA(fw)[ ]] [AA(fw)[‾‾‾‾]] [AA(fw)[ ]] ・ ・    
]PRE]

*** 適合性

[1019]
'''情報交換の適合性''':
[[情報交換]]の[[適合性]]は、[[JIS X 0208]]:1997
本体 3.2 ([SEE[ [[JIS X 0208]] ]]) によります。
ただし、[[符号化文字集合]]については[[JIS X 0208]]:1997
附属書2 4. (>>102) によります。
[SRC[JIS97 附属書2 2.1]]

[1020] 本体3.2の規定により、[[適合性]]を主張する情報交換は採用した[[符号化文字集合]]を[Q[[[文書]]に明示]]しなければなりません。
この規定は附属書2では上書きされておらず、有効と思われます。

[1021] '''装置の適合性'''
[[装置]]の[[適合性]]は、[[JIS X 0208]]:1997 附属書2.2の規定によります。
[SRC[JIS97 附属書2 2.1]]

;; 
[90] 
規格本体にも規定がありますが、そちらではなく、
個別の規定が適用されるようです。参考として
[Q[[[インターネット]]の[[情報交換]]においては、[INS[〜]][[空き領域]]の[[利用]]は行われない]]とあり、
そのために本体や[[シフト符号化表現]]とは別の[[適合]]の要件が規定されているのだと思われます。

- [1022] 本体3.1 ([SEE[ [[JIS X 0208]] ]]) [SRC[JIS97 附属書2 2.2]]
- [1023] 本体3.3.1 ([SEE[ [[JIS X 0208]] ]]) [SRC[JIS97 附属書2 2.2]]
- [1024] 本体3.3.2 ([SEE[ [[JIS X 0208]] ]]) と附属書2 2.2.2 (>>1026) の一方又は両方 
[SRC[JIS97 附属書2 2.2, 2.2.1]]
- [1027] [[適合性]]を主張する場合、附属書2の[[符号化文字集合]]を採用したことを[Q[[[文書]]に明示]]しなければなりません。
[SRC[JIS97 附属書2 2.2]]
- [1028] 指定された[[図形文字]]の組を入れ替えても構いません。
その場合、入れ替えの一覧を[Q[[[文書]]に明示]]しなければなりません。
[SRC[JIS97 附属書2 2.2]]
- [1029] 指定された[[図形文字]]を実装しなくても構いません。
その場合、実装しないものの一覧を[Q[[[文書]]に明示]]しなければなりません。
[SRC[JIS97 附属書2 2.2]]

;; 
[1025] >>1028 は[[JIS X 0208]]‐1983や[[JIS X 0208]]‐1990で入れ替え等があった[[漢字]]。
>>1029 は[[JIS X 0208]]‐1983や[[JIS X 0208]]‐1990で追加された[[図形文字]]。

[1026] '''受信装置の要件''':
本体3.3.3 ([SEE[ [[JIS X 0208]] ]]) によります。
ただし、[CODE[0x0D 0x0A]]を[[受信]]した場合、
[[図形文字]]の領域を[[ISO/IEC 646]] (最新版) [[IRV]]
に遷移しても構いません。その場合、
[Q[[[文書]]に明示]]しなければなりません。
[SRC[JIS97 附属書2 2.2.2]]

;; 
[1031]
>>1010 や >>1011 で[[制御文字]]の領域を[[使用しない]]時に[CODE[0x0D 0x0A]]を[[受信]]すると、
[[制御文字]]の領域がそのまま[[使用しない]]のままになってしまいますが・・・。


[1039]
[[JUNET利用の手引き]]にも[[RFC 1468]]にもない
>>1026 の規定はどこからでてきたのでしょう?

;; そのような実装があった (いまもある?) ことは事実ですが・・・。

[1040]
[[JIS X 0208]]:1997の解説には、
- [[改行]]の後の状態が異なる実装があること、
- [[指示シーケンス]]の解釈が曖昧だと[[RFC 1468]]自身が認めていること、
- [[ISO/IEC 2022]]のサブセットであるかのような誤解を抱かせること

が問題として認められるので、[[ISO-2022-JP]]の実装が[[JIS X 0208]]への[[適合]]を主張できるように附属書にしたという旨の説明があります。

わかるようなわからないような説明である上に、
本当に挙げられた問題を解決できているのか甚だ疑問であります。

[96] 
[[JIS C 6226-1978]] と [[JIS C 6226-1983]] の2つの[[指示シーケンス]]を、
後者は [[JIS X 0208:1997]] の漢字集合、
前者は [[JIS X 0208:1997]] の漢字集合の一部 ([[83JIS]] 入れ替え相当) を入れ替えたもの、
という意味と定めています。
「古いJIS」と参照するわけにもいかず苦肉の策なのでしょうが、
入れ替えだけ戻して文字の追加や字形の変更は反映していないので、
本来 [[78JIS]] であったものが 「[[78JIS]] のような変な何か」
になっているのは気持ち悪いですね。

[97] 
しかも実装は 
[[78JIS]], [[83JIS]], [[90JIS]] の適当なミックスでも適合するっぽいのですが、
本当にそんなのでいいのでしょうか。
[[相互運用性]]はハナから放棄していたのでしょうかね。
[SEE[ [[JIS X 0208]] ]]
実装については2つの[[指示シーケンス]]を区別しろとは書かれていません。
入れ替えについてはしてもしなくても適合しそうですが、
その他の変更についてはどうですかね?

[98] 
ちなみに [[ASCII]] と [[JIS X 0201]] [[ラテン文字用図形文字集合]]は区別しなくてもいいとは書かれていないので、
区別しなければ適合しないはずです。
実際には区別しない実装もたくさんあった (今もある) はずで、
そういう実装を適合させる意図はなかったのでしょうか。

;; [99] [[JIS X 0208:1997]] 全体的に言えることですが、
おかしな実装も含めて歴史的ないろいろを無理に適合させようとしている点と、
いろいろあるはずなのに救済措置が何もない点が混じっていて、
どこで線引したのかさっぱりわかりません。

[100] 
[[シフト符号化表現]]には[[外字]]を認めるような規定がありますが、
[[RFC 1468符号化表現]]にはありません。
(これも現実と乖離しています。)


[110] 
本体の [[ISO/IEC 2022]] 系の[[符号化文字集合]]や[[シフト符号化表現]]では[[全角英数字]]を禁止し、
または[[代替名称]]を用いることにしていますが、
[[RFC 1468符号化表現]]には相当の規定がありません。
従って[[全角英数字]]を使用しない[[漢字集合]]とみなすことも、
[[代替名称]]を用いることも認められません。

[111] 
使用しないまたは[[代替名称]]を用いるべき根拠が
[[ISO/IEC 2022]] の[[図形文字の一意符号化]]原則に求められており、
それによれば [[G1]] より [[G0]] のように G番号の小さな集合の文字のみが用いられるべきであるとされるところ、
[[RFC 1468符号化表現]]はすべての[[図形文字集合]]が [[G0]] に[[指示]]されるので、
適用されないのだと思われます。

[112] 
しかし [[RFC 1468符号化表現]]は [[ISO/IEC 2022]] に適合しないと言っています。
ならば [[ISO/IEC 2022]] の規定に厳密に従う必要性はないはずです。
実際[[シフト符号化表現]]は [[ISO/IEC 2022]] に元より適合せず、
[[G0]] も [[G1]] もないにも関わらず、なぜか[[重複符号化]]を禁じる措置がとられています。
ならば[[RFC 1468符号化表現]]もその気があれば禁止できたはずです。
そうしなかったのは、なにか理由があったのでしょうか。不思議です。



** IANA charset [CODE(MIME)@en[ISO-2022-JP]]

[7]
[[IANA]]の[[charset]]登録簿には、2006年3月現在
[PRE[
Name: ISO-2022-JP  (preferred MIME name)               [RFC1468,Murai]
MIBenum: 39
Source: RFC-1468 (see also RFC-2237)
Alias: csISO2022JP
]PRE]
とあり、[[charset]] [CODE(MIME)@en[[[ISO-2022-JP]]]]の定義は[[RFC 1468]]とされています。

;;
なぜか[CODE(MIME)@en[[[ISO-2022-JP-1]]]]の定義[[RFC 2237]]も参照されています。
[[RFC 2237]]の[[著者]]が当初[CODE(MIME)@en[[[ISO-2022-JP-1]]]]を[CODE(MIME)@en[[[ISO-2022-JP]]]]という名前にしようとしていたことと関係があるのでしょうか?

** 文字符号化[CODE(XML)@en[ISO-2022-JP]] (XML)

[4]
[[XML 1.0]]および[[XML 1.1]]の仕様書
<IW:XML1:"#charencoding"> では、
[[符号化宣言]] ([CODE(XMLa)@en[[[encoding]]]][[擬似属性]])
の値[CODE(XML)@en[[[ISO-2022-JP]]]]は
[Q@en['''[[SHOULD]]''' be used for the various encoded forms of JIS X-0208-1997]<IW:XML1:"#charencoding">]とされています。

これをどう解釈するべきかははっきりしませんが、
[[JIS X 0208]]:1997 附属書2 (規定) [CSECTION[[[RFC 1468符号化表現]]]]の参考に[[インターネット]]で[Q[ISO-2022-JP]]と呼ばれている旨の記述がありますから、
この[[符号化文字集合]]を指していると考えるのがもっともらしいでしょう。


** メモ


[56] [TIME[2022-02-18T10:07:58.000Z]] <https://katsu.watanabe.name/ancientfj/article.php?mid=376%40tsuda.JUNET>

- [1] Opera 7.20 で ISO-2022-JP の文書読んだら、ちゃんと ASCII と JIS X 0201 を区別してくれましたよ! 感動的。
- [2] >>1 コピペしてみると実はどっちも 0x5C だった、ってのがなんとも憎いね。[WEAK[ちなみに、他のブラウザのように [CODE[[[lang]]]] 属性でフォント切り替えなんて阿呆らしいことはやってないみたい。]]

[3] Win[[NC]]4 は [CODE(char)[ESC ( J]]
で出力します。 (ある意味正しい。)


[6]
昔からよくある不正な ISO-2022-JP 各種 ([[JIS X 0201]] 片仮名が [CODE(char)[ESC ( I]] とか [CODE(cahr)[SI]]/[CODE(char)[SO]] とか8ビットとかで混ざっている奴)、
まともに [[RFC 1468]] を実装していたら当然未対応なわけですけど、
一応別の文字コード復号の選択肢として用意しておいて欲しいですよね。
日本語向け MUA なら。

妙に一部だけ文字化けしたメイルが多いと思ったら、こういうわけでしたよ
(ほとんど spam でしたけど)。
([[名無しさん]] [WEAK[2004-08-23 05:41:37 +00:00]])


[8] [CITE@en[Web Applications 1.0 r6646     Define compatibility mapping for ISO-2022-JP.]]
( ([TIME[2011-10-06 15:32:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=6645&to=6646>

[9] [CITE@ja[吉野家HDと高島屋が日本語UTF-8メール普及コンソーシアムを設立 | スラッシュドット・ジャパン IT]]
( ([TIME[2012-04-01 11:11:19 +09:00]] 版))
<http://it.slashdot.jp/story/12/03/31/2322209/>

[12] [CITE@en[Remove JIS X 0212 from iso-2022-jp per https://www.w3.org/Bugs/Public/sh... · 5a20290 · whatwg/encoding]]
( ([TIME[2014-11-08 15:15:16 +09:00]] 版))
<https://github.com/whatwg/encoding/commit/5a2029026a013a1b9fd871f261dfa4059c96d746>

[13] [CITE@en[Rewrite iso-2022-jp https://www.w3.org/Bugs/Public/show_bug.cgi?id=27256 · 19b0ebf · whatwg/encoding]]
( ([TIME[2014-11-10 12:34:49 +09:00]] 版))
<https://github.com/whatwg/encoding/commit/19b0ebf0e48c3a607ab7623b5b272642dd59d6e7>

[5] [CITE@en[Treat U+2022 as U+FF0D in Japanese encoders. Fixes https://www.w3.org… · whatwg/encoding@a7ab97e]]
([TIME[2015-08-21 18:14:30 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/a7ab97e891773bd7a564b463c6a1cc31196a5bdd>

[14] [CITE@en[Fix #21: Japanese encoders have special treatment for U+2212, not U+2022 · whatwg/encoding@95f85a6]]
([TIME[2015-12-16 12:32:12 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/95f85a63ad4d6b6331f21ff60f9244b3bcbe6d84>

[FIG(quote)[
[FIGCAPTION[
[15] [CITE@ja[2007/04/27 日記: Java: Outlook 風の JISコード (ISO-2022-JP) を利用するための x-windows-iso2022jp というエンコーディング]]
([TIME[2010-09-27 21:05:03 +09:00]] 版)
<http://homepage2.nifty.com/igat/igapyon/diary/2007/ig070427.html>
]FIGCAPTION]

> 拡張 ISO-2022-JP (MS932 ベース)
> ※ ちなみに CP50220 と x-windows-iso2022jp とは Javaにおいて挙動が異なりました。(エイリアスではありませんでした)
> また更に便利なことに、x-windows-iso2022jp では 重複符号化領域のコードについても、適切に Outlook風のUnicodeマッピングを行ってくれます。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[16] [CITE@ja[フィーチャーフォンについて | KDDI Mobile]]
([TIME[2016-01-15 19:37:48 +09:00]] 版)
<http://www.kddimobile.com/faqs/faq_featurephone/>
]FIGCAPTION]

> Eclipseの対応する日本語用文字コードは以下になります。
> iso-2022-jp (x-windows-iso2022jp)
> shift-jis (windows-31j)
> euc-jp
> utf-8
> iso-8859-1
> 送信は全てiso-2022-jp

]FIG]


[FIG(quote)[
[FIGCAPTION[
[17] [CITE@ja[【TKMP.dl】x-windows-iso2022jp対応]]
([TIME[2016-01-15 19:43:52 +09:00]] 版)
<http://uwa.potetihouse.com/bbs/patio.cgi?mode=past&no=401>
]FIGCAPTION]

> ?x-windows-iso2022jp?B?といったJavaMailのエンコードに対応頂けませんでしょうか?

]FIG]


[18] [CITE@en[Fix #15: prevent ISO-2022-JP encoder attack · whatwg/encoding@f9540e5]]
([TIME[2016-02-14 00:46:04 +09:00]] 版)
<https://github.com/whatwg/encoding/commit/f9540e53e72c3b455708a05e5ff5c7a552a5a733>

[19] [CITE@en[Update integration with Encoding Standard · whatwg/html@6a31c26]]
([TIME[2016-02-14 18:47:33 +09:00]] 版)
<https://github.com/whatwg/html/commit/6a31c26cf12e39dab1a488e75dd56c03d6786d39>

[20] [CITE@en[Editorial: avoid upsetting lazy compilers (#55)]]
( ([[annevk]]著, [TIME[2016-06-21 20:30:39 +09:00]]))
<https://github.com/whatwg/encoding/commit/9f7252a08211a623cabc5fe6b03dda7f0cc9ef11>

[27] [CITE@en[Note >8835 pointers in index jis0208 cannot be reached]]
([[annevk]]著, [TIME[2016-11-16 22:41:11 +09:00]])
<https://github.com/whatwg/encoding/commit/fb87552bfa03cc93a1077c8f13e2f58535d0e97c>

[28] [CITE@en[Thunderbird/SeaMonkey の既定のテキストエンコーディングを UTF-8 に変更する · Issue #63 · mozilla-japan/gecko-l10n]]
([TIME[2017-02-04 13:50:16 +09:00]])
<https://github.com/mozilla-japan/gecko-l10n/issues/63>

[29] [CITE@en[Document minimal implementation requirements]]
([[annevk]]著, [TIME[2017-03-20 20:06:36 +09:00]])
<https://github.com/whatwg/encoding/commit/9323530fae940d95b2c0b9f00a6a654bd2097aff>

[30] [CITE@en[563283 - Perform Hankaku to Zenkaku conversion in ISO-2022-JP encoder]]
([TIME[2017-05-11 15:21:48 +09:00]])
<https://bugzilla.mozilla.org/show_bug.cgi?id=563283>

[31] [CITE@en[ISO-2022-JP encoder: document an oddity]]
([[annevk]]著, [TIME[2018-09-02 18:47:23 +09:00]])
<https://github.com/whatwg/encoding/commit/fe4934c2eb49a2e0b3a630c35b9fa23f7cc16fc0>

[32] [CITE@en[Concatenating two ISO-2022-JP outputs from a conforming encoder doesn't result in conforming input · Issue #115 · whatwg/encoding]]
([TIME[2018-09-29 17:17:01 +09:00]])
<https://github.com/whatwg/encoding/issues/115>

[33] [CITE@en[ISO-2022-JP encoder: document an oddity by annevk · Pull Request #155 · whatwg/encoding]]
([TIME[2018-09-29 17:17:15 +09:00]])
<https://github.com/whatwg/encoding/pull/155>

[34] [CITE@ja[MozillaZine.jp フォーラム • トピック - Thuderbird 60.3.0で、件名にU+FFFDが入るようになった]]
([TIME[2018-11-19 18:56:42 +09:00]])
<https://forums.mozillazine.jp/viewtopic.php?f=3&t=17271>

[35] [CITE@en[1374149 - Folded subject header using ISO-2022-JP doesn't get decoded properly]]
([TIME[2018-11-19 18:59:26 +09:00]])
<https://bugzilla.mozilla.org/show_bug.cgi?id=1374149>

[FIG(quote)[
[FIGCAPTION[
[36] ([TIME[2007-03-21 23:40:32 +09:00]])
<https://www.ttc.or.jp/jp/document_list/pdf/j/STD/JJ-80.10v1.pdf>
]FIGCAPTION]

> IAJ (日本インターネット協会 : Internet Association of Japan)のメール互換性検討部会では、下記の議論がなされている。サービス・プロバイダーは、それぞれのポリシーによって、JIS X 0201-1976 片仮名を JIS X 0208の仮名に変換して送信したり、JIS X 0201-1976 片仮名を G0 へ指示し送信することができる。ただし、 受信に関しては、他のシステムからの JIS X0201-1976 片仮名の指示シーケンスを使用したメッセージを受け入れられるようにしておくことが望ましい。

]FIG]


[FIG(quote)[
[FIGCAPTION[
[38] ([TIME[2016-03-28 11:24:44 +09:00]] 版)
<http://news.tbs.co.jp/>
]FIGCAPTION]

> <meta http-equiv="Content-Type" content="text/html; charset=iso-2022-jp" />

]FIG]

[50] [CITE@en-US[Differences in the ISO-2022-JP encoding between browsers » Blog for The Ultimate Pokemon Center]], [TIME[2020-12-28T12:02:49.000Z]], [TIME[2014-09-12T10:42:18.304Z]] <https://web.archive.org/web/20140912104045/http://upokecenter.dreamhosters.com/articles/2013/04/differences-in-the-iso-2022-jp-encoding-between-browsers/>

[49] [CITE@en[1374149 - Folded subject header using ISO-2022-JP doesn't get decoded properly]], [TIME[2020-12-28T12:02:07.000Z]] <https://bugzilla.mozilla.org/show_bug.cgi?id=1374149>

[51] [CITE@en[Concatenating two ISO-2022-JP outputs from a conforming encoder doesn't result in conforming input · Issue #115 · whatwg/encoding · GitHub]], [TIME[2020-12-28T12:06:17.000Z]] <https://github.com/whatwg/encoding/issues/115>


[37] [CITE[No U+FFFD Generation for Zero-Length Content between ISO-2022-JP Escape Sequences]], [TIME[2020-08-14T15:50:07.000Z]], [TIME[2020-12-28T11:55:42.739Z]] <https://www.unicode.org/L2/L2020/20202-empty-iso-2022-jp.pdf>

[55] [CITE@ja[RFC から読めない IRC]], [TIME[2021-04-13T03:41:28.000Z]] <https://yoshino.tripod.com/73th/data/irccode.htm#japaneseproblem_hiddenwhois>