;; mule-ja の方が良いのかな??
;; それとも emacs-mime-ja??
;; 適当なところにどなたか振ってください。
いつの頃からか… UTF-8 で送られて来るメールの decode が出来ず、きち
んと表示されません。
Header 情報には
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by eitc.epson.com id SAA08427
なんて情報が有り(Oops, またあの MUA ですか) この Header 情報を持った
メールは必ず decode 出来ていません。
このときの Modeline には S\-- と表示されていてます。
ちなみに、Mule-UCS は 0.84 をインストールしていて、設定に関しては
;; UNICODE 用の設定 - MULE-UCS
(require 'un-define)
;;(setq bitmap-alterable-charset 'tibetan-1-column)
(setq bitmap-alterable-charset 'indian-1-column)
(require 'jisx0213)
(set-language-environment "Japanese")
としていて、(set-language-environment "Japanese") の前に全ての
Mule-UCS 関連の設定はしています。
実際、このメールを生のまま find-file で見るときちんと読む(見る)こと
が出来ます。このときの Modeline は
u(Unix)--
となっていますので、Mule-UCS の設定はきちんとできているようです。
さて、このばやい何がいかんのでしょうか??
--
Tatsuya - Tim - Ichikawa <ichi...@jpl.org>
>>>>> In [meadow-users-jp : No.3823]
>>>>> “Tim” = Tatsuya Ichikawa <ichi...@jpl.org> wrote:
Tim> ちょっとどこにだしたら良いのか…多分 Meadow 固有だと思うので…ここに出
Tim> します。
[...]
Tim> いつの頃からか… UTF-8 で送られて来るメールの decode が出来ず、きち
Tim> んと表示されません。
Tim> Header 情報には
Tim> MIME-Version: 1.0
Tim> X-Mailer: Internet Mail Service (5.5.2653.19)
Tim> Content-Type: text/plain;
Tim> charset="utf-8"
Tim> Content-Transfer-Encoding: 8bit
Tim> X-MIME-Autoconverted: from base64 to 8bit by eitc.epson.com id SAA08427
Tim> なんて情報が有り(Oops, またあの MUA ですか) この Header 情報を持った
Tim> メールは必ず decode 出来ていません。
MTA が base64 を decode していますよね?
うちの MTA はそういうことはやらないので実験的に decode して
CTE: 8bit というファイルを作って表示したところ、化けました。
ごらんの User-Agent の組み合わせでで化けました。
でも Oort Gnus では化ずにちゃんと表示されました。
もしかすると FLIM/SEMI かも。(まだ特定できてません。)
Meadow じゃない Emacs20.7/Mule4.1 でも化けるのかしら。
--
こせき @ Emacs のページ作成中
http://www.NetLaputa.ne.jp/~kose/Emacs/
ko...@yk.NetLaputa.ne.jp
[...]
kose> Meadow じゃない Emacs20.7/Mule4.1 でも化けるのかしら。
この環境で化けました。
Emacs21/Mule5.0 では化けませんでした。
--
こせき @ Meadow のページも作成中
http://www.NetLaputa.ne.jp/~kose/Emacs/Meadow/
ko...@yk.NetLaputa.ne.jp
似たようなことを経験したことがあります。そのときは、
charset="shift_jis" で、
X-MIME-Autoconverted: from base64 to 8bit ...
がついていました。
深く追求せずに、sendmail.mc に
MODIFY_MAILER_FLAGS(`LOCAL', `-9')
を書き足し、MTA が decode しないようにして、解決としました。
>>>>> In [semi-gnus-ja : No.6211]
>>>>> 小関 吉則 (KOSEKI Yoshinori) <ko...@wizard.tamra.co.jp> wrote:
小関さん> MTA が base64 を decode していますよね?
僕の場合も、市川さんとほぼ同じ状況でした。
小関さん> Meadow じゃない Emacs20.7/Mule4.1 でも化けるのかしら。
Meadow じゃない Emacs20.7/Mule4.0 です。
--
NAKAJI Hiroyuki (中治 弘行)
小関> げっ、再現した。
Tim> Content-Type: text/plain;
Tim> charset="utf-8"
Tim> Content-Transfer-Encoding: 8bit
小関> ごらんの User-Agent の組み合わせでで化けました。
小関> でも Oort Gnus では化ずにちゃんと表示されました。
ちなみに、Mew 2 では Emacs-21/Mule-5.0, Emacs-20/Mule-4.1 ともに
化けませんでした。
小関> もしかすると FLIM/SEMI かも。(まだ特定できてません。)
小関> Meadow じゃない Emacs20.7/Mule4.1 でも化けるのかしら。
Mule 4.1 は Meadow と UNIX で確かめましたけど、良く考えたら、こ
の前の半田さんの mule-ja のパッチをあてているので、その辺りの因
果関係が不明です。
# けど、FILM/SEMI かしらん?
--
白井秀行@これから会議
Tim> Content-Type: text/plain;
Tim> charset="utf-8"
Tim> Content-Transfer-Encoding: 8bit
kose> ごらんの User-Agent の組み合わせでで化けました。
kose> でも Oort Gnus では化ずにちゃんと表示されました。
Oort Gnus では FLIM/SEMI を使ってないし、
白井> ちなみに、Mew 2 では Emacs-21/Mule-5.0, Emacs-20/Mule-4.1 ともに
白井> 化けませんでした。
Mew は FLIM/SEMI を使ってないし。
kose> もしかすると FLIM/SEMI かも。(まだ特定できてません。)
kose> Meadow じゃない Emacs20.7/Mule4.1 でも化けるのかしら。
白井> Mule 4.1 は Meadow と UNIX で確かめましたけど、良く考えたら、こ
白井> の前の半田さんの mule-ja のパッチをあてているので、その辺りの因
白井> 果関係が不明です。
ボクの環境では Windows も Solaris も mule-ja のパッチ
http://www.m17n.org/mule-ja-archive/2001-8/msg00000.html
はあてていません。
白井> # けど、FILM/SEMI かしらん?
かなぁ。
Emacs20.7 で cmail, Wanderlust では文字化けしますか?
> >>>>> In [semi-gnus-ja : No.6214]
> >>>>> “白井” = Hideyuki SHIRAI (白井秀行) <shi...@meadowy.org> wrote:
> kose> もしかすると FLIM/SEMI かも。(まだ特定できてません。)
> kose> Meadow じゃない Emacs20.7/Mule4.1 でも化けるのかしら。
>
> 白井> Mule 4.1 は Meadow と UNIX で確かめましたけど、良く考えたら、こ
> 白井> の前の半田さんの mule-ja のパッチをあてているので、その辺りの因
> 白井> 果関係が不明です。
>
> ボクの環境では Windows も Solaris も mule-ja のパッチ
> http://www.m17n.org/mule-ja-archive/2001-8/msg00000.html
> はあてていません。
>
> 白井> # けど、FILM/SEMI かしらん?
>
> かなぁ。
>
> Emacs20.7 で cmail, Wanderlust では文字化けしますか?
Wanderlust は大丈夫でした。
ちょっと調べたところ、添付のようなメールに対して T-gnus では
`mime-entity-content' の結果が
"\343\201\200\202\343\257\203\343\271\203\343\247\201\200\200\202\n\n"
とおかしいようです。
Wanderlust では
"\343\201\223\343\202\214\343\201\257\343\203\206\343\202\271\343\203\210\343\201\247\343\201\231\343\200\202"
と正常に取得されます。
>>>>> In [semi-gnus-ja : No.6216]
>>>>> “Ari” = a...@atesoft.advantest.co.jp (Akihiro Arisawa) wrote:
: --Multipart_Thu_Aug__9_13:55:12_2001-1
: Content-Type: message/rfc822
: To: a...@atesoft.advantest.co.jp
[...]
: Content-Transfer-Encoding: 8bit
: c c c /c c 9c c 'c c
こうなっちゃうのか。
base64 encode して添付すべきなのかなぁ。
ちなみに Oort Gnus は 添付すると
: --=-=-=
: Content-Type: message/rfc822
: Content-Disposition: inline
[...]
: Content-Type: text/plain; charset=utf-8
: Content-Transfer-Encoding: base64
と base64 encode するようです。
Mew は?
有沢> Wanderlust は大丈夫でした。
有沢> ちょっと調べたところ、添付のようなメールに対して T-gnus では
有沢> `mime-entity-content' の結果が
有沢> "\343\201\200\202\343\257\203\343\271\203\343\247\201\200\200\202\n\n"
有沢> とおかしいようです。
有沢> Wanderlust では
有沢> "\343\201\223\343\202\214\343\201\257\343\203\206\343\202\271\343\203\210\343\201\247\343\201\231\343\200\202"
有沢> と正常に取得されます。
的確なヒントをありがとうございます。
私の環境でも化けるもので,調べていたのですが,いったん
enable-multibyte-characters => t である, gnus-article-buffer な
いに decode 前のメッセージを読み込んでしまうところに問題があるよ
うです。
試しに local の, Nana7 では読み込んでメッセージを parse するま
での間は enable-multibyte-characters => nil となるようにしてみま
したが,化けなくなりました。
さて, T-gnus に関してですが, T-gnus ではなにも
gnus-article-buffer に読み込まずとも,直接 *original buffer* に
読み込んでしまえばよいような気がするのですがいかがでしょうか?
;; gnus-article-buffer の undecoded なものは何かに使うのでしょう
;; か?
--
鈴木圭一 / kei...@nanap.org
PGP finger print (DH/DSS)
0B32 B37E 6DE9 3BC1 68A4 4089 7AAF 2B03 ECBD 614B
> 私の環境でも化けるもので,調べていたのですが,いったん
> enable-multibyte-characters => t である, gnus-article-buffer な
> いに decode 前のメッセージを読み込んでしまうところに問題があるよ
> うです。
T-gnus も gnus-request-article-this-buffer をいじってみたら、化けなく
はなりました。
が、表示される記事が途中で切れてしました。
;; body-end が小さくなっているのですが、どこで設定しているのか分からな
;; くて挫折(^^;
> さて, T-gnus に関してですが, T-gnus ではなにも
> gnus-article-buffer に読み込まずとも,直接 *original buffer* に
> 読み込んでしまえばよいような気がするのですがいかがでしょうか?
賛同いたします。
>>>>> In [semi-gnus-ja : No.6217]
>>>>> ko...@wizard.tamra.co.jp (小関 吉則 (KOSEKI Yoshinori)) wrote:
> 話は別ですが、MTA が decode したメール(CTE:8bit)を添付すると
> こうなっちゃうのか。
> base64 encode して添付すべきなのかなぁ。
base64 で encode して送信したつもりだったのですが、だめでしたね(^^;
mime-edit-insert-message がうまくうごかなかった(?)ので、
mime-edit-insert-file を使い、base64 と指定したのですが。
で、今試しに T-gnus で mime-edit-insert-message を使ってみましたが、
8bit のメッセージだと化けちゃいました。
;; MIME-Edit next generation に期待?
--
有沢 明宏
圭一さん> さて, T-gnus に関してですが, T-gnus ではなにも
圭一さん> gnus-article-buffer に読み込まずとも,直接 *original buffer*
圭一さん> に読み込んでしまえばよいような気がするのですがいかがでしょう
圭一さん> か?
有沢さん> 賛同いたします。
8-bit, UTF-8 の記事の日本語が Emacs 20 で化けてしまう件、確認し
ました。Emacs 21 と XEmacs では化けないことも。
;; ふうっ、やっと話に追い付いた。(^^;;)
実は現在の T-gnus が、まず生の記事を gnus-article-buffer に取り
込んでから gnus-original-article-buffer に転送し、それを元に
MIME-View で再び gnus-article-buffer を書き換えるようになってい
ることはだいぶ前に気が付いていたのですが、変更するのが恐ろしいの
と、ぼくは主に XEmacs を使っているので multibyte と unibyte の絡
みには疎かったことも手伝って、手を付けずにいました。
添付したパッチの変更ではいかがでしょうか?
t-gnus-6_15-quimby 枝 の T-gnus を元にしましたが t-gnus-6_15 枝
のものにも当たるので、できましたら少なくともこの話に参加された、
T-gnus を使っていらっしゃる方々全員のみなさんに試用をお願いしま
す。:-)
なお、T-gnus の起動後に改造した gnus-art.el(c) を load して試す
場合には、一度 gnus-article-buffer ("*Article*" バッファ) を
kill して下さい。でも、なるべくならば make install して、普通の
生活で使って下さることを希望します。
2001-08-10 Katsumi Yamaoka <yam...@jpl.org>
* lisp/gnus-art.el (gnus-request-article-this-buffer): Insert an
an article into `gnus-original-article-buffer' instead of
`gnus-article-buffer'.
Tim> いつの頃からか… UTF-8 で送られて来るメールの decode が出来ず、き
Tim> ちんと表示されません。
>>>>> In [semi-gnus-ja : No.6220]
>>>>> Katsumi Yamaoka <yam...@jpl.org> wrote:
山岡> 添付したパッチの変更ではいかがでしょうか?
の件ですが、市川さんから動作確認のリポートをいただいたのと、ぼく
自身も先週末から使っていて特に問題は無さそうなので CVS commit し、
revision 番号を更新しました。
--
Katsumi Yamaoka <yam...@jpl.org>
>> On 09 Aug 2001 15:25:47 +0900
>> 「鈴木」== kei...@nanap.org (Keiichi Suzuki) said as follows:
鈴木> さて, T-gnus に関してですが, T-gnus ではなにも
鈴木> gnus-article-buffer に読み込まずとも,直接 *original buffer* に
鈴木> 読み込んでしまえばよいような気がするのですがいかがでしょうか?
この変更によって、gnus-cache-enter-article() が動かなくなってしまいま
した。
鈴木> ;; gnus-article-buffer の undecoded なものは何かに使うのでしょう
鈴木> ;; か?
gnus-cache-enter-article()
-> gnus-cache-possibly-enter-article()
-> gnus-request-article-this-buffer()
という順序で呼び出されて、元々の記事を取り出す目的で利用されるようです。
--
土屋 雅稔 ( TSUCHIYA Masatoshi )
鈴木> さて, T-gnus に関してですが, T-gnus ではなにも
鈴木> gnus-article-buffer に読み込まずとも,直接 *original buffer* に
鈴木> 読み込んでしまえばよいような気がするのですがいかがでしょうか?
土> この変更によって、gnus-cache-enter-article() が動かなくなってしまいま
土> した。
*Original Article* の内容を、gnus-article-buffer にもコピーするように
変更すると、とりあえず動くようになりました。UTF-8 decoding 問題の方に、
悪影響が出ていないか、動作確認をお願いします。
;; gnus-current-select-method の変更が入った直後だったので、エンバグし
;; てしまったかしらと、冷や汗たらたらものでした。
>>>>> In [semi-gnus-ja : No.6289]
>>>>> TSUCHIYA Masatoshi <tsuc...@pine.kuee.kyoto-u.ac.jp> wrote:
土屋さん> *Original Article* の内容を、gnus-article-buffer にもコピー
土屋さん> するように変更すると、とりあえず動くようになりました。UTF-8
土屋さん> decoding 問題の方に、悪影響が出ていないか、動作確認をお願い
土屋さん> します。
土屋さん、どうもありがとうございます。
確認した結果まったく問題無いようなので、`t-gnus-6_15' 枝にも反映
しました。
--
Katsumi Yamaoka <yam...@namazu.org>
山> 確認した結果まったく問題無いようなので、`t-gnus-6_15' 枝にも反映
山> しました。
と思ったら、ミスを見つけてしまいました。
(with-current-buffer (set-buffer gnus-original-article-buffer)
(gnus-request-article-this-buffer ARTICLE GROUP))
という状況になると、記事内容が重複してしまうのです。
;; しかも、nnvirtual なグループでこの条件が満たされるらしい…。つまり、
;; gnus-namazu-search() で作成したグループでそうなるんですねえ。
対策コードを追加しましたので、update をお願いします。