Re: [Wonder-disc] ERJavaMail encoding issues solved !

[<anj...@t-...>]

Hi Camille,

the errors Tatsuya is having are the same as those which led me to make =20=

the changes I sent you. And I agree with his point that one should be =20=

able to send english and japanese mail from the same app. (you could =20
probably do this by passing the property to the JavaMail session, but =20=

why bother...)

I didn't delve very far into that matter (and certainly didn't read any =20=

API docs) but I do know that I'm sending mails correctly with and =20
incorrectly without the charset info.

Cheers, Anjo

Am Donnerstag, 19.12.02 um 21:46 Uhr schrieb Tatsuya Kawano:

>
> Thanks Camille,
>
>>> As you can see, I made this one:
>>>     return new DataHandler (textContent, "text/plain");
>>>
>>> into this one:
>>>     return new DataHandler (textContent, "text/plain; charset=3D\""
>>>     + charset () + "\"");
>>
>> Yes, unfortunately I am not sure this is the correct way to do this.
>> JavaMail handles all this stuff automatically.
>>
>> I don't think it is not recommended to "force" the value of these
>> headers since (I am not sure) JavaMail will not parse them again =20
>> before
>> sending the message.  Rather, JavaMail will parse the message String
>> and try to find the right encoding using a heuristic.
>
> I'm not sure how well (or, if) JavaMail performs heuristic scans to =20=

> figure
> out the correct encoding for the message. The following Javadoc is =
very
> confusing, and I can't tell if it does the heuristic scan or not.
>
> http://java.sun.com/products/javamail/1.3/docs/javadocs/javax/mail/=20
> internet/
> MimeBodyPart.html#setText(java.lang.String)
> -----------------------------------------------------------
> public void setText(java.lang.String=A0text)
>              throws MessagingException
>
> Convenience method that sets the given String as this part's content, =20=

> with a
> MIME type of "text/plain". If the string contains non US-ASCII =20
> characters,
> it will be encoded using the platform's default charset. The charset =20=

> is also
> used to set the "charset" parameter.
>
> Note that there may be a performance penalty if text is large, since =20=

> this
> method may have to scan all the characters to determine what charset =20=

> to use.
>
> If the charset is already known, use the setText() version that takes =20=

> the
> charset parameter.
>
> Specified by:
> setText in interface MimePart
>
>
> See Also:
> setText(String text, String charset)
>
> =
-----------------------------------------------------------------------=20=

> -
> public void setText(java.lang.String=A0text,
>                     java.lang.String=A0charset)
>              throws MessagingException
>
> Convenience method that sets the given String as this part's content, =20=

> with a
> MIME type of "text/plain" and the specified charset. The given Unicode
> string will be charset-encoded using the specified charset. The =20
> charset is
> also used to set the "charset" parameter.
>
> Specified by:
> setText in interface MimePart
> =
-----------------------------------------------------------------------=20=

> -
>
> Japanese books suggest to use the latter method (with encoding =20
> specified).
> and I know I must do it with Japanese texts with JavaMail 1.3, =20
> otherwise
> I'll get ????? chars all over the place where Japanese texts should =20=

> be. ( ?
> Is used when Java API is not able to convert the character into the =20=

> target
> encoding)  Apparently, JavaMail uses system's default encoding =20
> (MacRoman on
> Mac OS X) for Japanese characters.
>
> I think JavaMail API 1.3 *specification* leaves the heuristic scan =20
> part to
> actual *implementations*. If you create your own mail library that =20
> complaint
> JavaMail API 1.3 specification, your implementation can provide
> comprehensive heuristic scan, or totally no scan but uses system's =20
> default
> encoding.
>
> Probably Sun's current implementation doesn't do the heuristic scan, =20=

> and if
> so, we'd better manually set the charsets.
>
>
>>> and Alyssa's Japanese book says this should make JavaMail to encode
>>> body text correctly and also put the right header. (The book:
>>> ISBN4-7980-0089-2)
>>
>> Oh, then it seems like I am wrong.
>>
>> If it solves the problem, that's great, but I must admit I am quite
>> worried about the introduction of charset-dependant stuff in =20
>> ERJavaMail
>> since JavaMail *should* handle it by default.
>>
>> Then, it means we don't need the "file.encoding" trick anymore.
>
> I agree; it's ideal, but JavaMail 1.3 doesn't automatically handle =20
> Japanese
> encoding at all.
>
> Meanwhile, I need to send both Japanese and English versions of the =20=

> emails
> from one WO app instance. If I set -file.encoding ISO-8859-1, it won't =
=20
> be
> able to encode Japanese messages anymore. If I set -file.encoding
> ISO-2022-JP, it may work with both Japanese and English messages, but =
I
> don't like to change file.encoding because it has a side effect to =20
> file I/O
> and String/byte[] conversions, and also I don't want our English uses =20=

> to
> receive messages encoded with ISO-2022-JP. (There will be no effect on =
=20
> ASCII
> chars but many mailer changes fonts to display when it see ISO-2022-JP =
=20
> on
> the header. Typical Japanese fonts are not good to display English
> characters in terms of legibility.)
>
> Also, ERXSession holds ERXMessageEncoding object that represents =20
> appropriate
> encoding for the session's current language. Its current rols is to =20=

> control
> browser encodings, but I can extend it to provide email encodings =
(like
> Travis suggested to us other day).
>
> Thanks,
> Tatsuya
>
> --=20
> Tatsuya Kawano
> New York  NY 10016
>
> E924 0D0D C0BF 3DCF 9F83  F2CD 20D1 8377 633A D84F
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Geek Gift Procrastinating?
> Get the perfect geek gift now!  Before the Holidays pass you by.
> T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
> _______________________________________________
> Wonder-disc mailing list
> Won...@li...
> https://lists.sourceforge.net/lists/listinfo/wonder-disc
>
>
>