Up 「メールの文字化け」のロジック 作成: 2007-12-17
更新: 2011-10-20

「文字化け」のロジック

    　文字化けの意味

    メールを含め，インターネット上のデータの送受信では，つぎのことが起こっている：

    1. カラダの分解 (送信側)
    2. ネットを流れる
    3. カラダの復元 (受信側)

    送信側のメールソフトは，「カラダ復元」のための情報をメール本文につけ加える。
    受信側はこの情報をもとに，「カラダ復元」の処理をする。

    カラダの復元は，失敗することがある。
    また，カラダの復元には成功しても，それを開いて読む段階で失敗することがある。
    「文字化け」は，このようなときの現象である。


    「カラダ復元」情報の実際と，「添付ファイル」の実体

    メールに「Shift-JIS コードの htmlファイル」を添付した場合を考える。

    送信側メールソフトがつくる「カラダ復元」情報は，つぎのようになる。
    （メールソフトで, message source を表示させると，これが見られる。)

    1. 異なるパート（本文と添付ファイル) で成ることを宣言：
      Content-Type: multipart/mixed; boundary="------------090506090400090804050201"
      ここで「boundary="------------090506090400090804050201"」は，つぎの意味：
        「各パートの区切りに，つぎの文字列を用いる：
        　 "------------090506090400090804050201" 」

    2. つぎのメッセージの後から，本文のパートが始まる：
      This is a multi-part message in MIME format.
    3. 本文パートの最初で，本文の文字コードが ISO-2022-JP であることを宣言
      --------------090506090400090804050201 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit
    　註 : メールソフトは，本文の文字コードを判別しない。 メールソフトの設定でユーザが文字コードを ISO-2022-JP に設定しているので，メールソフトはその情報をここに書いているだけ。

    4. 添付ファイルパートの最初で，添付ファイルのファイルタイプと，エンコード形式を宣言
      --------------090506090400090804050201 Content-Type: text/html; name="index.html" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="index.html" (html 文書でエンコード形式が base64，と宣言している。)

    　註 : メールソフトは文書のタイプを判別するものではない。 文書のタイプは，ファイルの拡張子「.html」だけから判断している。
    また，メールソフトは文字コードを判別するものではない。添付の html ファイルの文字コードは Shift-JIS であるが，上の記述の中に「文字コードは Shift-JIS」と言っている箇所が無いことに注意。

    この宣言の後に，「添付ファイル」の実体であるところのエンコードされた文字列が，メールソフトによって書かれる。
      PGJvZHkgYmdjb2xvcj0iI2ZmZmZmZiI+Cgo8dGFibGUgd2 IGFsaWduPWxlZnQgdmFsaWduPXRvcCB3aWR0aD0iMTUlIj Z249Y2VudGVyIHdpZHRoPSI3MCUiPjxmb250IHNpemU9Ii gsmK1oLtgumVto6aibuCrzwvZm9udD48L3RkPgo8dGQgYW ‥‥‥‥
    　註 : 文書は，ビットの列。 メールのエンコードは，このビットの列を，アルファベットの文字列に変換する。 「base64」は，この変換方式の一つ。

    5. 添付ファイルが複数のときは，添付ファイルのそれぞれについて 4 と同様のパートが作成される。

    6. 最後に，boundary 文字列を書き，そしてその後ろに「--」をつけて，「これ以上はパートがない (メールはここで終わり)」を示す。
      --------------090506090400090804050201--


    　受信側で文字化けが起こる原因/理由

    1. ネットを流れている途中で，データが損なわれた。

      今日，これは考えなくてよい。 (ビット落ちの問題は，今日では解決されているとしてよい。)

    2. 本文が化けていれば，

      メールViewer (POPメールならメールソフト，Webメールなら Webブラウザ) の判別した文字コードが，ISO-2022-JPではない。（Viewer が文字コードの判別に失敗。）
      この場合は，Viewer の表示メニューから「文字コード」を選択して，ISO-2022-JP を設定すれば，文字化けが直る。


    3. 本文は化けないが，添付ファイルが化ける場合，

      対応に必要となる基礎知識：
      1. 添付ファイル文書は，送信側のメールソフトで，アルファベット文字列にエンコードされている。エンコード方式は base64。
      受信側メールソフトは，これをそっくり受信する。

        message source を表示させて，どんなふうに受信されているかを見てみよう。
        本文に続いてアルファベットの塊があるが，これが復元される前の文書。
      　
      2. メールソフトは，ユーザから「文書復元」のリクエストがきたときに，「base64 でアルファベット文字列をデコードする」という形で文書を復元する。
      ユーザからの「文書復元」のリクエストは，ユーザが添付ファイルを開こうとしたときに発生する。

      ユーザが添付ファイルを開こうとすると，メールソフトはつぎの選択肢を聞いてくる：

        (1) デフォルト・アプリケーションで開く
        (2) ファイルとして保存する

      (1) を選択したとき，文書ファイルが cache フォルダの中に復元されて，これがデフォルト・アプリケーションで開かれる。
      (メールソフトでは，「このタイプの文書はこのアプリケーションで開く」というデフォルト・アプリケーションが設定されている。)

      (2) を選択したとき，保存先として指定した場所に文書ファイルが復元される。


      「添付ファイルが化ける」には，つぎの２通りがある：

      1. 復元そのものが失敗している。
      2. 復元は成功しているが，文書を開いて読むのに失敗している。


      A. 復元そのものに失敗していると見込まれる場合は，
      　メールソフトを定評のあるものに変更する。

        POPメールならメールソフトを Thunderbird にする， Webメールなら Webブラウザを Firefox にする，とか。
        但し，ソフトの「環境設定」で，文字コードの設定を適切に行うことが必要。


      B.「復元は成功しているが，文書を開いて読むのに失敗する」には，
      　つぎの２通りがある：

      1. 文書を開くアプリケーションに問題がある。

          その文書を開けるアプリケーションではない。

      2. 文書を開いて読めるアプリケーションで開いているが，アプリケーションが当て込んでいる文字コードが文書の文字コードと違っている。（アプリケーションが文字コードの判別に失敗。）

          添付ファイルが html のときは Webブラウザでこれを開いて読むことになる。 Webブラウザは，文字コードを当て込む。 これが外れると，文字化けになる。
          ──このときは，Webブラウザに文字コードを直接教えてやる。 （「View」メニューの「Character Encoding」で指定）


    　　註1 : メールサーバは，文字コードの処理をしていない。 したがって，文字化けの原因から外してよい。
    　　　2 : ウェブメール──例えば，サイボーズ──での文字化けについては，つぎの２つのそれぞれを疑うことになる：
    1. サイボーズが行う文書復元
    2. ウェブブラウザが行う文字コード判別