424.txt

,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]
- ESC 02/08 [(] 04/07 [H] は
-- 使ってはいけません [JUNET]
-- 使わないのが望ましいです (should not) [RFC1468]
- 制御文字を使う時は 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]
- JIS X 0208‐1990 を使う時は [[IRR]] を
-- 使わないことにしましょう。 (suggest) [RFC1468]
-- 使ってはいけません。 [JISX0208:1997]
- JIS X 0208 で規定されていない符号位置は
-- 使ってはいけません [JUNET] (MUST [BIS1468])
-- 情報交換の当事者間の合意で使用できますが、 Internet では使用しません [JISX0208:1997]

※[PRACTICE] は、実際の習慣


* 歴史

もともと [[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 への適合性

[[ISO-2022-JPのISO/IEC 2022適合性]]


* 参考文献

:[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

* 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]]]]という名前にしようとしていたことと関係があるのでしょうか?

[[#comment]]

* 文字符号化[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]]と呼ばれている旨の記述がありますから、
この[[符号化文字集合]]を指していると考えるのがもっともらしいでしょう。

* 例

[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]]

* メモ

- [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/>