[要約] RFC 2237は、インターネットメッセージのための日本語文字エンコーディングに関する規格です。その目的は、日本語のテキストを効果的にエンコードし、インターネット上での正確な伝達を保証することです。
Network Working Group K. Tamaru
Request for Comments: 2237 Microsoft Corporation
Category: Informational November 1997
Japanese Character Encoding for Internet Messages
インターネットメッセージの日本語文字エンコーディング
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
This memo defines an encoding scheme for the Japanese Characters, describes "ISO-2022-JP-1", which is used in electronic mail [RFC-822], and network news [RFC 1036]. Also this memo provides a listing of the Japanese Character Set that can be used in this encoding scheme.
このメモは、日本語文字のエンコードスキームを定義し、電子メール[RFC-822]やネットワークニュース[RFC 1036]で使用される「ISO-2022-JP-1」について説明しています。また、このメモは、このエンコード方式で使用できる日本語の文字セットのリストを提供します。
This document uses terms that appear in capital letters to indicate particular requirements of this specification. Those terms are "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY". The meaning of each term are found in [RFC-2119]
このドキュメントでは、大文字で表示される用語を使用して、この仕様の特定の要件を示しています。それらの用語は、「必須」、「必須」、「必須ではない」、「必須ではない」、および「MAY」です。各用語の意味は[RFC-2119]にあります
RFC 1468 defines the way Japanese Characters are encoded, likewise what this memo defines. It defines the use of JIS X 0208 as the double-byte character set in ISO-2022-JP text.
RFC 1468は、このメモが定義するのと同様に、日本語の文字がエンコードされる方法を定義します。 JIS X 0208の使用をISO-2022-JPテキストの2バイト文字セットとして定義しています。
Today, many operating systems support proprietary extended Japanese characters or JIS X 0212, This includes the Unicode character set, which does not conform to JIS X 0201 nor JIS X 0208. Therefore, this limits the ability to communicate and correspond precise information because of the limited availability of Kanji characters. Fortunately JIS (Japanese Industry Standard) defines JIS X 0212 as "code of the supplementary Japanese graphic character set for information interchange". Most Japanese characters which are used in regular electronic mail in most cases can be accommodated in JIS X 0201, JIS X 0208 and JIS X 0212.
今日、多くのオペレーティングシステムは、独自の拡張日本語文字またはJIS X 0212をサポートしています。これには、JIS X 0201またはJIS X 0208に準拠していないUnicode文字セットが含まれます。漢字の数に限りがあります。幸い、JIS（日本工業規格）では、JIS X 0212を「情報交換のための補足的な日本語グラフィック文字セットのコード」と定義しています。通常の電子メールで使用されるほとんどの日本語文字は、JIS X 0201、JIS X 0208、JIS X 0212に対応しています。
Also it is recognized that there is a tendency to use Unicode, however, Unicode is not yet widely used and there is a certain limitation with old electronic mail system. Furthermore, the purpose of this comment is to add the capability of writing out JIS X 0212.
また、Unicodeを使用する傾向があることも認識されていますが、Unicodeはまだ広く使用されておらず、古い電子メールシステムには一定の制限があります。さらに、このコメントの目的は、JIS X 0212を書き出す機能を追加することです。
This comment does not describe any representation of iso-2022-jp-1 version information in addition to JIS X 0212 support.
このコメントでは、JIS X 0212のサポートに加えて、iso-2022-jp-1バージョン情報の表現については説明していません。
In "ISO-2022-JP-1" text, the initial character code of the message is in ASCII. The "double-byte-seq"(see "Format Syntax" section) (ESC "$" "B" / ESC "$" "@" / ESC "$" "(" "D") is the only designator that indicates that the following character is double-byte, and it is valid until another escape sequence appears. It is very discouraged to use (ESC "$" "@") for double byte character encoding, new implementation SHOULD use only (ESC "$" "B") for double byte encoding instead.
「ISO-2022-JP-1」のテキストでは、メッセージの最初の文字コードはASCIIです。 「double-byte-seq」（「フォーマット構文」セクションを参照）（ESC "$" "B" / ESC "$" "@" / ESC "$" "（" "D"）は、次の文字は2バイトであり、別のエスケープシーケンスが表示されるまで有効です。2バイト文字のエンコードに（ESC "$" "@"）を使用することは非常に推奨されません。新しい実装では（ESC "$"のみを使用する必要があります「B」）代わりに2バイトエンコーディング。
The end of "ISO-2022-JP-1" text MUST be in ASCII. Also it is strongly recommended to back up to the ASCII at the end of each line rather than JIS X 0201-Roman if there is any none ASCII character in middle of a line.
「ISO-2022-JP-1」テキストの最後はASCIIである必要があります。また、行の途中にASCII文字がない場合は、JIS X 0201-Romanではなく、各行の終わりでASCIIにバックアップすることを強くお勧めします。
Since "ISO-2022-JP-1" is designed to add the capability of writing out JIS X 0212, if the message does not contain none of JIS X 0212 characters. "ISO-2022-JP" text MUST BE used.
「ISO-2022-JP-1」は、メッセージにJIS X 0212文字が含まれていない場合に、JIS X 0212を書き出す機能を追加するように設計されているためです。 「ISO-2022-JP」のテキストを使用する必要があります。
JIS X 0201-Roman is not identical to the ASCII with two different characters.
JIS X 0201-Romanは、2つの異なる文字を持つASCIIとは異なります。
The following list are the escape sequences and character sets that can be used in "ISO-2022-JP-1" text. The registered number in the ISO 2375 Register which allow double-byte ideographic scripts to be encoded within ISO/IEC 2022 code structure is indicated as reg# below.
次のリストは、「ISO-2022-JP-1」テキストで使用できるエスケープシーケンスと文字セットです。 ISO 2375レジスターに登録されている番号で、2バイトの表意文字をISO / IEC 2022コード構造内でエンコードできるようにするには、以下のreg＃を使用します。
reg# character set ESC sequence designated to 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 Other restrictions are given in the Formal Syntax below.
reg＃文字セット6に指定されたESCシーケンス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その他の制限は公式に記載されています以下の構文。
The notational conventions used here are identical to those used in STD 11, RFC 822 [RFC822].
ここで使用されている表記法は、STD 11、RFC 822 [RFC822]で使用されているものと同じです。
The * (asterisk) convention is as follows: l*m something meaning at least l and at most m something, with l and m taking default values of 0 and infinity, respectively.
*（アスタリスク）の規則は次のとおりです。l* m何かは少なくともlと多くてもmの何かを意味し、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;( Octal, Decimal.)
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 = <any one of 94 values>;(41-176,33.-126.)
one-of-96 = <any one of 96 values>;(40-177,32.-127.)
7BIT = <any 7-bit value>;(0-177,0.-127.)
single-byte-char = <any 7BIT, including bare CR & bare LF,
but NOT including CRLF, and not including
ESC, SI, SO>
This memo raises no known security issues.
このメモは既知のセキュリティ問題を引き起こしません。
The name to be used for the Japanese encoding scheme in content is "ISO-2022-JP-1". When this name is used in the MIME message form, it would be:
コンテンツで日本語のエンコード方式に使用される名前は「ISO-2022-JP-1」です。この名前をMIMEメッセージフォームで使用すると、次のようになります。
Content-Type: text/plain; charset=iso-2022-jp-1
Since the "ISO-2022-JP-1" is 7bit encoding, it will be unnecessary to encode in another format by specifying the "Content-Transfer-Encoding" header. Also applying Based64 or Quoted-Printable encoding MAY cause today's software to fail to decode the message.
「ISO-2022-JP-1」は7bitエンコーディングなので、「Content-Transfer-Encoding」ヘッダを指定して別のフォーマットでエンコードする必要はありません。また、Based64またはQuoted-Printableエンコーディングを適用すると、今日のソフトウェアがメッセージのデコードに失敗する場合があります。
"ISO-2022-JP-1" can be used in MIME headers. Also "ISO-2022-JP-1" text can be used with Base64 or Quoted-Printable encoding.
「ISO-2022-JP-1」は、MIMEヘッダーで使用できます。また、「ISO-2022-JP-1」テキストは、Base64またはQuoted-Printableエンコーディングで使用できます。
As long as mail systems are capable of writing out Unicode, it is recommended to also write out Unicode text in addition to "ISO-2022-JP-1" text. Also writing out "ISO-2022-JP" text in addition to "ISO-2022-JP-1" is strongly encouraged for backward compatibility reasons.
メールシステムがUnicodeを書き込める限り、「ISO-2022-JP-1」テキストに加えてUnicodeテキストも書き出すことをお勧めします。また、下位互換性の理由から、「ISO-2022-JP-1」に加えて「ISO-2022-JP」のテキストを書き込むことを強くお勧めします。
Some mail systems write out 8bits characters in 'parameter' and 'value' defined in [RFC 822] and [RFC 1521]. All 8bit characters MUST NOT be used in those fields. The implementation of future mail systems SHOULD support those only for interoperability reasons.
一部のメールシステムは、[RFC 822]と[RFC 1521]で定義されている「パラメータ」と「値」に8ビット文字を書き込みます。これらのフィールドですべての8ビット文字を使用することはできません。将来のメールシステムの実装は、相互運用性の理由でのみサポートする必要があります（SHOULD）。
[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).
[ISO2022]国際標準化機構（ISO）、「情報処理-ISO 7ビットおよび8ビットのコード化文字セット-コード拡張技術」、国際標準、Ref。 ISO 2022-1986（E）。
[ISOREG] International Organization for Standardization (ISO), "International Register of Coded Character Sets To Be Used With Escape Sequences".
[ISOREG]国際標準化機構（ISO）、「エスケープシーケンスで使用されるコード化文字セットの国際登録」。
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC-822] Crocker、D。、「Standard for the Format for ARPA Internet Text Messages」、STD 11、RFC 822、1982年8月。
[RFC-1468] Murai, J., Crispin, M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, June 1993.
[RFC-1468] Murai、J.、Crispin、M。、およびE. van der Poel、「インターネットメッセージの日本語文字エンコーディング」、RFC 1468、1993年6月。
[RFC-1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[RFC-1766] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1995年3月。
[RFC-2045] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, December 1996.
[RFC-2045] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年12月。
[RFC-2046] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, December 1996.
[RFC-2046] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年12月。
[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-2047]ムーア、K。、「多目的インターネットメール拡張（MIME）パート3：インターネットメッセージヘッダー内の非ASCIIテキストの表現」、RFC 2047、1996年12月。
[RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: MIME Registration Procedures", RFC 2048, December 1996.
[RFC-2048] Freed、N.、Klensin、J。、およびJ. Postel、「Multipurpose Internet Mail Extensions（MIME）Part Four：MIME Registration Procedures」、RFC 2048、1996年12月。
[RFC-2049] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, December 1996.
[RFC-2049] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part 5：Conformance Criteria and Examples」、RFC 2049、1996年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
Author's Address
著者のアドレス
Kenzaburo Tamaru Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
けんざぶろ たまる みｃろそｆｔ こｒぽらちおん おね みｃろそｆｔ わｙ れｄもんｄ、 わ ９８０５２ー６３９９
EMail: kenzat@microsoft.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。