パスワードを忘れた? アカウント作成
14266604 story
Mozilla

すべての言語版の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化は確実に進んでいる。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by jzkey (47353) on 2020年08月14日 17時14分 (#3870324)

    UTF-8が普及するには50年かかる、と直接は書いてないっぽい。
    あらゆる「暫定」の寿命は50年はあるので、実際には永続するものとして(暫定策をしっかり)考えるべき、
    みたいなニュアンスに読めた。

    • by hjmhjm (39921) on 2020年08月15日 15時28分 (#3870828)

      「99年」は永遠レベルの長期、「50年」は終わりが見えないレベルの長期、くらいの感覚なんかねえ。

      # 香港。。。

      親コメント
    • by Anonymous Coward

      ということは、Wikipediaの記述も微妙?
      https://ja.wikipedia.org/wiki/%E9%9B%BB%E5%AD%90%E3%83%A1%E3%83%BC%E3%... [wikipedia.org]

    • by Anonymous Coward

      > however, the timeframe of "interim" may be at least 50 years, so
      > there is every reason to think of it as permanent in practice.

      それは「ニュアンス」なのか?

      • by Anonymous Coward

        この50 yearsはローコンテキストの言語における具体例を置かなきゃ面倒くさいときのプレースホルダだから、日本の人間五十年を大体、人の一生の意味で使うのと同じニュアンスでしょ?

        • by Anonymous Coward

          ”50years"って書いてあるのを「50年」って理解する
          これを「ニュアンス」って称するのは止めといたほうがいいな
          議論の仕方はその次だ

  • by Anonymous Coward on 2020年08月14日 17時22分 (#3870337)

    もともと伝送経路で8bit目が落ちるのでISO-2022やUTF-7が使われていたんじゃなかったっけ?
    今はもう大丈夫なの?

    • by Anonymous Coward on 2020年08月14日 17時29分 (#3870354)

      MIMEエンコーディング(日本語版では Base64 が主流)するから問題ない。

      ただなぁ、ISO-2022-JP だと生メール見れば 1byte 文字はそのまま読めるので
      MUA なくてもコードや英文の引用なんかはアタリを付けることができたけど、
      Base64 でエンコードされたらデコードしないと本文は全く分からなくなるからな。

      親コメント
    • by iwa (2980) on 2020年08月14日 18時42分 (#3870436)

      伝送経路というよりはSMTPの規格ですね。
      ESMTPで8BITMIME対応ならボディパートは8bitで送信してOK。
      (ヘッダパートはUS-ASCII固定なのでMIMEエンコード必須)

      親コメント
      • by Anonymous Coward

        MIMEエンコードされていないヘッダーはUTF-8として処理する、というのは受信したMUAだけで、送信はダメなんだっけ?

        • by iwa (2980) on 2020年08月14日 19時17分 (#3870451)

          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.

          なんで、ダメなんではないかと。

          親コメント
        • by Anonymous Coward

          MIMEエンコードされていないヘッダーはUTF-8として処理するMUAなんてある? 何か勘違いしてそう
          本文のエンコード方式を指定するヘッダのエンコード方式はUS-ASCII決め打ちにしておかないと不都合でしょ
          // 本文のエンコード方式を指定するヘッダのエンコード方式を指定するメタヘッダのエンコード方式の……

          • by Anonymous Coward

            MIMEエンコードされていないヘッダーはUTF-8として処理するMUAなんてある?

            既存のメールを.emlファイルとして保存し、Subject:などを生のUTF-8に書き換え、Thunderbirdで開いてみてください。文字化けしないと思います。この仕様変更は、Thunderbird 38からで、RFC 5335によるものだそうです。

            • by Anonymous Coward

              確かに文字化けしない。RFC 5335 [ietf.org]を読む限り、本来は Content-Type: message/global を指定した場合にUTF-8を含むものとして処理する意図のようだけど、Thunderbirdはmessage/rfc822やtext/plainでも気を利かせてくれるということか

        • by Anonymous Coward

          ESMTPの「UTF8SMTP」に対応してるならオッケー
          受信についてはRFC 5335
          送信についてはRFC 5336

    • by Anonymous Coward

      どっかでそういうメールサーバーの情報を集めて晒すとかやってくんないかな
      実在してるかどうか怪しいもんだし、してても実際問題として誰かなんか困るのか?って思うよ

      • by Anonymous Coward

        あれだ。携帯電話を使うとペースメーカーが誤作動するんで、優先座席付近では電源を切りましょう、ってアナウンスだ。

    • by Anonymous Coward

      UTF-8のメールは(本文でも)Base64でエンコードされるから問題ない。

      昔々、まだInternet Mail and Newsと呼ばれていた頃のOutlook ExpressがBase64エンコードされたUTF-8のメールを送って「読めるわけねーだろこんなもん!」とキレられていたものだが、時代は変わったものだ。

      • by Anonymous Coward

        UTF-8のメールが勝手にBase64エンコードされるわけではないよ。
        明示的にUTF-8/Base64指定しない場合はUTF-8/8bitで送信されるはず。
        日本ではエンコーディング指定をしてないPHPMaillerのサンプルコードが出回っているせいでUTF-8/8bitで一斉送信されるメールが案外多い。

      • by Anonymous Coward

        > Internet Mail and News

        本文に

        end

        と書いておくと誤作動起こすやつだっけ。
        fjで一時はやった。

    • by Anonymous Coward

      「まだ7ビットのサーバが生き残ってたのか」な話題が過去のスラドに出ていた気がするが、それが10年以上前か否か、よく思い出せない。

  • by Anonymous Coward on 2020年08月14日 17時52分 (#3870383)

    自分が受信するメールでは、Subjectの改行部分に「�」が現れたり、「08月�分」のように本文の文字連結部分っぽいところに「�」が現れるパターンがある。
    ISO-2022-JPメールを正しく扱うことは難しい時代になったんじゃないかな。

    • by Anonymous Coward

      s-nailという、コマンドラインでメール送受信ができる(SSL対応)アプリがあるが、既にUTF-8決め打ち。
      ISO-2022-JPで送信しようとあれこれ試したが、結局諦めてしまった。
      といってもSylpheedはまだ移行する予定なし。

  • by Anonymous Coward on 2020年08月14日 17時13分 (#3870323)

    送ってこられても文字化けでなに書いてあるかもう読めないね。
    iso-2022-jp決め打ちだからね。しょうがないね。
    まあ今時ガラケー使ってるような人はアレな人だから、UTF-8なメール以前にどうせメール相手自体が居ないのだろうけどw

    • by Anonymous Coward on 2020年08月14日 18時36分 (#3870427)

      正確には、「ガラケーのゲートウェイはUTF-8対応」ですけどね。

      3キャリアとも、ガラケーのメールはゲートウェイでエンコードやメールヘッダー等が改竄されます。
      その際に文字コードも、書き換えられますのでUTF-8でも無問題です。
      「iso-2022-jp決め打ち」も意味不明で、ガラケー内部ではShift_JIS(に近いコード)使っている端末もあってそういう端末に対してはShift_JISに変換されますよ。

      メールヘッダー等も表示に必要な最低限の物以外は削除されますので、途中の Received: のIPアドレスとか X-なんとかとかそういうヘッダーも削除されて、送信元のIPアドレス等の特定もガラケー本体からは不可能になってます。

      いい加減なしったかぶりしないでくださいね。

      親コメント
      • by Anonymous Coward

        あ、一応書いとくと、Shift_JIS等で表現できない文字は削除されたり〓みたいな文字に変換されますので、UTF-8で表現できる全ての文字が使えるという事ではないです。

    • by Anonymous Coward

      そもそも数年以内には3Gを使ったガラケーは使えなくなるんだからいいんでないのかなと。

    • by Anonymous Coward

      UTF-8対応してないガラケーて何年前の機種?
      いつまでのが対応してないのか興味あるんだけど

  • by Anonymous Coward on 2020年08月14日 17時40分 (#3870372)

    付けとけよ

    • by iwa (2980) on 2020年08月14日 18時31分 (#3870418)

      charsetが明示されてるならいらない。

      親コメント
      • by Anonymous Coward

        作りの悪いアプリを炙り出すためにもBOM付けは必要

        • by Anonymous Coward

          BOMがないとおかしくなるアプリこそ作りが悪い

        • by Anonymous Coward

          正規化しろって話なら正規化するアプリのほうが圧倒的少数だったりしないかね?
          macが無駄にバイト数増える正規化掛けて従来型文字コードと1:1対応できないクソファイル名を吐きまくるって例くらいじゃね?普段見るのって。

          そもそもUTF-8でBOM付けること自体が本来のUTF-8ではおかしい処理だし。

          • by Anonymous Coward

            UTF-8の正規化なんてアプリが面倒みるわけなかろう。
            string型(の中身)か、ファイル/ストリームのエンコーダ/デコーダが勝手にやること。
            C でベタに書くのでもなければ、正規化されないライブラリ使うほうが面倒くさい。

            macのファイル名は UTF8-MACとも呼ぶべき特殊なフォーマット
            日本語に関してはNFDだが、ほとんどの欧米言語ではNFCで、一部NFDという混在正規化
            方針も決めない、結果も確認しないまま各国のローカライズスタッフが勝手に実装したのをマージしただけなんだろうな。

            • by Anonymous Coward

              大間違いだ。
              Macのファイル名の正規化は「互換領域の文字はそのまま、それ以外をNFD」。
              通常のNFC/NFDでは互換文字は字形が変わるにも関わらず正規化の対象になってしまっているからこうなってる。有名なのは示偏の神が神に化けるとか。
              NFCではなくNFDなのは、NFCは新しい字の追加で等価な短い形式ができるかもしれないのに対してNFDの方が将来に渡って安定とされていたから。
              (今は字形は互換文字ではなくIVSで指定できるから過去の遺物ではある)

  • by Anonymous Coward on 2020年08月14日 20時16分 (#3870491)

    複数端末で利用しているので、某プロバイダのWebメールを使用中。
    UTF-8のメールは今のところフィルタを突破してるのでは1/10程度。
    でプロバイダのフィルタを突破できないのは、ほぼいわゆるHTMLメール(添付形式でないもの)。
    どちらも使用しているWebメールではまともに見れないのだけど、
    これを機にそろそろUTF-8くらいは対応して欲しいなぁ。
    #HTMLメールは読んで欲しかったら添付形式にしやがれ!

  • by Anonymous Coward on 2020年08月15日 12時58分 (#3870770)

    普通のMUAはともかく、とあるメーリングリストのプログラムが
    駄目なんだよね。化けちゃって。
    名前は忘れたけどPython2.7で書いてあるらしい。バージョンアップ
    はもう止まっているのかもしれん。

typodupeerror

コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell

読み込み中...