Quoted-Printable の仕組み

Quoted-Printable は、メールなどの MIME ドキュメントで、日本語メッセージなど、8 ビットデータを含む文書を、ASCII 文字列 (7 ビット) に変換するための仕組みのひとつです。

　

どうやったら Quoted-Printable のエンコードがかけられるのだろう…、ということで調べてみました。

なるべく正しいことを書くつもりですが、この道に詳しいわけではないので間違っている可能性もあります。ので、他で解説されている内容の補足程度にでもご利用ください。

　

エンコード方法は、一部の表示可能な記号を除いて、それ以外の文字は "=" に続く 16 進数といった文字列で表現されるようにします。

たとえば、 "=" ならば、ASCII コードは 0x3D (61) なので、"=3D" というようになります。なお、16 進数表記にはアルファベットが登場しますけど、それらは大文字でなくてはいけないようです。

　

一部の表現可能な記号というのは、ASCII コード表の 0x21 (33 '!') から 0x3C (60 '<') という範囲の文字と、0x3E (62 '>') から 0x7E (126 '~') までの範囲をいいます。

これらは特に符号化しなくてもいい文字です。

これらの範囲のちょうど真ん中は '=' という文字ですが、これは符号化した際に '=0F' のように '=' が入ってくるため、符号化した際の '=' なのか、実際のデータの '=' なのかを区別するために、データの '=' は符号化して、"=3D" という文字列にします。

他にも、[TAB] 記号 (0x09) や、空白記号 (0x20) も、符号化せずにデータとしてもつことができるそうですが、行末にこれらの空白文字が符号化されないまま現れないように注意する必要があるようです。

　

改行文字 (CRLF) はそのままエンコードせずに使えばいいようですが、エンコード後の、１行あたりの文字数は改行を含めないで、合計 76 文字までのようです。

これ以上の文字数になってしまう場合は、76 文字以下の文字列に分ける必要があるようです。そうすると本来は改行のなかった部分にも、事実上の改行が入ってしまうため、その分かれてしまった文字列の、本来連結していた文字行の最後には、= で終わるようにする必要があるようです。

つまり、= のあと、改行で終わっている行は、次の行とつながっているという意味になるようです。

　

エンコード方法から考えると、デコードはその逆のはずです。

それを整理してみると、= から始まる文字列は 16 進数表記と見立てて、後ろのアルファベット２文字を数値に変換した文字に置き換えればよさそうです。

ただし、文末の = は次の行へ続いていることをあらわすので、そのあたりを考慮しないといけなそうです。文末でなくても、その後に空白文字しか続かない場合には、それも文末の = と同等として取り扱ったほうがよさそうです。

また、行末の空白文字は取り除いた方がよさそうです。