ヘッダでの非US-ASCII 文字の扱い
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2020/03/24 07:00 UTC 版)
「Multipurpose Internet Mail Extensions」の記事における「ヘッダでの非US-ASCII 文字の扱い」の解説
上記のヘッダの導入によって、body部のデータタイプや符号化方式は指定できるようになったが、このままではヘッダ部は相変わらずUS-ASCIIしか利用できない。MIMEではRFC 2047やRFC 2231によって、ヘッダ部分での非US-ASCII文字の扱いを規定している。RFC 2047によれば、 =?charset?encoding?encoded-text?= という形式により、文字コード系がcharset、符号化方法がencodingで、encoded-textと符号化された単語を表現できる。charsetは Content-Type:text/plain における charset パラメータで指定するのと同じ、IANAに登録された文字列を用いる。encoding は Q または B（大文字でも小文字でもよい）であり、前者はほぼ quoted-printable と同じ符号化方法、後者は base64を用いることを表す。 RFC 2047では、「"」で囲まれた中でこのような符号化された単語を解釈することはできない、とされている。したがって、「"=?ISO-2022-JP?B?GyRCRnxLXDhsGyhC?="」は「=?ISO-2022-JP?B?GyRCRnxLXDhsGyhC?=」と解釈しなければならず、これを「日本語」と解釈することは、規格違反となる。しかし、Microsoft Outlook Expressなど、一部のMUAがこのような誤った符号化を実装してそれが普及してしまったため、それを規格違反と知っているMUAの作者も、それに対応することを余儀なくされている。 RFC 2231では、MIMEパラメータの値に非US-ASCII文字を指定する方法を規定している。これによれば、添付ファイル名など、MIMEパラメータの値としての「ISO-2022-JP''%1B$BF|K%5C8l%1B%28B」を「日本語」と解釈することができる。また、RFC 5322に適合しない長さの文字列を短く分割して指定する方法も規定している。
※この「ヘッダでの非US-ASCII 文字の扱い」の解説は、「Multipurpose Internet Mail Extensions」の解説の一部です。
「ヘッダでの非US-ASCII 文字の扱い」を含む「Multipurpose Internet Mail Extensions」の記事については、「Multipurpose Internet Mail Extensions」の概要を参照ください。
- ヘッダでの非US-ASCII 文字の扱いのページへのリンク
