K. Tamaru
Microsoft Corporation
November 1997
Network Working Group
Request for Comments: 2237
Category: Informational

Japanese Character Encoding
for Internet Messages

(インターネット・メッセージのための日本語文字符号化法)

このメモの位置づけ

このメモはインターネット・コミュニティーのために情報を提供するものであり、いかなる種類のインターネット標準も定めない。 このメモの配布に制限はない。

著作権表示

Copyright (C) The Internet Society (1997). All Rights Reserved.

1. 摘要

このメモでは、"ISO-2022-JP-1" という日本語文字のための符号化方式を定義する。 これは電子メール [RFC-822] や ネットワーク・ニュース [RFC 1036](1) で利用されるものである。 この符号化方式で用いられる日本語文字集合の一覧も示す。

2. 要件の表記法

この文書では、仕様の特定の要件を表わすのに太字で示される用語を使用する。 すなわち、「しなければならない」、「すべきである」、「してはならない」、「すべきではない」、「してもよい」である。 各用語の意味は [RFC-2119] にある。

3. 序論

RFC 1468 は、このメモと同様、日本語文字の符号化の方法を定義している。 そこでは、ISO-2022-JP のテキストにおける 2 バイト文字集合として JIS X 0208 の使用が定義されている。

今日では、多くのオペレーティング・システムが独自仕様の拡張日本語文字や JIS X 0212、あるいは Unicode 文字集合をサポートしているが、それは JIS X 0201 にも JIS X 0208 にも適合しないものである。 その結果、利用可能な漢字が制限され、正確な情報を伝達したり交換したりする能力が制限されてしまっている。 さいわい、JIS (日本工業規格) は JIS X 0212 を「情報交換用漢字符号 — 補助漢字」として定義している。 通常の電子メールで使われる日本語文字のほとんどは、JIS X 0201、JIS X 0208、および JIS X 0212 に収容されている。

また、Unicode は確かに利用されつつはあるが、まだ広くは利用されておらず、旧来の電子メール・システムではある程度制限されてしまう。 さらに言えば、この文書の目的は JIS X 0212 の書き出し機能を追加することにある。

この文書では、iso-2022-jp-1 に関して、JIS X 0212 のサポートのほかには何らの情報も記述しない。

4. 解説

ISO-2022-JP-1 のテキストでは、メッセージの当初の文字コードは ASCII である。 "double-byte-seq" (「ESC "$" "B"」か「ESC "$" "@"」か「ESC "$" "(" "D"」、「形式的構文」の章を参照) だけが、後続の文字が 2 バイト文字であることを示す指示子であり、別のエスケープ・シーケンスが現れるまでその効力を有する。 2 バイト文字の符号化に「ESC "$" "@"」を使用することはあまり推奨されない。 新たに実装する際には、代わりに「ESC "$" "B"」だけを用いるべきである

ISO-2022-JP-1 のテキストの最後は ASCII でなければならない。 また、各行の末尾では、行中に ASCII 文字がない場合、JIS X 0201-Roman ではなく ASCII に戻すことが強く推奨される。

ISO-2022-JP-1 は JIS X 0212 の書き出し機能を追加するために設計されたものであり、メッセージが JIS X 0212 の文字を含まない場合、ISO-2022-JP のテキストを使用しなければならない

JIS X 0201-Roman は、ASCII とは 2 字を異にしており、同一ではない。

次の表に、ISO-2022-JP-1 のテキストの中で利用することのできるエスケープ・シーケンスおよび文字集合の一覧を示す。 「登録番号」の欄は、ISO/IEC 2022 の符号構造において 2 バイト表意文字の符号化を可能にする ISO 2375 Register の登録番号である。

登録番号  文字集合  エスケープ・シーケンス     指示先
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
159  JIS X 0212-1990  ESC 2/4 2/8 4/4  ESC $ ( D  G0

その他の制約については次の「形式的構文」で与える。

5. 形式的構文

ここで用いる表記上の規約は、STD 11 すなわち RFC 822 [RFC822] において用いられているものと同一である。

アステリスク (*) の規約は次のとおり。

l*m something

これは、少なくとも l 個、多くとも m 個の something を意味する。 l および m はそれぞれ 0 および無限大のデフォルト値をとる。

iso-2022-jp-1-text  = *( line CRLF ) [line]

line                = (*single-byte-char *segment
                     single-byte-seq *single-byte-char) /
                     *single-byte-char

segment             = single-byte-segment / double-byte-segment

single-byte-segment = single-byte-seq *single-byte-char
double-byte-segment = double-byte-seq *(one-of-94 one-of-94)

reset-seq           = ESC "(" ( "B" / "J" )
single-byte-seq     = ESC "(" ( "B" / "J" )
double-byte-seq     = (ESC "$" ( "@" / "B" )) /
                           (ESC "$" "(" "D" )

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 も含まない>

6. セキュリティーに関する考慮事項

このメモではセキュリティー上の既知の問題は提起しない。

7. MIME に関する考慮事項

コンテントにおける日本語の符号化方式用の名称は "ISO-2022-JP-1" である。 この名称を MIME のメッセージ形式において用いる場合、次のようになる。

Content-Type: text/plain; charset=iso-2022-jp-1

ISO-2022-JP-1 は 7 ビットの符号化法であるため、Content-Transfer-Encoding ヘッダーの指定による別形式での符号化は必要ない。 また、Based64 符号化法ないし Quoted-Printable 符号化法を適用すると、現行のソフトウェアではメッセージの復号に失敗してしまうかもしれない。

ISO-2022-JP-1 は MIME ヘッダーにも用いることができる。 ISO-2022-JP-1 はまた、Base64 符号化法ないし Quoted-Printable 符号化法とともに用いることもできる。

8. 補足情報

メール・システムを Unicode の書き出しができるものとする場合は、ISO-2022-JP-1 のテキストに加えて Unicode のテキストも書き出せるようにすることが推奨される。 また、後方互換の理由から、ISO-2022-JP-1 のテキストに加えて ISO-2022-JP のテキストも書き出せるようにすることが強く推奨される。

メール・システムの中には、[RFC 822] および [RFC 1521](2) で定義されている ‘parameter’ や ‘value’ に 8 ビット文字を書き出すものもあるが、いかなる 8 ビット文字もそれらのフィールドで使用してはならない。 今後、メール・システムを実装する場合は、ただ相互運用のためだけに、それをサポートすべきである

9. 参考文献

[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".

[RFC-822]
Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.

[RFC-1468]
Murai, J., Crispin, M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, June 1993.

[RFC-1766]
Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.

[RFC-2045]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.

[RFC-2046]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.

[RFC-2047]
Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC 2047, December 1996.

[RFC-2048]
Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, December 1996.

[RFC-2049]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996.

[RFC-2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.

著者連絡先

Kenzaburo Tamaru (田丸健三郎)
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399

EMail: kenzat@microsoft.com

著作権宣言全文

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書およびその翻訳は、全体または一部について、いかなる種類の制約も受けることなく、複製および他者への供与ができるほか、これについて注釈し、または他の方法で解説し、あるいはその実装を助ける派生的著作を用意、複製、出版、および配布することができる。 ただし、上記の著作権表示およびこの一節が当該の複製および派生的著作のすべてに含まれるものとする。 一方、この文書自体は、著作権表示を削除したり Internet Society ないし他のインターネット機関への参照を削除したりするなどのいかなる方法によっても改変してはならない。 ただし、インターネット標準の開発の目的のために必要とされるインターネット標準化プロセスの著作権の手続きに従う場合、および英語以外の言語に翻訳するのに必要とされる場合を除く。

上で与えた制限つきの許諾は恒久のものであり、Internet Society またはその後継者ないし譲受人によって取り消されることはない。

この文書およびここに含まれる情報は「現状有姿」方式で提供されるものであり、Internet Society および Internet Engineering Task Force は、明示的であるか黙示的であるかを問わず、一切を保証しないここでいう保証には、ここにある情報の利用がいかなる権利をも侵害しないという保証や、特定の目的に対する市場性ないし適合性についての暗黙の保証が含まれるが、それらのみに限定されない

 


【訳注】

(1)  RFC 1036: "Standard for Interchange of USENET Messages", M. Horton & R. Adams, December 1987.
(2)  ここは [RFC 1521] の代わりに [RFC-2045] とするのが正しい。

※ 原文は誤謬と矛盾とに満ちた極めて杜撰な文書であるが、いちいち訂正はしていない。

 



2007年03月25日公開
2008年04月06日更新
Translated by: Mendoxi (面独斎)
mendoxi@cam.hi-ho.ne.jp