2011年03月04日

MIME再び #2: base64 と quoted-printable

さて、昨日の続き。


MIMEが出てきて、US-ASCIIだけの電子メールにテキスト以外の内容を載せるために、最終的にはUS-ASCIIにエンコードする必要がある。もっと古くは uuencode なんてのもあったけれど、知らない人の方が今や多いだろう。

それはさておき、最終的にUS-ASCIIにエンコードするためにMIMEの当初から用意されている基本的なエンコーディングは2つ、いずれもメールのボディに使用する目的のものだが、基本となるので避けては通れない。


base64


base64は任意のデータを、24bit(3オクテット分)単位で4オクテットのUS-ASCIIの文字で表現する。


  1. 8bitのオクテット列を6bit単位に分ける。
  2. 6bitということは0から63までの値となる。
  3. 順番にアルファベットの大文字、小文字、数字、プラス(+)、スラッシュ(/)の64文字で表す。
  4. 76オクテットを超えると改行する。

エンコードするデータがぴったり24ビット単位になることはないわけだが、足りない部分は等号(=)の文字によるパディング(詰め物)をする。細かいことは省略する。


base64は処理としては単純で、エンコードした結果に使用する文字を厳選していることもあって、メールのヘッダーで使用する場合に安全と言える。その一方で、必ずデータが4/3倍以上の大きさになってしまう。


quoted-printable


quoted-printableはアルファベットをベースとした言語を前提としていて、それ自身のエンコードの規則はあまり複雑でないように見える。



  1. 改行(CR + LF)以外の任意のオクテットはエンコードしてよく、エンコードは等号(=)に続けてオクテットを2文字の16進数で表現する。
  2. このときの2文字の16進数は数字とAからFの大文字のアルファベットを使用する。(小文字は使用できない。)
  3. オクテットの値が33から60と62から126についてはエンコードせずにUS-ASCIIの文字をそのまま使用してよい。これは等号(=)を除いた英数字と記号が該当する。
  4. スペースとタブはそのままUS-ASCIIを使用しても良いが、エンコードした文字列の最後に置いてはいけない。このような場合は最初の方法でエンコードしなければならない。
  5. SMTP的な改行(CR + LF)はエンコードする対象がテキストでない場合は、最初の方法でエンコードすべきである。
  6. 行が長くなり過ぎる場合は「ソフト改行」で改行する。これは等号(=)の直後に通常の会合を行うことで行う。

元はヨーロッパ圏の、殆どは英語のアルファベットにウムラウトが付いたような文字が少し混ざるような言語の場合に、エンコードした後でもだいたい読めるという利点がある。また、base64に比べるとデータが機械的に増えることもない。


しかし、きちんと処理しようとすると案外ややこしい面もあるが、本文をquoted-printableでエンコードする分はまだましと言える。


今日のところもここまで。

posted by Takahiro Kambe at 23:50| 京都 ☀| Comment(0) | TrackBack(0) | Contao | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス:

ホームページアドレス:

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
※ブログオーナーが承認したコメントのみ表示されます。

この記事へのトラックバック

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。