JIS

There is another page with same name:
Edit New

ISO-2022-JP (文字コード)

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

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

代替

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

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

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

符号化方式

[21]

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

※[PRACTICE] は、実際の習慣

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

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

[152] 非常に古いインターネットメールやネットニュースのメッセージ (昭和時代後期、JUNET 初期のもの) には ESC 2/8 4/8 を使ったものがあります。 インターネットメッセージを扱う実装は ISO-2022-JP (JUNETコード) の復号時にこれにも対応しておく必要があります。

冗長なエスケープシーケンス

[148] 現在の Webブラウザーの iso-2022-jp (Encoding Standard が規定するもの) では、冗長なエスケープシーケンス (例えば ASCII に切り替えた直後に JIS X 0208 切り替えるもの) は誤りとみなして、 U+FFFD が挿入されることになっています。

[149] これはセキュリティー上の理由とされています。

[150] 古い ISO-2022-JP の文書 (メールなど) には、 こうしたものが含まれることがあります。 日本語入力の関係か、編集の関係でそういうこともあったのでしょうか。 平成時代初期のものにはこれは頻出します。

[151] 従って Web 以外の ISO-2022-JP の復号は、 Encoding Standard の iso-2022-jp ではなく、 既存のファイルに対応可能な復号器を使う必要があります。

拡張

[113] ISO-2022-JP に独自要素を付け足した実装は無数にあります。拡張により ISO-2022-JP でなくなっているにも関わらず ISO-2022-JP と称していることもあります。

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

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

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

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

片仮名用拡張

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

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

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

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

[114] IRC はプロトコルレベルで文字コードを記述することがほぼ出来ないので、 当事者間で文字コードを取り決めて使っていました。 UTF-8 が主流になる前は日本では ISO-2022-JP が主流でしたが、 半角カナの扱いに流儀がいくつかありました。

[124] 現在では IRC で ISO-2022-JP が使われることは、 少なくても公開サーバーではほぼなくなりましたが (公開サーバー自体が絶滅寸前)、 過去に生成されたチャットログは受け取ったバイト列をそのまま保存していることも多いでしょうから、 それを読み込む需要は今後も皆無ではありません。

[123] LimeChat は日本で人気の IRC クライアントの1つです。 「ISO-2022-JP」 を含むいくつかの文字コードに対応しています。 LimeChat は次の4つの符号化のオプションを提供していました。 おそらくこれでかつて日本の IRC コミュニティーで行われた文字コードをほぼカバーできていると思われます。

[122] ISO/IEC 2022 的に見れば >>116, >>117 で JIS X 0201 ラテン文字用図形文字集合を G0 に指示する ESC ( J は何の意味も持ちません。 (直後に半角英数字が来ると間に ESC ( B が挿入されるので、 本当に何の意味も持ちません。) この方式を考案した人にとっては、「JIS X 0201 モードに入る」 というつもりだったのでしょうか。

[125] >>117 は SO を前に挿入しますが、 (説明にも反して) 後ろに SI を挿入しません。つまり GL を G1 に呼び出しするところまでは良いとして、 半角カナが終わっても GL を G0 に戻さないので、 以後すべてが半角カナ扱いになってしまいます。 この方式を考案した人にとっては、エスケープシーケンスで SI/SO の状態遷移はリセットされるというつもりだったのでしょうか。

シフトJIS関連の拡張

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

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

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

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

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

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

文脈

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

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

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

メールにおける利用

[153] 日本語のインターネットメールは (IP インターネットになる前の JUNET 時代から) ISO-2022-JP が標準の文字符号化として用いていました。

[154] 平成時代後期になって Gmail や Webサービスからの通知メールなどが UTF-8 を使うようになりました。Web 系企業を中心とした移行でしたが、 その当時 Webページでは既に UTF-8 が主流になっていて、 メール専用の文字コード変換をやめたいという思惑もありました。

[155] 特に標準化手続きなどはなく、なし崩し的に UTF-8 への移行が進められました。

[156] 一方で令和時代に入っても未だに ISO-2022-JP は使われ続けています。 令和5年に入って受信したメールをさらっと調べてみましたが、

といった ISO-2022-JP 利用事例が見つかりました。 平文が多いですが、 HTMLメールもありました。

Web における利用

[132] 日本のウェブの草創期 (平成時代前半頃) には、大学等 Unix 文化の流れを引くウェブサイトを中心に ISO-2022-JP (や ISO-2022-JP-2 など) が使われていました。

[133] 現在でもWebブラウザーは ISO-2022-JP に対応しています。 ISO-2022-JP に対応しない Webブラウザーは Web互換ではありません。

[134] ISO-2022-JP (など) は初期からいろいろな Webブラウザーに実装されていました。

[143] CGI 開発の一部界隈などでは、8ビット符号で区別が自明ではないシフトJIS や日本語EUC は避けて、エスケープシーケンスによって確実に漢字を判別できる ISO-2022-JP が好まれました。

[144] 初期の初期には x- のない charset 名がまともに使えるのは ISO-2022-JP だけだったので、シフトJISや日本語EUCよりも ISO-2022-JP を使うのが正統という考えの人もいました。

[186] Webにおける文字コードも参照。

[192] Lightweight document format `Predoc' (draft version 0.1.0), , http://web.archive.org/web/20070521195843/http://www.netfort.gr.jp/~kiyoka/predoc/predoc_spec.html

Predoc is a document format which has minimal features. So, Predoc is a

subset of HTML format.

You can choose popular character encoding in your country.

(I recommend ISO-2022-JP encoding for Japanese users)

[193] null, , http://web.archive.org/web/20070521195636/http://www.netfort.gr.jp/~kiyoka/predoc/faq_ja.html

    1. Internet Explorer 6で閲覧した時文字コード判別を間違えにくい。
    2. メール本文との互換性確保のため。
       - メールの本文はJISコード(ISO-2022-JP)が一般的です。Predocからメー
         ルの本文にコピー・ペーストした時に機種依存文字が文字化けするな
         どの問題を極力回避するためには最初からISO-2022-JPにしておけば
         よいと考えました。

テストページ

[183] Multilingual HTML Document for WWW!!!, , https://web.archive.org/web/19980208024433/http://www.ntt.co.jp/japan/note-on-JP/multi-example.html

実利用例

[168] Masayasu ISHIKAWA's Welcome Page, , https://www.w3.org/People/mimasa/

[173] 沖縄のインターネットプロバイダー COSMOS NET COMMUNICATIONS 2, , http://cosmos.ne.jp/

[174] コミックマーケット公式サイトへようこそ, , https://comiket.co.jp/

[175] GENTEI Kaijo ML, http://gentei.org/

[176] 魔術幻燈HTML研究室, , http://hp.vector.co.jp/authors/VA014833/index.html

[177] null, https://web.archive.org/web/20051212144007cs_/http://www.villagecenter.co.jp/atvc/wz/xhtml/xhtml/general.css

[178] >>177 ISO-2022-JP で書かれた CSS ファイル。 これを読み込む HTML はシフトJIS。 現在のブラウザーだと文字化けするが、当時はちゃんと読めていたということになる。 (:before を使っているので文字化けしたらすぐわかる。)

[179] VC Direct, , https://web.archive.org/web/19971014134305/http://www.villagecenter.co.jp/vcdirect/index.html

[180] >>179 charset 引数も meta もなし (時代が時代)。 今の Firefox では文字化けする。 Chrome では正しく表示される。

[181] >>180 フレームの方は ASCII文字だけで構成されるので、 どちらのブラウザーでも windows-1252 と判定されていて、 Firefox はフレーム内にそれを引き継ぎ、 Chrome は引き継がないでちゃんと判定しているらしい。 Firefox でもフレーム内のみ表示すればちゃんと化けない。

[188] >>187 MuleEthiopic を使ったエチオピア文字入り英語文

[190] >>189 これって当時の Emacs/W3 では正しく表示されていたのだろうか? ASCII ではないエチオピア文字部分まで < や & に置き換えられてしまっているのだけど。

[191] 手動でこんなことするとは思えないので自動でそうなってしまったのだろうけど、 誰が? Mule の保存時にそうなるような mode (?) があった? それとも Mule とは別のツールで HTML 化したときにそうなった?

性能

[145] エスケープシーケンスの分、 シフトJISや日本語EUCよりバイト長は微妙に大きくなる傾向があります。

[146] かな、漢字が3バイトになる UTF-8 よりはバイト長が短い傾向がありますが、 (文章ではなく) Webアプリケーションの HTML のように ASCII文字が多くかな、漢字がまばらだと UTF-8 の方が短いこともあります。

[147] gzip 圧縮するとこの傾向が逆転して、 シフトJISや日本語EUCや UTF-8 よりも ISO-2022-JP が短くなることがあります。 エスケープシーケンスの繰り返しはあまり問題にならなくなりますし、 7ビットの符号構造がかえって圧縮効率を高めていそうです。

歴史

もともと 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 に適合するかどうかの問題点 は次のものが挙げられています。

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

JISX0208:1997 の解説は、 RFC 1468 符号化表現の問題点を 3つ挙げる。

  1. 指示シーケンスによる文字集合の選択が曖昧である
  2. 改行後の文字集合の扱いの実装にばらつきがある
  3. ISO/IEC 2022 の subset であるかの誤解を与える
  4. (一々文字集合を指示するのは古くさい)

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

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

この問題はそもそも 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 はメール本体を text (1行) を改行区切りで連接したものとする ABNF 構文を定めていました。

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

[102] 改行が 0x0D 0x0A だけしか想定されていないのもおかしな点。 確かにインターネットメールでは改行は 0x0D 0x0A と定められていますが、 Unix 系ツールなら 0x0A のみでも改行とみなすものがほとんどのはず。 当時まだ現役だった Mac OS の 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 の ISO-2022-JP

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

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

古い案ではmessageとheadersはなく、lineがあったのに、わざわざいまの形に変更されている。 iso-2022-jp doc http://www.imc.org/ietf-822/old-archive1/msg02541.html

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

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

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

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の方がよくつかわれていた。 ESC$? ESC(? news:144@isdn1.smsc.sony.com, ESC$? ESC(? news:1993Jan3.064853.27094@sm.sony.co.jp

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

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

Re: iso-2022-jp http://www.imc.org/ietf-822/old-archive1/msg02480.html

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

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

Re: JUNET Kanji code document review news:Bu7Av0.2I4@poel.juice.or.jp
そもそもRFC 1468に向けた作業をしていたらしいメイリング・リストの記事が残っていない・・・。

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

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

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

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

[46] Formal Syntax によれば、CRとLFは単独では使用できず、 必ずCRLFでなければならない。

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

ではMIME本体以外でRFC 1468の文字コードが使われる場合にこの制限はどうなるのか。
JUNETの時代も、ネットワーク転送中はCRLFになるとしても (なるの?)、 UNIX内部ではLFにしていたのでは。

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

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

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

[48] Background Information に古い ESC ( H は使うべきではない (should not) と書いてある。

>>42 の should やそれへの指摘

Re: iso-2022-jp http://www.imc.org/ietf-822/old-archive1/msg02479.html

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

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

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

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

[1035]

ソースは?

▼インターネットで見た

[101] 仕様書:

  • JIS X 0208:1997
    • 附属書2 (規定) RFC 1468 符号化表現

符号化文字集合

[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))、ESCも例外とされていません。附属書2図3〜5もそうなっています。 附属書2 4.2 b) で 4.1 f) のバイト列が現れた場合は、 4.1 f) に示す利用状態の遷移が起こるとありますが、 4.1 f) の規定に従えば一旦JIS X 0208状態に遷移すると4.1 f) のバイト列は出現できないので・・・。

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

         ナ ゝ   ナ ゝ /    十_"    ー;=‐         |! |!   
          cト    cト /^、_&#65417;  | 、.__ つ  (.__   ‾‾‾‾   ・ ・

適合性

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

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

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

[90] 規格本体にも規定がありますが、そちらではなく、 個別の規定が適用されるようです。参考として インターネットの情報交換においては、〜空き領域の利用は行われないとあり、 そのために本体やシフト符号化表現とは別の適合の要件が規定されているのだと思われます。
  • [1022] 本体3.1 ( JIS X 0208 ) JIS97 附属書2 2.2
  • [1023] 本体3.3.1 ( JIS X 0208 ) JIS97 附属書2 2.2
  • [1024] 本体3.3.2 ( JIS X 0208 ) と附属書2 2.2.2 (>>1026) の一方又は両方 JIS97 附属書2 2.2, 2.2.1
  • [1027] 適合性を主張する場合、附属書2の符号化文字集合を採用したことを文書に明示しなければなりません。 JIS97 附属書2 2.2
  • [1028] 指定された図形文字の組を入れ替えても構いません。 その場合、入れ替えの一覧を文書に明示しなければなりません。 JIS97 附属書2 2.2
  • [1029] 指定された図形文字を実装しなくても構いません。 その場合、実装しないものの一覧を文書に明示しなければなりません。 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 ( JIS X 0208 ) によります。 ただし、0x0D 0x0Aを受信した場合、 図形文字の領域をISO/IEC 646 (最新版) IRV に遷移しても構いません。その場合、 文書に明示しなければなりません。 JIS97 附属書2 2.2.2

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

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

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

[1040] JIS X 0208:1997の解説には、

が問題として認められるので、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 の適当なミックスでも適合するっぽいのですが、 本当にそんなのでいいのでしょうか。 相互運用性はハナから放棄していたのでしょうかね。 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 ISO-2022-JP

[7] IANAのcharset登録簿には、2006年3月現在

Name: ISO-2022-JP  (preferred MIME name)               [RFC1468,Murai]
MIBenum: 39
Source: RFC-1468 (see also RFC-2237)
Alias: csISO2022JP
とあり、charset ISO-2022-JPの定義はRFC 1468とされています。

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

文字符号化ISO-2022-JP (XML)

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

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

Apple

[169] Apple MailのISO-2022-JP-90pv(適当に命名)について - 帰ってきた💫Unicode刑事〔デカ〕リターンズ, https://moji-memo.hatenablog.jp/entry/20060831/1157000920

[170] Apple Mailでハシゴ高が「釵」に化ける件 - 帰ってきた💫Unicode刑事〔デカ〕リターンズ, https://moji-memo.hatenablog.jp/entry/20060905/1157442421

[171] Apple Mailが送信する謎のハイブリッドCP932について - 帰ってきた💫Unicode刑事〔デカ〕リターンズ, https://moji-memo.hatenablog.jp/entry/20060914/1158217630

[172] Apple Mailの方言自動判別? - 帰ってきた💫Unicode刑事〔デカ〕リターンズ, https://moji-memo.hatenablog.jp/entry/20071128/1196224193

メモ

[56] 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 だった、ってのがなんとも憎いね。ちなみに、他のブラウザのように lang 属性でフォント切り替えなんて阿呆らしいことはやってないみたい。

[3] WinNC4 は ESC ( J で出力します。 (ある意味正しい。)

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

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

[8] Web Applications 1.0 r6646 Define compatibility mapping for ISO-2022-JP. ( ( 版)) http://html5.org/tools/web-apps-tracker?from=6645&to=6646

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

[12] Remove JIS X 0212 from iso-2022-jp per https://www.w3.org/Bugs/Public/sh... · 5a20290 · whatwg/encoding ( ( 版)) https://github.com/whatwg/encoding/commit/5a2029026a013a1b9fd871f261dfa4059c96d746

[13] Rewrite iso-2022-jp https://www.w3.org/Bugs/Public/show_bug.cgi?id=27256 · 19b0ebf · whatwg/encoding ( ( 版)) https://github.com/whatwg/encoding/commit/19b0ebf0e48c3a607ab7623b5b272642dd59d6e7

[5] Treat U+2022 as U+FF0D in Japanese encoders. Fixes https://www.w3.org… · whatwg/encoding@a7ab97e ( 版) https://github.com/whatwg/encoding/commit/a7ab97e891773bd7a564b463c6a1cc31196a5bdd

[14] Fix #21: Japanese encoders have special treatment for U+2212, not U+2022 · whatwg/encoding@95f85a6 ( 版) https://github.com/whatwg/encoding/commit/95f85a63ad4d6b6331f21ff60f9244b3bcbe6d84

[15] 2007/04/27 日記: Java: Outlook 風の JISコード (ISO-2022-JP) を利用するための x-windows-iso2022jp というエンコーディング ( 版) http://homepage2.nifty.com/igat/igapyon/diary/2007/ig070427.html

拡張 ISO-2022-JP (MS932 ベース)

※ ちなみに CP50220 と x-windows-iso2022jp とは Javaにおいて挙動が異なりました。(エイリアスではありませんでした)

また更に便利なことに、x-windows-iso2022jp では 重複符号化領域のコードについても、適切に Outlook風のUnicodeマッピングを行ってくれます。

[16] フィーチャーフォンについて | KDDI Mobile ( 版) http://www.kddimobile.com/faqs/faq_featurephone/

Eclipseの対応する日本語用文字コードは以下になります。

iso-2022-jp (x-windows-iso2022jp)

shift-jis (windows-31j)

euc-jp

utf-8

iso-8859-1

送信は全てiso-2022-jp

[17] 【TKMP.dl】x-windows-iso2022jp対応 ( 版) http://uwa.potetihouse.com/bbs/patio.cgi?mode=past&no=401

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

[18] Fix #15: prevent ISO-2022-JP encoder attack · whatwg/encoding@f9540e5 ( 版) https://github.com/whatwg/encoding/commit/f9540e53e72c3b455708a05e5ff5c7a552a5a733

[19] Update integration with Encoding Standard · whatwg/html@6a31c26 ( 版) https://github.com/whatwg/html/commit/6a31c26cf12e39dab1a488e75dd56c03d6786d39

[20] Editorial: avoid upsetting lazy compilers (#55) ( (annevk著, )) https://github.com/whatwg/encoding/commit/9f7252a08211a623cabc5fe6b03dda7f0cc9ef11

[27] Note >8835 pointers in index jis0208 cannot be reached (annevk著, ) https://github.com/whatwg/encoding/commit/fb87552bfa03cc93a1077c8f13e2f58535d0e97c

[28] Thunderbird/SeaMonkey の既定のテキストエンコーディングを UTF-8 に変更する · Issue #63 · mozilla-japan/gecko-l10n () https://github.com/mozilla-japan/gecko-l10n/issues/63

[29] Document minimal implementation requirements (annevk著, ) https://github.com/whatwg/encoding/commit/9323530fae940d95b2c0b9f00a6a654bd2097aff

[30] 563283 - Perform Hankaku to Zenkaku conversion in ISO-2022-JP encoder () https://bugzilla.mozilla.org/show_bug.cgi?id=563283

[31] ISO-2022-JP encoder: document an oddity (annevk著, ) https://github.com/whatwg/encoding/commit/fe4934c2eb49a2e0b3a630c35b9fa23f7cc16fc0

[32] Concatenating two ISO-2022-JP outputs from a conforming encoder doesn't result in conforming input · Issue #115 · whatwg/encoding () https://github.com/whatwg/encoding/issues/115

[33] ISO-2022-JP encoder: document an oddity by annevk · Pull Request #155 · whatwg/encoding () https://github.com/whatwg/encoding/pull/155

[34] MozillaZine.jp フォーラム • トピック - Thuderbird 60.3.0で、件名にU+FFFDが入るようになった () https://forums.mozillazine.jp/viewtopic.php?f=3&t=17271

[35] 1374149 - Folded subject header using ISO-2022-JP doesn't get decoded properly () https://bugzilla.mozilla.org/show_bug.cgi?id=1374149

[36] () https://www.ttc.or.jp/jp/document_list/pdf/j/STD/JJ-80.10v1.pdf

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

[38] ( 版) http://news.tbs.co.jp/

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

[50] Differences in the ISO-2022-JP encoding between browsers » Blog for The Ultimate Pokemon Center, , https://web.archive.org/web/20140912104045/http://upokecenter.dreamhosters.com/articles/2013/04/differences-in-the-iso-2022-jp-encoding-between-browsers/

[49] 1374149 - Folded subject header using ISO-2022-JP doesn't get decoded properly, https://bugzilla.mozilla.org/show_bug.cgi?id=1374149

[51] Concatenating two ISO-2022-JP outputs from a conforming encoder doesn't result in conforming input · Issue #115 · whatwg/encoding · GitHub, https://github.com/whatwg/encoding/issues/115

[37] No U+FFFD Generation for Zero-Length Content between ISO-2022-JP Escape Sequences, , https://www.unicode.org/L2/L2020/20202-empty-iso-2022-jp.pdf

[55] RFC から読めない IRC, https://yoshino.tripod.com/73th/data/irccode.htm#japaneseproblem_hiddenwhois

[126] [ICU-22166] Incomplete ESC sequence handling when converting ISO-2022-JP to Unicode is different from WHATWG spec - Unicode Consortium, https://unicode-org.atlassian.net/browse/ICU-22166

[127] 1371156 - Consider dropping ISO-2022-JP from the list of legacy encodings to support - chromium, https://bugs.chromium.org/p/chromium/issues/detail?id=1371156

[128] 1140965 - Error handling for ISO-2022-JP is incorrect - chromium, https://bugs.chromium.org/p/chromium/issues/detail?id=1140965

[129] 430823 - invalid byte sequence handling is not compliant to the WHATWG encoding spec in multibyte encodings - chromium, https://bugs.chromium.org/p/chromium/issues/detail?id=430823

[130] Concatenating two ISO-2022-JP outputs from a conforming encoder doesn't result in conforming input · Issue #115 · whatwg/encoding · GitHub, https://github.com/whatwg/encoding/issues/115

Updated: