MozillaZine.jp フォーラム

Thunderbirdが91.3.0(32 bit)に自動アップデートされたところ、突然文字化けが起きました。エンコードの設定を変更しようと思いましたが「テキストエンコーディングを修復」のみで詳細設定の項目が見当たりません。該当の設定方法をお知らせください。

ひばりさん、こんにちは

91.xからはテキストエンコード形式を変更する機能が削除されたようです。
対策としては Charset Menuという拡張機能を作成されている方が居てそれをインストールすることによりエンコード形式を変更して表示できるようになります。

ただこの機能、ヘッダー表示の画面では機能しないようで、文字化けメールなどをヘッダー表示で調べる際に使用できず少々不便です。

moto3さん。
ご丁寧にご教示いただきありがとうございました。そのプラグインを試してみようと思います。

それにしても詳細設定のできない仕様への変更は、なんのメリットがあるのか理解できません・・・。

moto3 さんが書きました: 対策としては Charset Menuという拡張機能を作成されている方が居て
それをインストールすることによりエンコード形式を変更して表示できるようになります。

　残念なことにThunderbird91.4で文字コードの強制変更機能自体が削除されるため、
このアドオンにより本文をコード変更して表示できるのは91.3までの模様です。
　【Charset Menu 1.1.1　作者 Jorg K さんのコメント　へのリンク】

　最近のThunderbirdは、Backward Compatibility（後方互換/過去にできていた動作の継承）
とかInteroperability（相互運用性/他のシステムとの協調）に背を向け、
「過去のことは知らない。完璧に今の標準に従ってないものは相手にしない。」
という態度になりました。

　古いしきたりで、MIMEで文字コードを明示的に埋め込まない形式により送信されてきた
メールは、たとえローカルフォルダに後生大事に保管しておいても「今の標準じゃない」
ものとして91.4以降は切り捨てられることになります。

　ビジネス用途のメールアプリケーションとして、こういう後方互換性を失うのは
結構致命的です。なにしろ5年でも10年でも昔のメールを取引の証拠として検索し
掘り出すのは日常茶飯事です。「過去のデファクトスタンダードで送受信したメールの
内容が今のメールアプリでは見れない」ということでは、当時のアプリ＋ＯＳ＋ハードを
無理やり維持するか、それが可能なアプリケーションに移行することを検討しなければ
なりません。

　今の段階でもISO-2022-JPでSubjectが書かれたメールを読むためにはVer.31(2015年)
以前を要します。MIME形式でないメールを過去にさかのぼって読もうとしたら
Ver.78とか91.3+Charset Menuを維持することになるのでしょうかね。

※やや脱線しますが、2022年1月施行の「改正電子帳簿保存法」では「電子メール本文に
　取引情報が記載されている場合は当該電子メールを[電子データで]保存する必要があります」
　と告示されており、しかも税法上の保管期間（7～10年）の間は電子データにおいて
　「検索可能」かつ「可読な状態」の維持が義務になりました。みなさんどうします？

f-angel-mzzjさん。
おっしゃるとおり、こちらも過去のメールまでぜんぶ文字化け。仕事にならずに途方に暮れています。今回のアプデが「Windows8.0」と同じ匂いがするのは気のせいでしょうか。

f-angel-mzzj さんが書きました: 　残念なことにThunderbird91.4で文字コードの強制変更機能自体が削除されるため、
このアドオンにより本文をコード変更して表示できるのは91.3までの模様です。
　【Charset Menu 1.1.1　作者 Jorg K さんのコメント　へのリンク】

　作者のコメントが更新されました。Thunderbird91.3.2の段階でAPIが削除され、
表示の強制変更はダメになったとのことです。

　文字化けして読めないメール本文を手間をかけて解読するのが常で、
解読が無理なら怪しげな en-JP ?をやり取りした20世紀末の
日本語電子メール黎明期に戻った感がします。

f-angel-mzzj さんが書きました:　文字化けして読めないメール本文を手間をかけて解読するのが常で、
解読が無理なら怪しげな en-JP ?をやり取りした20世紀末の
日本語電子メール黎明期に戻った感がします。

その「日本語電子メール黎明期」のままズルズルと来てしまった、そして今になって慌てているという状況なのだろうと思います。
ISO-2022-JP という文字符号化方式が生まれたのは1993年です。
20世紀末というか平成の初めとしては他に選択肢はなかったわけですが、令和になった2021年の現在、ISO-2022-JP を使わなければいけない正当な理由もメリットもありません。
7bit しか通さないMTAなど絶滅していますし、そもそもそれは文字エンコーディングではなく、 BASE64 や Quoted-Printable などの伝送エンコード方式の仕事です。

f-angel-mzzj さんが書きました:「過去のデファクトスタンダードで送受信したメールの
内容が今のメールアプリでは見れない」ということでは、当時のアプリ＋ＯＳ＋ハードを
無理やり維持するか、それが可能なアプリケーションに移行することを検討しなければ
なりません。

過去に受信したメールは閲覧・検索用に別管理すればいいだけです。
Thunderbird であれば、メールデータはmbox形式なので、Outlook の pst や ost と違って他アプリに持っていくのも楽です。
古い OS やハードを維持する必要などありません。
望めば Thunderbird 31 くらいならダウンロードもインストールも全く問題ありませんし、閲覧・検索専用ならセキュリティを気にする必要もありません。

もし、古いPCの古い Outlook に重要なメールがあったらどうでしょうか。
バージョン間でデータ形式に互換性がなく、あまりにも古すぎたらエクスポート／インポートする手段もなくなり、同じ古いバージョンのアプリをインストールすることも不可能です。

皆さん、maji です。

過去の諸々混乱してた時期を引きずったメール文字化けへの対応については
私自身も苦慮してるのと同時に、
現時点(orこれから)の「あるべき姿(→EUC化の方向？)」にどう流れを是正していくか
にも強く興味を持っています。

-----

そんな中で気になったのは f-angel-mzzj さんの以下の「やや脱線」の部分。

viewtopic.php?f=3&t=19049#p69905

f-angel-mzzj さんが書きました:今の段階でもISO-2022-JPでSubjectが書かれたメールを読むためにはVer.31(2015年)
以前を要します。MIME形式でないメールを過去にさかのぼって読もうとしたら
Ver.78とか91.3+Charset Menuを維持することになるのでしょうかね。

※やや脱線しますが、2022年1月施行の「改正電子帳簿保存法」では「電子メール本文に
　取引情報が記載されている場合は当該電子メールを[電子データで]保存する必要があります」
　と告示されており、しかも税法上の保管期間（7～10年）の間は電子データにおいて
　「検索可能」かつ「可読な状態」の維持が義務になりました。みなさんどうします？

上記に書かれてる通りですが
「改正電子帳簿保存法」の施行は 2022年1月 であり、
それ以前の電子メールデータについては言及していない、
てなのが私の解釈です。

かつ、ググって見付けた以下の記事では、、、、、

電子帳簿保存法一問一答 - 国税庁
0021006-031_03.pdf
https://www.nta.go.jp/law/joho-zeikaish ... 031_03.pdf

》 データ保存に当たっては、以下の点に留意が必要です。
(中略)
》 当該データが添付された電子メールについて、当該メ
》 ールソフト上で閲覧できるだけでは十分とは言えません。

とも記されています。
メールソフトのメールボックスにあるメールを文字化けせずに検索閲覧できること自体は
改正電子帳簿保存法での「電子データで保存する」要件を満たさないのではと
私は解釈しています。

なので、
たとえ「やや脱線」との注釈付きだとしても
ここでの「文字化け」に関する意見交換の中で「改正電子帳簿保存法」を絡めるのは適切ではない
のではと考えます(私見)。

-----

それ以外の部分については
私自身も興味深く皆さんの議論を閲覧させていただいています。

では。

maji さんが書きました:現時点(orこれから)の「あるべき姿(→EUC化の方向？)」にどう流れを是正していくか

EUC というのは End-User Computing の事でしょうか。
メール文字化けへの対応の文脈でエンドユーザーコンピューティング化が唐突に出てくるのに違和感を感じます。
それとも、UNICODE と Extended UNIX Code を間違えたのでしょうか。

皆さん、maji です。

EarlgreyTea さんから

EarlgreyTea さんが書きました:

maji さんが書きました:現時点(orこれから)の「あるべき姿(→EUC化の方向？)」にどう流れを是正していくか

EUC というのは End-User Computing の事でしょうか。
メール文字化けへの対応の文脈でエンドユーザーコンピューティング化が唐突に出てくるのに違和感を感じます。
それとも、UNICODE と Extended UNIX Code を間違えたのでしょうか。

と指摘いただきました。
「 UNICODE (→ UTF)」の間違いです。

以下、書き直しておきます。

-----(書き直しここから)-----

過去の諸々混乱してた時期を引きずったメール文字化けへの対応については
私自身も苦慮してるのと同時に、
現時点(orこれから)の「あるべき姿(→ UNICODE(UTF)化の方向？)」にどう流れを是正していくか
にも強く興味を持っています。

(以下省略)

-----(書き直しここまで)-----

EarlgreyTea さん、
これで良いですか？

ではでは。

なにも全文投稿し直さなくても・・・
私は昔UNIXワークステーションでの仕事してたこともありまして、EUC-JPでソースコードのコメント書いていました。
インターネット上のテキストをEUC化とか流石にトンデモ過ぎてついツッコミ入れた次第です。

EarlgreyTea さんが書きました:なにも全文投稿し直さなくても・・・

？？？

話が脱線＆場外乱闘気味になってきたので、
いったん振り出しに戻しましょう。

-----

ひばり さん、
viewtopic.php?f=3&t=19049#p69881

ひばり さんが書きました:Thunderbirdが91.3.0(32 bit)に自動アップデートされたところ、突然文字化けが起きました。

91.3.0 へのアップデート後に「突然文字化けが起きました」との事ですが、
その文字化けはどんな具合に起きてますか？

例えば、、、、、
全てのメールが文字化けしてるとか
一部のor特定のメールが文字化けしてるとか、
91.3.0 以前では正常だったメールまで文字化けしだしたとか、、、、、、、

文字化けしてる状況によっては、
別の流れでの情報交換が出来るでしょう。

-----

では。