パスワードを忘れた？ アカウント作成
Close
48258 submission
インターネット

e-mailで使われるcharsetにISO-2022-JP以外のものを使うのは是か？ 213

タレコミ by sarinaga
sarinaga 曰く、
先日、テキストエディタでメールの本文を書いてから、
それをメーラーに貼り付けて送信したら、相手先から
「一部の文字が?になっているよ」と返信が帰ってきました。

原因はテキストエディタで書いた文字の一部が
ISO-2022-JPに変換されなかったためでした。

e-mailで使われる文字エンコードは歴史的経緯からISO-2022-JPで
あることは有名な話です。しかし、ESMTPが登場したのは1994年7月と
いう昔の話。今のメーラーならメールヘッダの
Content-Typeは正しく理解できるだろうし、
Unicodeの対応も行われているのではないだろうか。

そう思って、メーリングリストで物は試しに送信の時の
文字エンコードをUTF-8で送ったところ、誰もが皆正しく
受信できている。

しかし、現実問題として、私のところに
送られてくるメールのすべてはISO-2022-JPです。

メールにおける文字コード問題は昔はだいぶ
議論されたものですが(Shift_JISで送るな！とか)、
最近は全く聞かれなくなりました。

今もう一度、文字コードの話をしてみてはどうでしょうか。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か More

  • なんのための文字コードの規約・約束事か? (スコア:5, すばらしい洞察)

    by ginga (20279) on 2009年01月18日 23時31分 (#1493740)
    問題をよく考えましょう．
    • 単独で動作するアプリケーションの話ではなく，不特定多数の相手との通信アプリケーション
    • 直接に相手の(文字コードなどの)能力仕様を確認する手順を踏まずに， 仮定(相手が ISO-2022-JP 等を処理できると決めうち)の上でいきなり送りつける (SMTPによる MTA 間のやり取りはEHLO 等で仕様確認して調整する余地があるが， MUA間のやり取りは RFC822,RFC2822,RFC5322 などの仕様で書かれたものを，完全一方通行で送る)
    • (とりあえず 8bit through かどうかはまた別の問題ということで置いておく)

    さてここで，歴史的に考えるとこんな感じになります．

    1. 原始時代: 英語? ローマ字?(私はよく知らない)
    2. pre-MIME時代: メッセージには JIS(≒ISO-2022-JP)を使うという プロトコル外の「共通の了解事項」を設定することにより 「日本語メール」が決められて日本語で送受信が可能に
    3. MIMEの登場: 送る側については，前記の「暗黙の了解」に頼らずに 文字コードを指定する方法が登場．ただし符号化方式と文字セットのごった煮問題とか， 受信側との「文字コード対応能力判定」みたいな機能はないことに注意． (また，従来方法も現在に至るまで若干併存)

    日本語限定でなくいろいろな言語・文字コードが飛び交うようになり 「ISO-2022-JP のみ」が若干時代遅れという印象を持つ人もいるかも知れませんが， 実は「文字コードを何にしないといけないか」はほとんど変わっていないはずです．

    多国語を扱いたいとかの要望も含めてutf-8 等の需要は高まっているかも知れませんが， 実はいまでもかなり多くのシステムが MIME の文字コードにすらきちんと従っていません．

    "charset=iso-2022-jp" と宣言しておきながら，実際には本文を shift_jis で送ってくる MUA

    のなんと多いことか． (これはある意味 「ISO-2022-JP 対応で十分」とは言えない理由ともいえるかもしれませんが) 結局のところ，多くのシステムは MIME 情報も参考にしつつ， 「ISO-2022-JP 決めうち(時々変態からの shift_jis や utf-8 に例外的に対応)」 などということを，今でもしているのではないでしょうか．

    MIME 対応すら正しい実装が完全に普及したとは言えないときに, 特殊な文字セットを使いたいとかの場合以外は，「勝手に」変える理由は何もありません． むしろ実装の種類が星の数ほど増え，ユーザーも極めて多種多様になった現在， 旧来の仕様を廃止して全員が納得する「新しい合意」を作るのは以前より遥かに難しいでしょう． 「utf-8 を使いたい」という人がいても良いですが，それは 「相互に utf-8 を使うということに合意がとれている2者間」ないし 「同様の合意のある特定のコミュニティ内」に 閉じて使われるべき話であろうと考えます．

  • Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは
    最初に検出したエンコードで全体をデコードするため
    subjectのエンコードと異なるcontent-typeでは問題がでるなど、
    MIMEの扱いはぼろぼろです。

    さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。

    メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などで
    エンコード/デコードが必要となります。

    これらについて、現状ではiso-2022-jpであることや、
    メール全体が同じエンコーディングであることを仮定したハックによる
    対応が行われているものが散在し、Content-Typeに従った対応が
    全般に渡ってされていると仮定するのは無理があります。

    • Re:現状のContent-Type対応は十分ではありません (スコア:1, 興味深い)

      by Anonymous Coward on 2009年01月18日 19時25分 (#1493598)

      Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは
      最初に検出したエンコードで全体をデコードするため
      subjectのエンコードと異なるcontent-typeでは問題がでるなど、
      MIMEの扱いはぼろぼろです。

      とは言いますが、そもそもSubjectフィールドとContent-Typeフィールドは、同じ形式でエンコードしておくべきでは？
      更に言えば、Subeject/Content-Typeフィールドに別々のエンコードをしてしまうというのは、 新米Emacsen使いな方々の設定ミスが主な原因と記憶していましたが。

      Emacsを利用していると、各国語のエンコードが入り混ったメールでも良きに図らってくれる為、 単なるリーダとして利用している分には、誰が使おうと構わないのですが。
      Emacsで、いざメールを書くとなると設定のあやしい新米さんの場合、 Subjectやメール本文をエンコードせずに送信したり、あちこち異なった形式でエンコードしたりと、 色々と迷惑をかけるので困りものです。
      Emacsで読んでいる為、読むことには何の支障もないので、自分では気づきにくい、 というか、他人から指摘されるまで気づかないので本当に困ります。

      ＃ 自称ギークな上司が正にこのパターンで、分かってもらうのにとても苦労したAC
      ＃ 何年もやりとりしていた取引先の方が、実は我慢してやりとりしていた事実を知って、本人も流石に凹んでいましたが…

      シェア
      親コメント

    • そもそも、一時期セキュリティまわりでかなり叩かれていたOutlook Expressを使ってる人って割合としてどれくらいなんでしょう。
      企業によっては普通に「Outlook Expressは禁止」なんてところも多いように思えますが。

      --
      神社でC#.NET
      シェア
      親コメント

  • 「送るときは保守的に、受けるときはリベラルに」ということで、私は基本的に iso-2022-jp、text/plain で送っています。でも、もうそろそろ utf-8 でも良い気はしますが。

    --
    HIRATA Yasuyuki

  • 最小の適切な文字コードを選択 (スコア:3, すばらしい洞察)

    by Anonymous Coward on 2009年01月18日 18時47分 (#1493571)
    受信者が処理できる可能性を高くするために、最小の適切な文字コードを選択するべきだと思います。
    MIME には最小の適切な文字コードを charset に指定するという規則があるそう [mew.org]だし、ケータイではまだ UTF-8 に対応していないものも少なくないという現実もあるので。
    日本語だと、US-ASCII/7bit → ISO-2022-JP/7bit → UTF-8/Base64 の順で良いのではないでしょうか。

  • ISO-2022-JPで書けない文字 (スコア:3, 興味深い)

    by tsuya (14020) on 2009年01月18日 21時43分 (#1493685) 日記

    ISO-2022-JPで満足すべきか否かが問題になるのは、ISO-2022-JPで書けない文字が存在するから、に他ならないのですが、何故かその点の議論が少ないですね。ISO-2022-JPで困っている実感がないなら、他の文字コードを使用可能にせよ、という主張は確かに迷惑でしかないでしょうね。

    日本でも、少数ながらISO-2022-JPで表現できない人名や地名が存在し、その多くはUnicodeで表記できます。自分自身がその条件にあてはまる人は（この方 [srad.jp]のように？）、そうでない人よりもメール環境のUnicode対応を強く主張できるのでしょうが、あいにく私はそのような境遇にはありません。

    しかし、そういう人を名簿に載せなければならない人などの事情なども汲むと、Unicodeの需要者はもう少し増えるので、そのような利便を考えるとe-mailも対応すべき、ということで、トピックに対する私の答えは是、ということになります。

    ただし、将来すべてのMTA、MUAが対応したとしても、Unicodeが広く使われるようになる可能性はあまり高くないでしょう。たとえば、"...charset=UTF-8" とヘッダに書きさえすればUTF-8が使えるWebでさえ、「■は王へんに宛」などと、Unicode文字を使ってもらえずに本名もまともに書いてもらえない人が、特に中国系や韓国系の人にたくさんいます（ペ・ヨンジュンみたいにカタカナで統一すれば失礼な書き方をしなくてもいいのに、と思うがこれは余談）。これが、使っているWeb制作システムが未対応だからなのか、個人使用のエディタの問題か、メールで記事を投稿するシステムでMUAがISO-2022-JPしか使えないのか、あるいはIMEでの入力の仕方を知らないのか、Unicode非対応のごくわずかなブラウザに配慮しているのか、理由はよくわかりませんが。

    ですから、対応する甲斐があまりない、とも言えるかもしれません。最適な利便という観点で考えると、ISO-2022-JP非対応文字を使う必要のある人よりも、Unicode非対応なMTAやMUAを使っている情報弱者の方が多いと思われますので、現状が一番よい落としどころなのかもしれません。またUnicodeで表記できない人名も恐らくは存在しているので、Unicodeが完全なソリューションというわけでもないでしょう。

  • 受け取れない奴が悪い (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2009年01月18日 18時34分 (#1493563)
    今時、複数の漢字コードを受け取れないようなメーラーを使う人は少数派、
    どうしても読みたいなら適切なクライアントを用意するはず。
    大体、すべてiso-2022-jpで来ることを期待するなんて設計や思想そのものが間違っている。
    「送る場合は厳密に、受け取る場合は寛容に」なんて送受信を行う上での基本でしょ。

    というのは暴論でしょうか。

    • Re:受け取れない奴が悪い (スコア:5, 興味深い)

      by takl (14577) on 2009年01月18日 19時12分 (#1493587)
      暴論です。

      e-mail の場合、送信者と受信者だけでなく中継者も考えに入れる必要があります。
      昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
      運悪くそのような中継者に当たってしまうと、文字化けします。
      そのような中継者が絶滅したと言い切れないのであれば、
      iso-2022-jp を使うべきです。

      # もう絶滅したよね、と思ってたら2006年に遭遇しました…。
      # いい加減滅ぼしてくれよ。
      シェア
      親コメント

    • Re:受け取れない奴が悪い (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2009年01月18日 19時41分 (#1493612)
      受け取る場合の寛容さって行き過ぎるとセキュリティホールにつながりませんかね？

      例えばcharset="iso-2022-jp"なのにSJISで送ってくるようなメールとか、
      multipartなのにboundaryがない（MIMEのpreambleしかない）メールを
      表示できるような寛容さはスパム対策上好ましくない気がします。

      文字コードとは関係ないですけど、IE等の「寛容な」HTML解釈でinvalidなHTML文書
      が氾濫した状況を見ると、受け取る場合こそ厳密にやるべきなんじゃないかとも思います。
      シェア
      親コメント

    • Re:受け取れない奴が悪い (スコア:1)

      by s02222 (20350) on 2009年01月18日 20時01分 (#1493625)
      受け取れなかったらそれまでのこと。クリティカルな用途でemail投げっぱなしがそもそも悪い、まで含めるなら同意・・・・というか、最近、送ったはずのメールが届かない事例が増えてきてる気がします。

      # タイムアウトしたら再送、それじゃダメなら電話、に落ち着いてるので誰も根本原因を調べようとしない。
      シェア
      親コメント

  • まだまだ無理 (スコア:2, 興味深い)

    by Anonymous Coward on 2009年01月18日 19時10分 (#1493586)

    最近かかわったJavaの仕事で、他人が作ったところでメールの文字化けやらで問題が多発していました。
    で、いろいろ自分もお手伝いとして調査していたんですが・・・

    文字コードに平気で Shift-JIS とか Windows-31J とか指定してましたorz

    メールについて何も知らないような、かつ調べようともしないような素人に作らせるなよ・・・。
    という話はともかく、実際問題として、（Windows-31Jは論外としても）Shift-JISでも化けるようなメーラーやWebメールは残ってるので、受信者側のことを考えると迂闊には切り替えられないと思いますよ。

    あと、中国とのオフシェア開発で、日本語メールだと微妙に化ける人がいたときに、UTF-8でメールしてたことがあります。
    が、これも、日本人の関係者から、～さんからのメールがいつも化けます。ちゃんとした設定で送ってください。とクレームがきたので、そんなメーラー使うなよと思いつつ諦めました。
    そういうトラブルを考えると、まだまだ ISO-2022-JP を使わざる得ないかなと。

    • エンコードがbase64でそうなら、そうするしかないかもですねぇ。
      末端は利便性優先で機能が向上してもいいのにーとは思うんですが。

      中継のことのために7bit/base64でやりとりしてるなら。あとは末端間のネゴシエートの問題ですかね。
      添付ファイルもそうですけど、一度相手と"つかって平気か?"のネゴが必要ですよね。やっぱ。
      逆に調整できてれば複数言語交じりOKとか(UTF-8)、ファイルの変換不要(添付ファイル)とかできるわけですし。

      # OEだけでなく、各種メーラの機能向上ってなかなか進みませんよね...(自戒をこめて)

      メーラとメールヘッダにCapabilityとかあってもいいような気がしてきた。

      --
      M-FalconSky (暑いか寒い)
      シェア
      親コメント

  • 理由はいくつもあるが、一番大きいのは spam mail 対策。
    複数の文字コードを混在させたメールで spam mail を送ってこられると、本文を使った spam mail 判定が恐ろしく難しくなる。

    何もわざわざ spam mail 屋さんに優しい環境にしなくてもいいよな、と言うわけで、現行のままでいいと思う。
    もっとも、会社の中とかは Outlook + Exchange Server なのでリッチテキストが飛び交っていますが。

    --
    fjの教祖様

  • MS-Wordで送ればいいやん (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2009年01月18日 20時21分 (#1493636)

    サブジェクトは暴論でない。ただし、タレコミレベルの話をする場合において。
    タレコミに書いている内容は、一見文字コードの話をしているように見えるが、実際の内容は「読める人がいるから使ってよいのでは?」ですよね。
    それならばMS-Wordで良い。図だって使えるし。(実際はPDFあたりが最適と思う)

    たとえば「メールにおける文字コード問題は昔はだいぶ議論されたものですが(Shift_JISで送るな！とか)、最近は全く聞かれなくなりました。」を理由に持ってくることは間違です。
    いま問題が無いのは、きっちりとコードなどの各種規格を整備した結果であって、ほかの文字コードの無秩序な使用が可能になった結果ではない。

    間違えてほしくないけど、私はメールの表現が豊かになることには反対しないよ。
    ただ、タレコミに書かれているような姿勢でそれを論じるのは明らかに違っているということと、タレコミレベルなら「MS-Wordで送ればいいやん」が回答になると主張するのです。

    あと、日本にはまたとな文字コードとそれを作れる人や組織が無いといってよいほど弱小なのも問題だよね。
    #自戒でもあるが、どの年の規格化とかエンコードはどうで他国の文字との同居はどうすればよいかをちゃんと理解している人は数えられるほどだろうなぁ。自国の言葉なのに...

  • 日本語以外 (スコア:2, 興味深い)

    by uguisu (9285) on 2009年01月18日 23時14分 (#1493732) ホームページ 日記
    日本語以外の話がまったく出ていないので新たに立てます。

    自分は、毎回エンコードを設定するようにしています。日本語＋英語+ロシア語とかのメールを書きたい時があるので。正直うっとおしいので、UTF-8がデフォになってくれたら助かります。

    ウェブページも、エンコード指定していないと、OSの言語設定が日本語以外だといちいちエンコードを指定しないといけないので、ウェブの場合はなんでもいいからエンコードを指定して欲しい。
  • 雑談サイトで話の腰を折るというご法度を承知で書くと、
    ・現状で問題ないものに手をつける必要はない(無駄なリファクタリングみたいな)
    ・誰も儲からないことは誰もやらない
    ・小難しいことを言っても一般ユーザには何のことやら
    という感じで、こんな是非は正直「非だ非！」という視線で見てしまいます。
    Unicodeとかげんなりです。字体の変なまとまり方とか、全角ハイフンとか。

    現状でユーザの満足度が上がりそうな変更は携帯で使っている絵文字が
    正しく表示されるとか、そんなもんではないでしょうか。

    # JustsystemあたりがShurikenとATOKを携帯絵文字対応にしたら
    # 初心者ユーザとかうっかり取り込めるかも知れんなぁ、とか妄想してみる。
    # データがかけちゃったところを補完するの込みで(^^;

  • 確かに私の周囲の環境でも8bit transparentでない
    MTAって見掛けません。あとはクライアント側が
    うまく解釈してくれるかどうかだけかな。

    携帯電話への転送に際しては文字コードを
    しないとだめでしょうけど。

    --
    屍体メモ [windy.cx]
  • MLの過去ログを閲覧するWebインタフェースがある場合、
    前提にしていない文字コードが含まれたメールを表示するときに
    トラブルになりがちですね。

    まあそれも対応しろの一言で済ますんでしょうけど。言い出すときりが無いわけで。

  • 非です。 (スコア:1)

    by gonta (11642) on 2009年01月18日 17時55分 (#1493530) 日記

    知人がmh使っています。
    ＃最近のmhは非iso-2022-jpでも動作するんかな？

    コンピュータに詳しい人とかいう人が、(株)とか丸数字とかをシグネチャに入れるやつがいて困る。

    --
    -- gonta --
    "May Macintosh be with you"

  • Gmailの場合 (スコア:1, 興味深い)

    by Anonymous Coward on 2009年01月18日 17時56分 (#1493531)
    もうメールクライアントを使わなくなって久しいのですが、Gmailでは設定でそれっぽい項目があります。
    自分は"送信メールにデフォルトのテキスト エンコードを使用する"にチェックしてます。たしかこれでISO-2022-JPに変換されてた。
    一方、"送信メールに Unicode (UTF-8) エンコードを使用する"という選択肢もありますが、ヘルプ [google.com]では、受信者側で適切に表示できない場合に使えるよとありますね。
    受け取る側としてはウェブブラウザなのでどっちでもいいよって感じですが、たまに欧米のウェブメールを使うとISO-2022-JPでは文字化けすることがあります。文字コードに疎い欧米のソフトを使うならUTF-8のほうが良いのかも。

  • 後ろ向きかもしれないけど (スコア:1, 興味深い)

    by Anonymous Coward on 2009年01月18日 18時09分 (#1493538)
    「せっかく統一されている物を積極的に乱す理由もないかな？」
    という事でISO-2022-JPを使っていますね。

    特に最先端をいかなきゃならない理由もないですし、皆の後を
    ついていけばいいのかな、と。

    こうやって文章に書くと、「ああ、なんて後ろ向きなんだろう」
    とは思いますけど。

    # 文字コードよりも、Outlookの添付ファイルの分割送信の方を
    # 先になんとかしてほしい。

  • 機種依存文字 (スコア:1)

    by USH (8040) on 2009年01月18日 18時10分 (#1493540) 日記

    最近のメーラは頑張ってくれるので、漢字コード自身はそれほど気になりませんが、
    機種依存文字だけは何とかして欲しい。

    送られてくるデータがメーラで閉じていればいいのですが、
    他のアプリに渡すためにファイル保存した際、機種依存コードが化けてしまう。
    特に「丸１」とかローマ数字とか、使われている文章ではかなりの数、出現してしまう。
    これを手で修正するのは面倒だし、、、、

  • 使っているメールソフトがUnicodeに対応していないのでISO-2022-JPでお願いしたいところですが、
    Unicodeに対応していて、軽くて使いやすいメールソフトがあれば乗り換えても良いと思っています。

    皆さんはどのメールソフトをお使いでしょうか？

    • Sylpheedを使ってます。

      1メール1ファイル形式なので、意味不明な文字化けメールが来ても、
      当該ファイルを直接エディタで開いていろいろ調べられそうです。
      (今のところそのようなメールには遭遇していませんが・・・)
      --
      匠気だけでは商機なく、正気なだけでは勝機なし。
      シェア
      親コメント

  • 先日、テキストエディタでメールの本文を書いてから、それをメーラーに貼り付けて送信したら、相手先から「一部の文字が?になっているよ」と返信が帰ってきました。原因はテキストエディタで書いた文字の一部がISO-2022-JPに変換されなかったためでした。

    ここ，現代でもそのメーラー(MUA)が対応してないという話．

    e-mailで使われる文字エンコードは歴史的経緯からISO-2022-JPであることは有名な話です。しかし、ESMTPが登場したのは1994年7月という昔の話。

    ここで，ESMTPの話が出てくる．ま，ESMTPを実装するMTAの話ですわな．ISO-2022-JPとUTF-8の話をするときにはMUAとMTAの話は切り分けて考えるべきだと思うんだけど．なぜなら身近なところに非対応のMUAがあるので(以下参照)．

    今のメーラーならメールヘッダのContent-Typeは正しく理解できるだろうし、Unicodeの対応も行われているのではないでしょうか。

    やっぱりそうではなかった，ということが最初の段落で分かったわけですね．実際，私の携帯電話のMUAもUTF-8では文字化けします．じゃあ，やっぱりISO-2022-JP使った方がトラブルが小さいわけですね→結論．

    もちろん，MUAの実装者が対応するべきという議論はあり得るし，それはそれで進めなければならない．でもそれを利用者に押しつけることはできない．特に携帯電話のMUAみたいに利用者が選びようのないものにとっては．ということで当面はISO-2022-JPでやりとりすべきだと私は思います．

  • フィルタリング (スコア:1)

    by mshynd (31907) on 2009年01月18日 19時49分 (#1493614)
    ISO-2022-JP以外のメールは、迷惑メールフォルダ行きです。
    まともなMUAでデフォルトがISO-2022-JPじゃないものってありますか？

    • Re:フィルタリング (スコア:2, すばらしい洞察)

      by mr_spock (908) on 2009年01月18日 19時59分 (#1493623)
      え～、それって海外とのメールやりとりは無い前提ですよね？
      シェア
      親コメント

      • Re:フィルタリング (スコア:3, 興味深い)

        by quililila (23086) on 2009年01月19日 0時09分 (#1493757) 日記

        同じ事やってます。ごみ箱どころかそのまま廃棄ですが。
        基本的に海外とのやりとりはないし、もし必要な場合はそのときだけフィルタを殺します。

        とかやってたら、JALの領収書(メールでPDFファイルが送付される)が
        ISO-2022-JPじゃなくて消滅。しかも再発行拒否だし。
        メールで送って再発行拒否はないよなぁ。

        シェア
        親コメント
typodupeerror

アレゲは一日にしてならず -- アレゲ見習い