Re: String encoding problem (WSMethodInvocation)
Re: String encoding problem (WSMethodInvocation)
- Subject: Re: String encoding problem (WSMethodInvocation)
- From: Nick Toumpelis <email@hidden>
- Date: Tue, 29 Jan 2008 11:26:45 +0200
It seems to me that the problem here lies with the actual encoding
used in the invocation, rather than the designated character set. Both
issues may be present though. I haven't used SOAP yet and it is very
likely that the SOAP implementation has a different problem altogether.
As far as I can tell, in the case of XML-RPC, implementing a different
serialization method for strings is the solution. I'm not sure whether
this affects the encoding designation in the header in any way.
Thanks,
Nick
P.S. Apple has to respond to these, at some point... The issue
submitted by Stéphane is more severe than the one I've encountered.
On 29 Ιαν 2008, at 12:10 ΠΜ, Nir Soffer wrote:
On Jan 25, 2008, at 11:22, Nick Toumpelis wrote:
I assumed that something like this might be the problem, so I
overode the serialization procedure with
WSMethodInvocationAddSerializationOverride. And it works (more or
less).
It appears that there is an additional bug with the actual encoding
itself.
Nick
On 25 Ιαν 2008, at 10:06 ΠΜ, Stéphane Corthésy wrote:
rdar://problems/4792516
Sent on 19-Oct-2006
WebServicesCore: SOAP messages miss charset information in HTTP
header
Summary:
HTTP header in HTTP requests generated by WebServicesCore, for
kWSSOAPBodyEncodingStyle, miss a 'charset=utf-8' key-value in the
content-type header.
Steps to Reproduce:
1) Using WebServicesCore, create a web invocation, with debug
information on.
2) Send the invocation, and wait for result.
3) When receiving results, look at the outgoing headers, in the
result dictionary.
Expected Results:
The header value for 'content-type' should contain the charset
used to encode the body, because body is encoded in UTF-8, and
without any information in the header, all receivers will decode
body using ISOLatin1 charset.
Actual Results:
If sent body contains non-ASCII characters, body is wrongly
decoded using ISOLatin1.
Apple never replied to that bug report. Status is still set to
open, though it's 15 months old.
According to this:
http://www.rfc-editor.org/rfc/rfc3023.txt 3.1 Text/xml Registration
If a charset is not specified, the receiver should use us-ascii,
which explain your issue.
Nick Toumpelis :: Software Developer :: BEng (Wales), MSc (Manchester)
Thessaloniki, Greece :: email:email@hidden :: AIM:email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden