日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か 213
ストーリー by hayakawa
sarinaga 曰く、
先日、テキストエディタでメールの本文を書いてから、それをメーラーに貼り付けて送信したら、相手先から「一部の文字が?になっているよ」と返信が帰ってきました。原因はテキストエディタで書いた文字の一部がISO-2022-JPに変換されなかったためでした。
e-mailで使われる文字エンコードは歴史的経緯からISO-2022-JPであることは有名な話です。しかし、ESMTPが登場したのは1994年7月という昔の話。今のメーラーならメールヘッダのContent-Typeは正しく理解できるだろうし、Unicodeの対応も行われているのではないでしょうか。そう思って、メーリングリストに送信する時、文字エンコードをUTF-8で送ったところ、誰もが皆正しく受信できていました。しかし、現実問題として、私のところに送られてくるメールのすべてはISO-2022-JPです。メールにおける文字コード問題は昔はだいぶ議論されたものですが(Shift_JISで送るな！とか)、最近は全く聞かれなくなりました。
今もう一度、文字コードの話をしてみてはどうでしょうか。
なんのための文字コードの規約・約束事か? (スコア:5, すばらしい洞察)
さてここで，歴史的に考えるとこんな感じになります．
日本語限定でなくいろいろな言語・文字コードが飛び交うようになり 「ISO-2022-JP のみ」が若干時代遅れという印象を持つ人もいるかも知れませんが， 実は「文字コードを何にしないといけないか」はほとんど変わっていないはずです．
多国語を扱いたいとかの要望も含めてutf-8 等の需要は高まっているかも知れませんが， 実はいまでもかなり多くのシステムが MIME の文字コードにすらきちんと従っていません．
のなんと多いことか． (これはある意味 「ISO-2022-JP 対応で十分」とは言えない理由ともいえるかもしれませんが) 結局のところ，多くのシステムは MIME 情報も参考にしつつ， 「ISO-2022-JP 決めうち(時々変態からの shift_jis や utf-8 に例外的に対応)」 などということを，今でもしているのではないでしょうか．
MIME 対応すら正しい実装が完全に普及したとは言えないときに, 特殊な文字セットを使いたいとかの場合以外は，「勝手に」変える理由は何もありません． むしろ実装の種類が星の数ほど増え，ユーザーも極めて多種多様になった現在， 旧来の仕様を廃止して全員が納得する「新しい合意」を作るのは以前より遥かに難しいでしょう． 「utf-8 を使いたい」という人がいても良いですが，それは 「相互に utf-8 を使うということに合意がとれている2者間」ないし 「同様の合意のある特定のコミュニティ内」に 閉じて使われるべき話であろうと考えます．
現状のContent-Type対応は十分ではありません (スコア:4, 参考になる)
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは
最初に検出したエンコードで全体をデコードするため
subjectのエンコードと異なるcontent-typeでは問題がでるなど、
MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などで
エンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、
メール全体が同じエンコーディングであることを仮定したハックによる
対応が行われているものが散在し、Content-Typeに従った対応が
全般に渡ってされていると仮定するのは無理があります。
Re:現状のContent-Type対応は十分ではありません (スコア:1, 興味深い)
とは言いますが、そもそもSubjectフィールドとContent-Typeフィールドは、同じ形式でエンコードしておくべきでは？
更に言えば、Subeject/Content-Typeフィールドに別々のエンコードをしてしまうというのは、 新米Emacsen使いな方々の設定ミスが主な原因と記憶していましたが。
Emacsを利用していると、各国語のエンコードが入り混ったメールでも良きに図らってくれる為、 単なるリーダとして利用している分には、誰が使おうと構わないのですが。
Emacsで、いざメールを書くとなると設定のあやしい新米さんの場合、 Subjectやメール本文をエンコードせずに送信したり、あちこち異なった形式でエンコードしたりと、 色々と迷惑をかけるので困りものです。
Emacsで読んでいる為、読むことには何の支障もないので、自分では気づきにくい、 というか、他人から指摘されるまで気づかないので本当に困ります。
＃ 自称ギークな上司が正にこのパターンで、分かってもらうのにとても苦労したAC
＃ 何年もやりとりしていた取引先の方が、実は我慢してやりとりしていた事実を知って、本人も流石に凹んでいましたが…
Re:現状のContent-Type対応は十分ではありません (スコア:1)
そもそも、一時期セキュリティまわりでかなり叩かれていたOutlook Expressを使ってる人って割合としてどれくらいなんでしょう。
企業によっては普通に「Outlook Expressは禁止」なんてところも多いように思えますが。
神社でC#.NET
Re:現状のContent-Type対応は十分ではありません (スコア:4, 参考になる)
Re:現状のContent-Type対応は十分ではありません (スコア:2, 参考になる)
Windows 7 に Windows Mail は付属しませんが、既に置き換え目的の Windows Live Mail はリリース版が配布されています。
# どっちにしろ Outlook 2007 と Sylpheed の共用なので使ってませんが。
Re:現状のContent-Type対応は十分ではありません (スコア:2, 参考になる)
解決方法もありますよ、ということで。
一応ご案内。
mew-fake-cdp-sending.el [meadowy.org]
Re:現状のContent-Type対応は十分ではありません (スコア:2, 興味深い)
あ、そんないいものがあるのか、と思いましたが
mew-1.95betaでは不要
と書いてありますね。マージしたけど今はやっぱりなくなったとかですかね。
4.2使ってますが、日本語のファイル名のファイルを添付するときはDを押して拡張子を削除したDescriptionを追加してます。
Re:現状のContent-Type対応は十分ではありません (スコア:2, 参考になる)
というのが、まさにOutlookなのが問題なのですよ。
……で、しかも、相手が同様の対応をすることを期待するから：
……ということになるわけで。はあ。
送るときは保守的に、受けるときはリベラルに (スコア:3, 参考になる)
「送るときは保守的に、受けるときはリベラルに」ということで、私は基本的に iso-2022-jp、text/plain で送っています。でも、もうそろそろ utf-8 でも良い気はしますが。
HIRATA Yasuyuki
最小の適切な文字コードを選択 (スコア:3, すばらしい洞察)
MIME には最小の適切な文字コードを charset に指定するという規則があるそう [mew.org]だし、ケータイではまだ UTF-8 に対応していないものも少なくないという現実もあるので。
日本語だと、US-ASCII/7bit → ISO-2022-JP/7bit → UTF-8/Base64 の順で良いのではないでしょうか。
Re:最小の適切な文字コードを選択 (スコア:3, おもしろおかしい)
Re:最小の適切な文字コードを選択 (スコア:4, おもしろおかしい)
nが多い (スコア:2, 興味深い)
分かち書きしてない元コメ [srad.jp]の
＞izennni
も、
new releaseさんの
＞sonnna
もですが、
「ん」＋「ナ行」でnが3つ並ぶのはローマ字として正しいのでしょうか・・・
# 9割方の人がそうなると思いますけど。
Re:最小の適切な文字コードを選択 (スコア:1)
> ケータイではまだ UTF-8 に対応していないものも少なくない
これ重要。
同じ理由でwebも完全にはutf-8に切り替えられない
ISO-2022-JPで書けない文字 (スコア:3, 興味深い)
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, すばらしい洞察)
どうしても読みたいなら適切なクライアントを用意するはず。
大体、すべてiso-2022-jpで来ることを期待するなんて設計や思想そのものが間違っている。
「送る場合は厳密に、受け取る場合は寛容に」なんて送受信を行う上での基本でしょ。
というのは暴論でしょうか。
Re:受け取れない奴が悪い (スコア:5, 興味深い)
e-mail の場合、送信者と受信者だけでなく中継者も考えに入れる必要があります。
昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
運悪くそのような中継者に当たってしまうと、文字化けします。
そのような中継者が絶滅したと言い切れないのであれば、
iso-2022-jp を使うべきです。
# もう絶滅したよね、と思ってたら2006年に遭遇しました…。
# いい加減滅ぼしてくれよ。
Re:受け取れない奴が悪い (スコア:4, おもしろおかしい)
>昔は8ビット目をクリアしてしまう中継者がたくさん居ました。
そこでUTF-7ですよ。
Re:受け取れない奴が悪い (スコア:3, すばらしい洞察)
Content-Transfer-Encoding: base64 という手もありますね。
HIRATA Yasuyuki
Re:受け取れない奴が悪い (スコア:3, すばらしい洞察)
というか、たれ込みの時点で文字集合と符号化を混同しているような気がします。
シフトJISでもUTF-8でもbase64で符号化したら7bitで通せますよね。
Re:受け取れない奴が悪い (スコア:1, すばらしい洞察)
> そのような中継者が絶滅したと言い切れないのであれば、
これはいわゆる悪魔の証明ではなくて？
Re:受け取れない奴が悪い (スコア:3, すばらしい洞察)
の
Re:受け取れない奴が悪い (スコア:2, 興味深い)
7bit しか透過しないネットワークや機器を考慮してそうなったのだと思いますが。
TomOne
Re:受け取れない奴が悪い (スコア:1, すばらしい洞察)
例えばcharset="iso-2022-jp"なのにSJISで送ってくるようなメールとか、
multipartなのにboundaryがない（MIMEのpreambleしかない）メールを
表示できるような寛容さはスパム対策上好ましくない気がします。
文字コードとは関係ないですけど、IE等の「寛容な」HTML解釈でinvalidなHTML文書
が氾濫した状況を見ると、受け取る場合こそ厳密にやるべきなんじゃないかとも思います。
Re:受け取れない奴が悪い (スコア:1)
# タイムアウトしたら再送、それじゃダメなら電話、に落ち着いてるので誰も根本原因を調べようとしない。
まだまだ無理 (スコア:2, 興味深い)
最近かかわったJavaの仕事で、他人が作ったところでメールの文字化けやらで問題が多発していました。
で、いろいろ自分もお手伝いとして調査していたんですが・・・
文字コードに平気で Shift-JIS とか Windows-31J とか指定してましたorz
メールについて何も知らないような、かつ調べようともしないような素人に作らせるなよ・・・。
という話はともかく、実際問題として、（Windows-31Jは論外としても）Shift-JISでも化けるようなメーラーやWebメールは残ってるので、受信者側のことを考えると迂闊には切り替えられないと思いますよ。
あと、中国とのオフシェア開発で、日本語メールだと微妙に化ける人がいたときに、UTF-8でメールしてたことがあります。
が、これも、日本人の関係者から、～さんからのメールがいつも化けます。ちゃんとした設定で送ってください。とクレームがきたので、そんなメーラー使うなよと思いつつ諦めました。
そういうトラブルを考えると、まだまだ ISO-2022-JP を使わざる得ないかなと。
Re:まだまだ無理 (スコア:1)
エンコードがbase64でそうなら、そうするしかないかもですねぇ。
末端は利便性優先で機能が向上してもいいのにーとは思うんですが。
中継のことのために7bit/base64でやりとりしてるなら。あとは末端間のネゴシエートの問題ですかね。
添付ファイルもそうですけど、一度相手と"つかって平気か?"のネゴが必要ですよね。やっぱ。
逆に調整できてれば複数言語交じりOKとか(UTF-8)、ファイルの変換不要(添付ファイル)とかできるわけですし。
# OEだけでなく、各種メーラの機能向上ってなかなか進みませんよね...(自戒をこめて)
メーラとメールヘッダにCapabilityとかあってもいいような気がしてきた。
M-FalconSky (暑いか寒い)
個人的には、メールで使われる文字コードは徹底して制約されるべきと思う (スコア:2, 興味深い)
理由はいくつもあるが、一番大きいのは spam mail 対策。
複数の文字コードを混在させたメールで spam mail を送ってこられると、本文を使った spam mail 判定が恐ろしく難しくなる。
何もわざわざ spam mail 屋さんに優しい環境にしなくてもいいよな、と言うわけで、現行のままでいいと思う。
もっとも、会社の中とかは Outlook + Exchange Server なのでリッチテキストが飛び交っていますが。
fjの教祖様
MS-Wordで送ればいいやん (スコア:2, すばらしい洞察)
サブジェクトは暴論でない。ただし、タレコミレベルの話をする場合において。
タレコミに書いている内容は、一見文字コードの話をしているように見えるが、実際の内容は「読める人がいるから使ってよいのでは?」ですよね。
それならばMS-Wordで良い。図だって使えるし。(実際はPDFあたりが最適と思う)
たとえば「メールにおける文字コード問題は昔はだいぶ議論されたものですが(Shift_JISで送るな！とか)、最近は全く聞かれなくなりました。」を理由に持ってくることは間違です。
いま問題が無いのは、きっちりとコードなどの各種規格を整備した結果であって、ほかの文字コードの無秩序な使用が可能になった結果ではない。
間違えてほしくないけど、私はメールの表現が豊かになることには反対しないよ。
ただ、タレコミに書かれているような姿勢でそれを論じるのは明らかに違っているということと、タレコミレベルなら「MS-Wordで送ればいいやん」が回答になると主張するのです。
あと、日本にはまたとな文字コードとそれを作れる人や組織が無いといってよいほど弱小なのも問題だよね。
#自戒でもあるが、どの年の規格化とかエンコードはどうで他国の文字との同居はどうすればよいかをちゃんと理解している人は数えられるほどだろうなぁ。自国の言葉なのに...
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:3, すばらしい洞察)
ダメです。メールのフォーマットに関しては素人なので以下に挙げる問題点を解決できる仕様があれば教えてもらいたいです。
例えば、現在のプレーンテキストのメールの仕様では、あらゆる言語で使いやすい、受信側のMUAで都合の良い場所で改行して表示する仕様がありません。76文字程度で改行することで大抵の環境で読みやすい、なんていう話も昔はありましたが、携帯電話のように想定外のデバイスが出てくると、このような話は成り立たなくなります。欧米の言語のようにスペースで単語を分かち書きする場合には"format=flowed"で自動改行の問題を解決できますが、これはスペースを利用しない言語のことは考えていない仕様なので、日本語や中国語等では意図しない場所に勝手にスペースが挿入されてレンダリングされることになるので日本人的には使い物になりません。
また、国際的なWebアプリケーションを作成する場合には、送信側のWebアプリケーションの開発が非常に大変である、という問題もあります。例えば(詳しくは知りませんが)タイ語は辞書がなければ改行位置が決まりませんし、そこまで複雑ではないとしても日本語には禁則処理もあります。Web用にtextareaから自由に投げられたテキストをメール送信のために適当な場所で改行してプレーンテキストのメールを作るだけでかなり大変な処理が必要になり、その分、Webサーバの負荷も大きくなります。ですが、HTMLメールで送信する場合は受信側の各レンダリングエンジンが自動改行を解決してくれますので、送信側が改行位置を気にする、という必要がなくなります(受け取り側のMUAがその人の利用する言語の処理が弱いとは考えにくい)。
また、プレーンテキストでは文字から言語を特定することができませんが、HTMLではlang属性が適切に設定されていればレンダリング時にその言語情報を利用することができます。例えば、日本語と中国語が混在しているメールを適切にレンダリングすることができるようになることを意味しますので、ビジネス等でそのような利用がよくある方には便利でしょう。
HTMLメールを使うと、セキュリティが不安だという都市伝説的な話や、スタイル指定で派手なものを送りつけられるのが鬱陶しいという話を聞きますが、どちらも受信側で再現する情報を取捨選択すれば済む話で、例えばMUA側でjavascriptや画像をオフにしたり、ユーザスタイルシートで作成者のスタイルシートを無効化する、ということが理論上はできます。
このように、HTMLメールは作成側には便利で、受信側にとっても意味のあるものを受け取ることができる、という点でプレーンテキストのメールよりも有利ですが、HTMLメールに対応していない資産を活用できなくなる、というあたりが最大の難点でしょうか。
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:2, 興味深い)
quoted-printableやbase64でエンコードすればいいと思います。実際添付ファイルはプレーンテキストでもエディタが都合のいい場所で改行して表示できます。日本語メールの本文をquoted-printableやbase64でエンコードしないのは、これまたRFC 1468が禁止しているからに過ぎません。で、禁止の根拠が「quoted-printableやbase64は対応していない環境もあるけど76文字程度で改行することで大抵の環境で読みやすい」だったりするのがもう…。
Thunderbirdは実際にそうしてますよね。
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:2, 参考になる)
禁止というほど強くはないんですけどね。RFC 1468 [ietf.org] によると：
ということで
という程度でしょう。それから15年も経っているのだから、状況は変わっているはずです。
これも、原文は
とあります。80カラムの制限が出てきたのは、当時は1行80カラムのディスプレイ端末（ウィンドウシステムですらない）が多く使われていたことの反映で、今では状況も違いますね。
日本語以外 (スコア:2, 興味深い)
自分は、毎回エンコードを設定するようにしています。日本語＋英語+ロシア語とかのメールを書きたい時があるので。正直うっとおしいので、UTF-8がデフォになってくれたら助かります。
ウェブページも、エンコード指定していないと、OSの言語設定が日本語以外だといちいちエンコードを指定しないといけないので、ウェブの場合はなんでもいいからエンコードを指定して欲しい。
動いているものに手をつけるなの法則 (スコア:2, 興味深い)
・現状で問題ないものに手をつける必要はない(無駄なリファクタリングみたいな)
・誰も儲からないことは誰もやらない
・小難しいことを言っても一般ユーザには何のことやら
という感じで、こんな是非は正直「非だ非！」という視線で見てしまいます。
Unicodeとかげんなりです。字体の変なまとまり方とか、全角ハイフンとか。
現状でユーザの満足度が上がりそうな変更は携帯で使っている絵文字が
正しく表示されるとか、そんなもんではないでしょうか。
# JustsystemあたりがShurikenとATOKを携帯絵文字対応にしたら
# 初心者ユーザとかうっかり取り込めるかも知れんなぁ、とか妄想してみる。
# データがかけちゃったところを補完するの込みで(^^;
8bit transparentでないMTAってどれくらいあるのかな (スコア:1)
確かに私の周囲の環境でも8bit transparentでない
MTAって見掛けません。あとはクライアント側が
うまく解釈してくれるかどうかだけかな。
携帯電話への転送に際しては文字コードを
しないとだめでしょうけど。
屍体メモ [windy.cx]
メールで閉じてない場合は？ (スコア:1)
前提にしていない文字コードが含まれたメールを表示するときに
トラブルになりがちですね。
まあそれも対応しろの一言で済ますんでしょうけど。言い出すときりが無いわけで。
非です。 (スコア:1)
知人がmh使っています。
＃最近のmhは非iso-2022-jpでも動作するんかな？
コンピュータに詳しい人とかいう人が、(株)とか丸数字とかをシグネチャに入れるやつがいて困る。
-- gonta --
"May Macintosh be with you"
Gmailの場合 (スコア:1, 興味深い)
自分は"送信メールにデフォルトのテキスト エンコードを使用する"にチェックしてます。たしかこれでISO-2022-JPに変換されてた。
一方、"送信メールに Unicode (UTF-8) エンコードを使用する"という選択肢もありますが、ヘルプ [google.com]では、受信者側で適切に表示できない場合に使えるよとありますね。
受け取る側としてはウェブブラウザなのでどっちでもいいよって感じですが、たまに欧米のウェブメールを使うとISO-2022-JPでは文字化けすることがあります。文字コードに疎い欧米のソフトを使うならUTF-8のほうが良いのかも。
後ろ向きかもしれないけど (スコア:1, 興味深い)
という事でISO-2022-JPを使っていますね。
特に最先端をいかなきゃならない理由もないですし、皆の後を
ついていけばいいのかな、と。
こうやって文章に書くと、「ああ、なんて後ろ向きなんだろう」
とは思いますけど。
# 文字コードよりも、Outlookの添付ファイルの分割送信の方を
# 先になんとかしてほしい。
機種依存文字 (スコア:1)
最近のメーラは頑張ってくれるので、漢字コード自身はそれほど気になりませんが、
機種依存文字だけは何とかして欲しい。
送られてくるデータがメーラで閉じていればいいのですが、
他のアプリに渡すためにファイル保存した際、機種依存コードが化けてしまう。
特に「丸１」とかローマ数字とか、使われている文章ではかなりの数、出現してしまう。
これを手で修正するのは面倒だし、、、、
おすすめのUnicode対応メーラは？ (スコア:1)
使っているメールソフトがUnicodeに対応していないのでISO-2022-JPでお願いしたいところですが、
Unicodeに対応していて、軽くて使いやすいメールソフトがあれば乗り換えても良いと思っています。
皆さんはどのメールソフトをお使いでしょうか？
Re:おすすめのUnicode対応メーラは？ (スコア:1)
1メール1ファイル形式なので、意味不明な文字化けメールが来ても、
当該ファイルを直接エディタで開いていろいろ調べられそうです。
(今のところそのようなメールには遭遇していませんが・・・)
匠気だけでは商機なく、正気なだけでは勝機なし。
MTAが問題ではない．問題はMUA． (スコア:1)
ここ，現代でもそのメーラー(MUA)が対応してないという話．
ここで，ESMTPの話が出てくる．ま，ESMTPを実装するMTAの話ですわな．ISO-2022-JPとUTF-8の話をするときにはMUAとMTAの話は切り分けて考えるべきだと思うんだけど．なぜなら身近なところに非対応のMUAがあるので(以下参照)．
やっぱりそうではなかった，ということが最初の段落で分かったわけですね．実際，私の携帯電話のMUAもUTF-8では文字化けします．じゃあ，やっぱりISO-2022-JP使った方がトラブルが小さいわけですね→結論．
もちろん，MUAの実装者が対応するべきという議論はあり得るし，それはそれで進めなければならない．でもそれを利用者に押しつけることはできない．特に携帯電話のMUAみたいに利用者が選びようのないものにとっては．ということで当面はISO-2022-JPでやりとりすべきだと私は思います．
フィルタリング (スコア:1)
まともなMUAでデフォルトがISO-2022-JPじゃないものってありますか？
Re:フィルタリング (スコア:2, すばらしい洞察)
Re:フィルタリング (スコア:3, 興味深い)
同じ事やってます。ごみ箱どころかそのまま廃棄ですが。
基本的に海外とのやりとりはないし、もし必要な場合はそのときだけフィルタを殺します。
とかやってたら、JALの領収書(メールでPDFファイルが送付される)が
ISO-2022-JPじゃなくて消滅。しかも再発行拒否だし。
メールで送って再発行拒否はないよなぁ。
Re:音声で送ればいいんじゃね? (スコア:2)
いや、メールはすべてpdfに書いたものを添付して送ることにすれば問題解決。
Re:音声で送ればいいんじゃね? (スコア:1)
後で検索できないぢゃん。
Re:時期 (スコア:1, 興味深い)
あの会社の製品のデフォルトが変な文字コードになっていたのが、
そのまま使うとマナー違反だという話が広まった時期と重なりませんか?