中治> ときどき、ヘッダに 中治> 1. Content-Type はあるが、Mime-Version がない 中治> 2. どちらもない 中治> メッセージがあります。そういうメッセージの本文を表示するのに、 中治> XEmacs さんは jisx0208-1978 なフォントを使うらしく、見苦しいです。 us-ascii にすれば良いですか？:-) というお約束は置いておいて、ある MIME charset をどういう風に解釈するかを 決めているのは MUA であって、XEmacs ではありません。よって、1, 2 である かはこの『問題』に関係ありません。 通常、emacsen 上の MUA は MIME charset に対応する coding-system を決め、 それで decode してくれるように emacsen に依頼します。 で、iso-2022-jp データ列で JIS X 0208:1978 を指示していたら、ISO 2022 decoder は GB 2312 でも ISO 646 IRV でも JIS X 0212 でもなく JIS X 0208:1978 として解釈しなければならないのは当然のことです。 ところが、従来、JIS X 0208:1978 と JIS X 0208:1983 を同一視する悪しき慣 習がありました。もちろん、文字集合とその上での符号位置で表現される符号化 文字をさらに解釈して system 固有の文字に mapping するのは良いことですが、 従来、文字を文字として解釈するのではなくて、異なる文字集合の符号位置の意 味を勝手に unify するというでたらめなことをしていた訳です。 ISO/IEC 2022 の図形文字集合上の符号位置から文字オブジェクトに mapping す る機構と正確な data があれば文字の同一性を考慮して unify するのは真っ当 でしょう。しかしながら、現在の XEmacs にはその双方がありません。そうであ る以上、悪しき慣行に基づく ad-hoc なやり方はやめておいた方が良いと思いま す。 なお、Emacs/MULE では昔は hard coding により unify されていたのですが、 現在では文字を文字に変換する translation-table 機構により実現されていま す。で、default の値が腐っている訳です。多分、これは将来直るのではないか と思っていますが Emacs 20.4 は今のままになるようです。 という訳で、以下の質問ですが、 中治> 1. そういうメッセージの存在そのものは許されるものでしょうか? 中治> MIMEの世界征服が達成されると、許されない? 許されます。 そもそも charset=iso-2022-jp を明示しても同じ問題が起こります。また、 charset の指定がないものを us-ascii として解釈した場合、 charset=iso-2022-jp を明示した message に対してのみこの問題が起こります。 ;; MIME はメタな枠組なので、個々の内容に依存した問題は MIME に関係しない ;; ことが多いです。 ;;; utf-8 の世界征服が達成されると起こらない？（あ、でも、JIS X ;;; 0208:1983 の font とかを使っていると相変わらず起こるとか、UCS ;;; encoding でも穴空き font だともっと激しく起こったりして(^_^;;;） -- ===『幾千億の分子に分かれても ======================================== 決して忘れない。 この宇宙が終るまで』 守岡 知彦 (MORIOKA Tomohiko) ======================================== Email: <tomo(a)etl.go.jp&gt; ===== ;; PGP public key: http://www.etl.go.jp/~tomo/hiko/pgp.key P.S. 新 JIS だと JIS X 0208:1978 と 1990 の両方の文字が入っているのでお 得？（果して、今年中に出るのか？）