[mew-dist 29564] Re: 添付テキストファイルの文字コード

[Shuichi KITAGUCHI]

北口です。

横から失礼します。

>    (utf-8で書いたファイルを添付したのだから)utf-8で送り出して欲しい

私は、文字コードや改行コードを変えずに送りたい時は、text/plain
から、application/octet-streamに変え添付しています(した)。
t で一発変更できるので、そんなに手間がかからないと思います。

ご参考までに。
# 後ろ向きな方法だと思いますが、とりあえず一番楽だったので...


--
Shuichi KITAGUCHI // kit at example.com / ki at example.com

> かずさま
> 
> お返事ありがとうございます！
> 
>>> を試してみました。結果は変わらず、iso-2022-jp で
>>> 送り出されてしまいました。(set-language-environment")は
>>> 無効のまま、emacsは再起動してあります。
>> 
>> えーと、問題は iso-2022-jp-3 になることでしたよね？
> 
> 違います！ 書き方が悪かったです。ごめんなさい。
> 
>    (utf-8で書いたファイルを添付したのだから)utf-8で送り出して欲しい
> 
> という素朴な希望だったんです。iso-2022-jp も iso-2022-jp-3 も
> どちらも望ましくないです。
> 
> そもそも、添付のためにテキストファイルを読み込むときに、
> emacsは文字コードを自動判定してくれるのですから(ですよね?)
> その判定結果をそのまま使うという訳にはいかないものでしょうか？
> 
> 現在は、一旦emacs内部形式に変換して、その上で
> mew-cs-database-for-encoding のようなルールに従い
> 「最適」な文字コードを選択する、という手順を踏んでいるんですね。
> 
> これは結構大事な問題だと思います。メール本文はどうでも良いのですが、
> 
>   テキストファイルを添付して送信 -> 受信者が自分のディスクに保存
> 
> ということをした時に、内部の文字コードが変わってしまうのですから、
> こちらでは表示できるものが、受信者には表示できない可能性が
> あります(脚注1)。
> 
> 特に、unicode数学記号のような、「日本語」とは言えないものしか
> 含んでいないのにiso-2022-jpになってしまうのは . . .
> (脚注2)。
> 
>> 通常の範囲の日本語文字を含むテキストが、iso-2022-jp になるのは当然です。
>> mew-cs-database-for-encoding にそういうルールを書いているからです。
> 
> と言う事は、
> 
> /usr/share/emacs23/site-lisp/mew/mew-mule3.el
> 
> を参考にして mew-cs-database-for-encoding を再定義してやれば
> いいんですね！ 理想的には、添付に関してだけ変更できればいいんですが、
> 僕にはそれだけの知識はありません。
> 
> 古恵 亮
> ---
> (*脚注１)実際、Mac上でLibreOfficeを使って開いてみると、utf-8の
> テキストファイルは正常に開けましたが、添付したためiso-2022-jp
> になってしまったものは、文字化けしました。OSは英語環境です。
> 
> (*脚注２) 僕が実際に困ったのは、実際はこの問題なんです。話を単純に
> するつもりで日本語を例に出しましたが、実際は、英語の文章に数式を
> ちょこちょこ混ぜたテキストファイルを添付して送ったら、ドイツ人やら
> アメリカ人やらの受信者に開けないテキストファイルが出来てしまった、
> という話だったんです。それ以降、忘れないように"C"で変更するように
> 心がけています。