このファイルは Emacs MIME インターフェースの機能を文書化したものです。

Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005 Free Software Foundation, Inc.

     Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover texts being ``A GNU Manual'', and with the Back-Cover Texts as in (a) below.  A copy of the license is included in the section entitled ``GNU Free Documentation License'' in the Emacs manual.

     この文書を、フリーソフトウェア財団発行の GNU フリー文書利用許諾契約書第 1.2 版またはそれ以降の版が定める条件の下で複製、配布、あるいは変更することを許可します。変更不可部分は指定しません。「A GNU Manual」は表表紙テキスト、以下の (a) は裏表紙テキストです。この利用許諾契約書の複写は「Emacs manual」の「GNU フリー文書利用許諾契約書」という章に含まれています。

     (a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify this GNU Manual, like GNU software.  Copies published by the Free Software Foundation raise funds for GNU development.''

     (a) FSF の裏表紙テキスト:「あなたにはこの GNU Manual を GNU ソフトウェアのように複製したり変更する自由があります。複製はフリーソフトウェア財団によって出版されました。(フリーソフトウェア財団は) GNU の開発のために必要な資金を集めています。」

     This document is part of a collection distributed under the GNU Free Documentation License.  If you want to distribute this document separately from the collection, you can do so by adding a copy of the license to the document, as described in section 6 of the license.

     この文書は「GNU フリー文書利用許諾契約書」に基づいて配布された収集著作物の一部です。もしあなたがこの文書を収集著作物から分離して配布したいときは、契約書の第 6 項に記述されているように、文書に契約書の複写を付加することによって、行なうことができます。

Emacs MIME
**********

このマニュアルは MIME メッセージの表示と作成に使われるライブラリーを文書化したものです。

このマニュアルは、MIME のエンコード/デコード・プロセスの振る舞いを変更したいか、Emacs MIME ライブラリーがどのように動作するかのもっと詳細な描写を望むユーザ、および MIME の要素を操作する関数およびコマンドを書きたい人たちを対象にしています。

MIME は Multipurpose Internet Mail Extensions の省略表記です。この標準は多数の RFC に文書化されていて、主なものは次の通りです: RFC2045 (インターネット・メッセージ本文の書式), RFC2046 (メディアタイプ), RFC2047 (メッセージヘッダーの非-ASCII テキスト拡張), RFC2048 (登録手続), RFC2049 (適合基準と事例)。MIME に準拠したソフトウェアを書こうと思っている人は誰でも、少なくとも RFC2045 と RFC2047 は読んでおくことを強く勧めます。

デコードと表示
*******

この章は、上位階層での MIME メッセージのデコードと表示を扱います。

その主な目的は、最初に MIME の記事を解析し、次にその解析の結果返される「ハンドル」 のリストに基づいて、他のプログラムが物事を行なうことを可能にすることです。

解体
==

mm-dissect-buffer は MIME 記事の解体を担当する関数です。マルチパートのメッセージが与えられると、メッセージを再帰的に掘り下げ、構造に従って、そのメッセージの構造を描写する MIME ハンドルの木構造を返します。

非-MIME
======

Gnus はいくつかの非-MIME の添付ファイルも理解します。それらは postscript, uuencode, binhex, yenc, shar, forward, gnatsweb, pgp, diff のようなものです。それぞれの機能は mm-uu-configure-list に項目を追加することによって、無効にすることができます。例です。

     (require 'mm-uu)
     (add-to-list 'mm-uu-configure-list '(pgp-signed . disabled))

postscript
     ポストスクリプトのファイル。

uu
     Uuencode されたファイル。

binhex
     Binhex でエンコードされたファイル。

yenc
     Yenc でエンコードされたファイル。

shar
     Shar 書庫ファイル。

forward
     非-MIME で転送されたメッセージ。

gnatsweb
     Gnatsweb の添付ファイル。

pgp-signed
     PGP で署名された平文 (clear text)。

pgp-encrypted
     PGP で暗号化された平文 (clear text)。

pgp-key
     PGP の公開鍵。

emacs-sources
     Emacs のソースコード。この項目は mm-uu-emacs-sources-regexp に合致するグループでのみ動作します。

diff
     パッチ。これは、コミットされたファイルの差分が自動的に送られるグループを対象にしたものです。mm-uu-diff-groups-regexp に合致するグループでのみ動作します。

ハンドル
====

MIME ハンドルは、MIME の構成要素を完全に記述するリストです。

ハンドルの要素をアクセスするために、以下のマクロを使うことができます:

mm-handle-buffer
     デコードされていない MIME パートの内容物を保持しているバッファを返します。

mm-handle-type
     解析済みの、パートの Content-Type を返します。

mm-handle-encoding
     パートの Content-Transfer-Encoding を返します。

mm-handle-undisplayer
     表示されているパートを消すことができるもの (訳注: 関数など) を (それが表示されている場合に) 返します。

mm-handle-set-undisplayer
     表示されているパートを消すことができるもの (訳注: 関数など) を設定します。

mm-handle-disposition
     解析済みの、パートの Content-Disposition (訳注: 配置指定) を返します。

mm-get-content-id
     Content-ID で参照されるハンドル (単数または複数) を返します。

表示
==

表示し、消去し、保存するための関数。

mm-display-part
     パートを表示します。

mm-remove-part
     パートを (それが表示されていたら) 消去します。

mm-inlinable-p
     MIME タイプがインラインで表示可能かどうかを返します。

mm-automatic-display-p
     MIME タイプが自動的に表示されるべきかどうかを返します。

mm-destroy-part
     パートによって使われているすべての資源を開放します (訳注: パートの表示、およびパートを解体して得た個々の部品を一時的に保持しているバッファやファイルを消去します)。

mm-save-part
     パートをファイルに保存します。

mm-pipe-part
     パートをあるプロセスにパイプします。

mm-interactively-view-part
     パートを表示するために使う mailcap の手段を尋ねます。

表示のカスタマイズ
=========

mm-inline-media-tests
     これは連想リストです。鍵 (第一要素) は MIME タイプ、第二要素はパートを インライン で (すなわち Emacs の画面に埋め込んで) 表示するための関数、そして第三要素はそのパートがインラインで表示することが可能かどうかを調べるために評価 (eval) されるフォームです。

     この変数は、あるパートがインライン表示可能かどうかと、もし可能ならそのやり方を指定します。パートが現実にインライン表示されているかどうかを示すものではありません。

mm-inlined-types
     一方これは、上記の変数によって設定された条件を満足する、インライン表示可能なタイプを示します。これは MIME メディアタイプのリストです。 (訳注: それぞれの要素は正規表現です。)

mm-automatic-display
     これは上記の変数が認めるタイプのうちで、「自動的」に表示されるタイプのリストです。つまり、インライン表示が可能なパートだけが自動的に表示されます。

mm-automatic-external-display
     これは外部ビューワーで自動的に表示されるタイプのリストです。

mm-keep-viewer-alive-types
     これは、別の記事を選択しても、外部ビューワーが kill されないメディアタイプのリストです。

          訳注: postscript や dvi など (変数のディフォルト値を参照のこと) のように、読むのに時間がかかるかもしれないパートのタイプを含むリストです。一方、これに含まれない単純な画像のパートなどは、それが含まれていた記事の表示をやめたときに、自動的に外部ビューワーが kill されます。

mm-attachment-override-types
     いくつかの MIME エージェントは、配置指定 (content-disposition) として 添付 (attachment) ファイルであることを設定したパートを生成します。この変数はそんな配置指定を上書きして、そのパートをインライン表示することを許します。(そのパートのインライン表示することが可能で、私たちがそうすることを望む場合だけ、配置指定が上書きされることに注意して下さい。)

mm-discouraged-alternatives
     multipart/alternative を表示することが嫌われる MIME タイプのリストです。それが最も興味深いものであると想定しているために、表示エージェントはメッセージの後半にある可視なパートを表示することになっています。しかし、ユーザーは代わりに他のタイプを好むかもしれません。このリストは、何のタイプが最も望まれないかを示します。例えばもし、 text/html パートは非常に望まず、かつ text/richtext パートをやや望まないということであれば、以下のように宣言することができます:

          (setq mm-discouraged-alternatives
                '("text/html" "text/richtext")
                mm-automatic-display
                (remove "text/html" mm-automatic-display))

mm-inline-large-images
     ウィンドウより大きなインライン画像を表示すると、Emacs はスクロールすることができない、つまり画像の全体を見ることができません。これを避けるため、ライブラリーはそれをインライン表示する前に画像のサイズを計って、それがウィンドウに合わない場合は、ライブラリーはそれを外部で (例えば ImageMagick や xv で) 表示します。この変数を t に設定するとこの検査をさせなくして、ライブラリーにすべてのインライン画像をサイズに関わりなくインラインで表示させます。

mm-inline-override-types
     mm-inlined-types は、例えばすべての text/.* パートをインラインで表示することを指示するような、正規表現を含むことができます。一方、インライン表示が可能だけれども添付ファイルとして扱いたいタイプがあるならば、そのタイプに合致する正規表現のリストを、この変数に設定することによって成し遂げることができます。例えば mm-inlined-types が text/.* を含んでいるものとすると、この変数に text/html を含ませることによって、text/html パートは添付ファイルとして扱われるようになります。

mm-text-html-renderer
     HTML を描画するために使う関数を選択します。すでに用意してある描画プログラムは、w3, w3m (emacs-w3m についての詳細は http://emacs-w3m.namazu.org/ を見て下さい。), links, lynx, w3m-standalone または html2text のシンボル群のうちの一つを指定することによって選択します。もし nil だったら、外部ビューワーを使います。さらに関数 (引数として MIME ハンドルが与えられて呼ばれる) を設定することもできます。

mm-inline-text-html-with-images
     HTML メールには <img> タグを使った spammers (spam をばらまくやから) の卑劣な悪巧みが含まれているかもしれません。最もありそうなのは、あなたがそのメールを読んだことを確認するための意図があることです。このオプションを nil に設定する (それがディフォルトです) ことによって、あなたの個人情報が流出するのを防ぐことができます。現在 Emacs/w3 は、これを無視します。Emacs-w3m では、これが nil であっても、画像を表示するために、それが埋め込まれた場所で t コマンドを使うことができます。 (T コマンドはすべての画像を取り込みます。 w3m-key-binding オプションを info に設定したならば、代わりに i か I を使って下さい。)

mm-w3m-safe-url-regexp
     安全な URL 名、すなわち HTML メールを描画するときに個人情報が流出しそうもない URL に合致する正規表現です (ディフォルト値は \\`cid: です)。nil であると、すべての URL が安全だと判断します。

mm-inline-text-html-with-w3m-keymap
     このオプションを非-nil に設定することによって、インライン表示された text/html パートで emacs-w3m のコマンドキーを使うことができます。ディフォルト値は t です。

mm-external-terminal-program
     外部の端末を起動するために使われるプログラムです。

mm-enable-external
     外部の MIME ハンドラーを使うべきかどうかを指定します。

     t であると、定義されたすべての外部の MIME ハンドラーが使われます。nil だったら、ファイルはディスクに保存されます (mailcap-save-binary-file)。これが ask というシンボルであったならば、外部の MIME ハンドラーが起動される前に尋ねられるでしょう。

     Mailcap (see mailcap) を介して添付ファイルの表示を始めると、最も安全なオプションで安全なビューワーを使うことを試みます (添付ファイルをディスクに保存して、異なる手段 (コマンドラインかダブルクリック) でその表示を始める場合とは違います)。とにかく、どんな外部プログラムも使いたくないのであれば、この変数を nil か ask に設定して下さい。

ファイルとディレクトリー
============

mm-default-directory
     添付ファイルを保存するディフォルトのディレクトリーです。nil だったら default-directory を使います。

mm-tmp-directory
     一時ファイルを格納するディレクトリーです。

mm-file-name-rewrite-functions
     MIME パートのファイル名を書き換えるために使われる関数のリストです。それぞれの関数はファイル名を受け取って、ファイル名を返します。出来合いの関数は以下の通りです。

     mm-file-name-delete-control
          すべての制御文字を消去します。

     mm-file-name-delete-gotchas
          弱みがあるシェルスクリプトで使われると意図しない結果を生じる文字、すなわち |, > および <、加えて最初の文字として使われる - と . を消去します。

     mm-file-name-delete-whitespace
          すべての空白文字を取り除きます。

     mm-file-name-trim-whitespace
          先頭と末尾の空白文字を取り除きます。

     mm-file-name-collapse-whitespace
          複数の連続した空白文字を単一のスペース文字で置き換えます。

     mm-file-name-replace-whitespace
          空白文字を下線 (underscore) で置き換えます。下線がお好みでなければ、他の文字を mm-file-name-replace-whitespace 変数に設定して下さい。

     Emacs 標準の関数である capitalize, downcase, upcase および upcase-initials も、役立つことは明らかです。

mm-path-name-rewrite-functions
     MIME パートのフル・ファイル名を書き換えるために使われる関数のリストです。これはパートを外部に表示するとき (すなわち、融通の効かないプログラムが、ファイルが保存された場所を見つけることができるように、絶対パス名を変換するため) に使われます。

新しいビューワー
========

これは text/enriched パートをインライン表示するビューワーの例です:

     (defun mm-display-enriched-inline (handle)
       (let (text)
         (with-temp-buffer
           (mm-insert-part handle)
           (save-window-excursion
             (enriched-decode (point-min) (point-max))
             (setq text (buffer-string))))
         (mm-insert-inline handle text)))

この関数がパラメータとして MIME ハンドルを受け取ることがわかりますね。それは一時バッファに作業場所を移し、パートのテキストを挿入し、そのテキストにある処理を施し、結果を覚えておいて、関数が呼ばれたときのバッファに戻ってその結果を挿入します。

ここにある二つの重要なお助け関数は mm-insert-part と mm-insert-inline です。最初の関数は、ハンドルのテキストを現在のバッファに挿入します。これは文字セットおよびエンコーディグ (content transfer decoding) を取り扱います。二番目の関数は、挿入しろと言ったどんなテキストでも単に挿入しますが、テキストを手軽な方法で「表示されなくする (undisplayed)」ことができるような諸設定をも行ないます。

MIME メッセージの作成
*************

MIME メッセージの作成はうんざりする仕事だし簡単でもありません。そこで、MML (MIME Meta Language) という、言語を解析して MIME メッセージを生成するための、mml というライブラリーが作られました。

主要なインターフェース関数は mml-generate-mime です。これは現在の (狭められた) バッファの内容物を調べて、MIME メッセージを含む文字列を返します。

単純な MML の例
==========

multipart/alternative の単純な例です:

     <#multipart type=alternative>
     This is a plain text part.
     これはプレーンテキストのパートです。
     <#part type=text/enriched>
     <center>This is a centered enriched part</center>
     <center>これは中心に置かれる enriched パートです</center>
     <#/multipart>

これを mml-generate-mime に通すと、次のものが得られます:

     Content-Type: multipart/alternative; boundary="=-=-="

     --=-=-=
     Content-Type: text/plain; charset=iso-2022-jp

     This is a plain text part.
     ^[$B$3$l$O%W%l!<%s%F%-%9%H$N%Q!<%H$G$9!#^[(B

     --=-=-=
     Content-Type: text/enriched; charset=iso-2022-jp

     <center>This is a centered enriched part</center>
     <center>^[$B$3$l$OCf?4$KCV$+$l$k^[(B enriched ^[$B%Q!<%H$G$9^[(B</center>

     --=-=-=--

わっ、文字化けだ!?  いいえ、もとの文が charset=iso-2022-jp でエンコードされたものです。受信者が見るときに、適切にデコードされるでしょう。

MML の定義
=======

MML 言語はとても単純です。SGML アプリケーションに少し似ていますが、異なるものです。

MML の主要な概念は パート です。それぞれのパートは異なるタイプか異なる文字セットのものであり得ます。パートは <#part ...> タグで記述されます。マルチパート型のパートでは <#multipart ...> タグが用いられます。それぞれのパートは <#/part> タグか <#/multipart> タグで終端されますが、さらに、<#part ...> で始まったタグは次のパートの始まりによっても閉じられます。

<#external ...> タグというものもあります。これは external/message-body 型のパートを記述するために使われます。

それぞれのタグは parameter=値 の形式でパラメータを含むことができます。値をクォーテーションマーク ("...") で囲むことができますが、値が空白文字を含む場合以外は囲む必要がありません。したがって、 filename=/home/user/#hello$^yes は完全に有効です。

以下のパラメータは MML で使われます。意味を持たないパラメータは無視されます。MML パラメータの名前は MIME パラメータの名前と同じで、括弧の中にあるものは、それがどのヘッダーの中で使われるかを宣言します。

type
     パートの MIME タイプです (Content-Type)。

filename
     パートに含ませるファイルの名前です (Content-Disposition)。

charset
     パートの内容物をエンコードするときに使われる文字セットです (Content-Type)。See Charset Translation.

name
     パートをファイルに保存するときのファイル名を示唆するために使われるかもしれません (Content-Type)。

disposition
     配置指定に使います。有効な値は inline と attachment です (Content-Disposition)。

encoding
     有効な値は 7bit, 8bit, quoted-printable および base64 です (Content-Transfer-Encoding)。See Charset Translation.

description
     パートの説明書きです (Content-Description)。

creation-date
     パートが作成された時刻 (RFC822 形式) です (Content-Disposition)。

modification-date
     パートが変更された時刻 (RFC822 形式) です (Content-Disposition)。

read-date
     パートが読まれた時刻 (RFC822 形式) です (Content-Disposition)。

recipients
     パートを誰宛てに暗号化/署名するかを指定します。これは To/CC を基にした自動検出よりも優先されます。

sender
     パートに署名するときの名義です。このフィールドはディフォルトの鍵が使われないようにするために使われます。

size
     パートのサイズを octet (8-bit) の単位で表します (Content-Disposition)。

sign
     この MML のパートに、何の技術手段 (smime, pgp または pgpmime) で署名するかを指定します。

encrypt
     この MML のパートを、何の技術手段 (smime, pgp または pgpmime) で暗号化するかを指定します。

以下は text/plain のためのパラメータです:

format
     テキストをフォーマットするパラメータで、有効な値は fixed (ディフォルト) と flowed です。普通はこれを手で設定する必要はありません。それは、テキストの本文が、RFC 2646 で定められた特別な方法でフォーマットされることを必要とするからです。See Flowed text.

以下は application/octet-stream のためのパラメータです:

type
     パートのタイプ (人間が読むことを想定した、非公式な) です (Content-Type)。

以下は message/external-body のためのパラメータです:

access-type
     ファイルを取得するための、サポートされているアクセス手段を示す語です。値は ftp, anon-ftp, tftp, localfile および mailserver のどれかです。(Content-Type.)

expiration
     ファイルが取得できなくなるかもしれない日時 (RFC822 形式) です。 (Content-Type.)

size
     Octet (8-bit) の単位で表したファイルのサイズです。(Content-Type.)

permission
     有効な値は read と read-write です (Content-Type)。

以下は sign=smime のためのパラメータです:

keyfile
     署名する人の証明書を含んでいるファイルです。

以下は encrypt=smime のためのパラメータです:

certfile
     受取人の証明書を含んでいるファイルです。

高度な MML の例
==========

複雑なマルチパート・メッセージの例です。これは multipart/mixed です。多数のパートを含んでいて、その一つは multipart/alternative です。

     <#multipart type=mixed>
     <#part type=image/jpeg filename=~/rms.jpg disposition=inline>
     <#multipart type=alternative>
     This is a plain text part.
     これはプレーンテキストのパートです。
     <#part type=text/enriched name=enriched.txt>
     <center>This is a centered enriched part</center>
     <center>これは中心に置かれる enriched パートです</center>
     <#/multipart>
     This is a new plain text part.
     これは新しいプレーンテキストのパートです。
     <#part disposition=attachment>
     This plain text part is an attachment.
     このプレーンテキストのパートは添付ファイルです。
     <#/multipart>

And this is the resulting MIME message:

     Content-Type: multipart/mixed; boundary="=-=-="

     --=-=-=
     Content-Type: image/jpeg
     Content-Disposition: inline; filename=rms.jpg
     Content-Transfer-Encoding: base64

     /9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRof
     Hh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/wAALCAAwADABAREA/8QAHwAA
     AQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQR
     BRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RF
     RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ip
     qrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEB
     AAA/AO/rifFHjldNuGsrDa0qcSSHkA+gHrXKw+LtWLrMb+RgTyhbr+HSug07xNqV9fQtZrNI
     AyiaE/NuBPOOOP0rvRNE880KOC8TbXXGCv1FPqjrF4LDR7u5L7SkTFT/ALWOP1xXgTuXfc7E
     sx6nua6rwp4IvvEM8chCxWxOdzn7wz6V9AaB4S07w9p5itow0rDLSY5Pt9K43xO66P4xs71m
     2QXiGCbA4yOVJ9+1aYORkdK434lyNH4ahCnG66VT9Nj15JFbPdX0MS43M4VQf5/yr2vSpLnw
     5ZW8dlCZ8KFXjOPX0/mK6rSPEGt3Angu44fNEReHYNvIH3TzXDeKNO8RX+kSX2ouZkicTIOc
     L+g7E810ulFjpVtv3bwgB3HJyK5L4quY/C9sVxk3ij/xx6850u7t1mtp/wDlpEw3An3Jr3Dw
     34gsbWza4nBlhC5LDsaW6+IFgupQyCF3iHH7gA7c9R9ay7zx6t7aX9jHC4smhfBkGCvHGfrm
     tLQ7hbnRrV1GPkAP1x1/Hr+Ncr8Vzjwrbf8AX6v/AKA9eQRyYlQk8Yx9K6XTNbkgia2ciSIn
     7p5Ga9Atte0LTLKO6it4i7dVRFJDcZ4PvXN+JvEMF9bILVGXJLSZ4zkjivRPDaeX4b08HOTC
     pOffmua+KkbS+GLVUGT9tT/0B68eeIpIFYjB70+OOVXyoOM9+M1eaWeCLzHPyHGO/NVWvJJm
     jQ8KGH1NfQWhXSXmh2c8eArRLwO3HSv/2Q==
     --=-=-=
     Content-Type: multipart/alternative; boundary="==-=-="

     --==-=-=
     Content-Type: text/plain; charset=iso-2022-jp

     This is a plain text part.
     ^[$B$3$l$O%W%l!<%s%F%-%9%H$N%Q!<%H$G$9!#^[(B

     --==-=-=
     Content-Type: text/enriched; charset=iso-2022-jp; name=enriched.txt

     <center>This is a centered enriched part</center>
     <center>^[$B$3$l$OCf?4$KCV$+$l$k^[(B enriched ^[$B%Q!<%H$G$9^[(B</center>

     --==-=-=--

     --=-=-=
     Content-Type: text/plain; charset=iso-2022-jp

     This is a new plain text part.
     ^[$B$3$l$O?7$7$$%W%l!<%s%F%-%9%H$N%Q!<%H$G$9!#^[(B

     --=-=-=
     Content-Type: text/plain; charset=iso-2022-jp
     Content-Disposition: attachment

     This plain text part is an attachment.
     ^[$B$3$N%W%l!<%s%F%-%9%H$N%Q!<%H$OE:IU%U%!%$%k$G$9!#^[(B

     --=-=-=--

ややっ、文字化けしてる!?  いや、もとの文が charset=iso-2022-jp でエンコードされただけのことです。受信者が見るときに、適切にデコードされるでしょう。

エンコーディングのカスタマイズ
===============

mm-body-charset-encoding-alist
     MIME 文字セットに割り当てるエンコーディングです。この変数は、例えば他の要件によって特定のエンコーディングが強制されないときに、通常使われます (電子署名されたメッセージは 7bit エンコーディングを必要とします)。ディフォルト値は次の通りです。

          ((iso-2022-jp . 7bit)
           (iso-2022-jp-2 . 7bit)
           (utf-16 . base64)
           (utf-16be . base64)
           (utf-16le . base64))

     例えば ISO-8859-1 文字セットが quoted-printable でエンコードされないようにしたい場合は、この変数に (iso-8859-1 . 8bit) を追加すれば良いでしょう。MML の encoding タグを使って、メッセージ毎にそれをこの変数より優先させることもできます (see MML Definition)。

mm-coding-system-priorities
     送出するメッセージで使う coding system の優先度を指定します。ディフォルト値は nil です (その場合は Emacs におけるディフォルトの優先順位が適用される) が、日本語環境で Emacs を実行する場合は (iso-8859-1 iso-2022-jp iso-2022-jp-2 shift_jis utf-8) になります。値は coding system のシンボルのリストです (coding system の別名を使っても構いません。設定するときは M-x describe-coding-system を使って、coding system の名前が正確であることを確かめて下さい)。例えば UTF-8 を最優先とするように Emacs を設定したものの、可能な場合は ISO-8859-1 で メッセージを送信するようにしたいという場合だったら、この変数を (iso-8859-1) にすれば良いでしょう。 MML の charset タグを使って、メッセージ毎にそれをこの変数より優先させることもできます (see MML Definition)。

          訳注: 日本語環境とは current-language-environment 変数の値が Japanese になっている環境のことです。日本語のメッセージのエンコードには伝統的に iso-2022-jp が使われているのに対し、Emacs で定められた優先順位に基づくと euc-jp や shift_jis などが第一候補になってしまうので、この値が nil ではよろしくないのです。

          なお、ラテン語圏の人たちに宛ててに送るメッセージが、彼らがデコードできないかもしれない iso-2022-jp-2 などでエンコードされてしまうのを防ぐために、ディフォルト値の先頭に iso-8859-1 が置かれています。

mm-content-transfer-encoding-defaults
     MIME のタイプに割り当てるエンコーディングです。この変数は、例えば他の要件によってより安全なエンコーディングが強制されないときに、通常使われます (電子署名されたメッセージは 7bit エンコーディングを必要とします)。通常の MIME エンコーディングの他に、 quoted-printable と base64 のうちで最も効率的な方を、個々の場合に使うべきであることを示す qp-or-base64 を使うこともできます (訳注: qp-or-base64 の実際の動作は、quoted-printable と base64 の両方でエンコードしてみて、サイズが小さくなる方を採用することです)。

     qp-or-base64 にはもう一つの効果があります。それは MIME のパートが MTA によって壊されないようにするために、長い行を折り畳みます。quoted-printable と base64 もそうです。

     パートが受信したときのままの生の転送されたメッセージ (例えば、引数に 2 を与えた gnus-summary-mail-forward によって作られるもの) であるか、text/* タイプや message/* ではない場合に、これが本文のエンコーディグに影響を与えることに注意して下さい。それらの場合でさえ、 MML の encoding タグを使って、メッセージ毎にそれをこの変数より優先させることもできます (see MML Definition)。

mm-use-ultra-safe-encoding
     これが非-nil である場合、本文に 76 文字よりも長い行や "From " で始まる行があったら、それらのテキストのパートは quoted-printable でエンコードされます。非-7bit エンコーディング (8bit, バイナリー) は一般に認められていません。これは 8bit を通さない MTA か MDA がメッセージを改変してしまう確率を下げます。これは直接に設定されるのではなく、他の関数によって (例えば、電子署名されるメッセージをエンコードするときに) 必要に応じて束縛されるべきです。

文字セットの変換
========

MML を MIME に変換するときに、Emacs の内部で作られる MIME パートのそれぞれについて、適切な文字セットを選ばなければなりません。

もし非-MULE の Emacs を走らせているのであれば、この処理は単純です。パートがどんな非-ASCII (8-bit) 文字を含んでいても、 mail-parse-charset (シンボル) で与えられる MIME 文字セットを使えば良いのです。(もっとも、この変数を直接に設定しないで下さい。ディフォルトの文字セットを変更したい場合は、MIME メッセージを処理するために使うパッケージの説明書を調べてください。例えば: see Various Message Variables (Message Manual))。ASCII 文字セットしか無ければ、MIME 文字セット US-ASCII が使われるのはもちろんです。

MULE 機能を備えた Emacs を走らせている場合は、ものごとは多少複雑になります。この場合は、パートで使われている MULE 文字セットのリストを取得し、Emacs 自身が提供するテーブルか、XEmacs のための mm-mime-mule-charset-alist 変数の値に基づいて、それらの MULE 文字セットを MIME 文字セットに変換します。結果が単一の MIME 文字セットだったら、それを使ってパートをエンコードします。しかし、結果の MIME 文字セットのリストが二つ以上の要素を含んでいる場合には、二つのことが起こり得ます。もしパートを UTF-8 でエンコードすることが可能だったら、その文字セットを使います。(このために Emacs は utf-8 coding system をサポートしなければならないし、そのパートは Unicode で定義された、それらに対応する文字だけから成っていなければなりません。)  何らかの理由によって UTF-8 を利用できない場合、そのパートは、それぞれが単一の MIME 文字セットでエンコードすることができるように、いくつかに分割されます。もっとも、パートは行の境界でしか分割することができないので、単一の行をエンコードするのに複数の MIME 文字セットが必要だとすると、そのパートをエンコードすることは不可能です。

MULE 機能を備えた Emacs を走らせている場合、どの coding system を使うかの優先順位は Emacs 自身から継承されます。これは、もし Emacs が UTF-8 を優先するように設定されていると、それがメッセージのエンコードに使われることを意味します。ただし mm-coding-system-priorities 変数の値を変えることによって、これを変更することはできます (see Encoding Customization)。

メッセージを作成するときに MML の charset タグを設定することによって、使われる文字セットを上書きすることができます。

文字セットのエンコーディング (quoted-printable, 8bit など) はここでの議論に直交する概念です。それは mm-body-charset-encoding-alist 変数と mm-content-transfer-encoding-defaults 変数によって制御されます (see Encoding Customization)。

変換
==

mime-to-mml 関数を使って MIME メッセージ (マルチパートでも可) を MML に変換することができます。これは現在のバッファにある MIME メッセージに作用して、MIME の境界を MML の印付け (markup) で置き換えます。テキストではないパートの内容物は、そのバッファに置く代わりに MML タグを介して参照される別のバッファに置かれます。

mml-to-mime 関数を使って MML メッセージを MIME に変換することができます。

これらの関数が行なうことはある意味で「不可逆 (lossy)」です。 mime-to-mml を実行し、次に mml-to-mime を実行すると、元とまったく同じメッセージは戻って来ないでしょう。ヘッダーの順序のようなどうでも良いことが違ってしまうだけでなく、ヘッダーの内容も変化してしまうかもしれません。例えば、元のメッセージが base64 でテキストをエンコードしてあっても、mml-to-mime は quoted-printable を使うかもしれない、というようなことです。

しかし本質的には、これら二つは互いに逆関数であるべきです。結果として生成されるメッセージの内容物が、同一でないにしても等価なままであるような。

流動テキスト
======

Emacs MIME ライブラリーは、メッセージをエンコードするときは use-hard-newlines 変数 (see Hard and Soft Newlines (Emacs Manual)) に従い、メッセージをデコードするときは ``format=flowed'' Content-Type パラメータを尊重します。

テキストをエンコードするとき、ソフト改行文字で終端されている各行は use-hard-newlines に関わらずに詰め込まれ (filled)、そして fill-flowed-encode-column で決定される桁の後ろで折り畳まれます。引用印 (^>* ? に合致するテキスト) は尊重されます。その変数は、流動テキストをサポートしないクライアントにおいてテキストがどう見えるかを制御し、ディフォルトでは 66文字の後ろで折り畳みます。バッファにハード改行文字が無ければ、流動 (flowed) テキストのためのエンコードは行ないません。

流動 (flowed) テキストをデコードするとき、ソフト改行文字を持つ各行は詰め込まれ (filled)、そして fill-flowed-display-column で決定される桁の後ろで折り畳まれます。ディフォルトでは fill-column の後ろで折り畳みます。

mm-fill-flowed
     非-nil だったら、format=flowed の記事は流動的に表示されます。

インターフェース関数
**********

mail-parse ライブラリーは、次以降の章で述べる実際の低レベルなライブラリーを抽象化したものです。

標準は変わります。したがって、プログラムも新しい鋳型に適合するために変化しなければなりません。例えば、RFC2045 はパラメータのリストにある ASCII 文字だけを許容する Content-Type ヘッダーのためのシンタックスについて述べています。RFC2231 は、複数行に渡って継続する単一のヘッダーと非-ASCII 文字の構成を規定するための RFC2045 のシンタックスについて詳述しています。

これに対処する従来の方法は、単に新しいシンタックスを解析するためにライブラリーの機能を更新することでした。しかしながら、これは時には誤った行為です。場合によっては、新しいシンタックスと古いシンタックスの両方を理解できるようにすることが重要かもしれませんし、ライブラリーが一つだけある場合には、ライブラリーの古いバージョンと新しいバージョンのどちらかを選ばなければなりません。

Emacs MIME ライブラリーは異なる方針で行くことにしました。これは、対応する標準に従って厳密に解析する、一連の低レベルのライブラリー (rfc2047.el, rfc2231.el など) を定義します。とは言え、正規のプログラムは、これらのライブラリーが直接に提供する関数ではなく、代わりに mail-parse ライブラリーが提供する関数を使うべきです。このライブラリーの関数は、最新の低レベルのライブラリーの対応する関数への単なる別名です。この構成を使うことによって、プログラムはそれらが使うことができる首尾一貫したインターフェースを入手し、また、ライブラリーの開発者は、新しい標準を扱うコードを自由に作成することができます。

以下の関数が、このライブラリーで定義されています:

mail-header-parse-content-type
     Content-Type ヘッダーを解析して、以下の形式でリストを返します:

          ("type/subtype"
           (attribute1 . value1)
           (attribute2 . value2)
           ...)

     例です:

          (mail-header-parse-content-type
           "image/gif; name=\"b980912.gif\"")
          => ("image/gif" (name . "b980912.gif"))

mail-header-parse-content-disposition
     Content-Disposition ヘッダーを解析して、上記の関数と同じ形式のリストを返します。

mail-content-type-get
     二つのパラメータ、上記の形式のリストと属性、を受け取り、その属性の値を返します。

          (mail-content-type-get
           '("image/gif" (name . "b980912.gif")) 'name)
          => "b980912.gif"

mail-header-encode-parameter
     パラメータに使う文字列を受け取り、それをエンコードしたものを返します。これは Content-Type と Content-Disposition のようなヘッダーに入れるパラメータのために使われます。

mail-header-remove-comments
     ヘッダーからコメントを取り除いたものを返します。

          (mail-header-remove-comments
           "Gnus/5.070027 (Pterodactyl Gnus v0.27) (Finnish Landrace)")
          => "Gnus/5.070027  "

mail-header-remove-whitespace
     ヘッダーから ``linear white space'' (訳注: 単一の長いヘッダーを折り畳んで複数行にするときに使う連結子; 改行文字+空白文字) を取り除きます。クォートされた ("..." で囲まれた) 文字列の中にある空白文字とコメントは保存されます。

          (mail-header-remove-whitespace
           "image/gif; name=\"Name with spaces\"")
          => "image/gif;name=\"Name with spaces\""

mail-header-get-comment
     ヘッダーの最後のコメントを返します。

          (mail-header-get-comment
           "Gnus/5.070027 (Pterodactyl Gnus v0.27) (Finnish Landrace)")
          => "Finnish Landrace"

mail-header-parse-address
     アドレスを解析して、メールボックスとプレーンテキストの名前を含むリストを返します。

          (mail-header-parse-address
           "Hrvoje Niksic <hniksic@srce.hr>")
          => ("hniksic@srce.hr" . "Hrvoje Niksic")

mail-header-parse-addresses
     アドレスのリストを含んでいる文字列を解析して、上で述べたような要素のリストを返します。

          (mail-header-parse-addresses
           "Hrvoje Niksic <hniksic@srce.hr>, Steinar Bang <sb@metis.no>")
          => (("hniksic@srce.hr" . "Hrvoje Niksic")
               ("sb@metis.no" . "Steinar Bang"))

mail-header-parse-date
     日付の文字列を解析して、Emacs 形式の時刻を返します。

mail-narrow-to-head
     バッファをヘッダーの区域に狭めます。ポイントは狭められたバッファの先頭に置かれます。

mail-header-narrow-to-field
     バッファを現在位置のヘッダーに狭めます。複数行に渡って継続する単一のヘッダーを理解します。

mail-header-fold-field
     現在位置のヘッダーを折り畳みます。

mail-header-unfold-field
     現在位置のヘッダーの折り畳みを解除します。

mail-header-field-value
     現在位置のフィールドの値を返します。

mail-encode-encoded-word-region
     領域にある ASCII 以外の語をエンコードします。例えば Naïve は =?iso-8859-1?q?Na=EFve?= としてエンコードされます。

mail-encode-encoded-word-buffer
     現在のバッファにある ASCII 以外の語をエンコードします。この関数は、ヘッダーの区画に狭められたメッセージで呼ばれることを意図しています。

mail-encode-encoded-word-string
     文字列に含まれているエンコードする必要がある語をエンコードして、結果を返します。

          (mail-encode-encoded-word-string
           "This is naïve, baby")
          => "This is =?iso-8859-1?q?na=EFve,?= baby"

mail-decode-encoded-word-region
     領域にあるエンコードされた語をデコードします。

mail-decode-encoded-word-string
     文字列に含まれているエンコードされた語をデコードして、結果を返します。

          (mail-decode-encoded-word-string
           "This is =?iso-8859-1?q?na=EFve,?= baby")
          => "This is naïve, baby"

現在 mail-parse は ietf-drums, rfc2047, rfc2045 および rfc2231 を網羅して抽象化します。これらについて、次以降の章で説明します。

基本的な関数
******

この章は、下位の階層にある基本的な、解析と処理を行なう関数について説明します。ここで扱うことは From 行の解析、ヘッダーの各行にあるコメントの削除、語のデコードとエンコード、時刻ヘッダーの解析などです。上位階層の機能は最初の章 (see Decoding and Viewing) で扱います。

訳注: RFC822bis == draft-ietf-drums-msg-fmt-09.txt

rfc2045
=======

RFC2045 は「主要な」MIME の文献です。ならば、そこにはたくさんの実装があるだろうと想像するでしょう。しかし、ほとんどの詳細な実装はその後の RFC に委ねられていて、そこにはありません。

と言うわけで、rfc2045.el にはたった一つの関数があります:

rfc2045-encode-string
     パラメータと値を受け取り、PARAM=VALUE の形式の文字列を返します。 VALUE に安全ではない文字があったらクォートされ ("..." で囲まれ) ます。

rfc2231
=======

RFC2231 は Content-Type と Content-Disposition ヘッダーのシンタックスを定義します。その小粋な名称は MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations です。

一口で言うと、それらのヘッダーはこんなふうです:

     Content-Type: application/x-stuff;
      title*0*=us-ascii'en'This%20is%20even%20more%20;
      title*1*=%2A%2A%2Afun%2A%2A%2A%20;
      title*2="isn't it!"

普通はこんなにひどくないですが。

以下の関数がこのライブラリーで定義されています:

rfc2231-parse-string
     Content-Type ヘッダーを解析して、その要素を表すリストを返します。

          (rfc2231-parse-string
           "application/x-stuff;
           title*0*=us-ascii'en'This%20is%20even%20more%20;
           title*1*=%2A%2A%2Afun%2A%2A%2A%20;
           title*2=\"isn't it!\"")
          => ("application/x-stuff"
              (title . "This is even more ***fun*** isn't it!"))

rfc2231-get-value
     上記の形式のリストの一つを受け取り、指定された属性の値を返します。

rfc2231-encode-string
     Content-Type と Content-Disposition のようなヘッダーにあるパラメータをエンコードします。

ietf-drums
==========

drums は RFC822 の置き換え作業をしている IETF の作業部会です。

このライブラリーによって提供される関数は次の通りです:

ietf-drums-remove-comments
     引数からコメントを取り除いて、結果を返します。

ietf-drums-remove-whitespace
     文字列から ``linear white space'' (訳注: 単一の長いヘッダーを折り畳んで複数行にするときに使う連結子; 改行文字+空白文字) を取り除き、結果を返します。クォートされた ("..." で囲まれた) 文字列の中にある空白文字とコメントには手をつけません。

ietf-drums-get-comment
     文字列の最後尾にあるコメントを返します。

ietf-drums-parse-address
     アドレスの文字列を解析して、メールボックスとプレーンテキストの名前を含むリストを返します。

ietf-drums-parse-addresses
     カンマで区切られた複数のアドレスを含んでいる文字列を解析して、メールボックスとプレーンテキストの対を含むリストを返します。

ietf-drums-parse-date
     日付の文字列を解析して、Emacs 形式の時刻を返します。

ietf-drums-narrow-to-header
     現在のバッファをヘッダーの区域に狭めます。

rfc2047
=======

RFC2047 (Message Header Extensions for Non-ASCII Text) は、ヘッダーにある非-ASCII テキストをどのようにエンコードするかを定めます。実際これは少々複雑になるので、このライブラリーが行なうことを調整するために、多くの変数が必要です。

以下の変数が調整可能です:

rfc2047-header-encoding-alist
     これはヘッダーとエンコーディング・タイプの対を収めた連想リストです。その主な目的は、ある種のヘッダーがエンコードされないようにすることです。

     鍵 (訳注: 各要素の car 項) はヘッダーに合致する正規表現か t のどちらかです。

     値 (訳注: 各要素の cdr 項) が nil のとき、問題のヘッダーはエンコードされません。mime はそれらがエンコードされることを意味し、 address-mime の場合はヘッダーがアドレスを含んでいることを想定して注意深くエンコードします。

rfc2047-charset-encoding-alist
     RFC2047 は二つのエンコーディングの形式を定めています。一つは Q (Quoted-Printable のようなエンコーディング) で、もう一つは B (base64) です。この連想リストは、ある文字セットに対してどのエンコーディングを使うかを規定します。

rfc2047-encode-function-alist
     これはエンコーディングと関数の対を収めた連想リストです。エンコーディングとは Q, B および nil のことです。

rfc2047-encoded-word-regexp
     デコードを行なうとき、このライブラリーはこの正規表現に合致するものを探します。

rfc2047-encode-encoded-words
     エンコード済みの語 (例えば =?hello?=) を再度エンコードするかどうかを決めるブール変数です。

以上は変数でした。次は関数です:

rfc2047-narrow-to-field
     バッファを現在の行のヘッダーに狭めます。

rfc2047-encode-message-header
     メッセージのヘッダーに狭められたバッファで使わなければなりません。 rfc2047-header-encoding-alist に従ってエンコードします。

rfc2047-encode-region
     指定された領域にあるすべてのエンコード可能な語をエンコードします。

rfc2047-encode-string
     文字列をエンコードして結果を返します。

rfc2047-decode-region
     領域にあるエンコードされた語をデコードします。

rfc2047-decode-string
     文字列をデコードして結果を返します。

rfc2047-encode-parameter
     パラメータを RFC2047 ふうの様式でエンコードします。これは rfc2231-encode-string の置き換えです。See rfc2231.

     ファイルを MIME のパートとして添付するとき、非-ASCII 文字を含むファイル名を指定するには RFC2231 のエンコーディングを使わなければなりません。しかし、実際問題として多くのメールソフトがそれをサポートしないので、受信者は正しいファイル名を抽出することができません。代わりに RFC2047 ふうのエンコーディングが、広く受け入れられています。そんな情けない風潮を甘受して、この関数は RFC2047 によく似たエンコーディグの機能を提供します。これを使うには、~/.gnus.el ファイルに次の行を入れて下さい:

          (defalias 'mail-header-encode-parameter 'rfc2047-encode-parameter)

time-date
=========

本当は MIME ライブラリーの一部ではありませんが、ここで説明することは都合が良いのです。これは日付ヘッダーの解析と時刻の操作を扱います。 (もっとも四次元立方体は使いません。ごめんなさい。)

これらの関数は五つの形式 (時刻の文字列、Emacs 形式の時刻、デコードされた時刻のリスト、秒数、および日数) の間で変換を行ないます。

時刻/日付/秒数/日数の相互変換の例です:

     (parse-time-string "Sat Sep 12 12:21:54 1998 +0200")
     => (54 21 12 12 9 1998 6 nil 7200)

     (date-to-time "Sat Sep 12 12:21:54 1998 +0200")
     => (13818 19266)

     (time-to-seconds '(13818 19266))
     => 905595714.0

     (seconds-to-time 905595714.0)
     => (13818 19266 0)

     (time-to-days '(13818 19266))
     => 729644

     (days-to-time 729644)
     => (961933 65536)

     (time-since '(13818 19266))
     => (0 430)

     (time-less-p '(13818 19266) '(13818 19145))
     => nil

     (subtract-time '(13818 19266) '(13818 19145))
     => (0 121)

     (days-between "Sat Sep 12 12:21:54 1998 +0200"
                   "Sat Sep 07 12:21:54 1998 +0200")
     => 5

     (date-leap-year-p 2000)
     => t

     (time-to-day-in-year '(13818 19266))
     => 255

     (time-to-number-of-days
      (time-since
       (date-to-time "Mon, 01 Jan 2001 02:22:26 GMT")))
     => 4.146122685185185

あと、safe-date-to-time というものもあります。これは date-to-time と同じことをしますが、日付が構文的に不完全だった場合にゼロ時刻を返します。

五つのデータは以下のように表現されます:

date
     RFC822 (または類似の) 形式の日付の文字列。例: "Sat Sep 12 12:21:54 1998 +0200"

time
     Emacs の内部形式の時刻。例: (13818 26466)

seconds
     Emacs の内部形式の時刻を浮動小数で表したもの。例: 905595714.0

days
     00000101 を基点とする経過日数を整数で表したもの。例: 729644

     訳注: 00000101 が何を意味するのか不明ですが、ソースコードによればグレゴリオ歴・紀元前 (BC ではなく BCE の方の) 0001年12月31日のことらしいです。

decoded time
     デコードされた時刻のリスト。例: (54 21 12 12 9 1998 6 t 7200)

上記のすべての例は、同じ時を表しています。

関数には以下のようなものがあります:

date-to-time
     日付を受け取って時刻を返します。

time-to-seconds
     時刻を受け取って秒数を返します。

seconds-to-time
     秒数を受け取って時刻を返します。

time-to-days
     時刻を受け取って日数を返します。

days-to-time
     日数を受け取って時刻を返します。

date-to-day
     日付を受け取って日数を返します。

time-to-number-of-days
     時刻を受け取って、それが表している日数を返します。

safe-date-to-time
     日付を受け取って時刻を返します。日付が構文的に正しくなかったら「ゼロ」時刻を返します。

time-less-p
     二つの時刻を受け取って、一つ目が二つ目より少ない (すなわち早い) かどうかを示します。

time-since
     時刻を受け取って、その時刻からどれほど時間が経過したかを示します。

subtract-time
     二つの時刻を受け取って、一つ目から二つ目を減算します。すなわち、二つの時刻の間の時間差を返します。

days-between
     二つの日付を受け取って、それら二つの日付の間の日数を返します。

date-leap-year-p
     年の数字を受け取って、それがうるう年かどうかを示します。

time-to-day-in-year
     時刻を受け取って、その年の元日から経過した日数を返します。

qp
==

このライブラリーは Quoted-Printable によるテキストのデコードとエンコードを扱います。

非常に手短かに説明すれば、qp エンコーディングはすべての 8-bit 文字 (と多くの制御文字) を =EF のようなもの (イコール記号と、それに続く 16進数にエンコードされたバイト) に変換することです。

このライブラリーでは、以下の関数が定義されています:

quoted-printable-decode-region
     指定された領域にあるすべてのエンコードされたテキストを QP-デコードします。

quoted-printable-decode-string
     文字列に含まれている QP-エンコードされたテキストをデコードして、結果を返します。

quoted-printable-encode-region
     指定された領域にあるすべてのエンコード可能な文字を QP-エンコードします。省略できる第三引数 FOLD は、長い行を折り畳むかどうかを指定します。 (ここで「長い」は 72桁を越えるもののことを意味します。)

quoted-printable-encode-string
     文字列に含まれているすべてのエンコード可能な文字を QP-エンコードして、結果を返します。

base64
======

Base64 は 3-バイトを 4-バイトにエンコードします。そのため、約 33% サイズが増えます。エンコードで使われるアルファベットは、伝送される間に台無しにされることに対してとても耐久力があります。

以下の関数がこのライブラリーによって定義されています:

base64-encode-region
     選択された領域を base64 でエンコードして、エンコードされたテキストの長さを返します。省略できる第三引数 NO-LINE-BREAK は、長い行をより短い行に折り畳まないことを指図します。

base64-encode-string
     文字列を base64 でエンコードして結果を返します。

base64-decode-region
     選択された領域を base64 でデコードして、デコードされたテキストの長さを返します。領域がデコード可能でなかったら、nil を返すだけでバッファは変更しません。

base64-decode-string
     文字列を base64 でデコードして結果を返します。文字列がデコード可能でなかったら nil を返します。

binhex
======

binhex はマッキントッシュの環境に源を発するエンコーディングです。以下の関数がそれらを扱うために供給されています:

binhex-decode-region
     領域にあるエンコードされたテキストをデコードします。第三パラメータが与えられると、binhex のヘッダーをデコードしてファイル名を返すことだけをします。

uudecode
========

base64 がメールの世界を支配しているものの、おそらく uuencode はまだ Usenet で使われている最も普及しているバイナリーのエンコーディングです。

以下の関数がこのパッケージによって供給されています:

uudecode-decode-region
     領域にあるテキストをデコードします。

yenc
====

yenc は Usenet でバイナリーをエンコードするために使われます。以下の関数がこのパッケージによって供給されています:

yenc-decode-region
     領域にあるエンコードされたテキストをデコードします。

rfc1843
=======

RFC1843 はメッセージにおける中国語と ASCII 文字の混在文を扱います。本質的に、RFC1843 は以下を使って ASCII と中国語を切り替えます:

     This sentence is in ASCII.
     The next sentence is in GB.~{<:Ky2;S{#,NpJ)l6HK!#~}Bye.

まったく単純で、中国では広く使われています。

このエンコーディングを扱うために、以下の関数を使うことができます:

rfc1843-decode-region
     領域にある HZ-エンコードされたテキストをデコードします。

rfc1843-decode-string
     HZ-エンコードされた文字列をデコードして結果を返します。

mailcap
=======

~/.mailcap ファイルはほとんどの MIME 対応のメッセージ・ハンドラーによって解析されます。それには、各要素がどのように表示されるものと想定されているかを記述します。ファイルの例です:

     image/*; gimp -8 %s
     audio/wav; wavplayer %s
     application/msword; catdoc %s ; copiousoutput ; nametemplate=%s.doc

これは、すべての画像ファイルは gimp で表示されるべきであること、 WAVE 音響ファイルは wavplayer で再生されるべきであること、そして MS-WORD ファイルは catdoc によってインライン表示されるべきであることを語っています。

mailcap ライブラリーはこのファイルを解析して、合致するタイプのための関数を規定します。

mailcap-mime-data
     この変数は、バックアップされた (訳注: mailcap ファイルの内容を解析して Emacs が扱い易い形式にした) 表示規則を含んでいる、連想リストの連想リストです。

インターフェース関数:

mailcap-parse-mailcaps
     ~/.mailcap ファイルを解析します。

mailcap-mime-info
     引数として MIME タイプを受け取り、合致するビューワーを返します。

標準
**

Emacs MIME ライブラリーは、(やや) 多くの RFC、ドラフトおよび標準ドキュメントに従って、様々な要素を取り扱います。この章では関連するものを列挙します。これらはすべて http://quimby.gnus.org/notes/ から取得可能です。

RFC822
STD11
     ARPA インターネットテキストメッセージの書式のための標準。

RFC1036
     USENET メッセージ交換のための標準。

RFC2045
     インターネットメッセージ本体の書式。

RFC2046
     メディアタイプ。

RFC2047
     メッセージヘッダーでの非-ASCII テキスト拡張。

RFC2048
     登録手続。

RFC2049
     適合基準と事例。

RFC2231
     MIME パラメータ値と符号化単語拡張: 文字セット、言語および継続。

RFC1843
     HZ - 中英混在文を含むファイル交換のためのデータ形式。

draft-ietf-drums-msg-fmt-05.txt
     RFC822 の後継のための標準。

RFC2112
     MIME Multipart/Related Content-type。

RFC1892
     メールシステムの管理メッセージをリポートするための Multipart/Report Content Type。

RFC2183
     インターネットメッセージの情報通信表現: Content-Disposition ヘッダーフィールド。

RFC2646
     流動テキストのための text/plain 書式パラメータ。