Mailing-List: contact soap-dev-help@xml.apache.org; run by ezmlm
From: =?Windows-1252?Q?Mats_Forsl=F6f?= <mafoo@marcwell.se>
To: <soap-dev@xml.apache.org>
Subject: RE: Character encodings
Date: Tue, 7 Nov 2000 18:55:03 +0100
Message-ID: <000901c048e3$dff5fc30$bed409a4@majestix>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <006601c047da$a71bbf30$2b060e09@LANKABOOK>

Hi Sanjiva,

Since the UTF-8 algorithm supports Universal Character Set (UCS, equivalent
of Unicode) (ASCII 0-127 encoded as a single byte, ASCII 128+ encoded with
2-5 bytes) wouldn't the UTF-8 encodings be sufficient to support all
character combinations? Any reason not using it during a SOAP transfer?
(Maybe the SOAP spec says something about this but I haven't found it
though).

I may be missing some vital information here so I apologize if that is so or
this issue already has been discussed.

Regards,
Mats

-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: den 6 november 2000 11:17
To: soap-dev@xml.apache.org
Subject: Re: Character encodings


Hi Wada-san,

Do I understand correctly from your patch that you removed the UTF8
fixation from the code? That's the way it was originally I think, but
the UTF8 stuff was added because someone else pointed out it was
broken without it for something else. I don't recall the details.

If this patch doesn't affect any of the other I18n situations that
we've come across so far I'd like to commit it. Can someone who's
more I18n-aware than I am please check it out too? We really need
to identify at least one person who's keeping an eye on the code
(especially the v3 stuff) to make sure its I18n ok. Any volunteers?

Thanks,

Sanjiva.

----- Original Message -----
From: <wada@techno-infinitus.co.jp>
To: <soap-dev@xml.apache.org>; <mafoo@marcwell.se>
Sent: Sunday, November 05, 2000 3:07 AM
Subject: Re: Character encodings


> >> I am having trouble with character encodings in string parameters. I am
> >> trying to return a string containing umlaut characters, for example a
> >> char with code 214 is presented on the client side as two chars, 195
> >> and 8211.
>
> I had same trouble on japanese character and wrote a patch.
> this patch seems to works well for japanese character,and
> and I think this may be effective for other non-ascii characters.
>
> I hope this patch will help you.
>
> ----------------------------
> Masatake Wada
> wada@techno-infinitus.co.jp
> ----------------------------
>
>