[3] ISO-2022-INT (ISO-2022-INT-*) は、 平成時代初期に電子メールや電子ニュースなどで使われた国際化された文字コード群です。
[6] ISO-2022-INT-1 は ISO-2022-INT を称する最初の文字コードです。 これを足がかりに段階的に拡張していくことが想定されていました。
本項は歴史的事項を説明しています。本項の内容の一部または全部は、現在の状況とは異なるかもしれません。
(なお本項の内容の一部または全部は、互換性または歴史的連続性のために現在も有効な場合もあります。しかし新たに利用することは避けるべきです。)
[2] ASCII, ISO-2022-JP および ISO-2022-KR と完全な互換性があり、 ISO-2022-JP-2, EUC-JP, EUC-CN, EUC-KR, Shift_JIS, Big5 と文字集合的には互換性がある。
94 character sets
reg# character set ESC sequence designated to
------------------------------------------------------------------
6 ASCII ESC 2/8 4/2 ESC ( B G0
14 JIS X 0201-Roman ESC 2/8 4/10 ESC ( J G0 94*94 character sets
reg# character set ESC sequence designated to
------------------------------------------------------------------
42 JIS X 0208-1978 ESC 2/4 4/0 ESC $ @ G0
58 GB 2312-80 ESC 2/4 4/1 ESC $ A G0
87 JIS X 0208-1983 ESC 2/4 4/2 ESC $ B G0
149 KS C 5601-1987 ESC 2/4 2/9 4/3 ESC $ ) C G1
159 JIS X 0212-1990 ESC 2/4 2/8 4/4 ESC $ ( D G0
171 CNS 11643-1986-1 ESC 2/4 2/8 4/7 ESC $ ( G G0
172 CNS 11643-1986-2 ESC 2/4 2/8 4/8 ESC $ ( H G0 96 character sets
reg# character set ESC sequence designated to
------------------------------------------------------------------
100 ISO8859-1 ESC 2/13 4/1 ESC - A G1
126 ISO8859-7(Greek) ESC 2/13 4/6 ESC - F G1G1 は SO を使って左に呼び出し、 G0 は SI を使って左に呼び出す。
情報交換の最初と最後, 行頭と行末は G0: ASCII, G1: KS X 1001 の状態。但し、 G1 に KS X 1001 を入れて置くのは ISO-2022-KR との互換性のためであって、出力時は G1: empty とみなすのが 望ましい。 (一々行ごとに ESC $ ) C を吐く。)
"ISO-2022-INT-1" is designed to be purely 7-bit, so that it can be used with any transport which conforms to STD 11, RFC822 [RFC822] without MIME [MIME1,MIME2], which is the current practice in Japan to use "ISO-20220-JP" [2022JP].
"ISO-2022-INT-1" は純粋に7ビットに設計されていますから、 MIME なしの STD 11, RFC 822 に適合するどんな転送路でも 利用出来ます。これは、日本で "ISO-2022-JP" を使う際の現在の慣習です。
If "ISO-2022-INT-1" is used with MIME, MIME charset name may be given as follows:
"ISO-2022-INT-1" を MIME で使う場合は、 MIME charset 名を次のようにして構いません。
Content-Type: text/plain; charset=iso-2022-int-1
Even if the charset parameters are omitted, multilingual applications should still assume "ISO-2022-INT-1" (or its latest available successor discussed in the section "Future Extension Plan"), not US-ASCII of MIME's default, is used.
charset パラメーターが省略されていても、 多言語応用は "ISO-2022-INT-1" (または「将来の拡張案」 の賞で述べる、利用できる最新版。) (MIME の既定値である US-ASCII で無く。) が使われていると仮定するべきです。
The "ISO-2022-INT-1" encoding is already in 7-bit form, so it is not necessary to use a Content-Transfer-Encoding header. It should be noted that applying the Base64 or Quoted-Printable encoding will render the message unreadable in non-MIME-compliant software.
"ISO-2022-INT-1" は最初から7ビットですから、 Content-Transfer-Encoding 頭を利用する必要はありません。 Base64 や Quoted-Printable を無理に使うと、 非 MIME 適合ソフトウェアでは、メッセージが読めなくなります。
"ISO-2022-INT-1" may also be used in mail headers. If bare STD11, RFC822 without MIME is used, appropriate quoting of special characters as "quoted string" might be necessary with structured headers, which might not be supported by all the common mail transport, though it is a violation of STD11, RFC822. Such broken transport might not support some non-graphic characters in unstructured headers, either. In MIME headers, Both "B" and "Q" encoding could be useful with "ISO-2022-INT-1" text. As MIME conformant mailers prevails, it is expected that they also strictly support STD11, RFC822. That is, when MIME will becomes widely available, MIME encoding in headers will not be necessary so much for "ISO-2022-INT-*".
"ISO-2022-INT-1" は、メイル頭にも使うことが出来ます。 STD 11 単独 (MIME なしの RFC 822) が使われている場合、 特殊文字を「quoted string」として適切に quote することが構造化頭では必要かもしれません。これは 全ての共通メイル転送が対応していないかもしれませんが、 それは STD 11, RFC 822 違反です。その様な壊れた転送系は、 非構造化頭中の非図形文字で幾つか対応していないものもあるかもしれません。 MIME 頭では、 "ISO-2022-INT-1" 文には "B" 符号化も "Q" 符号化のどちらも有用です。 MIME 適合メイラーが普及するに連れ、 STD 11, RFC 822 の厳密な対応も期待されます。つまり、 MIME が広範囲で利用できるようになった時、 "ISO-2022-INT-*" には頭中での MIME 符号化は必要なくなるでしょう。
[9] TLUG Mailing List, Jim Schweizer - webmaster TLUG, , https://lists.tlug.jp/ML/9706/msg00040.html
[10] Re: Automatic part insertion: åäö and 吃哪塞 on the same line - Shenghuo ZHU, https://inbox.vuxu.org/ding/5bbtlme5fo.fsf@brandy.cs.rochester.edu/
[5] ISO-2022-INT は、 ISO-2022-JP の系譜で明文化された符号化文字集合としては、 最も進化したものかもしれません。
[8] ISO-2022-CN-EXT は包含していません。実装不能な EXT 部分を除外したのは意図的なのでしょうか。