このメモはインターネット・コミュニティーのために情報を提供するものであり、インターネット標準を定めるものではない。 このメモの配布に制限はない。
この文書では、日本のネットワークのいくつかにおいて、電子メール [RFC822] およびネットワーク・ニュース [RFC1036] のメッセージに用いられている符号化法について説明する。 この符号化法は当初、JUNET [JUNET] によって定められ用いられていたものであるが、現在では日本の IP コミュニティーにおいても広く利用されている。
この符号化法に与えられた名称は "ISO-2022-JP" である。 MIME ヘッダーの charset パラメーター・フィールド ([MIME1] および [MIME2] 参照) で用いることが意図されている。
テキストは ASCII [ASCII] で始まり、エスケープ・シーケンスによって日本語文字に切り替わる。 たとえば、エスケープ・シーケンス「ESC $ B」 (3 バイト、十六進表記で 1B 24 42) は、それに続くバイト列が日本語文字であることを示す。 日本語文字は、それぞれの文字が 2 バイトで符号化される。 ASCII に戻すには、エスケープ・シーケンス「ESC ( B」が用いられる。
次の表に、ISO-2022-JP のメッセージで使われるエスケープ・シーケンスと文字集合とを示す。 ISOREG 番号は ISO のレジストリー [ISOREG] における登録番号である。
エスケープ・シーケンス | 文字集合 | ISOREG | ||
ESC ( B | ASCII | 6 | ||
ESC ( J | JIS X 0201-1976 (「ローマ字」集合) | 14 | ||
ESC $ @ | JIS X 0208-1978 | 42 | ||
ESC $ B | JIS X 0208-1983 | 87 |
JIS X 0208 は、1987 年 3 月 1 日に名称が変更されるまでは JIS C 6226 と呼ばれていたことに注意されたい。 同様に、JIS C 6220 は JIS X 0201 に改称されている。
JIS X 0201 [JISX0201] の「ローマ字」文字集合は、バックスラッシュ (\) とティルデ (~) を除けば、ASCII と同一である。 バックスラッシュは円記号に、ティルデはオーバーラインに置き換えられている。 この文字集合は ISO 646 [ISO646] に対する日本の対応規格である。
JIS X 0208 [JISX0208] 文字集合は、漢字、ひらがな、カタカナ、およびその他の記号や文字からなる。 それぞれの文字は 2 バイトを占める。
JIS の日本語文字集合規格について、より詳しくは [JISX0201] および [JISX0208] を参照されたい。 エスケープ・シーケンスに関するさらなる情報については、[ISO2022] および [ISOREG] をご覧いただきたい。
もし、1 行のうちに JIS X 0208 の文字があるならば、その行の終わり (つまり CRLF) までに ASCII ないし JIS X 0201 の「ローマ字」集合への切り替えがなければならない。 これは、その次の行が、その切り替わった文字集合で始まることを意味する。
また、テキストは ASCII で終わらなければならない。
その他の制約は次の「形式的構文」において与える。
ここで用いる表記上の規約は、RFC 822 [RFC822] で用いられているものと同一である。
アステリスク (*) の規約は次のとおり。
l*m something
これは、少なくとも l 個、多くとも m 個の something を意味する。 l および m はそれぞれ 0 および無限大のデフォルト値をとる。
message = headers 1*( CRLF *single-byte-char *segment single-byte-seq *single-byte-char ) ; [MIME1] の "body-part" も見よ。 ; 注: ASCII で終わらねばならない。 headers = <[RFC822] の "fields" および [MIME1] の "body-part" を見よ> segment = single-byte-segment / double-byte-segment single-byte-segment = single-byte-seq 1*single-byte-char double-byte-segment = double-byte-seq 1*( one-of-94 one-of-94 ) single-byte-seq = ESC "(" ( "B" / "J" ) double-byte-seq = ESC "$" ( "@" / "B" ) 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.) 7BIT = <任意の 7 ビット値> ; ( 0-177, 0.-127.) single-byte-char = <任意の 7BIT, ただし裸の CR および裸の LF は 含むが CRLF は含まず, ESC, SI, SO も含まない>
JUNET の文字符号化法に与えられた名称は "ISO-2022-JP" である。 この名称は MIME メッセージにおいて次のように用いられることが意図されている。
Content-Type: text/plain; charset=iso-2022-jp
ISO-2022-JP 符号化法はすでに 7 ビット形式であるため、Content-Transfer-Encoding ヘッダーを用いる必要はない。 Base64 符号化法や Quoted-Printable 符号化法を適用すると、現在の JUNET ソフトウェアではメッセージが読めなくなってしまうことに注意すべきである。
ISO-2022-JP はまた、MIME 第 2 部のヘッダーにも用いることができる。 ISO-2022-JP のテキストには "B" 符号化法を用いるべきである。
JUNET の符号化法は「JUNET 利用の手引 (第 1 版)」[JUNET] において説明されている。
この符号化法は、4/1 によってアナウンスされる ISO 2022 の特定の利用法に基づいている (詳細については [ISO2022] 参照)。 ただし、本来ならそのアナウンスに用いられるエスケープ・シーケンスは、ISO-2022-JP のメッセージには含まれない。
JIS X 0201 のカナ集合は、ISO-2022-JP のメッセージの中では用いられない。
かつて、JUNET メッセージの中で誤って「ESC ( H」というエスケープ・シーケンスを用いるシステムがいくつかあった。 このエスケープ・シーケンスは、スウェーデン語文字集合 [ISOREG] 用に公式に登録されており、ISO-2022-JP のメッセージの中で使用すべきではない。
システムによっては、表示に際して、「ESC ( B」と「ESC ( J」とを区別しなかったり、「ESC $ @」と「ESC $ B」とを区別しなかったりするものがある。 しかし、メッセージを別のシステムへ中継する場合には、決してエスケープ・シーケンスを変更してはならない。
利用者 (実装者ではなく) は、1 行を 80 カラム以内に、あるいは引用に際して各行の先頭に ">" が挿入できるよう、なるべく 75 カラム (程度) 以内に保つことを心掛けるべきである。 JIS X 0208 の文字はそれぞれが 2 カラムを占める一方、エスケープ・シーケンスは 1 カラムも占めない。 実装者に対しては、JIS X 0208 の文字が 2 バイトを占めており、表示などのために改行する場合でもその途中で分割すべきではないということを指摘しておく。
JIS X 0208 規格は 1990 年に改訂され、文字表の末尾に 2 文字が追加された。 ISO 2022 は改訂文字集合の使用を示すための特殊な付加エスケープ・シーケンスを定めているが、ここでは、1990 年に JIS X 0208 に追加された 2 字を使う場合であっても、ISO-2022-JP のテキストの中ではこの特殊エスケープ・シーケンスは使用しないことを提案する。
日本語文字符号化法に関するさらなる情報——PC コード、実装を公開している FTP サイト、等々——については、「Electronic Handling of Japanese Text」 [JPN.INF] を参照されたい。
[ASCII] American National Standards Institute, "Coded character set -- 7-bit American national standard code for information interchange", ANSI X3.4-1986.
[ISO646] International Organization for Standardization (ISO), "Information technology -- ISO 7-bit coded character set for information interchange", International Standard, Ref. No. ISO/IEC 646:1991.
[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".
[JISX0201] 日本規格協会, 「情報交換用符号」, JIS X 0201-1976.
[JISX0208] 日本規格協会, 「情報交換用漢字符号」, JIS X 0208-1978, -1983, -1990.
[JPN.INF] Ken R. Lunde <lunde@adobe.com>, "Electronic Handling of Japanese Text", March 1992, msi.umn.edu(128.101.24.1):pub/lunde/japan[123].inf
[JUNET] JUNET 利用の手引作成委員会, 「JUNET 利用の手引 (第 1 版)」, 1988 年 2 月.
[MIME1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.
[MIME2] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1342, University of Tennessee, June 1992.
[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.
本文書の起草にあたっては多くの方々にご援助いただいた。 とりわけ、Akira Kato (加藤朗)、Masahiro Sekiguchi (関口正裕)、Ken'ichi Handa (半田剣一) の各氏には感謝したい。
セキュリティーの問題はこのメモでは議論しない。
Jun Murai (村井純)
Keio University
5322 Endo, Fujisawa
Kanagawa 252 Japan
Fax: +81 466 49 1101
EMail: jun@wide.ad.jp
Mark Crispin
Panda Programming
6158 Lariat Loop NE
Bainbridge Island, WA 98110-2098
USA
Phone: +1 206 842 2385
EMail: MRC@PANDA.COM
Erik M. van der Poel
A-105 Park Avenue
4-4-10 Ohta, Kisarazu
Chiba 292 Japan
Phone: +81 438 22 5836
Fax: +81 438 22 5837
EMail: erik@poel.juice.or.jp