quoted-printableでの「=」の扱い

・E-Mailで、文字コードはiso-2022-jp、エンコードがquoted-printable（ヘッダに誤りはない）
・各行で、エンコードされている部分は、「=1B$B」「=1B(B」で挟まれている

という状況で、文字コードに「3D」（エンコードすると=になる）を含む文字が出てきた場合、どう処理されるのでしょうか。

例：「そして（24 3D 24 37 24 46）」という文字列
エンコードすると、「$=$7$F」

ここで、この「=」は、さらにエンコードして「=3D」にするのでしょうか？
それとも、「=」そのままで扱うのでしょうか？


ある環境で受け取ったメールが一部文字化けしていたので調べたところ、
この部分が、「$=3D$7$F」とエンコードされていました。
（この部分は文字化けしていません）

文字化けしていたのは、「今週中（3A 23 3D 35 43 66）」の部分で、
エンコードすると「:#=5Cf」になると思うのですが、こちらの環境で「今樔（3A 23 5C 66）」になっていました。
デコードする際に、「=5C」→「\」にすると辻褄が合いそうなのですが…。
（ただ、受け取ったメールでは、この部分は「:#\f」になっていました。1回デコード済み？）

エンコードするシステムの管理にかかわっているわけではないので、半分興味本位（もう半分は、場合によっては不具合報告を出すため）なのですが、ご教示いただけると幸いです。


…まぁ、iso-2022-jpをわざわざquoted-printableでエンコードしなくても、とも思うのですが、絵文字とか対応のためにやってるのかなぁ、と…。

No.3 ベストアンサー 回答者： mtaka2 回答日時： 2010/11/10 12:47

> 「3D」を含む文字（「週」とか「そ」とか「出」とか）は、出てきた「=」についてもう一度エンコードしておかないと、デコードの際に問題が発生する、という感じで大丈夫でしょうか？

「エンコード」も「デコード」も一回こっきりです。「もう一度エンコードする」のではなく、一度のエンコードで、データ中の「1B や3Dを全て変換」するのです。
「エンコードしたものをまたエンコード」したり「デコードしたものをまたデコード」することはありませんし、してはいけません。

文字化けの要因は、おそらくデコードしなくていい文字列をさらにデコードしてしまっているということでしょう。

たとえば「そして=3D今週中」という文字列は、ISO-2022-JPでは
「ESC $B$=$7$F ESC (B=3D ESC $B:#=5Cf ESC (B」
(1B 24 42 24 3D 24 37 24 46 1B 28 42 3D 33 44 1B 24 42 3A 23 3D 35 43 66 1B 28 42)
になります。(わかりやすくするため、ESC(1B)の前後にスペースを入れてあります)

この文字列をquoted-printableにした場合、文字列中の printable でない文字「ESC」(1B)と「=」(3D)をquoteして「=1B」「=3D」に変換することになります。結果として、
「=1B$B$=3D$7$F=1B(B=3D3D=1B$B:#=3D5Cf=1B(B」
が「そして=3D今週中」を quoted-printable にしたものになります。

これをデコードすると、「=とそのあとの16進二桁」である「=1B」と「=3D」がそれぞれ ESC と = に変換されますので、
「ESC $B$=$7$F ESC (B=3D ESC $B:#=5Cf ESC (B」
すなわち、元通りの「そして=3D今週中」という文字列に戻ります。
この「一回のエンコード処理」および「一回のデコード処理」が、本来のquoted-printableの処理すべき姿です。

とこが、この文字列を、さらquoted-printableとしてデコードしてしまうと、
「=3D」が「=」に、「=5C」が「\」に変換されてしまいますので、
「ESC $B$=$7$F ESC (B= ESC $B:#\f ESC ( B」
つまり「そして=今樔」になってしまうのです。
これは、間違った処理結果です。

この回答へのお礼

再びありがとうございます。

これを見て、いろいろと混乱していたことに漸く気がつきました…（滝汗）
最初の記号混じりはただ単にJISを区切ってASCII文字に置き換えただけなのですね。
で、そこから先がquoted-printableで処理する領域、と…。

わざわざありがとうございました！
おかげ様で理解できました。

お礼日時：2010/11/10 13:54

No.2 回答者： mtaka2 回答日時： 2010/11/10 06:28

エンコードする側については「=」は必ず「=3D」にエンコードする必要はありますが、

「\」はquoted-printable でエンコードすべき文字ではありませんので、「\」のまま送るのが普通です。=5Cにする必要はありません。ですが、=5Cにエンコードしたとしても、quoted-printableとして正しい出力ではあります。

一方quoted-printable の「デコードのルール」は、
・「=とその後の16進数二桁」は、全て、その16進数値の示す文字に変換
・「行末の=とその後の改行」は削除(改行を消す)
するというものです。

つまり、受け取った側では、=1Bだけでなく、=3D や =5C も、とにかく=が出てきたら必ずデコード処理をしなければなりません。

この回答へのお礼

ありがとうございます。

デコードのルールを読んで、何となく理解できました。
「3D」を含む文字（「週」とか「そ」とか「出」とか）は、出てきた「=」についてもう一度エンコードしておかないと、デコードの際に問題が発生する、という感じで大丈夫でしょうか？

っと…
そのルールだと、もし一度目のエンコードで「=5Cf」などになったとしたら、もう一度「=3D5Cf」とエンコードしておいたとしても、

=3D5Cf → =5Cf → \f

とかにはなったりしないんですかね？
そんな文字が存在するかは謎ですが…。

お礼日時：2010/11/10 11:51

No.1 回答者： Tacosan 回答日時： 2010/11/10 03:25

「=」そのものを表すなら, 当然「=3D」とエンコードしなければなりません.

この回答への補足

お礼を埋めてしまったので補足で失礼します。

No.3へのお礼の方で書きましたが、こちらの認識（理解？）不足の結果だったようです。

その前提で見ると、No.1へのお礼はちょっといかがなものか…と思ってしまい、恥ずかしい限りです。
非礼をお詫びいたします。

御回答、ありがとうございました。

補足日時：2010/11/10 13:57

この回答へのお礼

ありがとうございます。

そこまでは問題ないのですが、エンコードしていった部分に=が出てきたらどうなるのかな、と思って質問させていただきました（詳しくはもう1人の方へのお礼で）。

お礼日時：2010/11/10 11:43