![Mozilla Mozilla](https://srad.jp/static/topics/mozilla_64.png)
すべての言語版のThunderbird、送信メールをUTF-8に変更へ 59
ストーリー by nagazou
多少の混乱はあるかな 部門より
多少の混乱はあるかな 部門より
あるAnonymous Coward 曰く、
Mozilla Thunderbirdはすべての言語版で、送信メールの文字コードをUTF-8へ変更するようだ(Bugzill
Googleグループ)。リリースバージョンへの反映は予定通り進んだ場合、現行バージョンであるThunderbird 78.xの次のThunderbird 88.0 (90.0?)に反映される見込み(Mozilla wiki)。
日本語環境としては、SubjectやFromなどのヘッダーがThunderbird 38.0.1からUTF-8に固定変更され、Thunderbird 52.0で既定の文字エンコーディングがISO-2022-JPからUnicode (UTF-8)へ変更されているため、大きな問題は起こらないと予想される。
受信側としてのThunderbirdでは、不正なISO-2022-JPメールを受信し、Mozilla製品共通のセキュリティ仕様により不要なU+FFFDが表示されるという報告もある。このような不正なISO-2022-JPメールに悩まされることのない日はいつ訪れるのだろうか。
RFC 2277に、UTF-8メールが普及するには50年かかる、実際には永久であると書かれたが、メールのUTF-8化は確実に進んでいる。
RFC2277 (スコア:2)
UTF-8が普及するには50年かかる、と直接は書いてないっぽい。
あらゆる「暫定」の寿命は50年はあるので、実際には永続するものとして(暫定策をしっかり)考えるべき、
みたいなニュアンスに読めた。
Re:RFC2277 (スコア:2)
「99年」は永遠レベルの長期、「50年」は終わりが見えないレベルの長期、くらいの感覚なんかねえ。
# 香港。。。
Re: (スコア:0)
ということは、Wikipediaの記述も微妙?
https://ja.wikipedia.org/wiki/%E9%9B%BB%E5%AD%90%E3%83%A1%E3%83%BC%E3%... [wikipedia.org]
Re: (スコア:0)
> however, the timeframe of "interim" may be at least 50 years, so
> there is every reason to think of it as permanent in practice.
それは「ニュアンス」なのか?
Re: (スコア:0)
この50 yearsはローコンテキストの言語における具体例を置かなきゃ面倒くさいときのプレースホルダだから、日本の人間五十年を大体、人の一生の意味で使うのと同じニュアンスでしょ?
Re: (スコア:0)
”50years"って書いてあるのを「50年」って理解する
これを「ニュアンス」って称するのは止めといたほうがいいな
議論の仕方はその次だ
Re:RFC2277 (スコア:1)
「人間五十年」は人間の寿命が五十年って意味じゃないですからね
Re: (スコア:0)
ちゃんとニュアンスの意味わかってんじゃん
Re:RFC2277 (スコア:1)
ブルーマウンテンのコーヒーの話題にヌワラエリアの紅茶で割り込んだとき
洒落が下手で準備不足だと叱咤されたことを思い出す。
// 「にんげんいたるところあおやまあり」は間違った読みだと云々
ビット落ち (スコア:1)
もともと伝送経路で8bit目が落ちるのでISO-2022やUTF-7が使われていたんじゃなかったっけ?
今はもう大丈夫なの?
Re:ビット落ち (スコア:1)
MIMEエンコーディング(日本語版では Base64 が主流)するから問題ない。
ただなぁ、ISO-2022-JP だと生メール見れば 1byte 文字はそのまま読めるので
MUA なくてもコードや英文の引用なんかはアタリを付けることができたけど、
Base64 でエンコードされたらデコードしないと本文は全く分からなくなるからな。
Re:ビット落ち (スコア:1)
伝送経路というよりはSMTPの規格ですね。
ESMTPで8BITMIME対応ならボディパートは8bitで送信してOK。
(ヘッダパートはUS-ASCII固定なのでMIMEエンコード必須)
Re: (スコア:0)
MIMEエンコードされていないヘッダーはUTF-8として処理する、というのは受信したMUAだけで、送信はダメなんだっけ?
Re:ビット落ち (スコア:2)
https://tools.ietf.org/html/rfc5321 [ietf.org]
> 2.3.1. Mail Objects
...
> Although SMTP extensions (such as
> "8BITMIME", RFC 1652 [22]) may relax this restriction for the content
> body, the content header fields are always encoded using the US-ASCII
> repertoire.
なんで、ダメなんではないかと。
Re: (スコア:0)
MIMEエンコードされていないヘッダーはUTF-8として処理するMUAなんてある? 何か勘違いしてそう
本文のエンコード方式を指定するヘッダのエンコード方式はUS-ASCII決め打ちにしておかないと不都合でしょ
// 本文のエンコード方式を指定するヘッダのエンコード方式を指定するメタヘッダのエンコード方式の……
Re: (スコア:0)
MIMEエンコードされていないヘッダーはUTF-8として処理するMUAなんてある?
既存のメールを.emlファイルとして保存し、Subject:などを生のUTF-8に書き換え、Thunderbirdで開いてみてください。文字化けしないと思います。この仕様変更は、Thunderbird 38からで、RFC 5335によるものだそうです。
Re: (スコア:0)
確かに文字化けしない。RFC 5335 [ietf.org]を読む限り、本来は Content-Type: message/global を指定した場合にUTF-8を含むものとして処理する意図のようだけど、Thunderbirdはmessage/rfc822やtext/plainでも気を利かせてくれるということか
Re: (スコア:0)
ESMTPの「UTF8SMTP」に対応してるならオッケー
受信についてはRFC 5335
送信についてはRFC 5336
Re: (スコア:0)
どっかでそういうメールサーバーの情報を集めて晒すとかやってくんないかな
実在してるかどうか怪しいもんだし、してても実際問題として誰かなんか困るのか?って思うよ
Re: (スコア:0)
あれだ。携帯電話を使うとペースメーカーが誤作動するんで、優先座席付近では電源を切りましょう、ってアナウンスだ。
Re: (スコア:0)
UTF-8のメールは(本文でも)Base64でエンコードされるから問題ない。
昔々、まだInternet Mail and Newsと呼ばれていた頃のOutlook ExpressがBase64エンコードされたUTF-8のメールを送って「読めるわけねーだろこんなもん!」とキレられていたものだが、時代は変わったものだ。
Re: (スコア:0)
UTF-8のメールが勝手にBase64エンコードされるわけではないよ。
明示的にUTF-8/Base64指定しない場合はUTF-8/8bitで送信されるはず。
日本ではエンコーディング指定をしてないPHPMaillerのサンプルコードが出回っているせいでUTF-8/8bitで一斉送信されるメールが案外多い。
Re: (スコア:0)
> Internet Mail and News
本文に
end
と書いておくと誤作動起こすやつだっけ。
fjで一時はやった。
Re: (スコア:0)
「まだ7ビットのサーバが生き残ってたのか」な話題が過去のスラドに出ていた気がするが、それが10年以上前か否か、よく思い出せない。
Re:ビット落ち (スコア:1)
日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か [it.srad.jp]が2009年1月
Subject: Re:8bit transparentでないMTAってどれくらいあるのかな [srad.jp]で
> 確かに私の周囲の環境でも8bit transparentでない
> MTAって見掛けません。あとはクライアント側が
> うまく解釈してくれるかどうかだけかな。
って話題が出ています。
ISO-2022-JPメールはロストテクノロジー (スコア:1)
自分が受信するメールでは、Subjectの改行部分に「�」が現れたり、「08月�分」のように本文の文字連結部分っぽいところに「�」が現れるパターンがある。
ISO-2022-JPメールを正しく扱うことは難しい時代になったんじゃないかな。
Re: (スコア:0)
s-nailという、コマンドラインでメール送受信ができる(SSL対応)アプリがあるが、既にUTF-8決め打ち。
ISO-2022-JPで送信しようとあれこれ試したが、結局諦めてしまった。
といってもSylpheedはまだ移行する予定なし。
ガラケー死亡 (スコア:0)
送ってこられても文字化けでなに書いてあるかもう読めないね。
iso-2022-jp決め打ちだからね。しょうがないね。
まあ今時ガラケー使ってるような人はアレな人だから、UTF-8なメール以前にどうせメール相手自体が居ないのだろうけどw
ガラケーはUTF-8対応ですよ (スコア:3, 興味深い)
正確には、「ガラケーのゲートウェイはUTF-8対応」ですけどね。
3キャリアとも、ガラケーのメールはゲートウェイでエンコードやメールヘッダー等が改竄されます。
その際に文字コードも、書き換えられますのでUTF-8でも無問題です。
「iso-2022-jp決め打ち」も意味不明で、ガラケー内部ではShift_JIS(に近いコード)使っている端末もあってそういう端末に対してはShift_JISに変換されますよ。
メールヘッダー等も表示に必要な最低限の物以外は削除されますので、途中の Received: のIPアドレスとか X-なんとかとかそういうヘッダーも削除されて、送信元のIPアドレス等の特定もガラケー本体からは不可能になってます。
いい加減なしったかぶりしないでくださいね。
Re: (スコア:0)
あ、一応書いとくと、Shift_JIS等で表現できない文字は削除されたり〓みたいな文字に変換されますので、UTF-8で表現できる全ての文字が使えるという事ではないです。
Re: (スコア:0)
そもそも数年以内には3Gを使ったガラケーは使えなくなるんだからいいんでないのかなと。
Re: (スコア:0)
UTF-8対応してないガラケーて何年前の機種?
いつまでのが対応してないのか興味あるんだけど
ちゃんとBOM (スコア:0)
付けとけよ
Re:ちゃんとBOM (スコア:2)
charsetが明示されてるならいらない。
Re: (スコア:0)
作りの悪いアプリを炙り出すためにもBOM付けは必要
Re: (スコア:0)
BOMがないとおかしくなるアプリこそ作りが悪い
Re: (スコア:0)
PHPのことですね。
Re: (スコア:0)
よし、PHPは使用禁止な
Re: (スコア:0)
正規化しろって話なら正規化するアプリのほうが圧倒的少数だったりしないかね?
macが無駄にバイト数増える正規化掛けて従来型文字コードと1:1対応できないクソファイル名を吐きまくるって例くらいじゃね?普段見るのって。
そもそもUTF-8でBOM付けること自体が本来のUTF-8ではおかしい処理だし。
Re: (スコア:0)
UTF-8の正規化なんてアプリが面倒みるわけなかろう。
string型(の中身)か、ファイル/ストリームのエンコーダ/デコーダが勝手にやること。
C でベタに書くのでもなければ、正規化されないライブラリ使うほうが面倒くさい。
macのファイル名は UTF8-MACとも呼ぶべき特殊なフォーマット
日本語に関してはNFDだが、ほとんどの欧米言語ではNFCで、一部NFDという混在正規化
方針も決めない、結果も確認しないまま各国のローカライズスタッフが勝手に実装したのをマージしただけなんだろうな。
Re: (スコア:0)
大間違いだ。
Macのファイル名の正規化は「互換領域の文字はそのまま、それ以外をNFD」。
通常のNFC/NFDでは互換文字は字形が変わるにも関わらず正規化の対象になってしまっているからこうなってる。有名なのは示偏の神が神に化けるとか。
NFCではなくNFDなのは、NFCは新しい字の追加で等価な短い形式ができるかもしれないのに対してNFDの方が将来に渡って安定とされていたから。
(今は字形は互換文字ではなくIVSで指定できるから過去の遺物ではある)
Webメール (スコア:0)
複数端末で利用しているので、某プロバイダのWebメールを使用中。
UTF-8のメールは今のところフィルタを突破してるのでは1/10程度。
でプロバイダのフィルタを突破できないのは、ほぼいわゆるHTMLメール(添付形式でないもの)。
どちらも使用しているWebメールではまともに見れないのだけど、
これを機にそろそろUTF-8くらいは対応して欲しいなぁ。
#HTMLメールは読んで欲しかったら添付形式にしやがれ!
某ML (スコア:0)
普通のMUAはともかく、とあるメーリングリストのプログラムが
駄目なんだよね。化けちゃって。
名前は忘れたけどPython2.7で書いてあるらしい。バージョンアップ
はもう止まっているのかもしれん。
Re:真当な対応ですな (スコア:1)
それ以前に極東の某一国で、どの程度Thunderbirdが使われてるかって話よ
Re: (スコア:0)
2015年のデータでは言語別シェアで3位
https://blog.thunderbird.net/2015/12/thunderbird-active-daily-inquirie... [thunderbird.net]
https://rockridge.hatenablog.com/entry/2015/03/01/220322 [hatenablog.com]
Re: (スコア:0)
大量のメールを処理・分類するので、Outlookではほぼ不可能。
まぁthunderbirdも頻繁に要約ファイルが破損して落ちたり、フォルダファイルが破損してメール大量喪失するので戦々恐々だけど…
Re: (スコア:0)
同じ悩みを抱えていた上司はShurikenに落ち着いたらしい。
俺はSylpheedで困ってないが
Re: (スコア:0)
シンプルで機能的なインターフェイスでShurikenすごく気になってる、もう10年以上w
ただ有料なので毎回候補から外れてしまう・・・
Re: (スコア:0)
1行目の「すべての言語版」すら読まずに攻撃的なコメントですか。
お盆休みだというのに嫌なことでもあったの?
Re: (スコア:0)
たしかにメニューが中国語になって久しい(違
メニューのフォントはどこで変えるんだよ。
教えてください。