このメモはインターネット・コミュニティーのために情報を提供するものであり、いかなるインターネット標準も定めない。 このメモの配布に制限はない。
このメモでは、"ISO-2022-JP-2" というテキスト符号化方式について説明する。 これは日本のいくつかのネットワークにおいて電子メール [RFC822] やネットワーク・ニュース [RFC1036] のメッセージに実験的に利用されているものである。 この符号化法は、日本語のための符号化法としてすでにある ISO-2022-JP [2022JP] の多言語拡張であり、Emacs ベースの多言語テキスト・エディター MULE [MULE] によってサポートされている。
"ISO-2022-JP-2" という名称は、MIME ヘッダーの charset パラメーター ([MIME1] および [MIME2] 参照) において用いることが意図されている。
ISO-2022-JP-2 によるテキストは、ASCII [ASCII] で始まり、エスケープ・シーケンスの少数の組み合わせによって他の文字集合に切り替わる。 文字はすべて 7 ビットだけで符号化される。
テキストの先頭には、アナウンス・シーケンス "ESC 2/0 4/1 ESC 2/0 4/6 ESC 2/0 5/10" の存在が (省略されるが) 仮定される。 そのため、94 文字集合の文字が G0 に指示され、GL として呼び出される。 C1 制御文字は 7 ビットで表現される。 96 文字集合の文字は G2 に指示され、SS2 (シングル・シフト 2、"ESC 4/14" すなわち "ESC N") によって呼び出される。
たとえば、エスケープ・シーケンス "ESC 2/4 2/8 4/3" すなわち "ESC $ ( C" は、それに続くバイト列が 1 文字 2 バイトで符号化される韓国の KSC の文字列であることを示す。 エスケープ・シーケンス "ESC 2/14 4/1" すなわち "ESC . A" は、ISO 8859-1 が G2 に指示されることを示す。 指示の後は、シングル・シフトされたシーケンス "ESC 4/14 4/1" すなわち "ESC N A" が「鋭アクセントつき A」の文字を表現するものと解釈される。
次の表に、ISO-2022-JP-2 のメッセージで用いられるエスケープ・シーケンスと文字集合とを示す。 「登録番号」は ISO のレジストリー [ISOREG] における登録番号である。
| 登録番号 | 文字集合 | 94 文字集合用 エスケープ・シーケンス | 指示先 | |||||
|---|---|---|---|---|---|---|---|---|
| 6 | ASCII | ESC 2/8 4/2 | ESC ( B | G0 | ||||
| 42 | JIS X 0208-1978 | ESC 2/4 4/0 | ESC $ @ | G0 | ||||
| 87 | JIS X 0208-1983 | ESC 2/4 4/2 | ESC $ B | G0 | ||||
| 14 | JIS X 0201-Roman | ESC 2/8 4/10 | ESC ( J | G0 | ||||
| 58 | GB2312-1980 | ESC 2/4 4/1 | ESC $ A | G0 | ||||
| 149 | KSC5601-1987 | ESC 2/4 2/8 4/3 | ESC $ ( C | G0 | ||||
| 159 | JIS X 0212-1990 | ESC 2/4 2/8 4/4 | ESC $ ( D | G0 | ||||
| 登録番号 | 文字集合 | 96 文字集合用 エスケープ・シーケンス | 指示先 | |||||
|---|---|---|---|---|---|---|---|---|
| 100 | ISO8859-1 | ESC 2/14 4/1 | ESC . A | G2 | ||||
| 126 | ISO8859-7(Greek) | ESC 2/14 4/6 | ESC . F | G2 | ||||
文字集合およびエスケープ・シーケンスについて、より詳しくは [ISO2022] および [ISOREG] を参照されたい。
テキストに G0 への指示があった場合、空白文字かまたはタブや CRLF などの制御文字より前に、ASCII ないし JIS X 0201-Roman への切り替えがなければならない (ただし、"ESC 4/14 2/0" すなわち "ESC N ' '" の前には必要ない)。 これは、次の行が、その切り替わった文字集合で始まることを意味する。 ISO-2022-JP との後方互換のために、JIS X 0201-Roman への指示は許されてはいるが、それを使用することは推奨されない。 ページャーやエディターなど、ISO-2022-JP-2 で符号化されたテキスト・ファイル内をランダムにシークするアプリケーションは、すべての行が JIS X 0201-Roman ではなく ASCII で始まるものと仮定してよい。
行頭では、その前の行の G2 への指示に関する情報はクリアされる。 96 文字集合の文字を使用する行には、それを使用する前に新たな指示が与えられなければならない。
テキストは、G0 に ASCII が指示された状態で終わらなければならない。
ISO-2022-JP は、したがって ISO-2022-JP-2 も、英語および現代日本語を表現するために設計されているため、テキストが水平方向に表示される場合には左から右へという方向性が想定されている。
ISO-2022-JP-2 の利用者は、一般的な搬送法の中には古い Bnews のように 7 ビット値 7/15 (十進では 127) が中継できないものもあるということを心得ていなければならない。 この値は、たとえば ISO 8859-1 では「分音符つき y」を符号化するのに用いられている。
その他の制約は次の「形式的構文」の章で与える。
ここで用いる表記上の規約は、STD 11 すなわち RFC 822 [RFC822] で用いられているものと同一である。
アステリスク (*) の規約は次のとおり。
l*m something
これは、少なくとも l 個、多くとも m 個の something を意味する。 l および m はそれぞれ 0 および無限大のデフォルト値をとる。
message = headers 1*(CRLF text)
; [MIME1] の "body-part" を見よ。
; 注意: ASCII で終わらねばならない。
text = *(single-byte-char /
g2-desig-seq /
single-shift-char)
[*segment
reset-seq
*(single-byte-char /
g2-desig-seq /
single-shift-char ) ]
; 注意: g2-desig-seq は
; single-shift-char に
; 先行しなければならない。
headers = <[RFC822] の "fields" および
[MIME1] の "body-part" を見よ>
segment = single-byte-segment / double-byte-segment
single-byte-segment = single-byte-seq
*(single-byte-char /
g2-desig-seq /
single-shift-char )
double-byte-segment = double-byte-seq
*((one-of-94 one-of-94) /
g2-desig-seq /
single-shift-char )
reset-seq = ESC "(" ( "B" / "J" )
single-byte-seq = ESC "(" ( "B" / "J" )
double-byte-seq = (ESC "$" ( "@" / "A" / "B" )) /
(ESC "$" "(" ( "C" / "D" ))
g2-desig-seq = ESC "." ( "A" / "F" )
single-shift-seq = ESC "N"
single-shift-char = single-shift-seq one-of-96
CRLF = CR LF
; ( 8 進, 10 進.)
ESC = <ISO 2022 ESC, escape> ; ( 33, 27.)
SI = <ISO 2022 SI, shift-in> ; ( 17, 15.)
SO = <ISO 2022 SO, shift-out> ; ( 16, 14.)
CR = <ASCII CR, carriage return>; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
one-of-94 = <94 個の値の任意のもの> ; (41-176, 33.-126.)
one-of-96 = <96 個の値の任意のもの> ; (40-177, 32.-127.)
7BIT = <任意の 7 ビット値> ; ( 0-177, 0.-127.)
single-byte-char = <任意の 7BIT, ただし裸の CR および裸の LF は
含むが CRLF は含まず, ESC, SI, SO も含まない>
この文字符号化法に与えられた名称は "ISO-2022-JP-2" である。 この名称は MIME メッセージにおいて次のように用いることが意図されている。
Content-Type: text/plain; charset=iso-2022-jp-2
ISO-2022-JP-2 符号化法はすでに 7 ビット形式であるため、Content-Transfer-Encoding ヘッダーを用いる必要はない。 Base64 符号化法や Quoted-Printable 符号化法を適用すると、MIME に準拠していないソフトウェアではメッセージが読めなくなってしまうことに注意すべきである。
ISO-2022-JP-2 はまた、MIME ヘッダーにも用いることができる。 ISO-2022-JP-2 のテキストには、"B" 符号化法も "Q" 符号化法もともに有効であろう。
| [ASCII] | American National Standards Institute, "Coded character set -- 7-bit American national standard code for information interchange", ANSI X3.4-1986. |
| [ISO2022] | International Organization for Standardization (ISO), "Information processing -- ISO 7-bit and 8-bit coded character sets -- Code extension techniques", International Standard, Ref. No. ISO 2022-1986 (E). |
| [ISOREG] | International Organization for Standardization (ISO), "International Register of Coded Character Sets To Be Used With Escape Sequences". |
| [MIME1] | Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993. |
| [MIME2] | Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, September 1993. |
| [RFC822] | Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982. |
| [RFC1036] | Horton M., and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987. |
| [2022JP] | Murai, J., Crispin, M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, June 1993. |
| [MULE] | Nishikimi, M., Handa, K., and S. Tomura, "Mule: MULtilingual Enhancement to GNU Emacs", Proc. of INET'93, August, 1993. |
このメモは、ニュース・グループ fj.kanji においてさまざまな人たちの間で交わされた議論の成果であり、メーリング・リスト jp-msg@iij.ad.jp によって吟味されたものである。 とりわけ、ISO 2022 および関連規格に関する深い造詣に基づいてご示唆くださった Eiichi Wada (和田英一) 教授には感謝したい。
セキュリティーの問題はこのメモでは議論しない。
Masataka Ohta (太田昌孝)
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku,
Tokyo 152, JAPAN
Phone: +81-3-5499-7084
Fax: +81-3-3729-1940
EMail: mohta@cc.titech.ac.jp
Ken'ichi Handa (半田剣一)
Electrotechnical Laboratory
Umezono 1-1-4, Tsukuba,
Ibaraki 305, JAPAN
Phone: +81-298-58-5916
Fax: +81-298-58-5918
EMail: handa@etl.go.jp