🚀 go-pugleaf

On 07/21/92(10:44) demizu@nff.ncl.omron.co.jp (DEMIZU Noritoshi) wrote
in <DEMIZU.92Jul21104424@boo.nff.ncl.omron.co.jp> (fj.mail:1503/etlss2):
 | |といいますのも、MIMEのcharsetパラメタは、bodyに実際に含まれている文字
 | |セットをもっとも小さく指示すべきだという方針があるからです。
 | |これは、読み手あるいはツールが、そのメッセージを読めるか否か、
 | |あるいはどう表示すべきか、を判断するために、このパラメタがある
 | |からです。
 |
 |メッセージを読めるか否かの情報が charset パートにある必要はないように
 |思います。ヘッダにひとつあるだけで十分じゃないでしょうか。例えば、
 |  X-Used-Charsets: ISO8859-1,JISX0208,GB2312
 |みたいに書けば目的は十分達成できると思います。

MIMEでは、必要なヘッダフィールドを出来る限り少なく、
また合意のとれたものだけにしたかったようです。
で、その結果、MIME-Version: , Content-Type: および
Content-Transfer-Encoding: の３つさえ通れば、MIME
の解読(^_^;)ができるように設計されています。

ボディ部の内容に関する記述はみな、Content-Typeフィ
ールド(RFC1049)に詰め込んで記述します。

＃私も、
＃charset="{US-ASCII,JIS-X-0208}/ISO-2022"
＃のようなのを打診したのですが、反応ありませんでした;-)


 |それでも無理矢理読もうとした時は、文字列を展開してみて知らない/表示で
 |きない文字列があったときにツールが考えればよろしい。:)

＃個人的には、わたしもそれに近い感覚ですけど(^_^)

MIME/Metamailでは、表示用のツールとしては、そのサイト
に既存のものを活用しようという方針みたいです。MIME用
に表示ツール作り直すのは、大変ですしね。
そうなると、表示ツールに渡す前に、MIME関係のことは解決
してしまうことが必要なのでしょう。

それから、単純に表示するだけでなく、richtextのように
テキスト処理を通す場合、文字セットやエンコーディング
スキームがはっきりしていないと処理不能、ということも
あるのでしょう。


 |文字種が変わる度に =?ISO-2022-JP?B?.... とやるのは転送すべきメッセージ
 |がとっても大きくなるのでたいへんだと思います。

まあ、こんな冗長な書き方をするのはヘッダ内だけですから、
そう問題ないのでは、と思ってたのですが、現状では、長い
ヘッダフィールドでこけるニュースリーダもあるようですの
で、そうも言ってられないようですね…
それから、前の記事にも書きましたが、文字種が変わる度に
=?ISO-2022-JP?B?...とやる必要はありません。私の安直な
実現ではそうなっていますが…

ボディ部に関してはエンコードせずにISO-2022-JPが通ります。
ただ、もしボディ部のESCを通してくれないようなシステムを
通過させたい時には、base64エンコーディングをかけて通す
こともできます。その場合のヘッダは、
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: base64
のようにします。base64のデコードは、読み手側のツールが
自動的にやってくれますので、読み手には日本語が生で届いた
ように見えます。

 |まぁ考えてみれば charset=ISO2022 という表現は、文字集合名としてエンコー
 |ディング・スキームを指定していることになるのでナンセンスですね。

そう思います。
ただ、MIMEのcharsetパラメタは、文字のエンコーディング・
スキームも含んでいる(ISO-2022-JPのように)ので、そう
言い切ることもできないとは思います。


 |もうちょっと勉強してまともなフォローができるようになってから出直します。

ぜひRFC1341,1342を読んで下さい。私もそれほどちゃんと
読んだわけではないので、誤解もあるかも知れません(^_^;)
「ここにこう書いてあるじゃないか」という形で指摘して
下さると、ありがたいです。

┰── ─┰─ ┰
┠─ ＋＋佐藤＠情報ベース．電総研　　　　　　　快進撃サトウのごはん
┸── 　┸　 ┸──────────────────────────�★☆�