この規格ページの目次
4
X 5810-3 : 2008
長さの制限は,ネットワーク間のメールゲートウェイを通る相互運用性を容易にするため,及び,トー
クンが“符号化語”であるか何かほかのものであるか決めることができるようになる前の,最後の“・=”区
切り子を探している間に,ヘッダの構文解析器が費やさなければならない先読みの量に制限を課するため
である。
注記 “encoded-word”は,RFC 822構文解析器によって,“atom”として認識されるように設計され
た。その結果として,符号化されないSPACE及びHTABのような空白文字は,“encoded-word”
中で禁止される。例えば,次の文字列は,RFC 822構文解析器による単一の“atom”としてで
はなく,又は,“encoded-words”を理解する構文解析器による“encoded-word”としてではなく,
四つの“atom”として構文解析される。
=・iso-8859-1・q・this is some text・=
文字列“this is some text”を符号化する正しい方法は,SPACE文字も同様に符号化することであ
り,例えば,次のようになる。
=・iso-8859-1・q・this=20is=20some=20text・=
“encoded-text”中に現れてもよい文字は,箇条5に規定する規則によって,更に制限される。
3 文字集合
“encoded-word”の“charset”部分は,符号化されていないテキストに関連する文字集合を指定する。
“text/plain”本体部分のMIME“charset”パラメタ中に許される任意の文字集合名,又は,MIMEのtext/plain
内容型で使うためにIANAで登録された任意の文字集合名が,“charset”として可能とする。
幾つかの文字集合は,“ASCIIモード”及び他のモードを切り換える,コード切換技法を使う。
“encoded-word”中の符号化されていないテキストが,ASCIIモードから抜ける切換を行うcharset解釈器
を起動する列を含む場合,“encoded-word”の最後に再びASCIIモードを選択する追加の制御コードを含ま
なければならない。この規則は,単一のヘッダフィールド内の直前の“encoded-word”を含み,それぞれ
の“encoded-word”に別々に適用される。
“encoded-word”中でテキストを表現する複数の文字集合を使う可能性がある場合で,メッセージの送
信者と受信者との間の私的合意がない場合,他の文字集合に優先してISO-8859-Xの一連のものの中から使
用することを推奨する。
4 符号化
始めに規定する“encoding”の合法的な値は,“Q”及び“B”とする。これらの符号化については,次に記述
される。“Q”符号化は,符号化される文字のほとんどがASCII文字集合に含まれる場合に,使用が推奨さ
れ,それ以外の場合は,“B”符号化を使用するのがよい。このことにはかかわらず,“encoded-word”を認
識すると宣言するメール読みプログラムは,サポートするすべての文字集合に対して,いずれの符号化も
受け入れなければならない。
“encoded-text”には,印字可能なASCII文字のサブセットだけを用いてよい。スペース文字及びタブ文
字は許容されないので,“encoded-word”の始まり及び終わりは明白である。“・”文字は,“encoded-word”
内の多くの部分を他の部分と分離するのに使われるから,“encoded-text”部分には現れることはできない。
他の文字は,特定の文脈では,不正である。例えば,Fromヘッダフィールドの中の,アドレスに先行する
“phrase”内の“encoded-word”は,RFC 822で規定されている“specials”のいずれも含んではならない。最
後に,ネットワーク間のメールゲートウェイを通過するメッセージの信頼性を保証するために,幾つかの
――――― [JIS X 5810-3 pdf 6] ―――――
5
X 5810-3 : 2008
文脈では特定の文字は許されない。
“B”符号化はこれらの要求に自動的に従うことになる。“Q”符号化は,Subjectなどのメッセージヘッダ中
の転送に重大ではない場所では,広い範囲の印字可能文字の使用を許容し,他の場所では,それより狭い
範囲の文字の使用を許容する。
4.1 “B”符号化
“B”符号化は,JIS X 5810-1で定義される“BASE64”符号化と同一とする。
4.2 “Q”符号化
“Q”符号化は,JIS X 5810-1で定義される“quoted-printable”内容転送符号化と似ている。ASCII端末で,
復号することなしに解読されるほとんどのASCII文字を許すように設計されている。
a) どの8 bit値も“=”に続く2けたの16進数字によって表現してよい。例えば,ISO-8859-1が文字集合と
して使われている場合,“=”文字は“=3D”で,SPACEは“=20”で符号化される。16進数字の“A”から“F”
には大文字を使ったほうがよい。
b) 8 bitの16進値の20(例えば,ISO-8859-1ではSPACE)は,“”(下線,ASCIIの95)として表して
よい。この文字は,幾つかのネットワーク間のメールゲートウェイを通過しないが,この符号化をサ
ポートしないメール読みプログラムでの“Q”符号化されたデータの見やすさを,非常に高める。使わ
れている文字集合中でSPACE文字が異なるコード位置を占めている場合であっても,“”はいつでも
16進の20を表すことに注意する。
c) “=”,“・”及び“”(下線)以外の印字可能なASCII文字に関連付けられる8 bit値は,それらの文字で
表現してよい。ただし,制限については箇条5を参照する。特に,SPACE及びTABは,符号化語内
でそれら自体によって表されてはならないものとする。
5 メッセージヘッダ中の符号化語の使用
“encoded-word”は,メッセージヘッダ中又は本体部分ヘッダ中に,次の規則に従って現れてよい。
a) “encoded-word”は,任意の主題ヘッダフィールド又はコメントヘッダフィールド,任意の拡張メッ
セージヘッダフィールド,フィールド本体が“*text”として定義されるための任意のMIME本体部分
フィールドの中のRFC 822で定義されている“text”トークンを置き換えてよい。“encoded-word”は,
“X-”で始まる利用者定義の,任意のメッセージヘッダフィールド又は本体部分ヘッダフィールド内に
も現れてよい。
普通のASCIIテキスト及び“encoded-word”は,同じヘッダフィールド中に両方現れてもよい。し
かし,“*text”として定義されたヘッダフィールド中に現れる“encoded-word”は,隣の“encoded-word”
又は“text”と,“linear-white-space”とによって分離されていなければならない。
b) “encoded-word”は,“(”及び“)”で区切られる“comment”中,すなわち“ctext”が許されるところに
はどこにでも,現れてよい。もう少し正確にいうと,“comment”のRFC 822での拡張BNF定義は,
次のように改正される。
comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
“comment”中に現れる“Q”符号化された“encoded-word”は,“(”,“)”又は“ " ”を含んではならず,
“comment”中に現れる“encoded-word”は,隣の“encoded-word”又は“ctext”と,“linear-white-space”
とによって分離されていなければならない。
“comment”は,“構造化された”フィールド本体の中でだけ認識されることに注意することが重要
である。“*text”として定義された本体のフィールド中の“(”及び“)”は,注釈区切り子としてではなく,
――――― [JIS X 5810-3 pdf 7] ―――――
6
X 5810-3 : 2008
普通の文字として扱われ,この箇条の規則a)が適用される(RFC 822の3.1.2及び3.1.3参照)。
c) “encoded-word”は,“phrase”中の“word”実体の置換え,例えば,Fromヘッダ,Toヘッダ又はCc
ヘッダ中のアドレスに先行するもの,として存在してよい。したがって,RFC 822からの“phrase”の
拡張BNF定義は次となる。
phrase = 1*( encoded-word / word )
この場合,“Q”符号化された“encoded-word”中で使ってもよい文字の集合は,次に制限される。
大文字及び小文字のASCII文字,数字,“!”,“*”,“+”,“-”,“/”,“=”及び
“”(アンダスコア, ASCIIの95)
“phrase”中に現れる“encoded-word”は,隣接する“word”,“text”又は“special”と,“linear-white-space”
とによって分離されなければならない。
“encoded-word”が現れてよい場所は,これらだけとする。特に,
1) “encoded-word”は,“addr-spec”のどの場所にも現れてはならない。
2) “encoded-word”は,“quoted-string”中に現れてはならない。
3) “encoded-word”は,Receivedヘッダフィールド中に使ってはならない。
4) “encoded-word”は,MIMEのContent-Typeフィールド又はContent-Dispositionフィールドのパラメ
タ中に使ってはならないし,“comment”又は“phrase”を除いて,構造化されたフィールド本体の
どこにも使ってはならない。
“encoded-word”中の“encoded-text”は自分自身に含まれなければならない。すなわち,“encoded-text”
は,一つの“encoded-word”からもう一つの“encoded-word”に続いてはならない。これは,“B” “encoded-word”
の“encoded-text”部分が4文字の長さの倍数となることを示唆する。“Q” “encoded-word”では,“encoded-text”
部分中に現れるどの“=”文字も二つの16進文字によって後続される。
それぞれの“encoded-word”は整数個のオクテットを符号化しなければならない。それぞれの
“encoded-word”中の“encoded-text”は,指定された符号化に従って整形されなければならない。すなわ
ち,“encoded-text”は,次の“encoded-word”に続いてはならない。例えば,“=・charset・Q・=・==・charset・Q・AB・=”
は不正である。なぜならば,同じ“encoded-word”中の二つの16進数字“AB”は“=”に続かなければならな
いからである。
それぞれの“encoded-word”は,整数個の文字を表現しなければならない。複数オクテット文字は,隣
接する“encoded-word”へ分割してはならない。
印字可能な文字データ及び空白文字データだけを,この体系を使って符号化するほうがよい。しかし,
これらの符号化体系は,任意のオクテット値の符号化を許すので,この復号を実装するメール読みプログ
ラムは,受信者の端末で復号されたデータの表示に,望まない副作用を引き起こさないことを保証するほ
うがよい。
これらの方法を非テキストデータ(例えば,画像又は音)を符号化するために使用することを,この規
格では定義しない。純粋なASCII文字の列を表現するための“encoded-word”の使用は,許されてはいる
が,しないほうがよい。まれではあるが,“encoded-word”のように見える普通のテキストを符号化する必
要があるかもしれない。
6 メールリーダによる“encoded-word”のサポート
6.1 メッセージヘッダ中の“encoded-word”の認識
メール読みプログラムは,“encoded-word”を正しく認識するため,RFC 822の規定に従って,メッセー
――――― [JIS X 5810-3 pdf 8] ―――――
7
X 5810-3 : 2008
ジヘッダ及び本体部分ヘッダを,構文解析しなければならない。
“encoded-word”は,次のように認識される。
a) “*text”として定義されるメッセージヘッダフィールド又は本体部分ヘッダフィールド,利用者定義
のヘッダフィールドは,次のように構文解析するのがよい。フィールド本体の開始及び毎回の
“linear-white-space”の直後で,“linear-white-space”を含まない75文字までのそれぞれの印字可能文
字の列が箇条2で規定する構文規則に従った“encoded-word”であるかどうか検査するほうがよい。
それ以外の印字可能文字の列は,普通のASCIIテキストとして扱ったほうがよい。
b) “*text”として定義されていないすべてのヘッダフィールドは,そのヘッダフィールドのための構文
規則に従って構文解析するのがよい。しかし,“phrase”中に現れるすべての“word”は,箇条2で規
定する構文規則に合う場合には,“encoded-word”として扱ったほうがよい。そうでない場合,それは,
普通のASCIIテキストとして扱ったほうがよい。
c) “comment”中では,“linear-white-space”を含まない75文字までの印字可能文字の列は,箇条2で規
定する構文規則に合う場合には,“encoded-word”として扱ったほうがよい。そうでない場合,それは,
普通のASCIIテキストとして扱ったほうがよい。
d) この規格に従って解釈される“encoded-word”のためには,MIME-Versionヘッダフィールドが提示さ
れることは要求されない。その一つの理由は,メールリーダが,“encoded-word”を含むかもしれない
行を表示する前に,メッセージヘッダ全体を構文解析することは期待されないためである。
6.2 “encoded-word”の表示
認識されるすべての“encoded-word”は復号され,その結果の符号化されていないテキストは,可能で
あれば,元来の文字集合で表示される。
注記 符号化語の復号及び表示は,構造化された本体が構文解析されてトークンになった後に,実行
される。したがって,取り囲むテキスト中の“special”文字と区別できない,符号化語中の
“special”文字は,表示されるときに,隠すことができる。この理由及びその他の理由によっ
て,“encoded-word”を含むメッセージヘッダを,RFC 822メール読みプログラムで構文解析す
ることができる符号化されていない形式に翻訳することは,一般には,できない。
複数の“encoded-word”を含む特定のヘッダフィールドを表示するとき,隣接する“encoded-word”の対
を分離するすべての“linear-white-space”は,無視される。これは,符号化されていないテキスト中の空白
がある場所で“encoded-word”を分離しなくてはならないことなしに,符号化されていないテキストの長
い文字列を表すために複数の“encoded-word”を使用することを許容するためである。
将来的に他の符号化が定義されて,メール読みプログラムが使われている符号化をサポートしない場合,
(a)“encoded-word”を通常のテキストとして表示するか,又は(b)テキストを復号できないことを示す適切
なメッセージに代えるかのどちらかをしてよい。
メールリーダが使われている文字集合をサポートしないとき,次のいずれでもよい。
a) “encoded-word”を通常のテキストとしてヘッダ中に表示する。
b) 利用可能な文字を使って表示する最大限の努力をする。
c) 復号されたテキストが表示できないことを示す適切なメッセージに代える。
使われている文字集合が,コード切替え技法を採用している場合,符号化されたテキストの表示は,暗
黙に“ASCIIモード”で始まるとする。さらに,メール読みプログラムは,“encoded-word”が表示された
後に,出力機器が再び“ASCIIモード”に戻ることを保証しなければならない。
6.3 誤った形式の“encoded-word”に対するメールリーダ処理
――――― [JIS X 5810-3 pdf 9] ―――――
8
X 5810-3 : 2008
箇条2に定義されている構文に適合する“encoded-word”が,使用された符号化の規則では誤った形式
になっている可能性がある。例えば,次のような場合である。
a) 特定の符号化では正当でない文字(例えば,“B”符号化中の“-”,若しくは,“B”符号化又は“Q”符号化
のいずれかの中のSPACE又はHTAB)を含んで,“encoded-word”が形式を誤っている場合。
b) 非整数個の文字又はオクテットを符号化して“encoded-word”が,形式を誤っている場合。
メールリーダは,形式が誤っている“encoded-word”に関連するテキストを表示しようとする必要はな
い。しかし,メールリーダは,“encoded-word”が誤った形式をしているからという理由で,メッセージの
表示又は処理を妨げてはならない。
7 適合性
この規格に適合すると主張するメール作成プログラムは,“=・”で始まり“・=”で終わる“*text”又は“*ctext”
内の空白でない印字可能なASCII文字の列が,正当な“encoded-word”であることを保証しなければなら
ない。ここで,“始まる”とは,“linear-white-space”の直後又は“*ctext”中の“encoded-word”では“(”の
直後の,フィールド本体の開始を意味し,“終わる”とは,“linear-white-space”の直前又は“*ctext”中の
“encoded-word”では“)”の直前の,フィールド本体の終わりを意味する。さらに,“=・”で始まり“・=”で終
わる“phrase”中のすべての“word”は,正当な“encoded-word”でなければならない。
この規定に適合すると主張するメール読みプログラムは,メッセージヘッダ中の適切な位置に現れると
きにはいつでも,箇条6に規定する規則に従って,“encoded-word”を“text”,“ctext”又は“word”と区
別できなければならない。そのプログラムは,サポートするすべての文字集合に対して,“B”符号化及び“Q”
符号化の両方をサポートしなければならない。そのプログラムは,文字集合が“US-ASCII”ならば,符号化
されていないテキストを表示できなければならない。ISO-8859-X文字集合に対しては,メール読みプログ
ラムは,少なくとも,ASCII集合にもある文字を表示できなければならない。
8 例
“encoded-word”を含むメッセージヘッダの例は次のとおりである。
From: =・US-ASCII・Q・KeithMoore・= <moore@cs.utk.edu>
To: =・ISO-8859-1・Q・KeldJ=F8rnSimonsen・= <keld@dkuug.dk>
CC: =・ISO-8859-1・Q・Andr=E9・= Pirard <PIRARD@vm1.ulg.ac.be>
Subject: =・ISO-8859-1・B・SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=・=
=・ISO-8859-2・B・dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==・=
注記 上記のSubjectフィールドの最初の“encoded-word”では,それぞれの“encoded-word”が自己
完結していなければならないので(“=”文字は2オクテットを表す四つのbase64文字のかたま
りを完了しなければならない。),“encoded-text”の終わりにある最後の“=”は必要である。2番
目の“encoded-word”が最初とは異なる“charset”を使うのでなければ,最初の“encoded-word”
で追加のオクテットが符号化されることはできた(符号化語はちょうど三つの符号化されたオ
クテットの倍数となる。)。
From: =・ISO-8859-1・Q・OlleJ=E4rnefors・= <ojarnef@admin.kth.se>
To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
Subject: Time for ISO 10646・
――――― [JIS X 5810-3 pdf 10] ―――――
次のページ PDF 11
JIS X 5810-3:2008の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.110 : 情報通信ネットワーキング
JIS X 5810-3:2008の関連規格と引用規格一覧
- 規格番号
- 規格名称
- JISX5810-1:2008
- 多目的インターネットメール拡張(MIME)―第1部:インターネットメッセージ本体のフォーマット