<抜粋引用> ---------------------- 電子メールと日本語 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 2049、は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. 命名規則 鈎括弧は("<"、">")は一般に使用されていません。規則の名前は、 ""でなく単に名前そのものです。引用符号はその通りの文字(大文字 かもしくは小文字であるかもしれない)を囲います。或る種の基本的な規則 はSPACE・TAB・CRLF・DIGIT・ALPHAなどのように大文字です。角括弧は、 規則定義やこの文書の後のほうで使われ、これらがあるので規則名を探す ことが容易になります。 2.2. 規則1/規則2: 代替 スラッシュ("/")で分離された要素は、代替です。従って、 "foo / bar" は foo もしくは bar を受け入れます。 2.3. (規則1/規則2): 部分的代替 丸括弧で囲われた要素は、単一要素として処理されます。かくて、 "(elem (foo / bar) elem)" は、トクン(字句)連続体 "elem foo elem" と "elem bar elem"が可能です。 2.4. *規則: 反復 要素の前の"*"文字は、繰り返しを指します。書式は: *element は、要素の最低そして最高出現を指します。既定値は0から無限大 で、"*(element)" は0を含めてどんな数値でもとります; "1*element" は 少なくとも一つを必要とします; そして "1*2element" は一つもしくは二 つを許容します。 2.5. [規則]: 選択 大括弧は選択性の要素を囲います; "[foo bar]" は "*1(foo bar)" と同 じものです。 2.6. n規則(NRULE): 特別な反復 "(element)" は "*(element)" と同じです; つまり、正確に (element) が出現します。かくて、2DIGITは2-数値、そして 3ALPHAは三つ のアルファベット文字列です。 2.7. #規則: リスト "#"構成は、"*" と似ていて、以下のように定義されます: #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" , JJV @ BBN は、以下のように表現できます: To: "Joe & J. Harvey" , JJV@BBN や To: "Joe & J. Harvey" , JJV @BBN や To: "Joe & J. Harvey" , JJV @ BBN ヘッダーフィールドの折り重ねられた多元行表現からその単一行表現への 移行は、「折り重ね復元="unfolding"」といわれます。「折り重ね復元 ="unfolding"」は、LWSP-charが直後にあるCRLFをLWSP-charと等価なもの として解釈することで、成し遂げられます。 注意: 標準では、空白行が入れられる所ならどこででも折り重ねが許され ますが、構造化されたフィールド、アドレス(address)が来る所のよ うな、は折り重ねをより高次レベル構文分断に限定しています。ア ドレスでは、そのような折り重ねは住所間で分離コンマの後に来る よう薦められています。 3.3. 語彙トークン(語彙字句) 以下の規則は、基本的な語彙解析を定義するのに使われていて、高次レベ ル解析にトークンを送り込みます。文献のANSI資料をみて下さい。 ; ( Octal, Decimal.) CHAR = ; ( 0-177, 0.-127.) ALPHA = ; (101-132, 65.- 90.) ; (141-172, 97.-122.) DIGIT = ; ( 60- 71, 48.- 57.) CTL = ; ( 177, 127.) CR = ; ( 15, 13.) LF = ; ( 12, 10.) SPACE = ; ( 40, 32.) HTAB = ; ( 11, 9.) <"> = ; ( 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 = atoms, specials, CR & bare LF, but NOT ; comments and including CRLF> ; quoted-strings are ; NOT recognized. atom = 1* quoted-string = <"> *(qtext/quoted-pair) <"> Regular qtext or ; quoted chars. qtext = , ; => may be folded "\" & CR, and including linear-white-space> domain-literal = "[" *(dtext / quoted-pair) "]" dtext = may be folded "]", "\" & CR, & including linear-white-space> comment = "(" *(ctext / quoted-pair / comment) ")" ctext = 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文字以上を意味すると解釈されます。前 者の長さが、シンプルな表示ソフトウェアーの最もシンプルな端末でメッ セージを閲覧する場合、制限になります; しかしこの制限はこの仕様書は 課せていません。