Edit

Page

Page title:

Page body:

[3] [DFN[ISO-2022-INT]] ([DFN[ISO-2022-INT-[VAR[*]]]]) は、
[[平成時代]]初期に[[電子メール]]や[[電子ニュース]]などで使われた[[国際化]]された[[文字コード]]群です。

[6] [DFN[ISO-2022-INT-1]] は [[ISO-2022-INT]] を称する最初の[[文字コード]]です。
これを足がかりに段階的に拡張していくことが想定されていました。

* 仕様書

[REFS[
- [1] 
[CITE[Internet Multilingual Text Encoding]]
<urn:ietf:id:draft-ohta-text-encoding-01>
]REFS]

* 符号化文字集合

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

[[G1]] は [[SO]] を使って左に[[呼び出し]]、
[[G0]] は [[SI]] を使って左に呼び出す。

情報交換の最初と最後, 行頭と行末は G0: ASCII, G1: KS X 1001
の状態。但し、 G1 に KS X 1001 を入れて置くのは [[ISO-2022-KR]]
との互換性のためであって、出力時は G1: empty とみなすのが
望ましい。 (一々行ごとに ESC $ ) C を吐く。)

* 電子メールでの利用

[FIG(quote)[ [7] ISO-2022-INT-1 01 の 4. Mail System Considerations

"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 符号化は必要なくなるでしょう。

]FIG]

[9] [CITE[TLUG Mailing List]], [[Jim Schweizer - webmaster TLUG]], [TIME[2007-05-20T03:27:15.000Z]], [TIME[2025-05-21T13:40:08.268Z]] <https://lists.tlug.jp/ML/9706/msg00040.html>

[10] 
[CITE[Re: Automatic part insertion: åäö and 吃哪塞 on the same line - Shenghuo ZHU]], [TIME[2025-05-21T13:40:44.000Z]] <https://inbox.vuxu.org/ding/5bbtlme5fo.fsf@brandy.cs.rochester.edu/>

* 実装

[4] 
[[Emacs]] など一部で実装されており、
[[電子メール]]などで使われていました。

* 関連

-<urn:ietf:id:draft-ohta-text-encoding-00>
-<urn:ietf:id:draft-ohta-text-encoding-01>
-[[電子メイル]]
--[[RFC 822メッセージ]]
--[[Content-Type:領域]]
--[[Content-Transfer-Encoding:領域]]
-[[MIME]]
-[[文字コード]]
-- [CODE[junet]]
--[[ISO-2022-JP]]
--[[ISO-2022-JP-2]]
--[[ISO-2022-KR]]
--[[ISO-2022-CN]]
-[[mohta]]

[5] 
[[ISO-2022-INT]] は、
[[ISO-2022-JP]] の[[系譜][junet]]で明文化された[[符号化文字集合]]としては、
最も進化したものかもしれません。

[8] 
[[ISO-2022-CN-EXT]] は包含していません。実装不能な EXT 部分を除外したのは意図的なのでしょうか。

* メモ

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)