[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: utf-16
>>>>> In [mule-ja : No.08766] 半田さん wrote:
>> そもそも、"unicode" という charset は登録されていません。
> その通りです。だから「utf-16 として扱わなければいけない」と
> いうことはありません。まあ、utf-8 か utf-16 かでデコードして
> みて良さそうなほうを採用するという親切さがあってもよいかなと
> は思います。
なるほど。「utf-8 か utf-16 を試してみよ」と言わせるくらいはでき
るかもしれません。まあ、そういう事例が目だってきたら、で良いと思
いますが。
>> 2. その記事を forward したら化けてしまった。それも問題。
>> (化けてしまったのは、その記事を Gnus が適当に判断した方法で
>> decode+encode を行なったかららしく、無変換で forward するのは
>> いちおう大丈夫。)
> Gnus ってデコードする前の元の記事をどっかのバッファに保存し
> ていませんでしたっけ?なんでそれを使わないんだろう?
えーと、そういうこともできるんですが、デフォルトでは単に記事を読
むときと同様に、何らかの方法でデコードしたもので送信用のドラフト
を作り、C-c C-c の後でエンコードします。フォワードする記事を簡単
に改変できるこのあたり、SEMI MIME-Edit とはだいぶ違います。
>> 3. 簡単なテストをしてみると、Emacs 21.3.50 と 22.0.0 ともに
>> utf-16 という coding system は使えないように見える。(しかし
>> Simon Josefsson は使えるように見える、と。)
> utf-16 ファミリーでは以下があります(*-unix, *-dos, *-mac の
> バリエーションは省く)。
> (1) utf-16be -- Big-Endian, without-BOM
> (2) utf-16le -- Little-Endian, without-BOM
> (3) utf-16be-with-signature -- Big-Endian, with-BOM (alias: utf-16-be)
> (4) utf-16le-with-signature -- Little-Endian, with-BOM (alias: utf-16-le)
> (5) utf-16 -- unknown-Endian, with-or-without-BOM
> (5) が一番曲者で、decode 時には BOM を自動検出し、もしあれば
> それによって Endian を決定します。BOM がなければ utf-16be を
> 仮定します。ファイル読込時には (1)..(4) のいずれかが
> buffer-file-coding-system に設定されます(つまりそれを書き出
> す時には utf-16 は使われません)。
> encode 時には (3) と同じです。
非常によくわかりました。どうもありがとうございます。
[...]
> 通常は Mule-UCS を使っているからではないでしょうか。
はい、おっしゃるとおりで。^^;;
>> 最後に問題になった記事のボディだけを添付しますが、
> このファイルは utf-16le-dos でエンコードされています。中身は
> ASCII のみです。
おお、-le で見事にデコードできました。しかし、こんなものを
utf-16 でエンコードしてしまうメイラーは困りものですね。;-)