MozillaZine.jp フォーラム :: トピック - サブジェクトがデコードされない

とあるところからやってくるメールのサブジェクトがデコードされずにそのまま表示されます。

本文は読めますか？

TB が、うまくデコードできないのか、わざとしてないのか。。。

どちらにしても、次期バージョンでは、うまくデコードしてほしいと思っています。

わざとしていないのです。そういう仕様です。

RFC にそれを概説した物があると推測するのですが探したところ発見できませんでした。

今回のは、
Mime-Version: 1.0 というヘッダが存在するのでMIMEメールと見なし、
Content-Type:ヘッダによりsjisエンコードと見なし、
ThunderbirdはSubject:ヘッダをsjisとしてデコードしようとして失敗。

Content-Type:ヘッダとSubject:ヘッダのエンコード指定に矛盾があるからデコードできない、と。

すみません。今回のメールには、ちゃんとヘッダに、

Content-type: text/plain; charset="iso-2022-jp"

と記載されているのに、デコードされていないのです。

気になるのは SUBJECT:ですが、大文字でしたか？
このSUBJECT:が原因なのかな。
可能なら、エディタでSUBJECT:をSubject:に修正してみてはどうでしょう。

コード:

SUBJECT: =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?=

のような終端のケースでも Thunderbird はデコードします。

=? で始まり、 ?= で終わるのが決まりのようですが、ビット数が合わない場合は
== として調整する仕様のようです。

Subject: 欄等のエンコードするヘッダ項目には仕様があるのですが、送り手側と
受け手側のメールクライアントの仕様により一致していないと文字化けとなります。

終端の処理のケースが2種類あるのは私には技術的知識が無いので不明ですが、
一方だけしかデコードできない Thunderbird は処理が厳格というか標準準拠なの
かなと思います。

そのデコードできないメールのヘッダ、送り手のメールクライアント、OS 等の情報を
具体的に提示してください。

それによってはバグかも知れませんし、そうではないかも知れません。
もしバグの場合はここで書いても開発者は見ていませんのでその存在をBugzilla@Mozilla
等にレポートしないと解決されません。

＊TB と略するのなら Tb がお勧めです。

=? で始まり、 ?= で終わるのが決まりのようですが、ビット数が合わない場合は
== として調整する仕様のようです。

では、エンコードの仕様的には正しそうですね。

文字化けは発生していません。デコードせずに、そのまま表示されます。

そうかもしれませんが、多くのクライアントでデコードできているという事実もあります。

バグか仕様かの判断ができずにいます。
英語でレポートできるのかという問題もありますが。。。

そうですね。どなたかよくご存知の方から「これはバグです」とか「仕様です」とか「どち
らも正しいです」とか明確に教えていただくとスッキリしますね。

作成者:	Y2 [ 2007年6月23日(土) 08:42 ]
記事の件名:	サブジェクトがデコードされない
とあるところからやってくるメールのサブジェクトがデコードされずにそのまま表示されます。ヘッダを見ると、内容は、 SUBJECT: =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= となっています。mutt や squirrelmail で見ると問題なく表示されますし、nkf でデコードしても問題なく表示されます。なので、エンコード自体は問題ないと思いますが、なぜデコードされないのでしょう？なお、OS には依存しないようで、Win, Mac, Linux どの OS 上の TB でもデコードされず、そのまま表示されます。ちなみに、デコードされた文字列を、TB や nkf でエンコードすると、 =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI=?= 最後の方のはてなマークの前のイコールが、2つではなく1つになりますが、元のメールのイコールが２つになるというのが、問題なのでしょうか？

作成者:	Premier [ 2007年6月24日(日) 07:39 ]
記事の件名:	Re: サブジェクトがデコードされない
こんにちは。 Y2 さんが書きました: とあるところからやってくるメールのサブジェクトがデコードされずにそのまま表示されます。本文は読めますか？私のところにやって来るそのたぐいのメールはほとんどがスパムです。ヘッダを見ればわかると思います。 Subject: は ?ISO-2022-JP? で書かれているが、 Content-Type: は charset="SHIFT_JIS" となっている場合です。 Thunderbird は器用なふるまいはしないで約束に沿って文字エンコードを表示します。参照： Mozilla Japan ナレッジベース - メッセージの件名が文字化けしたり「?」になってしまう

作成者:	Y2 [ 2007年6月24日(日) 10:23 ]
記事の件名:	Re: サブジェクトがデコードされない
こんにちは Premier さんが書きました: 本文は読めますか？問題なく読めます。また、一応スパムではありません。 TB が、うまくデコードできないのか、わざとしてないのか。。。どちらにしても、次期バージョンでは、うまくデコードしてほしいと思っています。

作成者:	Premier [ 2007年6月24日(日) 11:21 ]
記事の件名:	Re: サブジェクトがデコードされない
Y2 さんが書きました: TB が、うまくデコードできないのか、わざとしてないのか。。。わざとしていないのです。そういう仕様です。 Y2 さんが書きました: どちらにしても、次期バージョンでは、うまくデコードしてほしいと思っています。多分、将来のバージョンでも対応しないと思います。

作成者:	Y2 [ 2007年6月24日(日) 12:47 ]
記事の件名:	Re: サブジェクトがデコードされない
Premier さんが書きました: わざとしていないのです。そういう仕様です。どういう仕様なのか、詳細を教えていただけると助かります。もちろん、ポインタだけでも結構です。

MozillaZine.jp フォーラム https://forums.mozillazine.jp/

サブジェクトがデコードされない https://forums.mozillazine.jp/viewtopic.php?f=3&t=5931	ページ 1 ／ 2

作成者:	Premier [ 2007年6月24日(日) 22:06 ]
記事の件名:	Re: サブジェクトがデコードされない
詳細をと言われると、またポインタだけでもと言われると具体的に自信を持って示す根拠がありません。申し訳ありません。あくまでも経験値からのコメントになってしまいます。ヘッダにある Content-Type: に指定された文字エンコードに従っている仕様としか説明ができません。他のメールクライアントも一般的には同様の仕様だと思われます。 RFC にそれを概説した物があると推測するのですが探したところ発見できませんでした。 RFC indices related to the Internet Mail mozillaZine 本家のナレッジベースでも検索してみましたが、下記のものぐらいしか見つけられませんでした。 Mail content types - MozillaZine Knowledge Base もしどなたか「それはここに書いてあるよ」という資料がありましたらフォローいただくと助かります。

作成者:	kiyo4_k [ 2007年6月25日(月) 01:41 ]
記事の件名:	Re: サブジェクトがデコードされない
Premier さんが書きました: RFC にそれを概説した物があると推測するのですが探したところ発見できませんでした。 RFCは2047です。でも2047だけを読んでもわからないかも。 http://www.mew.org/Newsletters/2.html の「Subject: フィールド」と http://www.mew.org/Newsletters/3.html を読んでみてはどうでしょうか。今回のは、 Mime-Version: 1.0 というヘッダが存在するのでMIMEメールと見なし、 Content-Type:ヘッダによりsjisエンコードと見なし、 ThunderbirdはSubject:ヘッダをsjisとしてデコードしようとして失敗。 Content-Type:ヘッダとSubject:ヘッダのエンコード指定に矛盾があるからデコードできない、と。

作成者:	Y2 [ 2007年6月25日(月) 04:17 ]
記事の件名:	Re: サブジェクトがデコードされない
kiyo4_k さんが書きました: 今回のは、 Mime-Version: 1.0 というヘッダが存在するのでMIMEメールと見なし、 Content-Type:ヘッダによりsjisエンコードと見なし、 ThunderbirdはSubject:ヘッダをsjisとしてデコードしようとして失敗。 Content-Type:ヘッダとSubject:ヘッダのエンコード指定に矛盾があるからデコードできない、と。すみません。今回のメールには、ちゃんとヘッダに、 Content-type: text/plain; charset="iso-2022-jp" と記載されているのに、デコードされていないのです。そして、他のMUAでは、きちんとデコードされていることから、TBのバグかもしれないと思っていますが、もしかしたら他のMUAは、許容範囲が広いだけで、TBは厳格に処理している(仕様)だけなのか解からず、質問しています。なので、どちらにしても次期バージョンでの対応を願っているのですが。。。

作成者:	kiyo4_k [ 2007年6月26日(火) 01:31 ]
記事の件名:	Re: サブジェクトがデコードされない
Y2 さんが書きました: すみません。今回のメールには、ちゃんとヘッダに、 Content-type: text/plain; charset="iso-2022-jp" と記載されているのに、デコードされていないのです。あぁ、なるほど。"SHIFT_JIS"というのはPremierさんが書いていたのを読み違えていたようです。気になるのは SUBJECT:ですが、大文字でしたか？このSUBJECT:が原因なのかな。可能なら、エディタでSUBJECT:をSubject:に修正してみてはどうでしょう。ちなみにThunderbirdは「Content-Type: Multipart/Encrypted;」を理解できません。「Content-Type: multipart/encrypted;」でないとダメというバグがありました。（現バージョンでは確認できていませんが）

作成者:	Y2 [ 2007年6月26日(火) 03:20 ]
記事の件名:	Re: サブジェクトがデコードされない
kiyo4_k さんが書きました: 気になるのは SUBJECT:ですが、大文字でしたか？このSUBJECT:が原因なのかな。可能なら、エディタでSUBJECT:をSubject:に修正してみてはどうでしょう。はい、大文字でした。しかし、これを変更しても同じでした。エディタで修正というヒントをもらったので、最後から３文字目のイコール ('=') を削除すると、問題なくデコードされました。始めに書いた通り、最後の方のイコールが2つ続くのが余計なようでした。やはりエンコードミスなのでしょうか？つまり、TBの解釈が厳格すぎ？

作成者:	Premier [ 2007年6月26日(火) 07:28 ]
記事の件名:	Re: サブジェクトがデコードされない
コード: SUBJECT: =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= のような終端のケースでも Thunderbird はデコードします。 =? で始まり、 ?= で終わるのが決まりのようですが、ビット数が合わない場合は == として調整する仕様のようです。以下のケースがそうです。＊文字数が多い場合ですが。コード: X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Date: Mon, 22 Jun 2007 21:17:58 +0900 From: Premier <sample@cccccc.com> MIME-Version: 1.0 To: aaaaaa <aaaaa@bbbbbb.com> Subject: =?ISO-2022-JP?B?GyRCRnxLXDhsSEckTjk5PzckTkJOQCkkSxsoQg==?= =?ISO-2022-JP?B?GyRCJEQkJCRGGyhC?= Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: 欄等のエンコードするヘッダ項目には仕様があるのですが、送り手側と受け手側のメールクライアントの仕様により一致していないと文字化けとなります。参照：エンコード・コレクション (メール、テキスト関連) 終端の処理のケースが2種類あるのは私には技術的知識が無いので不明ですが、一方だけしかデコードできない Thunderbird は処理が厳格というか標準準拠なのかなと思います。そのデコードできないメールのヘッダ、送り手のメールクライアント、OS 等の情報を具体的に提示してください。それによってはバグかも知れませんし、そうではないかも知れません。もしバグの場合はここで書いても開発者は見ていませんのでその存在をBugzilla@Mozilla 等にレポートしないと解決されません。＊TB と略するのなら Tb がお勧めです。

作成者:	Y2 [ 2007年6月26日(火) 12:01 ]
記事の件名:	Re: サブジェクトがデコードされない
Premier さんが書きました: コード: SUBJECT: =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= のような終端のケースでも Thunderbird はデコードします。デコードされなかったので、質問しました。 Premier さんが書きました: =? で始まり、 ?= で終わるのが決まりのようですが、ビット数が合わない場合は == として調整する仕様のようです。では、エンコードの仕様的には正しそうですね。 Premier さんが書きました: Subject: 欄等のエンコードするヘッダ項目には仕様があるのですが、送り手側と受け手側のメールクライアントの仕様により一致していないと文字化けとなります。文字化けは発生していません。デコードせずに、そのまま表示されます。 Premier さんが書きました: 終端の処理のケースが2種類あるのは私には技術的知識が無いので不明ですが、一方だけしかデコードできない Thunderbird は処理が厳格というか標準準拠なのかなと思います。そうかもしれませんが、多くのクライアントでデコードできているという事実もあります。 Premier さんが書きました: そのデコードできないメールのヘッダ、送り手のメールクライアント、OS 等の情報を具体的に提示してください。ヘッダで関連すると思われるのは、下記の通り。 SUBJECT: =?ISO-2022-JP?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= Content-type: text/plain; charset="iso-2022-jp" 送り手のメールクライアントおよびOSは不明(User-Agent もありません)ですが、おそらくプログラムによる自動生成だと思われます。 Premier さんが書きました: それによってはバグかも知れませんし、そうではないかも知れません。もしバグの場合はここで書いても開発者は見ていませんのでその存在をBugzilla@Mozilla 等にレポートしないと解決されません。バグか仕様かの判断ができずにいます。英語でレポートできるのかという問題もありますが。。。 Premier さんが書きました: ＊TB と略するのなら Tb がお勧めです。了解しました。

作成者:	POCH [ 2007年6月26日(火) 20:33 ]
記事の件名:	Re: サブジェクトがデコードされない
試しに、Gmailから自分のメインアドレスに問題となっている件名の以下 =?ISO-2022-JP?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= をそのままGmailの件名欄に貼付けて自分のメインアドレスに送って Thunderbird で受信してみました。本文には「テスト」と書いてあります。 Thunderbird のUI上の件名は =?ISO-2022-JP?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= と表示されてます。本文は「テスト」と表示されます。メッセージのソースを見ると Subject: =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= となってます。 =?iso-2022-jp?B?GyRCTjE8aSViITwlSSQrJGkkTkRMQ04bKEI==?= を解読すると「留守モードからの通知」ですよね。これって自動生成の返信メールかなんかですよね? 自動生成の際に上記テストしたような事をやっているのではないでしょうか? ちなみに Mail.app や yahoo のフリーメールなんかではデコードしてくれてました。以上、報告まで。

作成者:	Premier [ 2007年6月26日(火) 23:26 ]
記事の件名:	Re: サブジェクトがデコードされない
Premier さんが書きました: =? で始まり、 ?= で終わるのが決まりのようですが、ビット数が合わない場合は == として調整する仕様のようです。 Y2 さんが書きました: では、エンコードの仕様的には正しそうですね。うーん、正確には私にはわかりません。 RFC 2045 を読むとどちらも正しいとも読み取れます。＊ 6.8 Base64 Content-Transfer-Encoding の部分です。 RFC2045 日本語訳 RFC2045 Base64 で使用する文字の種類 Y2 さんが書きました: 文字化けは発生していません。デコードせずに、そのまま表示されます。失礼しました。文字化けという表現はデコードされずにそのまま表示されるという意味で使いました。 Y2 さんが書きました: そうかもしれませんが、多くのクライアントでデコードできているという事実もあります。そのとおりですね。一方で多くのクライアントでデコードできているからそれが標準あるいは正しい仕様だとも言い切れないかも知れませんね。ちなみに Becky!Ver2 で「留守モードからの通知」をタイトルにしてダミーメールを作成したところ、Subject: の終端は ==?= ではなく、 ?= となりました。 Becky!Ver2 も終端はどちらのタイプもデコードしてくれましたので親切なのかな？ Y2 さんが書きました: バグか仕様かの判断ができずにいます。英語でレポートできるのかという問題もありますが。。。そうですね。どなたかよくご存知の方から「これはバグです」とか「仕様です」とか「どちらも正しいです」とか明確に教えていただくとスッキリしますね。バグ検索をしていないので不明ですが、日本語なら Bugzilla-jp がありますのでそちらで要望として ==?= の場合もデコードする仕様にしてほしいとレポートする方法もありかと思います。既に同様のレポートがあったとしたらごめんなさい。参照：はじめてのバグジラ ver2.16.1a2-ja編＊最新版ではないのですが参考まで。

ページ 1 ／ 2	All times are UTC + 9 hours
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/

作成者:	kiyo4_k [ 2007年6月27日(水) 00:45 ]
記事の件名:	Re: サブジェクトがデコードされない
Premier さんが書きました: そうですね。どなたかよくご存知の方から「これはバグです」とか「仕様です」とか「どちらも正しいです」とか明確に教えていただくとスッキリしますね。 Thunderbirdの開発側のポリシーと頑なな態度そのものがバグと言いたいものが多いです。送信はRFCをきっちり守り、受信は寛容＆柔軟に対応して欲しいです。