No "Content-Type:"

No "Content-Type:"

[Shigeki Uno]

Hi, I'm sorry to ask same question again.

I asked you about *Content-Transfer-Encoding* topic the other day and
No problems occured about Encoding MIME e-mails after that.  
(Thanks, Yamaoka-san.)

*But* I said that some e-mails causes *unintelligible sequence of
characters* and these e-mails are encoded by Quoted-Printable.  
I looked into them carefully today again and found that I made an error 
in reports. :-(
  
Following example is e-mail's headers which causes *unintelligible 
sequence of characters*(This is one of them).

***********************************************************************
To: netbsd@re.soum.co.jp
Subject: Re: boot: wd0a:netbsd: Unknown error: code 0 
In-reply-to: Your message of "Sun, 16 Jan 2000 22:52:20 JST."
             <200001161352.WAA10630@edge.sky.yamashina.kyoto.jp> 
Date: Mon, 17 Jan 2000 01:07:38 +0900
X-Gnus-Mail-Source: file:/var/mail/shigeki
Message-ID: <5016.948038858@pc-inoue.kusm.kyoto-u.ac.jp>
From: INOUE Yoshinari <inoue@kusm.kyoto-u.ac.jp>
Reply-To: netbsd@re.soum.co.jp
X-ML-Name: netbsd
Sender: jun@re.soum.co.jp
Errors-to: netbsd-request@re.soum.co.jp
X-Mail-Count: 04933
Precedence: bulk
X-list-help: <http://www.re.soum.co.jp/~jun/>
X-list-unsubscribe: <mailto:netbsd-request@re.soum.co.jp?subject=unsub>
X-list-subscribe: <mailto:netbsd-request@re.soum.co.jp?subject=subscribe>
Status:  U
X-UIDL: 948040444.5494.mail.mediawars.ne.jp
************************************************************************

I found *Content-Type: text/plain; charaset="iso-2022-JP"* line doesn't
exist. And others which cause *unintelligible sequence of characters*
also doesn't have *Content-Type* line. 

I can read it with _MEW_(Message in the Emacs World) without any problems
but, on the other hand, certainly can't read it with (P)Gnus :-(.  SIGH.

Any suggestions ? 

Thanks.
-- 
Shigeki Uno <mailto:shigeki@mediawars.ne.jp>

Re: No "Content-Type:"

[Kai Großjohann]

Shigeki Uno <shigeki@mediawars.ne.jp> writes:

> I can read it with _MEW_(Message in the Emacs World) without any problems
> but, on the other hand, certainly can't read it with (P)Gnus :-(.  SIGH.
> 
> Any suggestions ? 

The only thing I can think of is to use `e' to edit the article to add
the missing Content-Type header.

Maybe it would be nice to have a function which allowed you to view a
message as if it had a specific Content-Type header.

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: No "Content-Type:"

[Shigeki Uno]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> The only thing I can think of is to use `e' to edit the article to add
> the missing Content-Type header.

I gave it a try before but it was in vain.

Later,
-- 
Shigeki Uno <mailto:shigeki@mediawars.ne.jp>

Re: No "Content-Type:"

[Katsumi Yamaoka]

>>>>> In <86ogaleuse.fsf@mediawars.ne.jp> 
>>>>>	Shigeki Uno <shigeki@mediawars.ne.jp> wrote:

> I found *Content-Type: text/plain; charaset="iso-2022-JP"* line
> doesn't exist. And others which cause *unintelligible sequence of
> characters* also doesn't have *Content-Type* line.

You mean about the traditional japanese mails, I think.  The body has
japanese plain text (iso-2022-jp, 7bit), but the header does not have
no indicators for it.
The user option `gnus-group-charset-alist' helps such messages only
for news:

(defcustom gnus-group-charset-alist
  '(("^hk\\>\\|^tw\\>\\|\\<big5\\>" cn-big5)
    ("^cn\\>\\|\\<chinese\\>" cn-gb-2312)
    ("^fj\\>\\|^japan\\>" iso-2022-jp-2)
    ("^tnn\\>\\|^pin\\>\\|^sci.lang.japan" iso-2022-7bit)

[...]

but is does not work for mail groups.  So far I don't know how to fix
the problem.  Does anyone?

By the way, T-gnus or other Semi-gnusae can do that.  It is controled
by the variable `default-mime-charset'.
-- 
~{I=8T?KC@~} <yamaoka@jpl.org>

Re: No "Content-Type:"

[Kai Großjohann]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> The user option `gnus-group-charset-alist' helps such messages only
> for news:
> 
> (defcustom gnus-group-charset-alist
>   '(("^hk\\>\\|^tw\\>\\|\\<big5\\>" cn-big5)
>     ("^cn\\>\\|\\<chinese\\>" cn-gb-2312)
>     ("^fj\\>\\|^japan\\>" iso-2022-jp-2)
>     ("^tnn\\>\\|^pin\\>\\|^sci.lang.japan" iso-2022-7bit)
> 
> [...]

I'd be surprised if it only worked for news.  The regexes given here
only work for news, but there's nothing stopping you from having a
regex "^nnml:foo" in there...

kai
-- 
A large number of young women don't trust men with beards.  (BFBS Radio)

Re: No "Content-Type:"

[Katsumi Yamaoka]

>>>>> In <vafg0vxrr9h.fsf@lucy.cs.uni-dortmund.de> 
>>>>>	Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) wrote:

>> The user option `gnus-group-charset-alist' helps such messages only
>> for news:
>> 
>> (defcustom gnus-group-charset-alist
>>   '(("^hk\\>\\|^tw\\>\\|\\<big5\\>" cn-big5)
>>     ("^cn\\>\\|\\<chinese\\>" cn-gb-2312)
>>     ("^fj\\>\\|^japan\\>" iso-2022-jp-2)
>>     ("^tnn\\>\\|^pin\\>\\|^sci.lang.japan" iso-2022-7bit)
>> 
>> [...]

Kai> I'd be surprised if it only worked for news.  The regexes given
Kai> here only work for news, but there's nothing stopping you from
Kai> having a regex "^nnml:foo" in there...

Thanks to Kai, it really works.  Well, the method name is stripped
from `gnus-newsgroup-name' in the function
`gnus-summary-setup-default-charset', so we should set the value like
follows:

(setq gnus-group-charset-alist
      (cons '("^some\\.japanese\\.list$" . 'iso-2022-jp-2)
	    gnus-group-charset-alist))
-- 
~{I=8T?KC@~} <yamaoka@jpl.org>

Re: No "Content-Type:"

[Katsumi Yamaoka]

Oops,

>>>>> In <yosuu2kd80ry.fsf@jpl.org> 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> (setq gnus-group-charset-alist
>       (cons '("^some\\.japanese\\.list$" . 'iso-2022-jp-2)
> 	    gnus-group-charset-alist))

Sorry, the correct way is below:

(setq gnus-group-charset-alist
      (cons '("^some\\.japanese\\.list$" iso-2022-jp-2)
	    gnus-group-charset-alist))
-- 
~{I=8T?KC@~} <yamaoka@jpl.org>

Re: No "Content-Type:"

[Shigeki Uno]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> You mean about the traditional japanese mails, I think.  The body has
> japanese plain text (iso-2022-jp, 7bit), but the header does not have
> no indicators for it.

Yep.

> The user option `gnus-group-charset-alist' helps such messages only
> for news:
> 
> (defcustom gnus-group-charset-alist
>   '(("^hk\\>\\|^tw\\>\\|\\<big5\\>" cn-big5)
>     ("^cn\\>\\|\\<chinese\\>" cn-gb-2312)
>     ("^fj\\>\\|^japan\\>" iso-2022-jp-2)
>     ("^tnn\\>\\|^pin\\>\\|^sci.lang.japan" iso-2022-7bit)

I know this lisp...

> but is does not work for mail groups.  So far I don't know how to fix
> the problem.  Does anyone?

I'm disappointed...

> By the way, T-gnus or other Semi-gnusae can do that.  It is controled
> by the variable `default-mime-charset'.

I'll consider it to use T-gnus. ;-) 
(I used to be a user of semi-gnus. Semi-gnus is suitable for Japanese
Internet users, I think. But I'm not familliar with it , though.)

Thanks.
-- 
Shigeki Uno <mailto:shigeki@mediawars.ne.jp>

Re: No "Content-Type:"

[Michael Welsh Duggan]

Shigeki Uno <shigeki@mediawars.ne.jp> writes:

> I asked you about *Content-Transfer-Encoding* topic the other day
> and No problems occured about Encoding MIME e-mails after that.
> (Thanks, Yamaoka-san.)
> 
> *But* I said that some e-mails causes *unintelligible sequence of
> characters* and these e-mails are encoded by Quoted-Printable.  I
> looked into them carefully today again and found that I made an
> error in reports. :-(
>   
> Following example is e-mail's headers which causes *unintelligible
> sequence of characters*(This is one of them).

[...]

> I found *Content-Type: text/plain; charaset="iso-2022-JP"* line
> doesn't exist. And others which cause *unintelligible sequence of
> characters* also doesn't have *Content-Type* line.
> 
> I can read it with _MEW_(Message in the Emacs World) without any
> problems but, on the other hand, certainly can't read it with
> (P)Gnus :-(.  SIGH.

I also have had problems with malformed messages before.  Often I can
fix them by using washing functions.  For example, if I received a
quoted-printable iso-2022-jp article with a missing Content-Type
header, I would run the following washing functions:

`W q'  <- This should take care of quoted-printable
`C-u W M c iso-2022-jp RET' <- This should take care of the encoding

-- 
Michael Duggan
(md5i@cs.cmu.edu)

Solved (was: Re: No "Content-Type:")

[Shigeki Uno]

WOW. Filnally I've just succeeded in decoding unintelligible sequence of 
characters !!

'C-u W M c iso-2022-jp RET' works great ! I deeply appreciate your help.
And also I have to say thanks, Yamaoka-san and Kai.

Michael Welsh Duggan <md5i@cs.cmu.edu> writes:

> I also have had problems with malformed messages before.  Often I can
> fix them by using washing functions.  For example, if I received a
> quoted-printable iso-2022-jp article with a missing Content-Type
> header, I would run the following washing functions:
> 
> `W q'  <- This should take care of quoted-printable
> `C-u W M c iso-2022-jp RET' <- This should take care of the encoding

-- 
Shigeki Uno <mailto:shigeki@mediawars.ne.jp>