Outlook2002の不思議なエンコーディング 13
ストーリー by wakatono
オレもこんなのを使わなきゃいけないのか… 部門より
オレもこんなのを使わなきゃいけないのか… 部門より
k3c 曰く，"@ITの記事によれば、Outlook2002では日本語で電子メールを書くとquoted-printableでエンコードされてしまう。どうやら行頭のエスケープコード(0x1B)が引っかかってしまうらしいのだ。日本語の電子メールは多くの場合、キャラクタセットがISO-2022-JP、エンコードは7bitで送られているし、それで何ら問題ないのだから、いちいちエンコードを変更して頭痛の種を増やさないで欲しいところ。
Outlookを（業務で、または私的に）使っている人の数は決して少なくないと想像するので、彼らがそのうちOutlook2002にアップグレードすると、あちこちで同じような質問が繰り返されることは想像に難くない。しかも今度はレジストリを変更しないと解決しないのだから始末が悪い。レジストリをいじる勇気のない人はOutlook2002で日本語メールを書くなということか。…いや、ちょっと待って？
この記事を書いた人はメーリングリストに宛てたメールがエラーで返ってきたと書いている。ということはquoted-printableなメールを受け付けないポリシーをもったメーリングリストがあるということか。それはタブン、メーリングリストの参加者の中にはquoted-printableなメールをデコードできない環境でメールを読んでいる人がいることを想定してのことなのだと思われる。…でも、実際のところ、本当にそうなの？
というわけで、ワタシの疑問点を整理して/.-Jの皆さんにぶつけてみたい。
- Outlook2002のエンコード方法は（RFC的にor仁義的に）正しいのか？
- メーラーはquoted-printableなISO-2022-JPメールをデコードする機能を備えるべきなのか？
- 実際にquoted-printableなメールを読めない人がどれくらいの割合でいるものなのか？
- （海外では珍しくない）quoted-printableエンコードを拒否するメールサーバ（メーリングリストを含む）の設定は妥当なのか？
こんな面倒なことしなきゃ使えないんだったら、Outlook2002なんか使いたくないんだが…でも、使わなきゃいけない人も多いのは事実。というか、これって単にデグレードしてるだけなんじゃないの？
思いつくのは (スコア:2)
MHや古典的mailコマンドを使っている人も周りに結構いますし。
携帯へのHTMLメールなど、読めない時はとりあえず無視していますが、
最近、それで仕事のメールを無視してしまうことも多く。
これで問題の種が増えるかと思うと憂鬱です。
アップデートしませう (スコア:2, 参考になる)
Re:ただのバグ (スコア:2)
しかし、アップデートに関するマイクロソフトの説明がなんか釈然としないのですが…「本来は…必要があります」っていうのはどういうことなんでしょう？そういう規定がRFCのどれかにあるということでしょうか？
あと、Outlook2002を使っている人のなかでこのアップデートに辿りつける人がどれだけいるのか、という問題もあるのですが、それは今に始まった事ではないので脇へよけておいて。
＃ だったら書くなよ
quoted-printableなメールを読める人の方がかなり多いのであれば、quoted-printableなメールを配信拒否する理由は何もないと思うのですが、そのへんどうなんでしょうか？海外では発音記号などを表記するためにquoted-printableで送る必要があるケースがあるようなので、むしろquoted-printableを配信拒否するのは間違いではないかと思うのですが。
Re:ただのバグ (スコア:2)
これらを対処するWinME且つ、Outlook2002ユーザは大変だなあ。いやホント。
Re:ただのバグ (スコア:2, 参考になる)
これはRFC1468になりますが、Status: INFORMATIONALです。
ISO-2022-JP文字列をQuoted-Printableにするのは、Quoted-Printableの性質上望ましくはないですが、RFCに反してはいません。
RFC準拠のMUAであれば読めます。
また、本文の場合はともかく、ヘッダについては0x1Bが含まれてはいけないのでエンコードの必要があります。
このときRFC1468ではBエンコードを奨めていますが、エンコード対象文字が0x1Bしか存在しないなら、
日本固有の事情を考慮しないMUAならQエンコードを選択するでしょう。
これは誤りではないと思います。
しかしPostPetなどはQエンコードされたヘッダを解釈してくれませんけど^^;。
余計なエンコードにメリットはない (スコア:1)
のメールと、
Content-Transfer-Encoding: Quoted-Printable
Content-Transfer-Encoding: Base64
のメールで、どちらの方がより多くの環境で読めるか
どうか、ということを考えれば、どちらの方がいいか
は明白だと思う。
私はMewを使っているから一応Quoted-Printable
も読めるけれど、imgetで取り込んだメールをless
で直接読むことも多いから余計なエンコードを
されていると不便だ。
すみません (スコア:1)
とりあえず、i-modeは、quoted-printableなISO-2022-JPは正常に受けてくれるようです。
パッチ (スコア:1)
とりあえずレジストリいじらなくてもいいみたい。
0x1bでなくても? (スコア:1)
single-partの話ではないのですが、イギリスにいる知人がOutlookを使って(multipartの形で)パッチを私に送ってきたことがあります。実はそのパッチもquoted-printableでした。パッチ自体は単なる7bitなplain textです。
読めるかどうかという問題ですが、この答えは「どのようにして読むか」にもろに依存します。一応私もメーラを使えば読むことはできます。しかし、パッチのようなものだと
のようにいきなり当てる技もあります。パッチが7bitであれば、transparentにメールで投げることもパッチを当てることもできるわけです。
昔は通信におけるtransparencyの確保に大きなコストがかかっており、それゆえにtransparentな通信ができることはありがたいことでした。Windowsはそういう時代を知らないわけで、当然ありがたみもわからないわけです。事情を知らないでquoted-printableに走ってしまうのも仕方ありません。
ただのバグ (スコア:1)
@ITの記事が更新されて「問題の回避方法 その1（アップデートを適用する方法）」が追加されてます。
この件は、事実上の標準に対してマイクロソフトが意図的な変更を加えようとしたんじゃなくて、ただのバグということでよろしいのでは。
Re:ただのバグ (スコア:1, おもしろおかしい)
バグが出てもパッチを出せば許されるっていいなー。
俺もそういう会社で仕事したいなー（ぉぃ
Outlook 補完計画 (スコア:1)
Mc.N
アップデート… (スコア:0)
前は使えてたのに…という人がどれだけ出てくるでしょうか？
それを考えると、このテのバグ（記事ではデグレードとなってましたが）「パッチ提供したからOK」というスタンスは、ソフトベンダとしての良心を疑います。