[plamo:31265] Re: Plamo Linux における仮想化環境(7)

[Shun-ichi TAHARA]

>> Content-Type: text/plain; charset=ISO-2022-JP-2
>> となっているようですけど、その辺が関係してるのでしょうか？
> 
> ブラウザからコピペした『〜』の関係な気がしますねー．直接入力した『〜』
> では問題なく ISO-2022-JP になりますね．このメールも多分．

あぁ、WAVE DASH問題ですね。

〜をUnicodeに変換すると、U+301C になるべきなのですが、(Unicode仕様書どお
りのマップを持つUnixやMac等で変換するとこうなる)

Windowsで定義されている(SJIS(によく似たCP932)の)マップで変換すると、
U+FF5Eになるため、UTF-8なテキストはこちらで書かれているケースが多いよう
です。

実際問題として、(これはMicrosoftが悪いのではなく、Unicodeコンソーシアム
が出してきた例示字形が間違っていたのが原因らしいのですが)U+FF5Eを使った
ほうが、正しく表示されるフォントデータのほうが多数派だ、ということもある
のでしょうが。

mozc/GoogleIMEを使うと、U+301Cを入力するほうが難しかった記憶があります。

そんなわけで、本来のマップを持っているUnix環境でEmacsにペーストすると、
U+FF5Eは 〜 (JIS:0x2133) に変換できない、つまり「日本語のキャラクタセッ
ト」であるISO-2022-JPに射影できないため、Mewは多言語モードで送信しようと
します。

歴史的にMewは、多言語のキャラクタセットに ISO-2022-JP-2 を選ぶんですが、
これがデコードできるのが事実上Emacsくらいなので、ブラウザとかでは化けて
しまいますね。(ISO-2022-JPと思って表示しようとするけど、これに含まれない
エスケープシーケンスが出てきた時点で化ける)

今時、国際化されたテキストの交換はUTF-8を使うべきと思いますので、Mewのデ
フォルト設定を

  (setq mew-charset-m17n "utf-8")

にしちゃったほうがいいのかもしれません。
# これで出すと、多言語モード時にUTF-8を選択しますので、Web化しても化けな
# いと思います。

かなり前に、Mewのデフォルト値は上記に変更された記憶があります。

今回化けちゃったこれは、Emacsとかの ISO-2022-JP-2 を解するエディタで
UTF-8に変換してやるしかないでしょうけど。
-- 
田原 俊一
mailto:jado@xxxxxxxxxxxx