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 G1情報交換の最初と最後, 行頭と行末は G0: ASCII, G1: KS X 1001
の状態。但し、 G1 に KS X 1001 を入れて置くのは
"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 符号化は必要なくなるでしょう。
junet