>サイトトップへ >このカテゴリの一覧へ

X 5810-3:2008

(1)

目  次

ページ

序文

1

1  総則

1

1.1  適用範囲

1

1.2  概要

1

1A  引用規格

3

2  符号化語の構文

3

3  文字集合

4

4  符号化

4

4.1  “B”符号化

5

4.2  “Q”符号化

5

5  メッセージヘッダ中の符号化語の使用

5

6  メールリーダによる“encoded-word”のサポート

6

6.1  メッセージヘッダ中の“encoded-word”の認識

6

6.2  “encoded-word”の表示

7

6.3  誤った形式の“encoded-word”に対するメールリーダ処理

7

7  適合性

8

8  例

8

9  セキュリティへの考慮

10

附属書 A(参考)RFC 1522 からの変更(順不同)

11

附属書 B(参考)RFC 1521, 1522 及び 1590 からの変更点

12

附属書 C(参考)参考文献

14


 
X 5810-3:2008

(2)

まえがき

この規格は,工業標準化法第 12 条第 1 項の規定に基づき,財団法人日本規格協会(JSA)から,工業標準

原案を具して日本工業規格を制定すべきとの申出があり,日本工業標準調査会の審議を経て,経済産業大

臣が制定した日本工業規格である。

この規格は,著作権法で保護対象となっている著作物である。

この規格の一部が,特許権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に

抵触する可能性があることに注意を喚起する。経済産業大臣及び日本工業標準調査会は,このような特許

権,出願公開後の特許出願,実用新案権又は出願公開後の実用新案登録出願に係る確認について,責任は

もたない。

JIS X 5810 の規格群には,次に示す部編成がある。

JIS

X

5810-1  第 1 部:インターネットメッセージ本体のフォーマット

JIS

X

5810-2  第 2 部:メディア型

JIS

X

5810-3  第 3 部:非 ASCII テキストへのメッセージヘッダ拡張

JIS

X

5810-5  第 5 部:適合基準


日本工業規格

JIS

 X

5810-3

:2008

多目的インターネットメール拡張(MIME)−

第 3 部:非 ASCII テキストへのメッセージヘッダ拡張

Multipurpose Internet Mail Extensions (MIME)−

Part 3: Message Header Extensions for non-ASCII text

序文

この規格は,1996 年 11 月に Internet Engineering Task Force (IETF)から公表された RFC 2047,Multipurpose

Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text を基に,技術的内容

及び構成を変更することなく作成した日本工業規格である。

なお,この規格で側線を施してある箇所は,RFC 2047 にない事項である。

インターネット公式プロトコル規定 STD 11 である RFC 822 では,US-ASCII メッセージヘッダについて

多くの詳細を規定したメッセージ表現プロトコルを定義しているが,メッセージ内容,すなわち,メッセ

ージ本体については,構造のない US-ASCII テキストだけとしている。JIS X 5810 の規格群は,多目的イ

ンターネットメール拡張又は MIME と総称され,次のことを可能とするために,メッセージのフォーマッ

トを再定義する。

a) US-ASCII 以外の文字集合でのテキストのメッセージ本体

b)  非テキストのメッセージ本体のための異なるフォーマットの拡張集合

c)  マルチパートのメッセージ本体

d) US-ASCII 以外の文字集合でのテキストのヘッダ情報

MIME を規定する JIS X 5810 の規格群は,RFC 934,STD 11 及び RFC 1049 に文書化されている初期の

成果に基づくが,それらを拡張及び改正する。RFC 822 では,メッセージ本体についてはごくわずかに示

しているだけなので,JIS X 5810 の規格群の大部分は,RFC 822 の改正というより,RFC 822 を補う。

1

総則

1.1

適用範囲

この規格は,JIS X 5810 の規格群の第 3 部であり,インターネットメールヘッダフィールドの中で非

US-ASCII データを可能にするための RFC 822 の拡張について規定する。

注記  JIS X 5810 の規格群の第 1 部(JIS X 5810-1)の原規定は RFC 2045,第 2 部(JIS X 5810-2)の原規

定は RFC 2046,

第 3 部(JIS X 5810-3)の原規定は RFC 2047,

第 5 部(JIS X 5810-5)の原規定は RFC

2049 である。RFC 2045,RFC 2046,RFC 2047 及び RFC 2049 は,RFC 1521,RFC 1522 及び RFC

1590 の改正であって,RFC 1521,RFC 1522 及び RFC 1590 は RFC 1341 及び RFC 1342 の改正

であった。

附属書 に,過去の版との違い及び変更について記載する。

1.2

概要

JIS X 5810-1 は,多くの文字集合で符号化されたテキスト本体部分を表すための機構を,そのような本



X 5810-3:2008

体部分を印字可能な US-ASCII 文字の列として符号化する方法とともに,規定している。この規格は,既

存のメッセージ処理ソフトウェアを混乱させないような方法で,RFC 822 メッセージヘッダの多くの部分

での非 ASCII テキストの符号化を許すために,JIS X 5810-1 に規定されているものと類似の技法について

記述する。

JIS X 5810-1 に記述されている符号化技法と同様,ここで概要を示す技法は,既存のインターネットメ

ール処理プログラムの癖に妨害されないような方法で,メッセージヘッダ中に非 ASCII 文字を使用するこ

とを許すように,設計された。特に,幾つかのメール中継プログラムは,次のことをすることが知られて

いる。

a)  幾つかのメッセージヘッダフィールドを削除する。

b) To 又は Cc フィールド中のアドレスの順番を並べ替える。

c)  ヘッダフィールドの上下の順番を並べ替える。

d)  元のメッセージでされていたのとは別の場所で,メッセージヘッダを折りたたむ。

加えて,幾つかのメール読みプログラムでは,RFC 822 に従った合法的なものであっても,“<”,“,”,“:”

などの特別な文字を“隠す”ために逆スラッシュ引用を使用したメッセージ,又は他のあまり使われない

機能を活用したメッセージを,正しく構文解析することが難しいということが知られている。

これらのプログラムが RFC 822 ヘッダを正しく解釈しないことは不幸であるが,これらのプログラムを

“遮断”することは,インターネットメールシステムに深刻な運用上の問題を引き起こすことになる。そ

のため,この規格で記述される拡張は,RFC 822 のあまり使われていない機能には頼らない。

その代わり,

“符号化語( encoded-word )”として知られる,確実な“普通”の印字可能な ASCII 文字の列

が,符号化されたデータとしての利用に確保された。符号化語の構文は,メッセージヘッダ中の通常のテ

キストとして“偶然”に現れないようにする。さらに,符号化語に使われる文字は,符号化語が現れた文

脈で,特殊な意味をもたないものに制限される。

一般に,

“符号化語”は,“=?”で始まり,“?=”で終わり,中間に二つの“?”をもつ,印字可能な ASCII 文

字の列とする。それは,文字集合及び符号化方法を指定し,その符号化方法の規則に従って ASCII 図形文

字として符号化された原テキストも含む。

この規定を実装するメール作成ソフトウェアは,ヘッダに非 ASCII テキストを入力する手段を提供する

が,メッセージヘッダにそれらを挿入する前に,これらのフィールド又はこれらのフィールドの適切な部

分を符号化語に翻訳する。

この規定を実装するメール読みプログラムは,メッセージヘッダのある部分に現れたとき,符号化語を

認識する。符号化語をそのまま表示する代わりに,指示された文字集合で元のテキストに逆符号化して表

示する。

注記  この規格は,RFC 822 及び JIS X 5810-1 で定義された記法及び語に深く依存する。特に,RFC 822

由来の終端記号又は非終端記号の多くが,この規格で定義するヘッダ拡張のための文法で使わ

れ,同様に,この規格で使われる拡張 BNF のための構文が RFC 822 で定義される。RFC 822

で定義された記号のうち,この規格で参照するものは“addr-spec”“atom”“CHAR”“comment”

“CTLs”

“ctext”

“linear-white-space”

“phrase”

“quoted-pair”

“quoted-string”

“SPACE”及

び“word”である。このプロトコル拡張の実装を成功させるためには,これらの語の RFC 822

における定義に,注意深く目を向けることが必要である。

この規格で,“ASCII”という語が現れたら,それは,ANSI X3.4-1986,“7-Bit American Standard Code for

Information Interchange”を参照する。この文字集合のための MIME の charset 名は,“US-ASCII”である。簡


3

X 5810-3:2008

潔さと RFC 822 との一貫性のため,この規格で,特には MIME の charset 名を参照せずに,“ASCII”という

語を使う。しかし,MIME メッセージ及び本体部分ヘッダ中では,文字集合名は“US-ASCII”とつづられな

ければならないことに,実装者は注意しなければならない。

この規格は,メッセージヘッダ中に非 ASCII テキストを表現するためのプロトコルを規定する。この規

格では,“8 bit”ヘッダと純粋な ASCII ヘッダとの間の変換を定義しないし,このような変換を可能とする

ことも想定しない。

1A

引用規格

次に掲げる規格は,この規格に引用されることによって,この規格の規定の一部を構成する。これらの

引用規格は,その最新版(追補を含む。

)を適用する。

JIS X 5810-1  多目的インターネットメール拡張(MIME)−第 1 部:インターネットメッセージ本体の

フォーマット

注記 RFC

2045  "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message

Bodies", November 1996 が,この規格に一致している。

ISO/IEC 8859 (All parts)  Information technology−8-bit single-byte coded graphic character sets

2

符号化語の構文

次の拡張 BNF 文法によって“encoded-word”が定義される。

“encoded-word”の要素間に空白文字が現れ

てはならないことを除き,RFC 822 の記法が使われる。

encoded-word = "=?" charset "?" encoding "?" encoded-text "?="

charset = token    ;箇条  を参照

encoding = token   ;箇条  を参照

token = 1*<SPACE, CTLs 及び especials を除く任意の CHAR>

especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "

<"> / "/" / "[" / "]" / "?" / "." / "="

encoded-text = 1*<“?”又は SPACE 以外の任意の印字可能な ASCII 文字>

   ;

箇条 5  を参照

   ;

“encoding”名及び“charset”名は大文字・小文字を区別しない。だから,charset 名“ISO-8859-1”は

“iso-8859-1”と等価であり,“Q”と名付けられた符号化は“Q”又は“q”のいずれのつづりでもよい。

“encoded-word”は,

“charset”

“encoding”

“encoded-text”及び区切り子を含んで 75 文字より長くては

ならない。75 文字の“encoded-word”に収まりきらない長いテキストを符号化することが望まれる場合,

CRLF SPACE で区切られた複数の“encoded-word”を使ってよい。

複数行ヘッダフィールドの長さに対する制限はないが,一つ以上の“encoded-word”を含むヘッダフィ

ールドのそれぞれの行は 76 文字までに制限される。



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”中に現れてもよい文字は,箇条 に規定する規則によって,更に制限される。

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”のいずれも含んではならない。最

後に,ネットワーク間のメールゲートウェイを通過するメッセージの信頼性を保証するために,幾つかの


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 値は,それらの文字で

表現してよい。ただし,制限については箇条 を参照する。特に,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”として定義された本体のフィールド中の“(”及び“)”は,注釈区切り子としてではなく,



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 の規定に従って,メッセー


7

X 5810-3:2008

ジヘッダ及び本体部分ヘッダを,構文解析しなければならない。

“encoded-word”は,次のように認識される。

a)  “*text”として定義されるメッセージヘッダフィールド又は本体部分ヘッダフィールド,利用者定義

のヘッダフィールドは,次のように構文解析するのがよい。フィールド本体の開始及び毎回の

“linear-white-space”の直後で,

“linear-white-space”を含まない 75 文字までのそれぞれの印字可能文

字の列が箇条 で規定する構文規則に従った“encoded-word”であるかどうか検査するほうがよい。

それ以外の印字可能文字の列は,普通の ASCII テキストとして扱ったほうがよい。

b)  “*text”として定義されていないすべてのヘッダフィールドは,そのヘッダフィールドのための構文

規則に従って構文解析するのがよい。しかし,

“phrase”中に現れるすべての“word”は,箇条 で規

定する構文規則に合う場合には “encoded-word”として扱ったほうがよい。そうでない場合,それは,

普通の ASCII テキストとして扱ったほうがよい。

c)  “comment”中では,“linear-white-space”を含まない 75 文字までの印字可能文字の列は,箇条 で規

定する構文規則に合う場合には “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”に対するメールリーダ処理



X 5810-3:2008

箇条 に定義されている構文に適合する“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”でなければならない。

この規定に適合すると主張するメール読みプログラムは,メッセージヘッダ中の適切な位置に現れると

きにはいつでも,箇条 に規定する規則に従って,

“encoded-word”を“text”

“ctext”又は“word”と区

別できなければならない。そのプログラムは,サポートするすべての文字集合に対して,“B”符号化及び“Q”

符号化の両方をサポートしなければならない。そのプログラムは,文字集合が“US-ASCII”ならば,符号化

されていないテキストを表示できなければならない。ISO-8859-X 文字集合に対しては,メール読みプログ

ラムは,少なくとも,ASCII 集合にもある文字を表示できなければならない。

8

“encoded-word”を含むメッセージヘッダの例は次のとおりである。

From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>

To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <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?Olle_J=E4rnefors?= <ojarnef@admin.kth.se>

To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se

Subject: Time for ISO 10646?


9

X 5810-3:2008

To: Dave Crocker <dcrocker@mordor.stanford.edu>

Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se

From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se>

Subject: Re: RFC-HDR care and feeding

From: Nathaniel Borenstein <nsb@thumper.bellcore.com>

   (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)

To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US> , Ned Freed

<ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>

Subject: Test of new header generator

 MIME-Version:

1.0

Content-type: text/plain; charset=ISO-8859-1

次の例は,構造化されたフィールド本体に現れる“encoded-word”を含むテキストがどのようであるか

を示す。“(”及び“)”が“comment”区切り子として認識されないから,

“*text”として定義されるフィール

ドとは,規則が少し異なる。箇条 の a)を参照する。

次のそれぞれの例では,

“*text”フィールド中に同じ並びが起こらない場合,

“表示される”形式は,

“符

号化された形式”と同一であることを除き,符号化語として取り扱われない。これは,次の例では符号化

語のそれぞれが,“(”又は“)”文字と隣接しているからである。

符号化形式

表示形式

(=?ISO-8859-1?Q?a?=) (a)

(=?ISO-8859-1?Q?a?= b)

(a b)

“comment”中では,空白は,

“encoded-word”と取り囲むテキストとの間に現れなければならない[箇

条 の b)]

。しかし,空白は,

“comment”を始める最初の“(”と“encoded-word”との間には必要でない。

(=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=)

(ab)

隣り合う“encoded-word”間の空白は表示されない。

(=?ISO-8859-1?Q?a?=  =?ISO-8859-1?Q?b?=)

(ab)

“encoded-word”間に複数の SPACE があっても,表示の目的のためには無視される。

(=?ISO-8859-1?Q?a?=

    =?ISO-8859-1?Q?b?=)

(ab)

“encoded-word”間の任意の量の線形空白は,一つ以上の SPACE に後続される CRLF を含んでいても,

表示の目的のためには無視される。

(=?ISO-8859-1?Q?a_b?=) (a

b)


10 
X 5810-3:2008

符号化されたテキストの部分内で表示される SPACE を生じさせるため,SPACE は,

“encoded-word”の

一部として符号化されなければならない。

(=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=)

(a b)

符号化されたテキストの二つの文字列の間に表示される SPACE を生じさせるため,SPACE は,一つの

“encoded-word”の一部として符号化してもよい。

9

セキュリティへの考慮

セキュリティに関しては,この規格では規定しない。


11

X 5810-3:2008

附属書 A

参考)

RFC 1522 からの変更(順不同)

この附属書は,本体に関連する事柄を補足するものであって,規定の一部ではない。

RFC 1522 からの変更は,次のとおりである。

a) “encoded-word”を使用するために MIME-Version が要求されないことを,明示的に宣言した。

b)  正確を期するため,“encoded-word”が RFC 822 parser.values への“atom”のように見えなければならない

ということを説明する,“encoded-word”中の SPACE 及び TAB が許されないという,明示的な注記を

加えた。

c)  隣接する線形空白とともに符号化語がどのように表示されるかを示す,Olle Jarnefors(感謝!)から

の例を加えた。

d) RFC

822 で定義され,この規格で参照された用語を,明示的に列挙した。

e) nroff の癖によって,結果のテキストにおいて 1,2 行及び幾つかの文字が消えてしまうという誤植を

訂正した。

f) RFC

822 ヘッダ及び MIME 本体部分ヘッダのいずれの“*text”フィールド中でも,パラメタ値として

でないことを除いて,符号化語は許されることを明確化した。

g)  “encoded-word”の符号化された部分内で,コード切替えシーケンスを使うどんな文字集合に対して

も,ASCII に戻すという要求を明確化した。

h)  注釈の中で,“encoded-word”が“(”及び“)”によって区切られているが,*text 中ではそうではない(奇

妙だが)ことに関する注記を追加した。

i) =E9 の後の末尾の“_”が廃止された(1342 の後には必要ない)Andre Pirard の例を修正した。

j) *ctext 中の“(”及び“)”との隣接でない,注釈を区切る,直後の最初の“(”又は直前の最後の“)”が注釈を

区切る“encoded-word”が現れてもよいことを明確化した。

k) “B”

“encoded-word”はいつでも“encoded-text”部分で 4 文字の倍数となることを説明する注記を加

えた。

l)

例の中で“=”についての注記を加えた。

m)  “encoded-word”の処理は構文解析の後に行われ,そのために関連する幾つかのことを注記した。

n)  普通の RFC 822 又はいわゆる“8 bit ヘッダ”のどちらかと,RFC 1522 との間の変換を期待すること

はできないことを明示的に宣言した。

o)  “quoted-string”中の“encoded-word”が不正であることを明示的に宣言した。


12 
X 5810-3:2008

附属書 B

参考)

RFC 1521, 1522 及び 1590 からの変更点

この附属書は,本体に関する事柄を補足するものであって,規定の一部ではない。

MIME 関連の JIS X 5810 規格群は,RFC 1521,1522 及び 1590 の改正である。RFC 1521,1522 及び 1590

を熟知している人に便利なように,RFC 1521,1522 及び 1590 からの変更点をこの附属書に要約する。そ

れ以前の履歴に関して,

RFC 1521 がその前の版の RFC 1341 とどのように異なるかを RFC 1521 の Appendix

H が示している。

a)  この規定は完全に再構成され,複数の規定に分割された。これは,参照原稿であるために必要とされ

る,この規定のプレーンテキスト版の品質を高めるために行われた。

b) MIME オブジェクトヘッダの全体構成を記述する拡張 BNF が追加された。これは,文書化の変更だけ

で,根本的な構文は変わっていない。

c) MIME の七つのメディア型のための固有の拡張 BNF は削除された。この拡張 BNF は,不正確で,不

完全で,型独立の拡張 BNF と矛盾していた。型独立の拡張 BNF は既に多くの MIME ヘッダの構文を

完全に規定しているので,型固有の拡張 BNF は,結局,完全に不要であり,かえって問題を起こした。

d) RFC

1521,1522 及び 1590 の多くの部分における非公式の用語である ASCII の使用は,もっと固有の

“US-ASCII”という文字集合名に置き換えられた。

e)  主メディア下位型という非公式の概念を削除した。

f)  用語“オブジェクト”は,一貫性なしに用いられていた。この用語の定義は,関連の用語“本体”,

“本

体部分”及び“実体”とともに明確化され,用法は適切に訂正された。

g)  境界マーカに先行する CRLF が,先行する本体部分ではなくマーカそのものの一部であることを明確

にするため,マルチパートメディア型のための拡張 BNF は再整理された。

h)  マルチパートオブジェクト内の本体部分は,境界パラメタ文字列で始まる行を含んではならないこと

を明確にするため,マルチパートメディア型を記述する普通文及び拡張 BNF は変更された。

i) “message/partial”MIME 実体を再組立する規則において,内部メッセージからとるために,ヘッダの一

覧に“Subject”が追加され,この点を明確にするため例が修正された。

j) “message/partial”素片化子は,行境界での MIME オブジェクトの分割だけに制限される。

k) application/postscript 型の議論において,PostScript MIME 実体の中での binary データの組込みによって

引き起こされる可能性のある相互運用可能性の問題についての警告をする追加の段落を加えた。

l)

次の二つの形式を明確にするために,Content-Type ヘッダフィールドのための基本構文規則に対して

明確化の注記を加えた。

   Content-type: text/plain; charset=us-ascii (comment)

   Content-type: text/plain; charset="us-ascii"

これらは,完全に等価である。

m) MIME-Version ヘッダの議論から次の文を削除した “しかし,適合ソフトウェアは,版番号を検査し,

認識できない MIME-Version に遭遇したとき,利用者に少なくとも警告することが推奨される。

n) “message/external-body”ではなく“application/external-body”とした誤植を修正した。


13

X 5810-3:2008

o)  要件を明確にするため,文字集合の定義を再構成した。

p) “image/gif”メディア型の定義は,別文書に移した。この変更は,特許で保護された技術の標準化を管

理する IETF 規則と矛盾が生じる可能性があるため,行われた。

q) “7

bit”及び“8 bit”の定義を厳しくしたので,はだかの CR 及び LF は行終端列として使用されるだけと

した。この規格はまた,NUL 文字を保存することをもはや要求しない。それは,MIME を実世界の実

装と整合させる。

r) MIME における正準テキストの定義を厳しくしたため,行区切りは CRLF 列で表現されなければなら

ない。CR 文字及び LF 文字は,この用法以外には許容されない。それに伴って,quoted-printable 符号

化の定義が変更された。

s) quoted-printable 符号化の定義は,quoted-printable 符号化器が不適切に符号化されたデータをどう扱う

のが最もよいかについて,今では多くの推奨を含む。

t) “8

bit”又は“binary”データにカプセル化するメッセージ実体又はマルチパートで,“7 bit”,“8 bit”及び

“binary”の内容転送符号化の使用を明確にする普通文を加えた。

u) MIME 適合性の箇条において,最小限の MIME 適合性に関する要件の一覧に“multipart/digest”のサポー

トを追加した。“message/rfc822”のサポートのための用件も,再帰構造を認識することの重要性を明確

にするために,強化された。

v) “message”のメディア下位型の様々な制限は,今ではメディア下位型ごとに完全に規定されている。

w) “message/rfc822”の定義は,“From”,“Subject”又は“Date”ヘッダの少なくとも一つが存在しなければな

らないことを示すように変更した。

x)  認識できないメディア下位型の“application/octet-stream”としての必す(須)処理は,型定義の節及び

適合性指針の両方において,もっと明示的に作成された。

y) text/richtext を用いた例は,text/enriched に変更された。

z)  メディア下位型の拡張 BNF 定義は,IANA 登録済みメディア下位型又は非標準の“X-”メディア下位型

のどちらかが Content-Type ヘッダフィールドで使わなければならないことを明らかにするために変更

された。

aa)  使用するために単に登録される MIME メディア型と,IETF によって標準化される MIME メディア型

とは,今では MIME  拡張 BNF において区別される。

ab)  様々な MIME 登録手続のすべてを広範囲に改正した。文字集合に関する IANA 登録手続は,この JIS X 

5810 規格群に含まれない別の規格に移動した。

ac) RFC 1521,1522 及び 1590 が定義している US-ASCII 文字集合及び ISO-8859-X 文字集合におけるエス

ケープ機構及びシフト機構の使用を明確にした。これらの機構は,これらの文字集合,及びそれらの

使用が定義されないときの影響と一緒に用いてはならない。

ad) message/external-body のための AFS アクセス型の定義を削除した。

ae) multipart/alternative と message/external-body との組合せの処理には,今は特に言及していない。

af) message/external-body に固有のセキュリティの課題は,今では細かく示されている。


14 
X 5810-3:2008

附属書 C 

参考)

参考文献

この附属書は,参考文献について記載するものであって,規定の一部ではない。

ATK   Borenstein, Nathaniel S., Multimedia Applications Development with the Andrew Toolkit, Prentice-Hall,

1990

ISO/IEC 646:1991, 3rd ed., Information technology−ISO 7-bit coded character set for information interchange

注記  JIS X 0201:1997  7 ビット及び 8 ビットの情報交換用符号化文字集合 (MOD)

JIS X 0202  情報技術−文字符号の構造及び拡張法

注記  ISO/IEC 2022:1994, 4th ed., Information technology − Character code structure and extension

techniques (IDT)

JPEG  JPEG Draft Standard ISO/IEC 10918-1 CD

MPEG  Video Coding Draft Standard ISO/IEC 11172 CD, ISO/IEC JTC1/SC2/WG11 (Motion Picture Experts

Group), May, 1991

PCM  CCITT, Fascicle III.4−Recommendation G.711, "Pulse Code Modulation (PCM) of Voice Frequencies",

Geneva, 1972

POSTSCRIPT  Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, 1985

POSTSCRIPT2  Adobe Systems, Inc., PostScript Language Reference Manual, Addison-Wesley, Second Ed., 1990

RFC 783  Sollins, K.R., "TFTP Protocol (revision 2)", RFC 783, MIT, June 1981

RFC 821  Postel, J.B., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute,

August 1982

RFC 822  Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL,

August 1982

RFC 934  Rose, M. and E. Stefferud, "Proposed Standard for Message Encapsulation", RFC 934, Delaware and

NMA, January 1985

RFC 959  Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, USC/Information Sciences Institute,

October 1985

RFC 1049  Sirbu, M., "Content-Type Header Field for Internet Messages", RFC 1049, CMU, March 1988

RFC 1154  Robinson, D., and R. Ullmann, "Encoding Header Field for Internet Messages", RFC 1154, Prime

Computer, Inc., April 1990

RFC 1341  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

RFC 1342  Moore, K., "Representation of Non-Ascii Text in Internet Message Headers", RFC 1342, University of

Tennessee, June 1992

RFC 1344  Borenstein, N., "Implications of MIME for Internet Mail Gateways", RFC 1344, Bellcore, June 1992

RFC 1345  Simonsen, K., "Character Mnemonics and Character Sets", RFC 1345, Rationel Almen Planlaegning,

June 1992


15

X 5810-3:2008

RFC 1421  Linn, J., "Privacy Enhancement for Internet Electronic Mail:  Part I: Message Encryption and

Authentication Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, February 1993

RFC 1422   Kent, S., "Privacy Enhancement for Internet Electronic Mail:  Part II:Certificate-Based Key

Management", RFC 1422, IAB IRTF PSRG, IETF PEM WG, February 1993

RFC 1423  Balenson, D., "Privacy Enhancement for Internet Electronic Mail:  Part III:Algorithms, Modes, and

Identifiers",    IAB IRTF PSRG, IETF PEM WG, February 1993

RFC 1424  Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:  Part IV: Key Certification and

Related Services", IAB IRTF PSRG, IETF PEM WG, February 1993

RFC 1521  Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions)Part One: Mechanisms

for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft,

September, 1993

RFC 1522  Moore, K., "MIME (Multipurpose Internet Mail Extensions)Part Two: Message Header Extensions for

Non-ASCII Text ", RFC 1522, University of Tennessee, September 1993

RFC 1524  Borenstein, N., "A User Agent Configuration Mechanism for Multimedia Mail Format Information",

RFC 1524, Bellcore, September 1993

RFC 1543  Postel, J., "Instructions to RFC Authors", RFC 1543, USC/Information Sciences Institute, October 1993

RFC 1556  Nussbacher, H., "Handling of Bi-directional Texts in MIME", RFC 1556, Israeli Inter-University

Computer Center, December 1993

RFC 1590  Postel, J., "Media Type Registration Procedure", RFC 1590, USC/Information Sciences Institute, March

1994

RFC 1602  Internet Architecture Board, Internet Engineering, Steering Group, Huitema, C., Gross, P., "The Internet

Standards Process−Revision 2", March 1994

RFC 1652  Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., Stefferud, E., and Crocker, D., "SMTP Service

Extension for 8 bit-MIME transport", RFC 1652, United Nations University, Innosoft, Dover Beach Consulting,

Inc., Network Management Associates, Inc., The Branch Office, July 1994

RFC 1700  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute,

October 1994

RFC 1741  Faltstrom, P., Crocker, D., and Fair, E., "MIME Content Type for BinHex Encoded Files", December

1994

RFC 1896  Resnick, P., and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February, 1996

RFC 2048  Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four:

Registration Procedures", RFC 2048, Innosoft, MCI, ISI, November 1996

US-ASCII  Coded Character Set−7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986

X400   Schicker, Pietro, "Message Handling Systems, X.400", Message Handling Systems and Distributed

Applications, E. Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41