Thunderbird 45.0以降ではメールのContent-Typeに「format=flowed; delsp=yes」が追加される 19
変わるルール 部門より
まもなくリリース予定のThunderbird 45.0では、ISO-2022-JPで送信されるプレーンテキスト形式メールの「Content-Type」ヘッダに「format=flowed; delsp=yes」が追加される(MozillaのBugzilla)。「format=flowed」および「delsp=yes」はメール本文の自動改行とその復元を行う規格。多くのメールクライアントでは1行が76文字以下になるよう自動的に改行を行うような動作を行うが、この規格ではその改行方法と、自動改行された行を1行に復元するためのルールが定められている。
ISO-2022-JPのテキストメールを送信するとき、Thunderbird 38.xまでのContent-Typeヘッダーは「text/plain; charset=iso-2022-jp」だったが、45.0からは「text/plain; charset=iso-2022-jp; format=flowed; delsp=yes」のようになり、これに準じて長い行は処理される。
「format=flowed; delsp=yes」は日本語メールにおいて必ずしも良い仕様とは言えない点や、相互運用性問題があるという指摘もある。しかし、ガラケーからスマホまで様々な環境で利用されるメールにおいて、半角文字換算の70数文字で改行するという動作からの脱却は大きなメリットではないだろうか。
PCからガラケーにメールを送信したら、「変なところに改行が入っている」と言われた経験があるユーザーも多いことだろう。なお、Thunderbird 45.0は38.x以来のメジャーバージョンアップで、
現在45.0b3が公開中。
RFC 3676 (スコア:1)
これはRFC 3676で規定されたものです。
https://datatracker.ietf.org/doc/rfc3676/ [ietf.org]
> 「format=flowed」および「delsp=yes」はメール本文の自動改行とその復元を行う規格。
ここでRFC 3676に言及するつもりだったのでしょうが、忘れていますね。ストーリーになる前に1度見返していただくと有り難いんですけど…
動作比較 (スコア:1)
Thunderbird 45.0b1 における日本語メッセージの作成テスト
http://meitner.jimdo.com/2016/02/08/test-for-thunderbird-45-0b1/ [jimdo.com]
もっとはやく普及させてほしかった (スコア:1)
改行しないと古い人がうるさいし,改行すると新しい人が不満げだし,どうしたらいいのかわからないの.
Re:もっとはやく普及させてほしかった (スコア:1)
Re: (スコア:0)
自分の書くメールなんだから自分で好きな方にすりゃいいんだよ
メールの改行程度のことでぶうぶう言う奴の事を
気にしなきゃいけない理由のほうが分からないよ
そんな連中相手に神経すり減らすなんて勿体無いよ
Re:もっとはやく普及させてほしかった (スコア:1)
同意。
そして改行位置そのほかスタイル整形がクリティカルな文章はメール本文じゃなくて、添付ファイル等で。
Re: (スコア:0)
> そして改行位置そのほかスタイル整形がクリティカルな文章はメール本文じゃなくて、添付ファイル等で。
WordやPDFで添付になって、誰にも読まれなく・・・
Re: (スコア:0)
読まない人は本文も読まない
Re: (スコア:0)
まあ適当に受け流せば。
私も昔は改行派だったけど、改行しないメールを受信側でウィンドウ幅に合わせて折り返して表示できるので問題ない。
ただし、夜間にメールするなとかいう人は困る。電話じゃないんだから。
iso-2022-jp特有? (スコア:1)
リンクされているBugzillaの議論では、問題だとされているのはiso-2022-jpだから、ということではなく、日本語のような単語を空白で区切る習慣のない言語で、どこで区切りを入れればいいかという話のように見えます。(まあ、1行nバイトという制限をクリアするようにiso-2022-jpに変換するというのも結構面倒くさい話ではありますが、それとリンクされた議論なのかしら。)
英語のような、空白区切りの単語の集まりとして文章があらわされる言語なら、適当に空白が出てきたところに改行を入れればよい。でも、日本語だと空白が出てこないこともあるので、適当に70文字区切りとかで改行することになる。そうすると、format=flowedをサポートしていない相手には変な表示になる。format=flowedをサポートしているがdelsp=yesをサポートしていない相手だと、余計なところに空白が入る。とかなんとかややこしい議論が続いているが、長いので追いかけるのをやめた。
で、こういう処理は言語依存だから、iso-2022-jpを送信charsetに指定されたら日本語だと思って処理する、ということに見える。
で、ちょっと検索してみたところでは、format=flowedは、Apple Mail、Outlook Expressなどではサポートされていて、Gmailではサポートされていない(?)らしい。面倒だからquoted-printableで送信するとかなんとか、別の話と入り混じって、何が何やら。わけがわからないよ。
Re: (スコア:0)
1行nバイトという制限をクリアするようにiso-2022-jpに変換する
1行制限の単位は、RFC 2822のcharactersからRFC 5321のoctetsになったけど、ISO-2022-JP的には不明瞭なまま?
45.0b4出てます。 (スコア:0)
こちら [mozilla.org]
たまには開発版も見てみようと思ったんだけど、comm-auroraやcomm-centralの日本語版がなくなってる。
1年ほど前にはあったんだけど、最近はl10n版はビルドしなくなったの?
Re: (スコア:0)
単に今までボランティアが勝手にやっていたものだった。今まで勝手にやっていたボランティアが辞めた。
そんなことだろうと思う。
指摘もあるって言われてもなぁ (スコア:0)
それが十年近く前の日付でPostPetやらOutlook Expressやらの話してる記事じゃなぁ
むしろ「もはやそんな指摘はどうでもいい」ってことを示してるようなもんだ
だいたいセキュリティが厳しくなった昨今、それもメールなんて狙われやすいソフトは常に最新版にするのが当然。
古い動作のままのメールソフトの互換性なんかいちいち気にかける必要はない。
Re: (スコア:0)
PCのメールソフトはともかくガラケーが…。ガラケーさえなければそもそもUTF-8+Base64にできた。
Re: (スコア:0)
ほんとそれ。
いまだにiso-2022-jpとか使ってるのはメールぐらい。
もう無視したい。
さらにはrfc2047とか2231のような複雑な組み合わせも困る。
もうヘッダもボディもエンコード不要で生utf-8にまでできないものかね。
8BITMIME(と、ついでにSMTPUTF8)を義務づけたい。
Re: (スコア:0)
生UTF-8だとSMTPの1行998文字制限を克服するために結局format=flowedか何かが必要になるので、Base64のほうがいいと思う。
ThunderbirdがISO-2022-JPでBase64を採用しなかったのはRFC 1468に違反するから(RFC 1468を気にしないならそもそもUTF-8でいい)。