[Mew-dist 11274] Re: mew-1.94.2pre2 (was mew-1.94.2pre1)

[Kazu Yamamoto ( 山本和彦 )]

From: Murata Takashi <Takashi.Murata at example.com>
Subject: [Mew-dist 11270] Re: mew-1.94.2pre2 (was mew-1.94.2pre1)

>   もともと、sambaでコピーした、SJIS+CR/LFなファイルを添付しようとして、
> guessのままだとJIS(iso-2022-jp)になっていました。だからテキストの場合
> guessが働いていなかったのではないですか？

guess しているのは添付するファイルの文字コードです。日本の環境であれば、
ISO-2022-JP/EUC-JP/Shift_JIS のいずれであるかを推測します。そして、バッ
ファには Mule の内部表現として読み込みます。配送する際は、RFC の規定通
り ISO-2022-JP で送信します。ですから、ちゃんと guess しています。

添付領域に "C" があるのは、たとえば日本語の環境で latin-2 などを添付し
たいという要望に答えるためです。日本語の環境では、latin-2 のファイルの
文字コードを誤って推測する可能性があるので、明示できるようにしています。

latin-2 は送信時も latin-2 (ISO-8859-1) なので問題ありませんでした。入
力の文字コードを "C" で shift_jis に指定した場合、送信時にも shift_jis 
になるのは、僕の想定範囲を越えています。僕としては、ISO-2022-JP で送ら
れるべきだと考えていましたが、コードがそうなっていなかった訳です。(バ
グともいう。)

ここからは、仕様をどうするかの話になりますが、僕の質問は "C" は
	- 入力文字コードだけの指定
	- 入力文字コードと送信文字コードの両方の指定
のどちらがいいでしょうか、ということです。

>   通常はJISでいいのですが、受け取り側がNotesな人で、読めない、との苦情
> があったので、その場合は、"C"でshift_jisを選んでいました。

こういう需要があることも理解できます。

>   受け取って y でセーブすると、SJISですが、行末はLFですね。これは特に
> 苦情が無かったので気にしていませんでしたが、行末CR/LFにすることは可能
> でしょうか？

UNIX では行末は LF になります。Windows では CRLF になるはずです。そう
でなければ Mew のバグです。この仕様で特に困るとは思いません。

もし、UNIX でのテキストを Windows に持っていくと困るという話でしたら、
それは Mew の問題ではなく、Unix vs. Windows の一般的な問題です。

--かず