安全な符号化

以前からバイナリを配送するために uuencode という符号化プログラムが使われ ていました。uuencode は、8ビット3文字を6ビット4文字に変換しますが、変換 後にたくさんの記号が現れます。これらの記号はメッセージのヘッダで特殊な意 味を持つものが含まれており、ヘッダの拡張のためには利用できません。

また、空白文字も使われているのも厄介です。なぜなら、BITNET のファイルシ ステムには、行末に空白がありえないのです。もし、uuencode で符号化したと きに、行末にたまたま空白が現れたとしましょう。これを BITNET のメッセージ ゲートウェイが受け取ると、当然行末の空白を削ってしまいます。よって、受信 者は元のバイナリファイルを復元できません。

そこで、MIME では本文用に 2 つの符号化方式を定めました。

Base64 符号化方式

"0-9A-Za-z/+" の64文字を用いて、8ビット3文字を6ビット4文字に変換する。元々 は PEM で考え出された。

Quoted-Printable 符号化方式

表示不可能な文字を "=" に続けて16進表記する。

各コンテントヘッダ中の Content-Transfer-Encoding:(CTE:)で符号化方式を指 定します。取り得る値は以下の通りです。

7bit

無変換。7ビットの行から構成される。

8bit

無変換。8ビットの行から構成される。

binary

無変換。8ビットのデータ・ストリーム。

base64

Base64 で符号化した。7ビットの行から構成される。

quoted-printable

Quoted-Printable で符号化した。7ビットの行から構成される。

CTE: が省略された場合は `7bit' として扱われます。

ISO-2022-JP は7ビットの文字コードですから、CTE: は 7bit です。つまり、 CTE: は省略して構いません。もちろん、base64 や quoted-printable で符号化 しても構いませんが、フォルダにあるメッセージを more などで直接読めなくな るので、お勧めではありません。