Mozilla 翻訳

[masa]

さきほどa.m.oの日本語版ページで gmail のアドレスでユーザー登録したら、
登録確認メールのタイトルが、

Firefox Add-ons へご登録いただきあ��がとうございます

になっていて、メールヘッダを確認したら

Subject: =?UTF-8?B?RmlyZWZveCBBZGQtb25zIOOBuOOBlOeZu+mMsuOBhOOBn+OBoOOBjeOBguOC?= =?UTF-8?B?iuOBjOOBqOOBhuOBlOOBluOBhOOBvuOBmQ==?=

となっていましたが、これはメールヘッダのエンコード／デコードのどちらが悪いのでしょうか？

[濱崎]

符号化そのものはbase64にきちんと従っているようですから、文字化けの原因はデコード側にあると思います。

区切り(2番目の =?UTF-8?B )で文字化けしています。
base64 の書式が判る人は、簡単に確かめることができます。
区切りを超えて 4文字ずつ移し、手元の MUA で見てみてください。文字化けする場所が1文字ずつ移っていきます。

きっとデコードの過程で区切りに余計なものを入れたか削ったかしたのでしょう。
改行と空白は無視して素直につなげればいいんですけどね。
このあたりの実装をどうするかは MUA の作者も苦労している部分らしいです。
MIME の規定違反をする MUA (Outlook Express とか)が普及したことで、間違った規格が世に広まってしまったせいだとか。

もし、引用が改行も含めて正確なら、エンコード側にも問題があります。

ヘッダの MIME 変換を規定しているRFC2047、日本語訳の例 をちょっと読んでみたところ、
行の長さにこういう規定があります。

[[test user]]

multi-byte utf-8のバイト列の途中でぶった切っちゃぁいけません。。

[濱崎]

そうですね。
=?utf-8?b 〜 ?= までのひとまとまりが それぞれ独立して読める形にデコードできないといけませんよね。（☆）

＃ 理論的には、全部Base64デコードしたビット列をつなぎ合わせて、
＃ その後で頭から UTF-8 として解読してもいいわけですが、
＃ Subject: 全体の長さには制限がないため（何行になってもいい）、あまり賢くないやりかたです。

以下、正しいエンコーディングの例です。
76文字制限も考慮して「た」の前で分割した場合です。

[masa]

AMOのバックエンドのバグという判断でいいのでしょうか？
# bugzillaに投げるべき？

[濱崎]

bugzillaに投げてもいいと思います。整理すると問題点は2つで、

1. エンコード後の Subject: 行の1行目が76文字を越えていること
   
2. 行区切りが UTF-8 の文字境界とずれていること
   

1. はRFC2047 違反です。
2. については、対応しているメーラがあるかもしれないので（★）AMOのバックエンドのバグとは言い切れません。
RFC2047 にも、文字境界で切らなければいけないという記述はありませんから。

対応してもらえるかどうかはまた別の話ですが、ASCII文字圏では起きない事例でしょうから
報告しておくのはいいんじゃないでしょうか。
Thunderbird で読んでも文字化けするということなら対応してもらえるかもしれませんね。

★この前の投稿で、

[masa]

https://bugzilla.mozilla.org/show_bug.cgi?id=412409
で登録しました。

[あ]

[濱崎]

うわっ、そのものずばりですね。あ さん、ありがとうございます。
boundary （=境界）で探して引っかからなかったので、ないものと思ってしまいました。

あ さんが引用してくれた記述は、
RFC 2047 http://tools.ietf.org/html/rfc2047
5. Use of encoded-words in message headers
の (3)の中、後ろから 3つめのパラグラフの中にあります。

[masa]

どうやらPHPMailerのバグっぽいです。
XOOPS（メール送信のバックエンドがPHPMailerです)のフォーラムでも同様の
不具合と思われる現象が報告されています。

http://xoopscube.jp/modules/newbb/viewtopic.php?topic_id=6940&forum=11&post_id=35435

[masa]

PHPMailerでパッチが既にあったので、それを取り入れる形で修正されました。
ご協力いただいた皆さんに感謝します