［MacとWindows間のファイル交換］
MIMEへの過程
- 目次
- #.はじめに
- #.RFC 822のメールの基準化：ヘッダー規定
7ビット文字（US-ASCII）のテキストメール
- #.ヘッダー部分：符号化-単語（encoded-words）
言語・符号化情報を組み込んで符号化された、単語
- #.ボディ（本文）部分：構造化
メディアタイプ(サブタイプ)・符号化・言語情報を組み込んだ階層構造
- #.マニュアルを読んでみると
符号化-単語の説明があるかのか
- #.メールをみると
ヘッダー情報の事例を見る
- #.基本資料：関連サイトとRFC
- #.2000年問題とMIMEの類似と相違
電子メールと日本語 IIJ技術研究所山本和彦 から
電子メールがどういう思想の下に生まれどういう時代背景と共に発展したのか、そし
てどのような技術で構築されているのか。このような知識を得る努力をしないプログ
ラマがメーラを実装していたのでは、環境はなかなかよくなりません。また、技術や
マナーの習得なしにユーザが電子メールを利用し続けるのであれば、結局底の浅い文
化に留まってしまうでしょう。
電子メールを書く場合、最低以下の事項をどの位マスターしているか自分をチェック
してみることは、正しくまた上達がはやくなる方法です。
「送信には保守的で、受信には先進的である」という一般的なインターネッ
ト指針（RFC 1896）があることも、心に留めておくべきです。「送信には保守的で」は、利用者側も可能な行為です。
- *.MIME（マイム）
Multipurpose Internet Mail Extension、多目的な電子メールの拡張
MIMEをサポートしているメーラー
-
- *.テキスト編集 テキスト=エディター
- メーラーは充分な編集機能を装備していません。別にテキスト=エディターを用意しておきましょう。Jedtや秀丸（＋マクロ）など。
諏訪邦夫著 「パソコンとどうつきあう」（中公新書）：エディターの意味
メールの桁数は、古いメールサーバーの機能上76文字（1バイト文字で）以内とい
う制限と使用されている表示画面サイズ上65〜72文字（65文字は最小画面）という
制限があります。この両者を考慮して、テキストに60〜65〜70文字
（葉書〜手紙〜文章に相当）で適時改行を挿入しますが、一括桁数揃えのエディ
ター機能を利用すれば、文章を書いた後で一括して桁数が揃えられ、便利です。
ちなみに、インターネット上の公式テキスト文書の一つである RFC は、70（一バ
イト文字）文字で記載されています。
- *.安全な記号と機種依存文字
- テキストを記載する際に注意しておかなければならない、文字記号についての資料を手元に用意しておきましょう。
［how to avoid hankaku-kana etc］
http://www3.justnet.ne.jp/‾s_kishimoto/fj/misc/hankana.htm
- *.キーボード操作（タイピング）
- 日本語入力はローマ字変換で、タイピングはタッチ=メソッドの習得を。キーボードを見ないで入力するブラインド（blind）メソッドはプロですが、キーボドをちらちらとみるが、指一本ではないタッチ=メソッドには慣れるようにすると入力が早くなります。
諏訪邦夫著 「タイプ革命」（中公新書）：ローマ字変換入力
［電子メールで失敗したときに読む資料］
電子メールとメーリングリストに関する 38のTips (30〜38）から引用
●メールを活用するための一番の方法はキータイピングに習熟すること
嘘だと思いますか？
#^目次へ
メールの基準化は、以下のRFC 822（August 13, 1982）からはじまりました。封筒と
中味に例えられ、封筒の宛先に当たるヘッダー情報、FROM・TO・SUBJECTなど、の
規定が厳格に書式化されれましたが、中味に相当するメーセージ本体は、テキス
トのままとして、規定はありません。ヘッダーの規定でも、符号化などの規定は
なく、文字も7ビット文字US-ASCIIが前提とされています。テキスト・メールとも
表現されるものはRFC 561, 733そして822と基準化が進み、このRFC 822書式の
メールは、その後の拡張によってマインム・メールへと発展していく、土台で
す。7ビット化（8ビットでなくする）ということは、メールサーバーを通過する
という点で基本的考えで、色々な符号化も8ビットでないテキスト化と言えます。
以下のようにRFCの抜粋から、この状況を伺い知ることができますが、直接RFCに
当たり、目次の項目を見るだけでも、全体が伺えます。
日本語（八ビット文字）でメールが書けませんが、この段階でも7ビット日本語コー
ド系ISO-2022-JPを使用して、メールを送る試みは、RFC 1468（June 1993）で、はじ
まりました。RFC 822テキストメールは、封筒の宛名も内容も7ビット文字でしか記載
ができないのですが、ISO-2022-JPコード系は7ビットなので記載ができます。ただ、
ASCII文字がくると思っている所ではなく、ISO-2022-JPと思っているローカル領域で
使用され、宛名にはASCIIで共通に、Subject:にもISO-2022-JPを使用しないとして、
内容はローカル慣例に依存して、日本語コード系ISO-2022JPで記載していました。多難な時代ですが、ISO-2022-JPのお陰で可能でした。
RFC 561
=========================================================================
Standardizing Network Mail Headers 5 September 73
ネットワークメールヘッダーの標準化
現在のFTPメールプロトコールで欠けているものは、author・titleそして
dateといったヘッダー情報の明示的な仕様について何ら既定がないことで
す。多くのシステムは情報を送信しますが、各々異なった書式です。標準が
ないことの深刻な結果の一つは、到着するメールを統合的に処理することが、
システムもしくは利用者側プログラムで、できないことになることです。
この問題に対する長期の見通しでの解決は、おそらくメールプロトコール命
令空間に、そのような情報を特定する命令指示を加えること（RFC 524 --
1740で示唆されているように）でしょうが、ここではより迅速な装備解決を
暫定的に提唱します。
ネットワークメールのテキストは、FTPテレネット接続（MAIL命令経由）で
あれ分離データー接続（MLFL命令で）,であれ、以下の構文に支配されこと
を示唆します。
例：
From: White at SRI-ARC
Date: 24 JUL 1973 1527-PDT
Subject: Multi-Site Journal Meeting Announcement
NIC: 17996
At 10 AM Wednesday 25-JULY there will be a meeting
to discuss a Multi-Site Journal in the context of
the Utility. Y'all be here.
RFC 822
=========================================================================
ARPAインターネットテキストメッセージの書式のための標準
August 13, 1982
1977年までに、Arpanetネットはそのホストコンピューター間でのテ
キスト・メッセージ（メール）の情報標準を採用していた。これらの実践を
コード化し、差し迫っていると思われる機能を提供することが必要に想わ
れ、その努力の結果がRequest for Comments (RFC) #733、"Standard for
the Format of ARPA Network Text Message", by Crocker, Vittal, Pogran,
and Henderson、でした。
この仕様書はARPAインターネットでの使用を意図しています。しかし
この試みは、環境への如何なる依存からも自由であるようになされ、従って
別のネットワークテキストメッセージシステムに適用できます。
この文脈で、メッセージは封筒と中味を持っているものとして見られ
ます。封筒は転送や配達を成し遂げるのに必要な情報を何でも持っています。
中味は、受信者に配達される対象を組み立てています。
メッセージ（交流）枠組
メッセージはテキスト行からなっています。線画・複写・演説そして
構造化されたテキストを符号化するために、何ら特別な規定は作られていま
せん。データー圧縮問題もしくは転送や保存効率について重要な考慮は一切
払われなく、標準は使われるビット数は自由です。例えば、フィールド名は
特別な簡潔なコードでなく自由なテキストとして特定されています。
一般的な"memo"枠組みが使われています、言い替えると、メッセージ
は厳格な書式の情報つづいて主メッセージ部分、この文書で特定していない
書式を持った、が来るという構成です。厳格に書式化されたセクション
（ヘッダー＝"headers"）の構文はこの仕様書で定義されます；これら
フィールドは全てのメッセージに来なければなりません。
=========================================================================
#^目次へ
7ビット文字とiso-2022-jp
インターネットといえば今ではウェブみたいになっていますが、電子メールも使
う人がふえてきているようです。パソコン通信の質問からもそれが伺えます。
メールは「本文にTextがある」ということだけがわかる仕組（RFC 822サーバー）
で、その文字はアスキー文字（正式名はUS-ASCII）を前提にしていました（テキ
スト=メール）。この仕組の拡張（extension）が、MINEへの拡張です（テキスト
=メールからマインム=メールへの拡張）。
アスキー文字（ASCII: American Standard Code for Information
Interchange）は、7ビット文字といわれ最初のビットがゼロ（0）形式です。この
文字セットのMIME名は"US-ASCII"で、7ビット形式に日本語をしたものがMIME名
iso-2022-jp（JIS, JIS7）といわれるものです。これで、形式はアスキー文字と
同じになります。以下の引用で、この意味が分かると思います。
英語（アスキー文字）との混在も、切り替えの印（エスケープ連続体）で、可能になっています。「情報交換用」符号化の国際規格"ISO2022"が定められて、いろんな種類の文字集合の混在切替の仕組が定義されています。ISO-2022-JPは、この定義にそっています。
1 バイト 2バイト
(8ビット) (8ビット)
-------- --------
ASC II M 01001101 （補足：最上位bitが0 7ビット・1バイト文字）
JIS Ｍ 01001101 01001101 （補足：最上位bitが0 7ビット・2バイト文字）
JIS め 00100100 01100001 （補足：最上位bitが0 7ビット・2バイト文字）
S-JIS め 10000010 11011111 （補足：最上位bitが1 8ビット・2バイト文字）
EUC め 10100100 11100001 （補足：最上位bitが1 8ビット・2バイト文字）
「インターネットメールの注意点」から
英語圏で、Unix環境でメールの基準はすすみました。日本でもUnix環境の整備がすす
み、本文をJIS漢字コードを使って日本語のテキストをメールでやり取りするための拡
張（extension）が考えられました。その日本語も通過できるよう仕組を拡張しようと
いうことです。でも、To: From: Subject: フィールドなどのヘッダーには日本語は
使わないという約束の下で、日本語メールを使っていました。まだ、このJIS漢字コ
ードをアスキー文字と解釈される可能性があり、そうなれば文字化けするからです。
To:が文字化けしたら、メールは届きません。また、転送中のメールサーバーのローカ
ル慣例で改行などが変更され、本文の文字化けなどの可能性は残っていました。この
状況は、RFCにも記載があります。RFCの抜粋を上げておきます。
==========================================================================
RFC 822 からの引用
1.2. メッセージ（交流）枠組み
メッセージはテキスト行からなっています。線画・複写・演説そして
構造化されたテキストを符号化するために、何ら特別な規定は作られていま
せん。データー圧縮問題もしくは転送や保存効率について重要な考慮は一切
払われなく、標準は使われるビット数は自由です。例えば、フィールド名は
特別な簡潔なコードでなく自由なテキストとして特定されています。
--------------------------------------------------------------------------
RFC 2049 からの引用
インターネット電子メールは完全で、均一なシステムではありません。メール
は最終到着先までの旅の幾つかの段階で不正が働くかもしれません。特にイン
ターネットを経て送られるイーメールは、多くの網の目のように配置された技
術をまたがって旅するかもしれません。多くのネットワークとメール技術は
SMTP転送環境で可能な完全な機能をサポートしていません。これらのシステム
を横切るメールは、転送されることが可能な指令に変更されやすいのです。
インターネト上には多く非適合MTAsが、広く配置されています。これらMTAs、
SMTP手順のことです、で装備されているホストのインターネット構造に有利な
ように飛び交うメッセージを変更するかもしくは全く破壊します。
==========================================================================
文字情報を組み込む方法と符号化（encoded-words）
そこで、これはiso-2022-jpという日本語コード系ですよという情報を組み込み且
つ安全なアスキー文字（US-ASCII）を使った符号化を指定できる形式で対応して
います。「符号化-単語（encoded-words）」として知られている形式がそれで
す。以下にその構文や意味をRFC2047の抜粋引用でみます。安全なとは、どんな
メールサーバーでもロカル慣例によって変更されることなくそのまま通過すると
いう意味です。RFC2047の抜粋を以下にあげておきます。
<以下RFC2047の抜粋引用>
===================================================================
RFC2047 November 1996:
「MIME Multipurpose Internet Mail Extensions (MIME) Part Three:
非ASCIIテキストでのメッセージヘッダー拡張」
1. はじめに
RFC2045には、ASCIIと同じように様々な文字での符号化された、テキスト部
分の拡張機序に言及されています。既存のメールソフトを混乱させない方法
で、RFC 822メッセージヘッダーで非ASCIIテキストを符号化できる技術を記
載した覚書です。
データーを符号化するために、「符号化-単語 "encoded-words"」として知ら
れている一連の"普通"の印字可能な"ASCII文字が予約されています。
一般的にいって、「符号化-単語 "encoded-words"」は一連の印刷可能なASCII
文で、"=?"にはじまり"?="で終わり、その間に"?"が二つきます。文字セット
（character set）と符号化方法（encoding method）を特定し、元のテキス
トは符号化方法（encoding method）に従った画像的な（テキストでない）
ASCII文字として符号化されます。
この仕様を装備するメール構成は、ヘッダー領域の非ASCIIテキストを置く
手段を提供しますが、メッセージヘッダーに非ASCIIテキストを挿入する前
に、この領域（これらの領域の適切な場所）を「符号化-単語 "encoded-
words"」に翻訳します。
この仕様を装備するメールリーダーは、メッセージヘッダーのある場所に
「符号化-単語 "encoded-words"」が現われている場合それを認識します。
「符号化-単語 "encoded-words"」を「そのまま」表示するのではなくて、
符号を復元して指定された文字セットで元のテキストを表示します。
2. 「符号化-単語 "encoded-words"」の構文（使い方）
「符号化-単語 "encoded-words"」は、以下のように定義されます。
encoded-word = "=?" charset "?" encoding "?" encoded-text "?="
charset = token トークン（字句） ; 3.文字記号セットを参照
encoding = token トークン（字句） ; 4.符号化を参照
token = 1*<スペース・CTLsとespecialsを除く文字>
especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
<"> / "/" / "[" / "]" / "?" / "." / "="
encoded-text = 1*<"?" スペース以外の文字>
; （5. メッセージヘッダーでの
; encoded-wordsの使い方を参照）
'encoding'と'charset'名は、大文字小文字を区別しません。
3.文字記号セット（Character sets）
MIME名です。
4. 符号化
初期値（デフォルト）で正式な符号化方式（encoding method）の値は、
"Q"と"B"です。以下にこの符号化について記載します。符号化される文字
記号がほとんど ASCIIの場合符号化"Q"が薦められ、そうでない場合は符号
化"B"を使用すべきです。
「符号化-単語」内の"?"文字は、色々な「符号化-単語'encoded-word'」の
構成部分をお互いに区別するのに使われ、"符号化されたテキスト
（encoded-text）" 部分にはくることはできません。
5. メッセージヘッダーでの「符号化-単語"encoded-words"」の使い方
ヘッダーや本文のヘッダー部分にきます。
===================================================================
Subject: 夏休みの予定
Subject: =?iso-2022-jp?B?GyRCMkY1WSRfJE5NPURqGyhC?=
の =?iso-2022-jp?B?GyRCMkY1WSRfJE5NPURqGyhC?= が iso-2022-jp を組み
込んだ符号化です。「符号化-単語」の"B"モード（形式）です。
*1 iso-2022-jp ---< 文字コードはiso-2022-jpで、
*2 B ---< 符号化方式の値はB（=base64）。
*3 GyRCMkY1WSRfJE5NPURqGyhC ---< 文字コードはbase64で符号化されています。
<以下RFCの抜粋引用>
===================================================================
RFC1468 June 1993:
"Japanese Character Encoding for Internet Messages"
"インターネット・メッセージの日本語文字符号化"
MIMEについて
JUNET文字符号化は、"ISO-2022-JP"と命名され、この名称は以下のように、
MIMEメッセージで使われることをねらっています：
Content-Type: text/plain; charset=iso-2022-jp
ISO-2022-JP符号化は既に7ビット形式で、Content-Transfer-Encoding headerを
利用する必要はありません。
Base64もしくはQuoted-Printable符号化が使われてる場合、現在のJUNETソ
フトウェアーではメッセージは判読できないまま表示されることに注意して
下さい。
ISO-2022-JPはまた、MIME Part 2 headersでも使われます。
ISO-2022-JPテキストでは、符号化"B"を使わなければなりません。
-------------------------------------------------------------------
RFC2047 November 1996:
"MIME Multipurpose Internet Mail Extensions
(MIME) Part Three:
Message Header Extensions for Non-ASCII Text"
"非アスキーテキストのメッセージヘッダー拡張"
4. 符号化
初期値（デフォルト）で正式な符号化（encoding method）の値は、"Q"と"B"
です。以下にこの符号化について記載します。符号化される文字記号がほとん
ど ASCIIの場合符号化"Q"が薦められ、そうでない場合は符号化"B"を使用すべ
きです。
4.1. "B"符号化
符号化方法（encoding method）"B"は、RFC 2045で定義されている"BASE64"です。
4.2. "Q"符号化
符号化方法"Q"は、RFC 2045で定義されれいる "Quoted-Printable"
内容転送符号化と類似しています。大部分ASCII文字符号からなるテキストが
デコードされなくてもなんとか判読できるように設計されています。
-------------------------------------------------------------------
RFC2045 November 1996
"Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies"
"インターネットメッセージボディ部のフォーマット"
6.7. Quoted-Printable Content-Transfer-Encoding
符号化されたデーターが、主にUS-ASCIIテキストの場合、人が判読できます。
6.8. Base64 Content-Transfer-Encoding
Base64 Content-Transfer-Encodingの形式は、人が読む必要のないオクテット
（8ビット）の配列になっています。エンコードとデコードは単純で、エンコ
ード（符号化）されたデーターは、符号化されていないデーターより約33％し
か大きくなりません。
===================================================================
"B"形式は、
=?*1?*2?base64文字符号化?= となっています、base64デコー
ダーだけでは対応できなく、"B"形式に対応していなければなりません。日本文字
はUS-ASCIIからみると文字でなく読めないものに入りますので、"B"形式にするので
しょうか。こうして、ヘッダーの国際化が可能になりました。
-------------------------------------------------------------------
このヘッダの符号化の優れた点について触れておきましょう。当然、ASCII
以外の文字コードが ASCII 文字列に変換されていますので、配送システム
が誤動作を起こすことはありません。さらに、このヘッダの符号化は、テ
キスト・メールであっても (つまり MIME-Version: 1.0フィールドがなく
ても)利用できることになっています。
優れた MIMEメールリーダなら、ヘッダに ASCII以外の文字列が書か
れた場合は、送信時に自動的に符号化します。また MIMEメールリー
ダが受け取った場合は自動的に復号化して表示し、返答時には引用後
自動的に符号化します。
Newsletters（山本和彦） からの引用
+ MIMEバージョンは符号化-単語を使うのに必須ではない、と明示的に宣言。
RFC 2047 から 付録 - RFC 1522の変更
-------------------------------------------------------------------
#^目次へ
構造化と符号化
符号化-単語 "encoded-words"という形式も本文のコンテント・ヘッダーに取り込ん
でいますが、本文（コンテント、内容）もテキストなら、メールでおくることができ
ます。
GIFをuuencodeしてテキストにしておくれますが、メールは「本文にテキストがある」
ということだけがわかる仕組だと、受け取った人がdecodeしてみるわけです。これを
メールが判断できると便利です。この方向への仕組の拡張がMIME規格への歩みで符号
化も工夫されました。
MIMEでは、メールの内容に構造を持たせて、内容と符号化の情報をメールに組み込
み、メーラーが自動処理できるようになりました。
-----------------------------
From: xxxx@shs.kyushu-u.ac.jp
To: BD9Y-KTU@asahi-net.or.jp
Subject: Hello
-----------------------------
の仕組（テキスト=メール）から、
-------------------------------------
Date: Wed, 30 Oct 1996 18:09:29 +0900
To: BD9Y-KTU@asahi-net.or.jp
From: xxxx@shs.kyushu-u.ac.jp
X-Sender: xxxx@mx.shs.kyushu-u.ac.jp
Subject: Hello
MINE-VERSION 1.0
Content-Type: text/plain; charset=iso-2022-jp
---------------------------------------------
と構造をもった形式（マインム=メール）なります。
メール本文にある内容をヘッダに記述するように拡張されました。このヘッダの内容
の定義は、RFC1521(<--1341), RFC1522, RFC1590で定義され、現在は、
RFC2045 November 1996 "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"からRFC2049で改訂されています。
RFC 822の構造の拡張（MIME対応）図式化：
本文は、単にUS-ASCII 7ビット文字によるテキストが来るだけのRFC 822テキスト
メールに識別情報（以下のような）を組み込み、拡張構造化しています。
識別情報の例としては、
MINE-Version:
Content-Type:
Content-Trasfer-Encoding:
Content-ID:
Content-Description:
などの取り決めが定義されています。
* Content-Type:（内容タイプ＝メディアタイプ） の項目では、
内容を明示し、メディアタイプとして指定されます。このメディアタイプは、
RFC 2046で定義され、text/plain・image/gif・audio/basic・ video/mpeg・
application/PostScriptという書式です。
text・image・audio・video・applicationの五つの個別トップレベル・メディア
タイプがあり、それぞれサブタイプやパラメーターが来ます。例えば、
Content-Type: text/plain; charset="iso-2022-jp"は、
メディアタイプtext、サブタイプplain、パラメーターcharset="iso-2022-jp"
と言う情報を明示しています。
text/plain; Content-Type: text/plain; charset=US-ASCII
Content-Type: text/plain; charset="iso-2022-jp"
Content-Type: text/plain; charset=ISO-8859-1
image; Content-Type: image/gif
などがあり、これらの転送に際して符号化するやり方を図解すると、
* Content-Trasfer-Encoding:（内容転送符号化）の項目で、
[7 bit] [8 bit] [binary] はデーターです。一方、
<base64> と <quoted-printable> は、そのデーターを符号化する場合の方法で、
「textのまま」とは、
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 8bit （実際上ありえません、符号化しますから）
と表現されます。
<== textのまま ====[7 bit] : テキスト ：US-ASCII、JIS(JIS7)
+--[8 bit] : 行があるデータ(Text)：shift_jis, iso-8859-*
+-----------====|
| +--[binary]: 行の概念のないデータ：画像など
|
| += <base64> : shift_jis(text)
| | : バイナリーデーター
+----- 符号化 -----==> |
|
+= <quoted-printable> : iso-8859-*(text)
同じことですが、以下のようにも図解できます。日本語はJIS(JIS7)を使いますので、テキストデーターもしくはbase64符号化データーということになります。
<== textのまま ====[7 bit] : テキスト ：US-ASCII、JIS(JIS7)
+--[8 bit] : 行があるデータ(Text)：shift_jis, iso-8859-*
+---------------|
| +--[binary]: 行の概念のないデータ：画像など
|
| += <base 64> : shift_jis
| +- [8bit text]==|
+----- 符号化 -------> | += <quoted-printabl>: iso-8859-*9
|
+- [binary] ==+= <base 64> : 画像など
上の図解から分かるように、テキストでは、
* 7ビット文字はテキストのまま、
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit ［内容転送符号化: 7bit(テキスト)］
と7ビット文字［iso-2022-jp(JIS7)=7bit(text)］は、符号化されないでテキスト
として設定、一方
* 8ビット文字は、符号化して、
Content-Type: text/plain; charset="Shift_JIS"
Content-Transfer-Encoding: base64 ［内容転送符号化: base64 符号化方式］
X-MIME-Autoconverted: from 8bit to base64
by lancer.asahi-net.or.jp id OAA27365
と8ビット文字Shift_JISはテキストのままでなく、符号化する設定に。
asahi-net.or.jp は、ESMTP(拡張SMTP)です。
* 画像は、バイナリーデーターですので、符号化し、
Content-Type: image/gif
Content-Trasfer-Encoding: base64 ［内容転送符号化: base64 符号化方式］
と、画像gifがbase64で符号化されたものです、と伝えます。
MIMEをサポートしたメーラーは、この意味を理解し自動的にデコードし表示します。
Content-Transfer-Encoding: 8bit という設定をする項目があるメーラーがありますが、実際上この設定は無用です。上のshift_jisの例のように、8bitにしないで（その場合は符号化して）送るのがメーラーの目的ですから。
iso-2022-jpとエスケープシーケンス
iso2022-jpについては、以下のようなことも知っておくとより意味が分かります。US-ASCIIとの切り替えも、ISO2022国際基準にそっておこなわれます。
Internetでの日本語テキストエンコーディング
ISO-2022-JP(RFC1468)
1) 行の先頭はASCIIコードで始まる。
2) ASCIIコードから 漢字コードはESC-$-B、ESC-$-@を使う。 3) 漢字コードからASCIIコードはESC-(-J、ESC-(-Bを使う。
4) 行末は、ASCIIコードで終わる。
5) いわゆる半角カタカナは使わない。
エスケープシーケンスによってデータ列は少しながくなるが、
（最上位bitが1の）8bitデータがなくなるため、8 bitを通すこ
とができない通信系であっても、ほとんど問題になることはなく
なる。
シフトJISコード
82AO 82A2 82A4 31 32 33 82A6 82A8
あ い う 1 2 3 え お
JIS漢字コード
1B2442 2422 2424 1B2842 31 32 33 1B2442 242B 242A 1B2842
ESC-$-B あ い ESC-(-B 1 2 3 ESC-$-B え お ESC-(-B
符号化
本文内容での符号化についても決められました。7bitしか通過しない環境でも、デー
タを正しく送れるようにするためにバイナリデータをいったん7bitにして元にもどす
方法が考案された。uuencode, binhex, ishもこの一つですが、MIME拡張ではBASE64
エンコーディングという別の方法が使われる。uuencodeでは変換での記号が多く
「()<>@」などメールアドレスを表記する場合に意味を持つ文字があり、ヘッダには
利用できない。BASE64では、アルファベットと"+", "/", "="で、ヘッダでも利用し
ても問題が発生しない（コード化で33%大きくなる）。
ヘッダーの符号化は前にみたように、「符号化-単語 "encoded-words"」は、
====================================================================
RFC2047 November 1996:
"MIME Multipurpose Internet Mail Extensions (MIME) Part Three:
Message Header Extensions for Non-ASCII Text"：メッセージヘッダー
4. 符号化
初期値（デフォルト）で正式な符号化は、"Q"と"B"です。以下にこの符号
化について記載します。符号化される文字記号がほとんど ASCIIの場合符
号化"Q"が薦められ、そうでない場合は符号化"B"を使用すべきです。
4.1. "B"符号化
符号化方法（encoding method）"B"は、RFC 2045で定義されている"BASE64"
です。
====================================================================
とあり、本文内容の符号化では、
====================================================================
RFC2045 November 1996
"Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies"：メッセージボディの書式
6.7. Quoted-Printable 内容転送符号化方式
6.8. Base64 内容転送符号化方式
====================================================================
====================================================================
RFC 2049 November 1996
Multipurpose Internet Mail Extensions(MIME) Part Five:
Conformance Criteria and Examples 適合基準と事例
3. メールデーター送信指針
特に、全てのゲートウェイ通過で不変であると分かっている文字は73文字
で、大文字小文字A-Z・a-z・アラビア数字0-9と以下の特別な十一文字だ
けです。
最大に移動できるメール表現は、意味がある文字がこの73文字一式からな
る比較的短い行に限られています。base64符号化方式はこの規則に従って
います。
====================================================================
となっています。
- Note：初期値で多元部分メディアタイプ
- 初期値で、本文にテキストと同じ内容をHTML化したものの二つを設定してい
るものがあります（多元部分メディアタイプ）。相手のメーラーのことも考えて、
HTML化の設定ははずしておきましょう。相手もOKなら、HTML化メールも結構
ですが、一般的なものではありません。
これでテキストだけが送信されます。テキスト設定では、「エンコードなし」でテ
キストのまま送信します（テキストは前もって設定した7ビット文字JISなので）。
MIME設定になっているので、
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
が送られ、文字は正しく表示されます。
#^目次へ
日本語では、
7ビット2バイト文字は半角カタカナを使わない
iso-2022-jpです。メールヘッダーには以下の二つの符号化形式が
あり、RFC2047から引用しています。また、パソコンでの使用文字はshift_jisです。
この点をふまえて、Eudora-Jのread meをみてみます。
-----------------------------------------------------------------
RFC2047 November 1996:
「MIME Multipurpose Internet Mail Extensions (MIME) Part Three:
非ASCIIテキストでのメッセージヘッダー拡張」
4. 符号化
初期値（デフォルト）で正式な符号化は、"Q"と"B"です。以下にこの符号
化について記載します。符号化される文字記号がほとんど ASCIIの場合符
号化"Q"が薦められ、そうでない場合は符号化"B"を使用すべきです。
4.1. 符号化"B"
符号化"B"は、RFC 2045で定義されている "BASE64"符号化と同じです。
4.2. 符号化"Q"
符号化"Q"は、RFC 2045で定義されれいる "Quoted-Printable"内容転送符
号化と類似しています。大部分ASCII文字符号からなるテキストがデコー
ドされなくてもなんとか判読できるように設計されています。
-----------------------------------------------------------------
Eudora-Jのread meから
- 送信時:
- Eudora-J からメッセージ送信時の漢字コード変換のデフォルトは、SJIS -->
JISとなっています。
From:,Subject:,To:,Cc:,Bcc:に日本語が使われている時で、「MIMEヘッダ変換」
がオンになっているときはこれらのヘッダをISO-2022-JPのB形式でエンコー
ドしす。
GyRCMkY1WSRfJE5NPURqGyhC 部分は、
符号化"B"（=base64）で処理された日本語
=?
?iso-2022-jp
?B
?GyRCMkY1WSRfJE5NPURqGyhC
?=
の構成で、一連のASCIIからなる「符号化-単語 "encoded-words"」に
なっています。
=?iso-2022-jp?B?GyRCMkY1WSRfJE5NPURqGyhC?=
- 漢字変換,MIMEヘッダ変換,半角カナオプションと送信メッセージの関係:
- 送信メッセージの本文部分は指定の漢字変換がなされて送信されますが、ヘッダ
部分に違いがあります。
デフォルトは、MIME=オン・半角=オフです。-- iso-2022-jp
それ以外は、日本語を含む場合インターネットメッセージとしては不適当なものとな
りますので、ローカルサイト内での使用に留めるか、インターネットに出るまでのど
こかでISO-2022-JPに変換する必要があります。
MIME on MIME off 半角 on 半角 off
JIS 漢字変換 1,3 2,4 6 5
EUC,SJIS変換 1,4 2,4 7 7
- 1：ヘッダに日本語がある場合、
- そのヘッダをMIMEヘッダ変換をして送信する。-- ISO-2022-JPのB形式
半角カナの文字もMIMEヘッダ変換されるので送れる。
- 2：ヘッダに日本語がある場合、
- そのヘッダを指定の漢字変換して送信する。 -- B形式（-）
- 3：
- MIME-Version: 1.0 のヘッダがつく。
- 4：
- MIME-Version: 1.0 のヘッダがつかない。
- 5：
- Content-Type: text/plain; charset=iso-2022-jp のヘッダがつく。
- 6：
- Content-Type: text/plain; charset=iso-2022-jp のヘッダがつかない。
（iso-2022-jpに半角カタカナはない）
- 7：
- 半角カナオプションのポップアップメニューアイテムを選択できないし、
Content-Type: text/plain; charset=iso-2022-jp のヘッダがつかない。
#^目次へ
MINE形式のメールを見て、考えてみます。
From: y.kato@personal.email.ne.jp
To: y.kato@personal.email.ne.jp
Subject: 夏休みの予定
Date: Fri, 13 Aug 1999 00:18:39 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
「夏休みの予定 」は、文字はiso-2022-jpで配送システムが誤動作を起こさないような安全な符号方式でコード化しています（
=?iso-2022-jp?B?GyRCMkY1WSRfJE5NPURqGyhC?=）。サポートしているメーラーはこれ
をデコードし、iso-2022-jpとして表示します。iso-2022-jpでは、"B"モードですべき
となっています。iso-1859-1用の"Q"モードなどでコード化され、それをサポートし
ていないメーラーもあります（"B"モード＝安全なアスキー文字を使ったコード化）。
From: y.kato@personal.email.ne.jp
To: y.kato@personal.email.ne.jp
Subject: =?iso-2022-jp?B?GyRCMkY1WSRfJE5NPURqGyhC?=
Date: Fri, 13 Aug 1999 00:18:39 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
サポートしていないメーラーでは、
「=?iso-2022-jp?B?GyRCMkY1WSRfJE5NPURqGyhC?=」とそのまま表示されます。
修復ソフトを使い、夏休みの予定と分かります（base64コード化との報告がきま
す）。
さらに、「Content-Type: text/plain; charset="iso-2022-jp"」は、本文がテキスト
で日本語（iso-2022-jp）ですと明示されています。
Subject: =?utf-8?B?VW5pY29kZShVVEYtOCnjgafjga7pgIHkv6E=?=
Date: Wed, 29 Sep 1999 16:12:27 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
utf-8に対応してない場合です。
Content-Type: text/plain; charset="Shift_JIS"
Content-Transfer-Encoding: base64
X-MIME-Autoconverted: from 8bit to base64 by lancer.asahi-net.or.jp id OAA27365
base64形式のメールです。
と8ビット文字Shift_JISは符号化されます（ESMTP サーバー）。
From: A_Sr_Machine@internet.ca
To: y.kato@personal.email.ne.jp
Date: Tue, 24 Aug 1999 12:23:14
Message-Id: <483.705324.543104@ebiz1234ca_machine>
Subject: EBIZ = 1,2,3...4 CA
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by
patriot.asahi-net.or.jp id FAA20394
quoted-printable形式のメールです。
* X-MIME-Autoconverted: from quoted-printable to 8bit by
foo.bar.com id OAA22552
MLに送った自分のメールにこのようなヘッダが付加された場合は注
意が必要。この場合は、quoted-printableでエンコードされたメー
ルをシステム（MLが動作しているメールサーバーや中継サーバー）
が自動的に通常の形式に変換したことを示しています。
* ESMTP（拡張SMTP）
【とあるメールソフトが原因の文字化け】で、ESMTPに言及。
MINE形式にしない場合は、このような符号化や文字の明示的な指定がなく、テキス
ト・メール形式といいます。iso-2022-jpで送ってるので、サーバーは通りますが、そ
の文字がiso-2022-jpとの明示がないので、iso-2022-jpとの了解が得られる範囲では
正常に表示されます。
MINE設定のないテキス・メールをみます。
From: "luft"
To: "Yasutaka Kato"
Subject: プロフェッショナル電子メール
Date: Sat, 14 Aug 1999 20:06:00 +0900
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
「Content-Type: text/plain; charset="iso-2022-jp"」がないので、本文の文字指
定が明示されていません。日本語という了解が成り立つ範囲では文字化けなく、OKで
すが。
送信側の文字化け対策には、以下の方法があります。最初は、相手に受信状
態を聞いておきます。
- 各自のメーラー設定は、意味を理解して正しくする。送信はJISで。
- アドレスは英数文字を使い、Subject:に日本語を使い、且つSubject:を本文に並
記しておき、さらに署名を必ず記載しておく。
- MINEをはずして、テキスト・メールで送る場合もある。
- 別のマインム=メーラーを使う（iso-2022-jp "B"モードの）。
受信側対策としては、文字修復ソフトやデコードソフトを用意しておきます。
#^目次へ
資料：
Network by 民田 雅人 July 1996 SUPER ASCII p.165 Network
August 1996 SUPER ASCII p.177 Network
基本的なRFCも翻訳もしくは翻訳中です。また、要点が分かるようにと抜粋引用をあげておきました。
- テキストメール
- RFC561 ［翻訳版］ 5 September 1973
ネットワークメールヘッダーの標準化
- RFC822
［翻訳版］ August 13, 1982
ARPAインターネットテキストメッセージの書式のための標準
- RFC2156
MIXER (Mime Internet X.400 Enhanced Relay):Mapping between X.400 and RFC822/MIME
- 7ビット日本語文字コード系iso-2022-jp（JIS, 7bitJIS）
- 多目的インターネットメール拡張 November 1996
Multipurpose Internet Mail Extensions(MIME)
- RFC2045
［翻訳版］
第一部：インターネット通信（メッセージ）本体の書式
- RFC2046
［翻訳版］
第二部：メディア・タイプ
- RFC1896
［翻訳版］ February 1996
text/enriched マインム内容タイプ
- RFC2646
The Text/Plain Format Parameter August 1999
- RFC2047
［翻訳版］
第三部：メッセージヘッダーでの非アスキーテキストへの拡張
- RFC2048
Part Four: Registration Procedures
- RFC2049
［翻訳版］
第五部：適合基準と事例
- Multipurpose Internet Mail Extensions(MIME) の更新
- RFC2183
［翻訳版］ August 1997
インターネットメッセージの情報交流表現
内容配置ヘッダーフィールド
- RFC2184:
Obsoletes（破棄）され、rfc2231へ
RFC2231
［翻訳版］ November 1997
MIMEパラメーター値と符号化-単語の拡張：
文字セット・言語そして継続
- RFC2130
The Report of the IAB Character Set Workshop
<抜粋引用>
----------------------
電子メールと日本語
IIJ技術研究所山本和彦
----------------------------------------------------------------------------
日本初のハッカーである和田先生が先日 bitに Alan Kayの言葉を引用されていまし
た。うろ覚えですが、「ものごとを進める際には 2通りのやり方がある。 1つは目的
指向で過程への理解を疎かにするやり方。もう 1つは、過程への理解に重きを置く方
法である」という内容でした。
世の中にはいい加減なメーラがたくさんはびこっています。また、ユーザの多くも仕
事や流行に追い付くことに忙しく、理解することよりもまず使うことに心を奪われて
いるように思います。こういう現状を見るにつけ、この言葉はとても身にしみまた。
電子メールがどういう思想の下に生まれどういう時代背景と共に発展したのか、そし
てどのような技術で構築されているのか。このような知識を得る努力をしないプログ
ラマがメーラを実装していたのでは、環境はなかなかよくなりません。また、技術や
マナーの習得なしにユーザが電子メールを利用し続けるのであれば、結局底の浅い文
化に留まってしまうでしょう。
日本のインターネットをリードする IIJの社員が電子メールを理解できていないよう
であれば、他のユーザにそれを望むは無理な話です。そこで、この連載は電子メール
への理解が深まるような内容にしたいと考えています。今回の技術的なテーマは、「
電子メールと日本語」です。
コンピュータ科学を学んだ方ばかりが読んでいるわけではないと思いますので、少し
電子メールの書式をおさらいしてみましょう。インターネットでの約束ごとは、
RFC(Request For Comments)に英語で書かれています。電子メールの書式は RFC 822
で定義されています。この執筆は 1982年、元になった RFC 561に及んでは 1973年に
書かれています。現在でも通用する技術が、こんなにも昔に開発されていたとは驚き
です。
----------------------
ヘッダあれこれ
IIJ技術研究所山本和彦
----------------------------------------------------------------------------
インターネットとプロトコル
インターネットはすべての人が活動できるオープンな世界です。この特徴はインター
ネットのルールすべてが話し合いによって決定され、公開されていることが根底とな
って支えられています。インターネットでは、データの送受信方法やデータの書式な
どの取り決めも含む、技術的なルールをプロトコルと呼びます。
プロトコルは、 RFC(Request For Comments)という通し番号のついたオンライン・テ
キストとして公開されています。その名前が示すように、元々 RFCは議論をするため
の叩き台でした。 (もっと本当のことを言うと、RFCが書かれ始めた時代は、国を代
表するプロトコル設計のプロが仕様を定めていました。インターネットを設計した人
達は、彼らからすればアマチュアだったので、プロの反感をかわないように RFCとい
う名前を選びました。)しかし、RFCの権威が増すにつれ、インターネットの技術者は
RFCを仕様書として活用するようになりました。議論のための叩き台の役割は、現在
Internet-Draftに譲っています。綿密に議論され合意に達した Internet-Draftが
RFCに昇格します。
今回は、電子メールの書式を定めている RFC822を技術的な根拠として、電子メール
のヘッダについて解説していきます(RFC822は曖昧な点が多いので、現在改定の作業
が進められています)。インターネットで電子メールを利用するためには、 RFC 822
で規定された書式を厳密に守らなければなりません。これは、インターネットの秩序
を保つうえで歓迎すべき制約です。
規格に従いさえすれば、どんなベンダーもメールリーダを作成できます。複数のベン
ダーが参加すれば、公平な市場原理が働くことに加えて、市場も活性化されていきま
す。いくらでも代替品は存在するおかげで、ユーザは 1つの企業が独占している技術
や製品に頼る必要はありません。
理解して頂きたいことは、インターネットでは「大手ベンダーがそう実装しているか
ら正しい」とはいえないことです。逆に大手ベンダーの方が RFCを遵守することに無
頓着なきらいがあります。ユーザは公開されている技術的な内容をできる限り理解し
、それをベンダーに守ってもらうよう働きかける必要があります。このような日頃か
らの少しばかりの努力があれば、インターネットはいつまでも健全な状態に保たれる
のですから。
<抜粋引用>
=========================================
RFC 822（テキストメール）とマインムメール
=================================================================
RFC2045 November 1996
"Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies"
「インターネットメッセージ体部の書式」
概要
STD11、RFC 822、はUS-ASCII通信ヘッダーについての詳細を特定する通信表
現手順を定義し、通信内容もしくは通信本文を均一なASCIIテキストのまま
にしている。この一組の文書は、多目的インターネットメール拡張
（Multipurpose Internet Mail Extensions）もしくはMIMEと総称され, 以
下の事項が可能になるよう通信書式を再定義しています。この覚書の配布の
制限はありません。
（1）通信本体でのUS-ASCII以外の文字セットによるテキスト、
（2）通信本体での非テキストの色々な形式への拡張、
（3）多元的通信本体、そして
（4）US-ASCII以外の文字セットによるテキストヘッダー情報
これら文書は、RFC 934、STD 11、と RFC 1049で文書化されている初期の作業
に基づいていますが、これを拡張改訂しています。RFC 822は通信本文につい
て殆ど言及していませんので、これらの文書は（改訂というより）RFC 822と
は別方向のものです。
この最初の文書は、MIME通信（メッセージ）の構造を記載するために使われ
る様々なヘッダーを特定します。二番目の文書、RFC 2046、はメディアタイ
プシステムの一般的な構造を定義しメディアタイプの初期設定を定義しま
す。三番目の文書、RFC 2047、はインターネットメールヘッダー領域
（field）に非ASCIIテキストデーターを可能にするRFC 822の拡張を記載し
ます。
四番目の文書、RFC 2048、はMIME関連装備の色々なIANA登録手順を特定しま
す。五番目で最後の文書、RFC 22049、はMIME適合基準を記載し同時にMIME通
信書式の図解例・謝辞そして文献を提供しています。
これらの文書は、RFCs 1521・1522そして1590の改訂版で、これらそのもの
はRFCs 1341と1342の改訂版でした。RFC 2049の付録に前のバージョンとの
差異と変更点が記載されています。
<抜粋引用>
=======================
ヘッダー部分
=================================================================
RFC2047 November 1996
"MIME Multipurpose Internet Mail Extensions (MIME) Part Three:
Message Header Extensions for Non-ASCII Text"
「非ASCIIテキストでのメッセージヘッダー拡張」
4. 符号化
初期値（デフォルト）で正式な符号化は、"Q"と"B"です。以下にこの符号化
について記載します。符号化される文字記号がほとんど ASCIIの場合符号化
"Q"が薦められ、そうでない場合は符号化"B"を使用すべきです。
印字できるASCII文字の組だけが「符号化されたテキスト」内で使用できます
スペースとタブは許されません、というのは「符号化-単語」の始まりと
終りははっきりしているからです。"?"記号は「符号化-単語」内で使われ、
「符号化-単語」の色々な部分を他から分けるのに使われ、したがって「符
号化されたテキスト」内には現われることはことはできません。そのほかに
もある種の文脈上合法的でないものもあります。たとえば、Fromヘッダー欄
のアドレスに先行する句の「符号化-単語」は、RFC822で定義されている
"specials"をどれもとれません。最後にインターネット=メールのゲートウェ
イを通過するメッセージの信頼性を確保するために、ある種の文字記号はあ
る文脈上許されないものもあります。
RFC822で定義されている"specials"：
specials = "(" / ")" / "<" / ">" / "@" ; 言葉内で使うには、
/ "," / ";" / ":" / "¥" / <"> ; 引用符で囲まなければ
/ "." / "[" / "]" ; なりません。
符号化"B"はこの要求に適合します。符号化"Q"は、印字可能な幅広い文字を、
メッセージ・ヘッダー（例えば、Sucject）の厳密でない場所で、別の場所で
使うのに入手できる幾つかの文字とともに、使用できます。
4.1. "B"符号化
符号化"B"は、RFC 2045で定義されている"BASE64"符号化と同じです。
4.2. "Q"符号化
符号化"Q"は、RFC 2045で定義されれいる "Quoted-Printable"内容転送符
号化と類似しています。大部分ASCII文字符号からなるテキストがデコー
ドされなくてもなんとか判読できるように設計されています。
=======================
ボディ（本文）部分：
=================================================================
RFC2045 November 1996
"Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies"
「インターネットメッセージ体部の書式」
6.7. Quoted-Printable Content-Transfer-Encoding
Quoted-Printable encodingは、大部分US-ASCII文字セットの印字可能な文字
に相当するオクテット（8ビット）からなっているデーターを表現するよう考
えられています。コード化されたオクテットがメール転送によって変更され
ないような方法でデーターをコード化します。コード化されたデーターが殆
どUS-ASCIIテキストである場合、データーのコード化された書式はそれでも
人に判読可能です。US-ASCIIの体部も、文字変換や行−折り返しゲートウェ
イを通過するメッセージであるデーターの統一性を確保するためにQuoted-
Printableでコード化されるかもしれません。
6.8. Base64 Content-Transfer-Encoding
base64 Content-Transfer-Encodingは、人が判読する必要がない形式で任意
の一連のオクテット（8ビット）を表現するよう設計されています。コード化
やデコード手順は簡潔で、コード化されたデーターは単に非コード化デー
ターより33％大きくなるだけです。このコード化は、RFC 1421に定義されて
いるように、プライバシー強化メール（Privacy Enhanced Mail (PEM) ）ア
プリケーションで使用されものと同じです。
6ビットで印刷可能な文字を表現することができるために、US-ASCIIの65文字
が使われます（例外の65番目の文字、"="、は特別な処理機能を知らせるのに
使われます）。
コード化処理は、入力ビットの24ビットグループを四つのコード化文字出力
列で表現します。左から右にすすみ、24ビット入力グループは三つの8ビット
連結状態の書式にします。次いで、これらの24ビットは四つの6ビット連結状
態のグループとして処理され、base64アルファベットでシングル=デジタルに
変換されます。
テーブル 1: Base64 アルファベット
値 符号化 Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
符号化されて出力列は76文字以内で、一行に表現されなければなりません。
改行やテーブル1にない文字はデコードソフトは無視しなければなりません。
base64データーでは、テーブル1以外の文字・改行・空白文字は恐らく伝達間
違であるとことが示唆されていて、伝達間違いについて警告メッセージもし
くは排除メッセージがある状況では適切かもしれません。
コード化するデータの終わりで24ビットより少ない場合特別な処理が行われま
す。完全にコード化されるたものはボディの終わりで必ず完成します。入力グ
ループで24入力ビットより少ない場合、ゼロビットが（右に）加えられ、6ビット
グループの整数番号を形成します。データの終で補充（padding）は、"="文字を
使って行われます。base64入力は全てオクテットの整数ですので、以下のケース
のみがおこります：(1)コード化する入力の最終量は整数多元的24ビットです；こ
こではコード化られた出力の最終単位は "="補充のない整数多元的4文字です。
(2)コード化する入力の最終量が丁度8ビットである；ここではコード化された出
力の最終単位は、二つの補充文字"="がき、もしくは(3)コード化する入力の最後
の量が丁度16ビットである：ここではコード化された出力の最終単位は三つの補
充文字"="がきます。
=======================
ボディ（本文）部分
=================================================================
RFC 2046 November 1996
Multipurpose Internet Mail Extensions (MIME) Part Two:
Media Types
メディア・タイプ
3. トップ-レベルメディアタイプ概要
五つ別個のトップレベルメディアタイプには：
(1) text -- テキスト情報。特にサブタイプ"plain"は、書式化されたコマ
ンドもしくは如何なる種類の指示をいっさい内容にしていないプレー
ンテキストを指しています。プレーンテキストは、"その通りに"表示
されます。指示された文字セットのサポートのことも一切考えなく、
テキストの意味全部を得るのに何ら特別なソフトウェアーを必要とし
ません。その他のサブタイプは、アプリケーションソフトウェアーが
テキストの表示を高めますが、そのようなソフトウェアーはその内容
の一般的な考えを得るには必要ではない、enriched text用に使用され
なければなりません。かくて、"text"の可能なサブタイプは書式を理
解しているソフトウェアーに保存しなくても判読できる如何なるワー
ドプロセッサーを含みます。特に、組み込まれたバイナリー書式の情
報を採用している書式は直接判読できることを考えていません。簡単
で転送可能なサブタイプ"richtext"がRFC 1341で定義され、RFC 1896
で改訂され"enriched"となっています。
(2) image -- image data.
"jpeg" "gif"
(3) audio -- audio data.
"basic"
(4) video -- video data
"mpeg"
(5) application
"application/PostScript"
二つの合成トップ-レベルメディアタイプは：
(1) multipart "mixed"
(2) message
"partial" "external-body"
4. 個別のメディアタイプ値
4.1. テキスト・メディアタイプ（Text Media Type）
"text"メディアタイプは、書式上原理的にテクスト的な素材を送信することを
意図しています。"charset"パラメーターは"text"サブタイプ、注目すべきは
プレーンテキスト用の包括的なサブタイプであるsubtype "text/plain"をふく
み、のボディ・テキストの文字セットを指のに使われます。プレーンテキスト
は、書式コマンド・文字属性仕様・処理装置・指示解釈・内容マーク付けを提
供もしくは支給しません。プレーンテキストは単に文字の行として見られ、改
行や改頁で途切れることはあります。プレーンテキストは、テキストの同じ位
置に幾つかの文字の積み重ねを許します。アラビアとヘブライのようなスクリ
プトでのプレーンテキストは、反対に書く方向のある断片の任意の混在を許す
という機構をも持っています。
プレーンテキストを超えて、"rich text"として知られるものを表現する多く
のものがあります。多くのこのような表現の興味深い特徴は、それらを解釈す
るソフトウェアーなしでも或る程度判読可能であるということです。そこで、
これらを、高次のレベルで、画像・音響もしくは判読不可能な書式のテキスト
といった判読不可能なデーターと区別することは有益です。適切な解釈ソフト
ウェアーがなくても、利用者に"テキスト"のサブタイプを見せることは理に
適っていますが、一方大部分の非テキストデーターでそうすることは理に適っ
ていません。そのように書式化されたテクスト性データーは、"text"のサブタ
イプを使って表現されるべきです。
4.1.3. Plain サブタイプ
"text"の最もシンプルで最も重要なサブタイプは、"plain"です。これは、書
式化されたコマンドもしくは指示をいっさい内容としていないプレーンテキス
トを指します。プレーンテキストは、「そのまま」表示されるように意図され
ていて、つまり組み込まれた書式化されたコマンド・文字属性仕様・処理装
備・解釈指示もしくは内容マーク付けの解釈が、正しく表示するのに、一切必
要としないものであるべきです。インターネットメール用の"text/plain;
charset=us-ascii"という初期メディアタイプは、既存のインターネット実践
を述べています。つまり、RFC 822で定義されたボディ・タイプです。
これ以外の"text"サブタイプは、この文書では定義されていません。
4.1.4. 認識されないサブタイプ
認識されない"text"のサブタイプは、MIME装備がそのcharsetをどのように取
り扱うかが分かるなら、サブタイプ"plain"として処理されるべきです。認識
されないサブタイプで、charsetも認識されないものは、"application/
octet- stream"として処理されるべきです。
5. 合成メディアタイプの値
5.1 多元部分メディアタイプ
5.1.3 混在（Mixed）サブタイプ
5.1.4 代替（Alternative）サブタイプ
5.1.5 ダイジェスト（Digest）サブタイプ
5.1.6 並列（Parallel）サブタイプ
5.1.7 その他のマルチパート・サブタイプ
5.2 メッセージメディアタイプ
5.2.1 RFC 822 サブタイプ
5.2.2 部分（Partial）サブタイプ
5.2.3 外部ボディ（External-Body）サブタイプ
5.2.4 その他のメッセージサブタイプ
5.1.4. 代替（Alternative）サブタイプ
"multipart/alternative" タイプは構文的には"multipart/mixed"と同等でう
が、意味は異なります。特に各ボディ部分が同じ情報の代替版となります。
システムは色々な部分の内容がお互いに交換可能であることを認めるべきで
す。システムはローカルの環境や参照を基に一番いいタイプを選択すべきで
す。この例、代替は、オリジナルな内容に忠実な順に現われます。
一般的に最上の選択は、受信側システムのローカル環境によってサポートされ
ているタイプの最後の部分です。
"Multipart/alternative"は、例えば、変わったテキスト書式のメッセージを
送信するために使用されるかもしれなく、このような方法で容易に何処にでも
表示されることができます：
From: Nathaniel Borenstein
To: Ned Freed
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42
--boundary42
Content-Type: text/plain; charset=us-ascii
... メッセージのプレーンテキスト版はここに来ます。...
--boundary42
Content-Type: text/enriched
... RFC 1896 text/enriched 版のメッセージがここに来ます。...
--boundary42
Content-Type: application/x-whatever
... 変わった版のメッセージがここに来ます。 ...
--boundary42--
この例で、"application/x-whatever"書式を理解できるメールシステムの利用
者だけが変わった版を見、一方他の利用者はenrichedもしくはplainテキスト
しか見えなく、システムの能力に依存しています。
*****************************************
多元部分メディアタイプのOutlookでの事例
TEXT形式とHTML形式両者を使うと
*****************************************
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0036_01BF0E72.A07EFA40"
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
This is a multi-part message in MIME format.
------=_NextPart_000_0036_01BF0E72.A07EFA40
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
プレーンテキストがきます。
------=_NextPart_000_0036_01BF0E72.A07EFA40
Content-Type: text/html;
charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
HTML書式がきます。quoted-printableでなくbase64に設定を。
------=_NextPart_000_0036_01BF0E72.A07EFA40--
OutlookのHTML（enriched）形式は、多元部分メディアタイプの代替サブタイプの利用例ですが、全てのメーラーがサポートしていないので、HTML形式を外しておくようにと言われています。相手もサポートしていて、OKと分かれば使用してもいいのでしようが。
メール*環境*を考えて、text/html(HTML)の導入ではなく、text/enriched マインム内容タイプの導入が考えられています。以下のRFC 1896の抜粋からもその意味が伺えます。この方向が妥当なものと思います。
「送信には保守的で受信には先進的である、という一般的なインターネット指針」から見ると、Outlookの姿勢はいいとはいえません。
=================================
RFC 1896 February 1996
text/enriched マインム内容タイプ
=================================
要約
MIME [RFC-1521]は、インターネットメールの様々なデータータイプの表現の
書式と一般的な枠組みを定義しています。この文書はMIMEデーターのひとつの
特殊なタイプ、text/enriched マインムタイプを定義します。text/enriched
マインムタイプは、幅広いハードウェアーとソフトウェアーの交流でシンプル
な豊かなテキスト（enriched text）の広い相互操作性を装備するよう意図さ
れています。この文書は、[RFC-1523]と[RFC-1563]で最初に記載された豊かな
テキスト（enriched text）サブタイプの小幅な改訂版に過ぎなく、インター
ネットメールでテキスト整形の別のタイプが配置される迄、短期間使用するこ
とを意図しているだけです。
text/enriched マインムタイプ
単純な整形されたテキストの幅広い相互操作性を促進するために、この文書は
MIME内容タイプ"text"の非常に単純なサブタイプ、"text/enriched"サブタイ
プ、を定義します。このタイプの内容タイプ行は、"text/plain"MIME内容タイ
プに許されているのと同じ値を取る一つのパラメーター、"charset" パラメー
ター、を持っています。
text/enriched サブタイプは、以下の規範に合うように設計されました：
1. 構文は解析するのに非常に単純で、従ってテレタイプ指向のメールシステ
ムでさえも容易にこの整形する情報を取り去り、判読可能なテキストだけ
を解き放ちます。
2. 構文は新しい整形指示命令、アプリケーションによっては本質と考えられる、
ができるように拡張性でなければなりません。
3. 使用されている文字セットがASCIIないしは8ビットASCII上位セットなら、
データーの生の書式は、万一MIME非適合のメールリーダーの利用者の画面
で表示されることになっても、殆ど異議なく十分判読できなければなりま
せん。
4. 能力は、利用者の初歩的なワードプロセッサーでも表現できそうである以
上ののものは表現できないことを保証するために、非常に限定されなけれ
ばなりません。これは何を送信するかを制限する一方、送信されたものが
適切に表示されることができる公算を高めます。
これらの規範のあるものに合うテキスト整形標準が他にもあります。特に、
HTMLとSGMLはインターネットで広く行き渡って使われています。しかし、この
文書がそのような他の標準を越えてインターネットメールでtext/enrichedの
使用を進めるには二つの重要な理由があります：
1. 大部分のMIMEが分かるインターネットメールアプリケーションは、text/
enrichedメールを適切に書式化するか、もしくは少なくとも整形指示命令
（コマンド）を取り去り判読可能なテキストを表示することが既にできま
す。HTMLやSGMLでは同じようにはいきません。
2. 最近のHTMLに関するRFC [RFC-1866]やSGMLに関するインターネットドラフ
トは、多くの機能、インターネットメールには必要ない、を備え、text/
enrichedが既に持っている幾つかの能力を外れ守っていません。
これらの理由から、この文書はtext/enrichedの使用、別のインターネット標
準の使用がより広く行き渡る迄、を薦めています。HTMLを使いたいたい人に
は、この文書の付録Bに、text/enrichedを[RFC-1866]に記載されているHTML
2.0に変換するシンプルなCプログラムがあります。
構文
"text/enriched"の構文（使い方）は非常に単純です。単一文字セット--規定
値はUS-ASCII、で、異なる文字セットは"charset"パラメーターを使って特定
されますが、テキストを表現します。（非ASCII文字セットでのtext/enriched
の意味は、この文書の後半で言及されます。）文字全ては、整形命令の始め
をマークするのに使用される"<"文字（ASCII 60）を除いて、自分自身を表
します。字義通りのより小さいという記号（"<"）は、二つのそのような文
字の連続体、 "<<"によって表現されることができます。
整形指令は、角括弧（"<>", ASCII 60 と 62）で囲われた整形指示命令から
構成されます。各整形指示命令は長さで60文字を超さないで、全てがアルファ
ベットとハイフェン（"-"）文字に制限されたUS-ASCIIです。各整形指示命令
は個相線（"/", ASCII 47）によって先行されるかもしれなく、それらを否定し、
そのような否定は始めの開く命令とバランスをとるために必ず存在しなければ
なりません。かくて、整形命令 ""が同じ点で現われるならバランスを
とるために後のは""でなければなりません。（整形命令での60文字制
限は、そのような命令に沿え付けられる"<", ">"・もしくは"/" 文字を含まな
いことに注意してください。）整形命令は何時も大文字小文字を区別しません。
言い替えると"bold"と"BoLd"は効果の上では、好みの上ではそうでないとして
整形命令（Formatting Commands）
整形命令は全てで始まり、で終わり、この二つ
の字句（トークン）の間のテキストの整形に影響します。この命令はここで、
タイプに従ってグループ化し、説明します。
マーク付け命令（Markup Commands）
このセクションの命令は、その他のext/enriched命令と違って、宣言的なマー
ク付け言語です。Text/enrichedは全部のマーク付け言語としてでなく、代わ
りに整形命令を表現する単純な方法として考えられいます。従って、マーク付
け命令は意図的に最小に抑えられています。これらの特殊な命令が含まれてい
るのは、それが電子メール環境で普及し必要であると思えるからです。
======================================================
RFC 2049 November 1996
Multipurpose Internet Mail Extensions(MIME) Part Five:
Conformance Criteria and Examples 適合基準と事例
======================================================
1. はじめに
この一式の文書の最初と二番目の文書はMIMEヘッダーフィールドとMIMEメディ
アタイプの初期設定を定義しています。三番目の文書は、RFC 822書式に、
US-ASCII以外の文字セットを許す拡張について記載してあります。この文書で
は、適合MIME装備がサポートしなければならないのはどんな部分かを記載して
います。また、MIMEが基盤としている正式符号化モデルとともに現在のメッ
セージシステムの様々な落し穴を記載しています。
2. MIME 適合性
これら文書で記載されている機構は公開されています。装備全てが入手可能な
メディアタイプを全部サポートしているとも同じ拡張が割り当てられていると、
はっきりと期待はしていません。しかし、相互操作性を促進するために、US-
ASCIIテキストとは異なる内容をもったメッセージの、有用な相互作用を可能に
する「MIME適合」の概念を定義しておくことは有用です。このセクションで、
そのような適合性の条件を特定します。
3. メールデーター送信指針
インターネット電子メールは完全で、均一なシステムではありません。メール
は最終到着先までの旅の幾つかの段階で不正が働くかもしれません。特にイン
ターネットを経て送られるイーメールは、多くの網の目のように配置された技
術をまたがって旅するかもしれません。多くのネットワークとメール技術は
SMTP転送環境で可能な完全な機能をサポートしていません。これらのシステム
を横切るメールは、転送されることが可能な指令に変更されやすいのです。
インターネト上には多く非適合MTAsが、広く配置されています。これらMTAs、
SMTP手順のことです、で装備されているホストのインターネット構造に有利な
ように飛び交うメッセージを変更するかもしくは全く破壊します。
以下の指針は、網の目に配置されている技術と既知の破壊的なMTAsの範囲を無
傷で生き延びると考えられているデーター書式（メディアタイプ）を工夫する
人に役立つかもしれません。base64符号化方式で符号化されたものはどれで
も、これらの規則を満たしますが、よく知られた機構、UNIX uuencode装備が
有名で、のなかにはそうではないことに注意してください。またQuoted-
Printable符号化方式も大部分のゲートウェイ（通過門）を損なわれないで生
き延びますが、EBCDIC文字セットなどを使用するシステムへの通過門によって
は生き延びない可能性があります。
(5) 76文字より長い行は折り返されるかもしくはある環境では一部が切り
詰められるかもしれません。メール転送によって課せられた行折り返
しや行切り詰めは薦められませんが環境によっては避けられません。
長い行が必要なアプリケーションは、ソフトウェアーとハードウェアー
行分断でいささかことなります。（これをする簡単な方法はquoted-
printable符号化を使うことです。）
(7) 多くのメールドメインはUS-ASCII文字セットで一様でないものを使
い、もしくは大部分のUS-ASCIIがあるが全がそうではないEBCDICと
いった文字セットを使用しています。「一様＝invariant」でないセッ
トでは、文字の正しい転送は文字変換通過門通過に頼ることはできま
せん。例えば、BITNET・EBCDICシステムを経てuuencodeで符号化され
た情報を送信する場合、この状況は問題です。同じ様な問題が、ゲー
トウェイを経なくても起こり、というのは多くのインターネットホス
トが内部でUS-ASCII以外の文字セットを使用しているからです。
X.400の印字可能な列の定義は、ある特別なケースではさらなる制限を
加えます。特に、全てのゲートウェイ通過で不変であると分かってい
る文字は73文字で、大文字小文字A-Z・a-z・アラビア数字0-9と以下の
特別な十一文字だけです：
"'" (US-ASCII 十進値 39)
"(" (US-ASCII 十進値 40)
")" (US-ASCII 十進値 41)
"+" (US-ASCII 十進値 43)
"," (US-ASCII 十進値 44)
"-" (US-ASCII 十進値 45)
"." (US-ASCII 十進値 46)
"/" (US-ASCII 十進値 47)
":" (US-ASCII 十進値 58)
"=" (US-ASCII 十進値 61)
"?" (US-ASCII 十進値 63)
最大に移動できるメール表現は、意味がある文字がこの73文字一式か
らなる比較的短い行に限られています。base64符号化方式はこの規則
に従っています。
======================================================
RFC 822 August 13, 1982
STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES
から、枠組みと命名上の規約と語彙トークン（字句）
======================================================
1.2. メッセージ（交流）枠組み
メッセージはテキスト行からなっています。線画・複写・演説そして
構造化されたテキストを符号化するために、何ら特別な規定は作られていま
せん。データー圧縮問題もしくは転送や保存効率について重要な考慮は一切
払われなく、標準は使われるビット数は自由です。例えば、フィールド名は
特別な簡潔なコードでなく自由なテキストとして特定されています。
一般的な"memo"枠組みが使われています、言い替えると、メッセージ
は厳格な書式の情報つづいて主メッセージ部分、この文書で特定していない
書式を持った、が来るという構成です。厳格に書式化されたセクション
（ヘッダー＝"headers"）の構文はこの仕様書で定義されます；これら
フィールドは全てのメッセージに来なければなりません。
この文書で特定されたフィールドに加えて、その他のフィールドは普
通の使い方ができます。必要なら、これら「拡張フィールド」用の仕様は、
この文書を公開するのに使われたと同じ機構で、公開できます。個人的に使
う一式のフィールドを拡張したいと思う利用者もいるでしょう。そのような
「利用者定義フィールド」は許されています。
2. 命名上の規約
この仕様書は拡大Backus-Naur書式（BNF）命名法を用いていま
す。標準BNFとの違いは、命名規則や反復や「ローカル」代替を示唆
していることです。
2.1. 命名規則
鈎括弧は（"<"、">"）は一般に使用されていません。規則の名前は、
"<name>"でなく単に名前そのものです。引用符号はその通りの文字（大文字
かもしくは小文字であるかもしれない）を囲います。或る種の基本的な規則
はSPACE・TAB・CRLF・DIGIT・ALPHAなどのように大文字です。角括弧は、規
則定義やこの文書の後のほうで使われ、これらがあるので規則名を探すこと
が容易になります。
2.2. 規則1／規則2： 代替
スラッシュ("/")で分離された要素は、代替です。従って、
"foo / bar" は food もしくは bar を受け入れます。
2.3. （規則1／規則2）： 部分的代替
丸括弧で囲われた要素は、単一要素として処理されます。かくて、
"(elem (foo / bar) elem)" は、トクン（字句）連続体
"elem foo elem" と "elem bar elem"が可能です。
2.4. *規則： 反復
要素の前の"*"文字は、繰り返しを指します。書式は：
<l>*<m>element
は、要素の最低<l>そして最高<m>出現を指します。既定値は0から無限大
で、"*(element)" は0を含めてどんな数値でもとります；"1*element" は少
なくとも一つを必要とします；そして "1*2element" は一つもしくは二つを
許容します。
2.5. [規則]： 選択
大括弧は選択性の要素を囲います； "[foo bar]" は "*1(foo bar)"
と同じものです。
2.6. n規則（NRULE）： 特別な反復
"<n>(element)" は "<n>*<n>(element)" と同じです；つまり、
正確に<n> (element) が出現します。かくて、2DIGITは2-数値、そして
3ALPHAは三つのアルファベット文字列です。
2.7. #規則： リスト
"#"構成は、"*" と似ていて、以下のように定義されます：
<l>#<m>element
最低そして最高要素、一つ以上のコンマ（","）でお互い分離され
た、を指します。これは有効なリスト書式を大変容易に作成します； '
(element *("," element))' といった規則は "1#element" として見せるこ
とができます。この構造が使われる場合はヌール要素（null element）が許
されますが、そこにある要素にはかぞえません。
つまり、 "(element),, (element)" が許されますが、ただ二つの要素とし
て数えられます。従ってすくなくとも一つの要素が必要な場合少なくとも一
つの非ヌール要素（non-null element）が存在しなければなりません。既定
値は 0 と無限大で、"#(element)" が幾つでも、ゼロも入れて、許されま
す。"1#element" は少なくとも一つ必要です；そして "1#2element" は一つ
もしくは二つ許されます。
3. メッセージの語彙分析
3.1. 一般的な記述
メッセージは、ヘッダーファイルと選択性のボディから構成されてい
ます。このボディは単なるASCII文字を内容とする行連続体です。ヘッダー
とはヌール行（空行）で分離されています（すなわち、CRLFに先行するもの
がない行）。
電子メールは大雑把にいって、「ヘッダ」と「本文」を「空行」で区切った形式
になっています。たとえばこんな感じです。
From: kazu@iijlab.net
To: itojun@iijlab.net
Subject: test
IIJ 技術研究所のドメインでメールが届くかのテストです。
--かず
僕は、この形式に開発者のセンスを感じてしまいます。「ヘッダ」はユーザが記述す
る部分もある一方で、配送プログラムによっても付け加えられます。つまりヘッダの
長さは配送中変わるのです。長さを決めうちにせず、終端を「空行」で表すことで柔
軟に長さを変更できるようになっています。こういうデータ構造を「番兵
」(sentinel)といいます。データの終りを番兵さんが教えてくれているわけですね。
［Newsletters］の
「電子メールと日本語」 IIJ技術研究所山本和彦 からの引用
3.1.1. 長いヘッダーフィールド
各ヘッダーフィールドは、ASCII文字の単一論理的な行としてみることが
でき、フィールド名とフィールドボディを含みます。慣例として、この概念
実体のフィールドボディは多元行表現に分割できます；これは「折り重ね=
"folding"」と言われます。一般的な規則は、空行（linear-white-space）
がくるところは、最低一つのLWSP-charが直後に続くCRLFが代わりに挿入さ
れます。従って、以下の単一行
To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN
は、以下のように表現できます：
To: "Joe & J. Harvey" <ddd @ Org>,
JJV@BBN
や
To: "Joe & J. Harvey"
<ddd@ Org>, JJV
@BBN
や
To: "Joe &
J. Harvey" <ddd @ Org>, JJV @ BBN
ヘッダーフィールドの折り重ねられた多元行表現からその単一行
表現への移行は、「折り重ね復元="unfolding"」といわれます。「折り
重ね復元="unfolding"」は、LWSP-charが直後にあるCRLFをLWSP-charと
等価なものとして解釈することで、成し遂げられます。
注意： 標準では、空白行が入れられる所ならどこででも折り重ねが許さ
れますが、構造化されたフィールド、アドレス（address）が来
る所のような、は折り重ねをより高次レベル構文分断に限定して
います。アドレスでは、そのような折り重ねは住所間で分離コン
マの後に来るよう薦められています。
3.3. 語彙トークン（語彙字句）
以下の規則は、基本的な語彙解析を定義するのに使われていて、高次
レベル解析にトークンを送り込みます。文献のANSI資料をみて下さい。
; ( Octal, Decimal.)
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
ALPHA = <any ASCII alphabetic character>
; (101-132, 65.- 90.)
; (141-172, 97.-122.)
DIGIT = <any ASCII decimal digit> ; ( 60- 71, 48.- 57.)
CTL = <any ASCII control ; ( 0- 37, 0.- 31.)
character and DEL> ; ( 177, 127.)
CR = <ASCII CR, carriage return> ; ( 15, 13.)
LF = <ASCII LF, linefeed> ; ( 12, 10.)
SPACE = <ASCII SP, space> ; ( 40, 32.)
HTAB = <ASCII HT, horizontal-tab> ; ( 11, 9.)
<"> = <ASCII quote mark> ; ( 42, 34.)
CRLF = CR LF
LWSP-char = SPACE / HTAB ; 意味は = SPACE
linear-white-space = 1*([CRLF] LWSP-char) ; 意味は = SPACE
; CRLF => folding
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "¥" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
delimiters = specials / linear-white-space / comment
text = <any CHAR, including bare ; => atoms, specials,
CR & bare LF, but NOT ; comments and
including CRLF> ; quoted-strings are
; NOT recognized.
atom = 1*<any CHAR except specials, SPACE and CTLs>
quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or
; quoted chars.
qtext = <any CHAR excepting <">, ; => may be folded
"¥" & CR, and including
linear-white-space>
domain-literal = "[" *(dtext / quoted-pair) "]"
dtext = <any CHAR excluding "[", ; => may be folded
"]", "¥" & CR, & including
linear-white-space>
comment = "(" *(ctext / quoted-pair / comment) ")"
ctext = <any CHAR excluding "(", ; => may be folded
")", "¥" & CR, & including
linear-white-space>
quoted-pair = "¥" CHAR ; may quote any char
phrase = 1*word ; Sequence of words
word = atom / quoted-string
3.4. 説明
3.4.8. 長いヘッダーフィールドの折り重ね
各ヘッダーフィールドは、フィールド名とそのボディでCRLFで終わるも
のから構成される、正確に一つの行で表現されるかもしれません；これ
がパーサーが見ているものです。読み易さのために、長いヘッダー
フィールドは実際のフィールドでは多元行に「折り重ね」られるかもし
れません。「長い」とは、普通65もしくは72文字以上を意味すると解釈
されます。前者の長さが、シンプルな表示ソフトウェアーの最もシンプ
ルな端末でメッセージを閲覧する場合、制限になります；しかしこの制
限はこの仕様書は課せていません。
#^目次へ
メールの文字や転送の問題は、2000年問題と類似して考えておくとよく、
メール転送と2000年問題の両方の本質が掴めると思います。
＿＿引用 on
「2000年問題は世紀の変わり目の総力戦」からの引用
公文俊平
［http://www.glocom.ac.jp/proj/y2k/kumonvoice.html］
この問題は、四桁の西暦年号を下二桁だけで処理することにした慣行に由来する。そ
れが最初に広く採用された1960年代には、このような処理の仕方は実害がないばかり
か、当時は現在の百万倍も高価だったというコンピューター・メモリーの節約に貢献
する点でも、短期的には合理的な決定だったといえるだろう。日付を表わすデータ・
フィールドは、年月日あわせて6桁分を用意しておけば足りた。4桁年号がほしい場合
には、自動的に「19」を付加すればよかった。だが、このようなやり方を続けていけ
ば、世紀の変わり目が来て、年号の上二桁に別の数値を付加したり、異なる数値を混
在させる必要が生じた場合には、コンピューターの停止や誤作動が起こることは確実
だった。これがいわゆるコンピューターの「2000年バグ」に他ならない (1)。
＿＿引用 off
メールについても全く同じことがいえます。US-ASCIIだけでよかった慣行とメモ
リーが少なくて済むことは、両者に共通のスタートです。メールサーバーを新し
くするといっても世界中にあり、経済的にも新しいものに変えられない所もある
かもしれません。しかも、インターネットメールはどのサーバーを経由するのか
は分かりませんので、新しいものを導入しても不備がおこります。
そこで、基本的にはスター時のようなメールサーバーを通過する書式で、受信側
で対応していこうと言う符号化が考えられ（安全な符号化としてbase64 が考案さ
れ）、それに文字や符号化情報を加えてMIME書式で対応しようと言うことです。
通り道は、昔のまま（7ビットや6ビット）のものでもいいことになります。MIME
関連のRFCに「前のプログラムを排除しないで」と言う記載がでてきます。2000年
問題の対応は、これとはやや趣を異にします。
#^目次へ
[戻る][
HTML 4.0翻訳メモ：日本語字体コード][
HTML 3.2翻訳日本語字体コード]
このページはiso-2022-jp(JIS) 版で、
URLは、"http://www.asahi-net.or.jp/‾bd9y-ktu/dtd_f/mime.html" です。
加藤泰孝（bd9y-ktu@asahi-net.or.jp）
emai : y.kato@personal.email.ne.jp
Last modified 99.08.29
［ホームページ］