JISX5810-3:2008 多目的インターネットメール拡張（ＭＩＭＥ）－第３部：非ＡＳＣＩＩテキストへのメッセージヘッダ拡張

X 5810-3：2008

（1）

2019年7月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）

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

まえがき

この規格は，工業標準化法第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部：適合基準

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

日本工業規格 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

適用範囲

この規格は，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の改正

であった。附属書Bに，過去の版との違い及び変更について記載する。

1.2

概要

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

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

体部分を印字可能な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”である。簡

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

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

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

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

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

ことも想定しない。

引用規格

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

引用規格は，その最新版（追補を含む。）を適用する。

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

符号化語の構文

次の拡張BNF文法によって“encoded-word”が定義される。“encoded-word”の要素間に空白文字が現れ

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

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

charset = token ;箇条 3を参照

encoding = token ;箇条 4を参照

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

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

長さの制限は，ネットワーク間のメールゲートウェイを通る相互運用性を容易にするため，及び，トー

クンが“符号化語”であるか何かほかのものであるか決めることができるようになる前の，最後の“?=”区

切り子を探している間に，ヘッダの構文解析器が費やさなければならない先読みの量に制限を課するため

である。

注記 “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に規定する規則によって，更に制限される。

文字集合

“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の一連のものの中から使

用することを推奨する。

符号化

始めに規定する“encoding”の合法的な値は，“Q”及び“B”とする。これらの符号化については，次に記述

される。“Q”符号化は，符号化される文字のほとんどがASCII文字集合に含まれる場合に，使用が推奨さ

れ，それ以外の場合は，“B”符号化を使用するのがよい。このことにはかかわらず，“encoded-word”を認

識すると宣言するメール読みプログラムは，サポートするすべての文字集合に対して，いずれの符号化も

受け入れなければならない。

“encoded-text”には，印字可能なASCII文字のサブセットだけを用いてよい。スペース文字及びタブ文

字は許容されないので，“encoded-word”の始まり及び終わりは明白である。“?”文字は，“encoded-word”

内の多くの部分を他の部分と分離するのに使われるから，“encoded-text”部分には現れることはできない。

他の文字は，特定の文脈では，不正である。例えば，Fromヘッダフィールドの中の，アドレスに先行する

“phrase”内の“encoded-word”は，RFC 822で規定されている“specials”のいずれも含んではならない。最

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

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

文脈では特定の文字は許されない。

“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は，符号化語内

でそれら自体によって表されてはならないものとする。

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

“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

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

普通の文字として扱われ，この箇条の規則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”のように見える普通のテキストを符号化する必

要があるかもしれない。

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

6.1

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

メール読みプログラムは，“encoded-word”を正しく認識するため，RFC 822の規定に従って，メッセー

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

“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”に対するメールリーダ処理

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

箇条2に定義されている構文に適合する“encoded-word”が，使用された符号化の規則では誤った形式

になっている可能性がある。例えば，次のような場合である。

a) 特定の符号化では正当でない文字（例えば，“B”符号化中の“-”，若しくは，“B”符号化又は“Q”符号化

のいずれかの中のSPACE又はHTAB）を含んで，“encoded-word”が形式を誤っている場合。

b) 非整数個の文字又はオクテットを符号化して“encoded-word”が，形式を誤っている場合。

メールリーダは，形式が誤っている“encoded-word”に関連するテキストを表示しようとする必要はな

い。しかし，メールリーダは，“encoded-word”が誤った形式をしているからという理由で，メッセージの

表示又は処理を妨げてはならない。

適合性

この規格に適合すると主張するメール作成プログラムは，“=?”で始まり“?=”で終わる“*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集合にもある文字を表示できなければならない。

例

“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?

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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”として定義されるフィール

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

次のそれぞれの例では，“*text”フィールド中に同じ並びが起こらない場合，“表示される”形式は，“符

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

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

符号化形式

表示形式

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

(a)

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

(a b)

“comment”中では，空白は，“encoded-word”と取り囲むテキストとの間に現れなければならない［箇

条5の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)

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書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行及び幾つかの文字が消えてしまうという誤植を

訂正した。

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

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

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

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

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

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

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

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

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

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

えた。

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

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

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

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

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

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書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) 主メディア下位型という非公式の概念を削除した。

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

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

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

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

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

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

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

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

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

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

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

次の二つの形式を明確にするために，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”とした誤植を修正した。

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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

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

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

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

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

装と整合させる。

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

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

化の定義が変更された。

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

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

“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に固有のセキュリティの課題は，今では細かく示されている。

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

附属書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

X 5810-3：2008

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

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