こんにちは、
スルーしておりましたが、関連するかもしれない情報を投下です

2019/01/11のメールの『添付ファイル』で　この文字化けが起こっていたことを報告いたします。

相手のメーラーは
Microsoft Windows live mail 15.4.3555.308
でした

使用上特に困らなかったし、少なくとも件名ではなかったのでのでスルーしておりましたが
情報になれば。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Waterfox/56.2.12

「この文字化け」とはどのような現象でしょうか？

�はどこに入るのでしょうか？
添付ファイルというのはテキストファイルで、その中身に�が入っているのでしょうか？
それとも添付ファイルのファイル名に�が入ってしまっているのでしょうか？
あるいは別の何かですか？

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

ご指摘ありがとうございます。

補足となります

OS：Windows10（受信　送信　共）
添付ファイル形式　：　Microsoft Excel Worksheet (.xlsx)

ファイルの開封・内容には影響（問題）はありませんでした。

メールヘッダ情報

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=̲NextPart̲000̲00B5̲01D4A9CC.953E7D30"
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308


よく確認してみた所 %uFFFD が付くには条件がありまして、
一度Exelをかませる必要がありました

開く→Exelにて　名前を付けて保存
　2019.04.02 〇〇〇〇部 2018年度%uFFFDテーマ進捗報告(2019年03月実績).xlsx

名前を付けて保存
　2019.04.02 〇〇〇〇部 2018年�テーマ進捗報告(2019年03月実績).xlsx


また、1月と2月以降で文字化けの起こる位置が異なっていたことがわかりました

　2019.01.11 〇〇〇〇部 2018年テ�ーマ進捗報告(2018年12月実績).xlsx

メールヘッダは
Content-Type:　の　=̲NextPart̲以降が
異なるだけだったので省略いたします。

参考になれば

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Waterfox/56.2.12

John Smith さん、補足情報ありがとうございます。
それで、私の質問に対する回答としては
「添付ファイルのファイル名に�が入ってしまっている」
ということでよろしいでしょうか？

そして、挿入される個所について
　2019.04.02 〇〇〇〇部 2018年�テーマ進捗報告(2019年03月実績).xlsx
と
　2019.01.11 〇〇〇〇部 2018年テ�ーマ進捗報告(2018年12月実績).xlsx
の2パターンあったということですね。


それは、�が入ったファイル名を開こうとしたため、パーセントエンコード（URLエンコード）したというだけで、別の話ですね。

私のPCにも Windows 7のときの Windows Live メール Version 2009 (Build 14.0.8089.0726) が残っていたので、確認したところとりあえずの再現出来ました。

添付ファイルとして 2019.04.02 〇〇〇〇部 2018年テーマ進捗報告(2019年03月実績).xlsx ファイルを用意し、
JISエンコードで送信する設定にて、
----------
件名：2019.04.02 〇〇〇〇部 2018年テーマ進捗報告(2019年03月実績)
本文：2019.04.02 〇〇〇〇部 2018年テーマ進捗報告(2019年03月実績) を添付して送ります
----------
のメールにファイル添付して送信、Thunderbirdで受信したところ、
件名や本文には問題は無く、メール表示下部の添付ファイル名のみ下記画像のように�が入っていました。
�が入る位置に関しては、たまたまそういう区切りになっただけ（メール全体を調べないとわからない）であまり気にすることではないかと思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

＞ EarlgreyTeaさん
検証ありがとうございます。
ちょっと返答が足らなかったようで反省中です

件名の方では影響がないということで、元のテーマとは関係は薄そうですね……残念

ファイル名が長文で半角スペース 半角ピリオドと色々問題がおこりそうで
きっかけになるか少し期待したのですが

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Waterfox/56.2.12

いえ、そうではありません。貴重な情報です。

最初の投稿者 tano さんの事例はメールの件名でしたが、それはあくまできっかけであって、
現在のUNICODE関連の仕様に合致しないISO-2022-JPエンコードを行う、一部のメールソフトで送信されたメールを受信した場合に、ThunderbirdのISO-2022-JPデコーダーは仕様通りにエラーとして�(U+FFFD) に置き換えてしまうことがある、という一連の問題です。

ここで注意すべきなのは、原因自体はすでに判明していますが、Thunderbird側（当然Firefoxも）はあくまで標準仕様通りに修正したのであり、仕様に合致しないメールの方が悪い、ということになっているということです。

まず、その標準仕様に関する議論 https://github.com/whatwg/encoding/issues/115 に意見を出すというアプローチを試みました。
しかし、それは停滞してしまい効果は得られませんでした。

したがって、Thunderbirdの問題としてバグを立てて、どういう点が問題でなぜ対応しないといけないのかを、非日本語圏の開発者にも理解してもらうように説明する必要があるのです。
そのため、

• 日本では 〇〇〇 や △△△ といったソフトを使ってISO-2022-JPエンコードのメールが多数送信されていて
• それらのメールをThunderbird で受信すると U+FFFD が挿入されるケースが多発し、そのメールを返信、転送するたびに U+FFFD の除去を強いられており業務に支障が出るレベルであり
• Microsoft製のメールクライアントや他のWebメール（Gmail、Outlook.com、Yahoo!JAPAN）では問題ないため、賢明なユーザーはThunderbirdの使用を断念して他製品への乗り換えを検討することになる

という感じの主張をしたいと考えています。

なので、
〇〇〇というソフトでメール送信した場合はパターンA、△△△というソフトでメール送信した場合はパターンB の現象となる、
といった情報が重要になってくるのです。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

このトピックで報告された症状についてまとめてみました。

(1) Posted: 2018年11月09日(金) 09:32 tano
概要：メールの件名に U+FFFD が入る
詳細：
▼件名
　[plm-icadsx-support:238274] [WEBフォームシステム] プログラムサポートサービス利用開始登録届けへの入力がありました
　　↓
　[plm-icadsx-support:238274] [WEBフォームシステム] プロ�グラムサポートサービス利用開始登録届けへの入力がありました
送信ソフト：不明（AL-MAIL32ではない）

(2) Posted: 2018年11月13日(火) 09:55 KENT
概要：メールの本文で半角カナが使用されている箇所に U+FFFD が入る
詳細：
▼本文
　ｵｰﾀﾞｰ ( 半角カナ文字の1文字毎の直前に [ESC](B[ESC](I が出力され、最後 [ESC](I で終わっている )
　　↓
　�ｵ�ｰ�ﾀﾞ�ｰ
送信ソフト：不明

(3) Posted: 2019年1月21日(月) 09:27 wr_papa
概要：メールの件名と添付ファイル名に U+FFFD が入る
詳細：
▼件名
　週報（２０１９年　１月１１日～２０１９年　１月１７日）
　　↓
　週報（２０１９年　１月１�１日～２０１９年　１月１７日）
▼添付ファイル名
　赤羽志茂店簡易ストコンデータ.lzh
　　↓
　赤羽志茂店簡易ストコンデ�ータ.lzh
送信ソフト：AL-MAIL32（Outlookのメールでは症状は出ない）

(4) Posted: 2019年7月09日(火) 21:09 mose
概要：おそらく(3)と同様の症状
詳細：不明
送信ソフト：AL-MAIL32

(5) Posted: 2019年7月22日(月) 22:36 ◆？◆
概要：メールの添付ファイル名に U+FFFD が入る
詳細：不明
送信ソフト：Outlook 2016

(6) Posted: 2019年7月23日(火) 11:20 panorama
概要：メールの件名と本文に U+FFFD が入る
詳細：
▼本文
　田中一郎様 （最初に [ESC]$B、郎と様の間に [ESC](B[ESC]$B、最後に [ESC](B ）
　　↓
　田中一郎�様
送信ソフト：
　携帯コンテンツ変換・配信サーバーアプリ Durian https://www.symmetric.co.jp/durian/
　のメール配信機能がJISエンコード済み文字列を連結したと推測される

(7) Posted: 2019年7月26日(金) 23:04 John Smith
概要：メールの添付ファイル名に U+FFFD が入る
詳細：
▼添付ファイル名
　2019.04.02 〇〇〇〇部 2018年テーマ進捗報告(2019年03月実績).xlsx
　　↓
　2019.04.02 〇〇〇〇部 2018年�テーマ進捗報告(2019年03月実績).xlsx
送信ソフト：Windows Live メール 15.4.3555.308

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

[-WEBKIT-CENTER]EarlgreyTeaさん[/-WEBKIT-CENTER]

まとめ、ありがとうございます。わかりやすいです。

_________________
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36

確認いただきましてありがとうございます。
(5)の「概要」の文言が他と多少違っていましたので修正しました。
実例がありませんでしたので「詳細」は不明とさせていただいています。


大変興味深い関連する話ではありますが、別な問題として区別すべきかと思います。
このトピックで取り上げている問題は、ThunderbirdのISO-2022-JPデコード処理が標準仕様に準拠するように変更された結果、それに適合しない動作のISO-2022-JPエンコード処理で作成されたメールを受信した場合に、エラーを検出してU+FFFDが挿入されてしまうということです。

Thunderbirdから送信してOutlookで受信した場合というのは、ThundedrbirdのISO-2022-JPエンコード処理とOutlookのISO-2022-JPデコード処理の関係です。
ThundedrbirdのISO-2022-JPエンコード処理も、もちろん標準仕様に準拠するように変更されているはずで、Thunderbirdの両者の処理は適合しているはずです。
※ ThunderbirdからOutlookへ送信したメールの送信済みフォルダーに保存された控えは、Thunderbirdで問題なく表示できていますか？

新しいThunderbirdはISO-2022-JPの処理は、簡単にいうと厳格で融通の利かないものに変更になっており、それに対して従来のメールソフトはある程度のいい加減さを許容する処理になっている、という風に私は認識しています。

すなわち、その理屈からいうとThunderbirdのメールはOutlookで適切に表示されるはずです。
詳細がわかりませんので確かなことは言えませんが、Outlookで文字化けするというのは別の問題のように思われます。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

事例を報告させていただきます。添付ファイルの文字化けです。日々起きているので枚挙にいとまがありませんが。。。

使用（受信）ソフトウェア：Thunderbird 60.8.0 (32 ビット)

例１
リスクレジスタ(〇〇〇�〇〇〇) 20190605(案0).xlsx
〇：全角日本語
User-agent: Active! mail（Webメールですね）

例２
概算見積用実施内容案_ xxxx〇�〇〇〇〇〇〇〇〇〇〇.docx
x: 半角文字、〇：全角日本語
User-agent: Microsoft Outlook 16.0
Office 365 の Outlook です。バージョン 1908、ビルド 11929.20254

他には、大手メーカーからの添付ファイルが頻繁に文字化けします。
User-agentは消えていますが、Outlookを使っているのは話を聞いてわかっています。

添付ファイルを自動で保存するようにしているのですが、ファイル名の検索で見つけづらくなってしまい、少し困っています。

どこかに報告して話が転がればよいと思うのですが、どこに問い合わせればよいものでしょうか。
bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1506049) ではWHATWGに回されていますが、技術的背景を理解していない素人がWHATWGに書き込むのは少し気が引けます。
# hsivonen さんが提案書まで準備してくれているのに止まっているのももったいない気もしますが。。。

これまでの流れを見ていると、Thunderbirdとは標準仕様に合わせているものと理解しました。
むしろOfficeにフィードバックを送っても良いかなと思います。
Office側でどうエンコード処理をしてもらえばよいのかどなたか書いていただけませんでしょうか。英語にして書き込むくらいのことはしたいと思っています。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Rereremio さん、情報ありがとうございます。


添付ファイル名ですね。そして Active! mail ですか。
公式サイトの宣伝文句曰く「国内売り上げシェアNo.1を誇るビジネスWebメール」とのことなので、法人ユーザーは相当数いるものと思われます。
そして、実は Bug 1374149 で 言及 されていたので、実際の事例の報告を待っていたところだったのです。


WHATWGはもういいと思います。
そもそもあの Issue の発端は、2017年6月に報告された

• Bug 1374149 Folded subject header using ISO-2022-JP doesn't get decoded properly

なわけです。そして 2018年11月に Firefoxのバグとして出された、

• Bug 1506049 TextDecoder returns wrong result for ISO-2022-JP text

では、Firefoxは仕様に準拠しているとしてクローズになっています。
そこで WHATWG のIssueを紹介されたのでそちらにコメントしてみたわけですが、
意味が無かったとは思いませんが、あまり効果的なやりかたではなかったようです。

私たちがやるべきことは、Thunderbirdのバグとして報告を行い、そこでこの問題が日本でのThunderbirdのシェアに直結した深刻な問題であることを訴えることだと思うのです。

標準仕様ではエスケープシーケンス間が0バイトなら、セキュリティ上の懸念があるためエラーにする…まあいいでしょう。

しかし、それが重要な懸念であるならば、CVE などの脆弱性情報データベースに登録され、それをもとに日本の JPCERT/CC や IPAが動いて、標準仕様に準拠しない、瀬弱性のあるISO-2022-JPエンコーダー／デコーダーソフトウェアを根絶させるキャンペーンを打つ、というのでなければ、現実を無視した机上の空論というものです。
重要なのは、

• 日本のThunderbirdユーザーは、ThunderbirdでデコードしてエラーとみなされるようなISO-2022-JPエンコードの電子メールを日々扱うことを求められており
• Thunderbird以外の Outlookや、Windowsメールアプリや、Windows Liveメールや、Sylpheed や、AL-MAIL32 や、Gmail などの Webメールなんかは全く問題ない

という厳然たる事実でしょう。


いやあ、「ThunderbirdでエラーになるのでOutlookのISＯ-2022-JPエンコード処理を適合するように修正してください」とマイクロソフトに要望を出すというのは、ちょっと違う気がします。
ダメなのは（メールソフトでは）Thunderbirdだけであり、Thunderbirdが対応するのが筋だ思います。
それに、Thunderbirdがエラーを出すメールを送ってくるのはOutlookだけではないので、解決にはなりませんね。


英語お得意なのでしょうか。
私は正直言って得意ではありませんので、bugzilla にバグ出すのも一苦労です。
もしよろしければ、代わりに bugzilla にThunderbirdのバグ報告出していただけないでしょうか。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Thunderbirdとは関係ないですが
こちらの現象、Androidスマホ　Huawei mate20 lite　の標準メーラーでも起こっていますね。

発生条件はヘッダなどの確認ができないので調査できませんが。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0 Waterfox/56.2.13

EarlgreyTea さん、ご回答ありがとうございます。

やはりThunderbird側で対応すべきとの旨、理解しました。私もそうすべきだと思いました。




得意というほどでもないですが、それほど苦でもありません。一助になるのであれば喜んで文章作成いたします。元ネタを書いていただけませんでしょうか。
以下、ご依頼です。

• レポートする技術的な部分については、知識がほとんどありませんので、そのまま英訳できる形で書いていただけると助かります
• Thunderbirdで対応すべき、というところは、だいたいわかりましたので、要旨を箇条書きにしていただければ英文にいたします
• bugzillaに書き込んだことはないので、投稿はEarlgreyTeaさんからしていただけると助かるのですが。。。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

Office365のwebアプリ版OutlookとThunderbird60.9.0を併用しています。
Outlookから送信　Thunderbiedで受信すると、添付ファイル名が
（ひらがな19文字）.docx
では18文字目の後ろにU+FFFDの菱形が入ります。
長さを変えてみるとdot手前の文字数が18文字と19文字に境目があり、18文字以下なら問題なし、
19文字以上だと18文字目の後ろに菱形が入ります。
拡張子の有無や拡張子文字列の長さは無関係です。

これらのメールはそのままサーバーに残っていてOutlookでも受信できますが、
すべて元のファイル名どおりで文字化けしません。
すべてを試したわけではありませんが、これら長いファイル名のファイルを
Thunderbirdから送信しても文字化け問題は起こりません。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

てっきり、ご自身が問い合わせをしてなんとか問題解決したいという話かと思いましたが、英訳のお手伝いならできますよ、という感じのスタンスでしたか。
ネタというか材料なら、このトピックで十分に提供してきたつもりです。
このトピックが立った2018年11月09日当初から関わってきました。もう10カ月になります。
その間の私の投稿数を数えたところ17回です。

やっぱりモチベーションというのは大事だと思うんですよ。
私はもう、この件に関してモチベーションを維持するのはちょっと無理です。
遅きに失した感がありますし、そもそも私自身はさして困っているわけではないからなんです。
（むしろ、電子メールでISO-2022-JPを使うこと自体を早くやめるべきだと思っています）
本当に困っている人が、自ら行動すべきだと思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0