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

[Murata Takashi]

  文字コード云々について、深く理解せずに質問を続けています。
  すみません(最初に謝っておきます…)。

From: Kazu Yamamoto (山本和彦) <kazu at example.com>
Subject: [Mew-dist 11274] Re: mew-1.94.2pre2 (was mew-1.94.2pre1)

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

  その通りですね。私が理解不足でした。失礼しました。

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

  "C" -> charset(送信文字コード)の選択、と思っていましたが、入力文字
コードだけの指定になると、shift_jisを指定しても text/plain; charset=
iso-2022-jp になる、ということですよね？
  下の需要があるので、入力文字コードだけ、だとまずそうですが、そういう
場合は application/octet-stream にするのでしょうか？

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

  直感的には、"C" -> charset の選択、であり、入力文字コードの選択に
別のコマンド("I"とか)を与える方がいいように思えます。最初に"C"で
iso-8859-1が与えられれば、入力文字コードもiso-8859-1で推測する、と
すれば、今までの動作とも整合性が取れそうですし。


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

  そういうことか、と Meadow 1.10 + Mew 1.94 で試しましたが、Meadowで
作ったメールをMeadowでsaveしても、LFだけでした。ただし、Meadowで新規
作成したファイルもLFだけなので、それに従っているのだと思います。

Default coding system (for new files):
  S -- japanese-shift-jis (alias: shift_jis sjis)

  Mew以外のWindows Mailerだとどうなるか、までは試していません。
┌───────────── 村田 隆 / Takashi.Murata at example.com ┐
└ 日本システム技術(株) 技術部  Tel:03-3503-8736  Fax:03-3580-7806 ┘