スラッシュドット・ジャパン

• 単独で動作するアプリケーションの話ではなく，不特定多数の相手との通信アプリケーション
• 直接に相手の(文字コードなどの)能力仕様を確認する手順を踏まずに， 仮定(相手が 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に従った対応が
全般に渡ってされていると仮定するのは無理があります。

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

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

日本でも、少数ながらISO-2022-JPで表現できない人名や地名が存在し、その多くはUnicodeで表記できます。自分自身がその条件にあてはまる人は（この方 [slashdot.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が完全なソリューションというわけでもないでしょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

先日、テキストエディタでメールの本文を書いてから、それをメーラーに貼り付けて送信したら、相手先から「一部の文字が?になっているよ」と返信が帰ってきました。原因はテキストエディタで書いた文字の一部が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でやりとりすべきだと私は思います．

http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=6239 [mozilla.gr.jp]

① ISO-2022-JP とcharset宣言しておきながら、丸に数字、１文字の℡、カッコ付き㈱
② 何故か IANA に無い CP932 ... なのでエラーになったりするのに、これを charset宣言する MUA
③ Web では UTF-8 でみんな Happy なのに、保守的にと主張する古いメーラ

＃ここは Web なので、堂々と使ってみる丸に数字

いっそのこと、メール送受信の新規格を作っちゃえばいいんじゃないでしょうかね？
SPAM問題とかもありますし、既存のものをズルズル引きずることによる弊害も少なくないです。
かといって大幅に規格を変更して後方互換性を切り捨てるようなやり方では誰もついてこないわけで。

新しい規格に魅力があれば自然に移行されていくと思うのですがねー。
（個人的には認証回りがきちんとしてて、SPAMが来なければそれだけで移行の理由になったり。企業レベルでは流石にそう簡単にはいかないでしょうけど。）

ISO-2022-JP-3って結局IANAに登録されていない [iana.org]んですよね。なんでその後の動きは無いんでしょうか? (非難しているわけじゃなくて、単になぜなんだろうという疑問です)

ISO-2022-JP-2(RFC1554 [ietf.org])のように IANAに登録された拡張もあるけれども、 ISO-2022-JP-*って名前であれば万事問題ないという訳でもなく、結局は「対応していないMUAがあるはずだ」ということから移行に踏み切れないし、だったらすでに普及している文字コードを使った方が楽だしISO-2022-JP-3なんて要らない、ということなのでしょうか?

それはそれでいいんですけど、別にISO-2022-JP-*って名前でなくともいいので何らかの拡張された文字コードと共に「これからの日本語でのインターネットメールやニューズはこの文字コードを使うよ」って書いて統一を促してあるRFCは欲しいです。

後で検索できないぢゃん。

いや、メールはすべてpdfに書いたものを添付して送ることにすれば問題解決。

RFC2822 でとっくに 1 行 998 文字以下 (CRLF を除く) が MUST になってますね。78 文字以下 (CRLF を除く) はあくまでも SHOULD。

もっとも、大半の日本語メールは ISO-2022-JP で送る = 70 文字程度で送っているつもりでも 80 バイト 以上になっている場合がある、という罠はありますけどね。

事実上、誰もメンテしてないに等しい状況なんですけどねぇ……。＞cmail
# CVSも無い環境でパッチを投げ合ったのは良き思い出(ぉ