Thunderbird 52.0 で既定のテキストエンコーディングを UTF-8 へ変更

[mar]

しました。

Thunderbird/SeaMonkey の既定のテキストエンコーディングを UTF-8 に変更する · Issue #63 · mozilla-japan/gecko-l10n

次期リリース版の 52.0 beta がダウンロード可能になっています。
https://archive.mozilla.org/pub/thunder ... es/52.0b1/

何か問題がありましたらコメントください。

[偶然的通行人]

本件、ぼく自身は別トピックに書いたとおり、とくに困ることはありません。後述するような設定では使っていませんし...。
・【レポート】Thunderbird 52.0b1 を使ってみて気づいた新機能など
http://forums.mozillazine.jp/viewtopic.php?f=3&t=16489

ただ、テストした範囲で少し気になった点を書かせていただきます。

Windows 7 環境下において、現在 Thunderbird 45.7.0 で使っているプロファイルのコピーを作り、そのプロファイルで Thunderbird 52.0b1 を起動してみました。
ようは、45.7.0 から 52.0 に自動更新し、45.7.0 で使っていたプロファイルをそのまま継承した形になります。

更新前の 45.7.0 の設定内容は次のとおりです。

┌ テキストエンコーディング ───────────────────────────
│ メッセージの送受信に使用する既定のテキストエンコーディングを設定します。
│
│ 送信メッセージ(U): [日本語 (ISO-2022-JP)]　…… 45.x の初期値
│ 受信メッセージ(I): [日本語 (ISO-2022-JP)]　…… 45.x の初期値
│
│ ☑ 可能であれば返信メッセージに既定のテキストエンコーディングを使用する … チェック付
└────────────────────────────────────────

　[送信メッセージ] (mailnews.send_default_charset)
　[受信メッセージ] (mailnews.view_default_charset)
は、ともに 45.x 系の初期値のままです。52.0 の初期値が変更されているので、45.x 系の内容が引き継がれるのか、52.0 系の初期値にリセットされるのかを見るのが目的です。一方、
　[可能であれば返信メッセージに既定のテキストエンコーディングを使用する] (mailnews.reply_in_default_charset)
の初期値は、45.x 系、52.0 ともにチェックなし（無効 / false）なのですが、[テキストエンコーディング] の項目全体がどうマイグレートされるかを切り分けるため、意識的に変更（有効化）しておきました。

この内容のプロファイルを 52.0 に引き継がせた結果、当方では次のようになりました。

┌ テキストエンコーディング ───────────────────────────
│ メッセージの送受信に使用する既定のテキストエンコーディングを設定します。
│
│ 送信メッセージ(U): [Unicode (UTF-8)]　…… 52.0 の初期値に
│ 受信メッセージ(I): [Unicode (UTF-8)]　…… 52.0 の初期値に
│
│ ☑ 可能であれば返信メッセージに既定のテキストエンコーディングを使用する … チェック付！
└────────────────────────────────────────

既定のテキストエンコーディングの設定内容
　[送信メッセージ] (mailnews.send_default_charset)
　[受信メッセージ] (mailnews.view_default_charset)
は、ともに Thunderbird 52.0 の初期値 (UTF-8) にリセットされました。一方、
　[可能であれば返信メッセージに既定のテキストエンコーディングを使用する] (mailnews.reply_in_default_charset)
の設定値は、新規プロファイルでは 52.0 の初期値＝無効にリセットされず、45.7.0 の内容が継承されました。

もしこれが普遍的な移行結果だとすると、"返信の際は相手と同じエンコーディングがデフォルトになる" ことはなく、UTF-8 で返信されることになります。

実際、移行後の状態でテストしてみると、Content-Type の charset が ISO-2022-JP のメッセージに対しても、ISO-8859-1 や Windows-1252 のメッセージに対しても、返信は必ず UTF-8 になりました。

もちろん、このことが直ちに返信先で文字化けなどの問題を発生させるとは言えません。返信先の UTF-8 対応が十分なら、UTF-8 で返信されたメッセージを正常に扱えるとは思います。
45.7.0 でも、返信メッセージに ISO-2022-JP や ISO-8859-1 、Windows-1252 などで表現できない文字を追加したら、設定の如何に関わらず UTF-8 に変換されます。あくまで「可能であれば」ですし...。

しかし、45.x で明示的に ISO-2022-JP のエンコーディングで返信をするよう設定していたユーザー（少数派かもしれませんが）にとっては、52.0 にアップデート後、意図に反した結果（ISO-2022-JP のメッセージに対しても UTF-8 で返信）が常にもたらされることになります。
とくに法人環境において、45.x 以前から ISO-2022-JP を既定化していたような運用条件下で、52.0 に更新された直後の状況が気になります。

既定のテキストエンコーディングが UTF-8 になることに、ぼく自身は異論ありません。
しかし、[可能であれば返信メッセージに既定のテキストエンコーディングを使用する] も、いったん初期値（無効 / false）にリセットほうがいいのではないかと思います。
なぜなら、更新前のユーザー設定がどのようなものであれ、既定のテキストエンコーディングの変更にともなう不都合が起こり難くなり、"返信の際は相手と同じエンコーディングがデフォルトになる" の条件を維持できると思うからです。

（注）
上記は当方の環境に依存した特殊な結果なのかもしれませんし、テストの過程に何らかの手抜かりがあるかもしれません。他のユーザー環境では 45.x -> 52.0 のプロファイル継承がどうなるのか、もっと情報を集めたほうがいいかもしれません。

以上、エンドユーザーの立場で気になった事柄を述べさせていただきました。見当違いなことを書いていたらすみません。

[偶然的通行人]

すみません。文意が通じない箇所がありました。訂正させていただきます。

　[可能であれば返信メッセージに既定のテキストエンコーディングを使用する] (mailnews.reply_in_default_charset)
の設定値は、新規プロファイルでは 52.0 の初期値＝無効にリセットされず、45.7.0 の内容が継承されました。

　↓
の設定値は、新規プロファイルでは 52.0 の初期値＝無効になりますが、プロファイルの継承ではリセットされず、45.7.0 の内容が継承されました。

失礼いたしました。

[mar]

偶然的通行人さん、検証ありがとうございます。

ご指摘の通り、"mailnews.reply_in_default_charset" に関しては、52.0 で既定値が変更されるので 、引き続き ISO-2022-JP で使用したい場合はユーザーに設定を変更していただく必要があります。
まさに、この部分の兼ね合い（送信時のエンコーディング）をどちらにするかで、既定値の変更を 10 年も待っていたわけです。

[meeyar]

ここで訊いてよいのかためらいもありますが、一つ質問させてください。
Thunderbird45.7.0→52.0へ、今までのプロファイルを維持した状態で移行した場合の挙動が

この内容のプロファイルを 52.0 に引き継がせた結果、当方では次のようになりました。

┌ テキストエンコーディング ───────────────────────────
│ メッセージの送受信に使用する既定のテキストエンコーディングを設定します。
│
│ 送信メッセージ(U): [Unicode (UTF-8)]　…… 52.0 の初期値に
│ 受信メッセージ(I): [Unicode (UTF-8)]　…… 52.0 の初期値に
│
│ ☑ 可能であれば返信メッセージに既定のテキストエンコーディングを使用する … チェック付！
└────────────────────────────────────────

となるのであれば、まさしく

しかし、45.x で明示的に ISO-2022-JP のエンコーディングで返信をするよう設定していたユーザー（少数派かもしれませんが）にとっては、52.0 にアップデート後、意図に反した結果（ISO-2022-JP のメッセージに対しても UTF-8 で返信）が常にもたらされることになります。
とくに法人環境において、45.x 以前から ISO-2022-JP を既定化していたような運用条件下で、52.0 に更新された直後の状況が気になります。

の理由によって、「”可能であれば返信メッセージに既定のテキストエンコーディングを使用する”にチェックが入ったまま」であることの方が周知されるべきではないでしょうか？

送受信時のエンコーディングを気にしない（UTF-8だろうがISO-2022-JPだろうが頓着しない）環境の人であれば、わざわざここのチェックの有無を省みていないと思います。逆に言えば、今までISO-2022-JPでの送信に気を遣っている/いた人の方が、「どんなメールでも送信時のエンコーディングを統一したい（≒UTF-8では送らない）」の理由からチェックを入れていると思います。

marさんが提示された
https://archive.mozilla.org/pub/thunder ... es/52.0b1/
の中で、既定のエンコーディングがUTF-8になることそのものについては日本語のリリースノートに追記したい旨触れられていますが、あわせて”可能であれば返信メッセージに既定のテキストエンコーディングを使用する”のチェックが45.7.0以前の設定を継承することも触れておくべきと思いますし、法人対応を視野に入れるのであれば、正式版リリース前の段階でもきちんと(≒Mozillaの見解として)述べられている方が望ましいと思います。
（英語版の52.0betaリリースノート
https://www.mozilla.org/en-US/thunderbi ... easenotes/
の中では全くエンコーディングについての話がなく、日本語のリリースノート
http://www.mozilla.jp/thunderbird/releases/
は正式版のみ＆現在リダイレクトされてまともに読めないため）

個人的には、「規定をUTF-8に変更」とするなら、
”可能であれば返信メッセージに既定のテキストエンコーディングを使用する”のチェックも外しておく
の方が混乱は少なそうに思います。

[偶然的通行人]

mar さん、meeyar さん、拙い意見にお返事いただきありがとうございました。

本件の前提は、日本語のメールを扱うときの話です。多言語を同時に扱うようなケースでは、従来から UTF-8 が選択肢でした。

UTF-8 で日本語メールを送受信することに、本質的な障害は何もありません。ここが大前提です。
しかし、相手の事情等によって、今後も日本語メールを ISO-2022-JP で送信（返信、転送）することが必要なユーザーは、Thunderbird 52.0 に更新後、既定のテキストエンコーディングの設定に注意を払ってください ―― ということになりましょうか。

ただ、Thunderbird には [可能であれば返信メッセージに既定のテキストエンコーディングを使用する] (mailnews.reply_in_default_charset) という設定項目があるため、その存在に注目したとき視野に入ってくるのが、前便で申し上げたような設定内容で使ってきたケースでした。
実際は、そのようなユーザーがどの程度おられるかで、影響の度合いも変わってくると思います。

事前告知はあったほうがいいと思いますが、それでも混乱するユーザーをゼロにはできないでしょうから、そのようなユーザー向けのサポート記事を、早めに準備しておいたほうがいいかもしれませんね。
https://support.mozilla.org/ja/products/thunderbird

開発者のみなさんの日ごろのご努力に敬意と感謝を表しつつ、エンドユーザーの意見を述べさせていただいた次第です。

[メール一括送信]

FileMakerというデータベースソフトウェアから
テキスト形式メールの一括送信を行った際、
以下の設定を行っても、改行が反映されずに困り果てております。



・[表示] > [書式] > [フォントと配色] > [詳細設定] を開き、
　エンコーディングをISO-2022-JPに戻しましたが、
・mailnews.send_plaintext_flowed=false

良い解決策や情報があれば ご教示頂きたく存じます。

[meeyar]

まず、Thunderbirdの一般的な質問については
MozillaZine.jp フォーラム　・フォーラム閲覧 - Mozilla Thunderbird
でお願いします。
それから、OSの種類やThunderbirdのバージョンなどについても書いて下さい。

次に本題です。

FileMakerというデータベースソフトウェアから
テキスト形式メールの一括送信を行った際、
以下の設定を行っても、改行が反映されずに困り果てております。

・[表示] > [書式] > [フォントと配色] > [詳細設定] を開き、
　エンコーディングをISO-2022-JPに戻しましたが、
・mailnews.send_plaintext_flowed=false

この件については、当方の確認ではUTF-8条件下（＋テキストメールであること)でしか再現出来ていないのですが、メールの自動改行についてはmailnews.send_plaintext_flowedとplain_text.wrap_long_linesの2つが関与しているようです。

• mailnews.send_plaintext_flowed=false
• plain_text.wrap_long_lines=true

この2項目について試してみてください。Windows8.1＋Thunderbird52.0.1で確認しています。
画像付き→Thunderbird52.xでメール作成時の自動改行を有効化する - とりかごとなり。

【余談】
業務利用の場合は法人サポートも検討してください。
Firefox と Thunderbird の法人向けサポート | 法人向け情報 | Mozilla Japan

[メール一括送信]

meeyar様、アドバイス＆ご指摘を有難うございました。
・OS：Windows7 SP1
・Thunderbirdは52.0.1

・mailnews.send_plaintext_flowed=false
・plain_text.wrap_long_lines=true

共に設定を行いましたが、残念ながら改行は反映されませんでした事を報告させて頂きます。
有難うございました。

[meeyar]

ごめんなさい、一つ見落としがありました。

• mailnews.send_plaintext_flowed=false
• plain_text.wrap_long_lines=true

の設定で自動改行が有効になる条件が限られているらしいことが判明した(汗)ので訂正します。　

• [表示] > [書式] > [フォントと配色] > [詳細設定]でiso-2022-jpを指定していること
• メール本文の中身がiso-2022-jpで取扱い可能な範囲の文字であること

この2点が揃った場合にplain_text.wrap_long_lines=trueの設定が反映されます。
本文の内容がUTF-8でないと取扱い出来ない文字列が含まれている場合(機種依存文字を含むなど)には有効にならないようです。前便にて不完全な部分があり申し訳ありません。

この理由について調べた内容を書いておきます。

[表示] > [書式] > [フォントと配色] > [詳細設定]でiso-2022-jpを指定

の条件において、

1. 最初のメール作成時にUTF-8を指定
2. 一度メールを下書き保存(自動改行が効かない)
3. 2.のメール作成画面を再度開いて編集し、保存し直す

2→3の過程において、
plain_text.wrap_long_lines=false→エンコーディングはUTF-8のまま(自動改行が無効)
plain_text.wrap_long_lines=true→エンコーディングがiso-2022-jpに変化する(自動改行が有効)
になっているのがわかりました。
ですので、元のメール本文がiso-2022-jpで扱える内容(文字)である場合に、

• mailnews.send_plaintext_flowed=false
• plain_text.wrap_long_lines=true

が有効なようです。
この設定が効かないということは、元々のメール内容において、機種依存文字などの関係により、UTF-8でなければ送れない中身になっていることも考えられます。
そのあたりはどうでしょうか？

[通りマン]

FileMakerというデータベースソフトウェアから
テキスト形式メールの一括送信を行った際、
以下の設定を行っても、改行が反映されずに困り果てております。

なぜこのトピックに返信する形で質問しているのでしょうか？そのせいで、明後日の方向に行っている気がします。
まず、困っている現象について詳しく書いてください。

1. FileMakerから送ったメールのソースはどうなっていますか？
・Content-Typeヘッダー
・Content-Transfer-Encodingヘッダー
・ボディ
など

2. 何をした時に改行が反映されないのでしょうか？
・Thunderbirdで受信したメールを読んでいる時
・Thunderbirdで受信したメールに返信しようとしている時（編集中）
・Thunderbirdで返信したメールを他のメーラーで読んでいる時
など

[メール一括送信]

■meeyarさま、とんでもないです！
貴重なお時間を割いてまでアドバイス頂けている事を心より感謝しております。本当に有難うございます。
以前にご指摘を頂きましたので別トピへの移動を考えておりましたので、
前回は簡単なご報告のみとさせて頂きました。

はい「iso-2022-jp」に設定しており、
メール本文は
-------------------------
１行目１行目１行目
２行目２行目２行目
３行目３行目３行目
-------------------------
という、文字も↑のまんまというシンプルなテストメールでございますが、残念ながら改行は反映されませんでした。

■通りマンさま（＆ご覧の皆様）、色々とご迷惑をお掛けしてすみません。
このトピに返信した事が誤りであることをご指摘頂いた → 別トピへの移動を考慮するもお礼は必要と考え投稿した次第である事は前述の通りでございます。よって、改めてここに投稿するのも躊躇われますが
　・Content-Typeヘッダー：text/html; charset=[highlight=#ffff00]UTF-8[/highlight]
　・Content-Transfer-Encoding：8bit
　・Thunderbirdで受信したメールを読んでいる時で発生（BeckyやOutlookでも同様）

という状況でごすが、お二人のお陰様で新たな気付きを得る事ができました。
送信アｆプリ（filemaker）側には文字コードの設定なんてないのですが、その線も探ってみます。有難うございました。

[通りマン]

メール本文は
-------------------------
１行目１行目１行目
２行目２行目２行目
３行目３行目３行目
-------------------------
という、文字も↑のまんまというシンプルなテストメールでございますが、残念ながら改行は反映されませんでした。
（中略）
　・Content-Typeヘッダー：text/html; charset=[highlight=#ffff00]UTF-8[/highlight]
　・Content-Transfer-Encoding：8bit

つまり、以下のようになっているという事ですよね？

コード: 全て選択

Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

１行目１行目１行目
２行目２行目２行目
３行目３行目３行目

これだとhtml, bodyタグを省略したHTMLメールなので、表示する時に物理的な改行（改行コード）が無視されているだけだと思います。

[mar]

FYI: Unicode のメッセージの表示フォントの設定です。Windows 10, Thunderbird 52 の場合。

[オプション] > [表示] パネル > [書式] タブ > "フォントと配色" の [詳細設定] ボタン

対象言語: 他の表記体系
プロポーショナル: ゴシック体　　サイズ: 16
明朝体: Times New Roman
ゴシック体: Arial
等幅: Courier New　　サイズ: 13

上記設定は既定値です。文字サイズが小さい場合は、サイズを日本語と同じにしてください。
プロポーショナルのサイズ: 16 (日本語の既定値)
等幅のサイズ: 16 (日本語の既定値)

設定エディター (about:config) で変更する場合は、「x-unicode」で検索してください。