By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,786 Members | 1,142 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,786 IT Pros & Developers. It's quick & easy.

SoapException character encoding

P: n/a
Hi,

My native language is Icelandic and I´m making a web service that returns
results that contain many Icelandic characters. This works fine, however,
when I return a soap:Fault, the string in the faultstring element has the
Icelandic characters encoded like "réttindi", where "é" is an
Icelandic accented character.

Does anyone know why? If so, how do I deal with this?

Best regards,
Dadi.
Nov 23 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Hi,

The reason for it being XML escaped is that those characters are not
allowed 'natively' in XML text nodes. (just like the < changes into
&lt;). The encoding you see here is the 'Unicode Character Encoding'
being used.

réttindi => r + UniCodeChar(223) + ttindi

On the other side (client), this text will be XML Unescaped. Therefore
this format is only 'on the wire'.

As long as the Client can display those characters, there should be no
problem.

Hope this helps,

Marvin Smit.

On Wed, 7 Sep 2005 04:35:08 -0700, "Dadi"
<Da**@discussions.microsoft.com> wrote:
Hi,

My native language is Icelandic and Im making a web service that returns
results that contain many Icelandic characters. This works fine, however,
when I return a soap:Fault, the string in the faultstring element has the
Icelandic characters encoded like "réttindi", where "é" is an
Icelandic accented character.

Does anyone know why? If so, how do I deal with this?

Best regards,
Dadi.


Nov 23 '05 #2

P: n/a
Hi Marvin,

I´m currently testing this web service with NUnit and my assertion fails due
to this problem. By your account, should the characters not be unescaped in
the test too?

In the meantime I´m using HttpUtility.Decode to get my test to pass.

TIA,
Dadi

"Marvin Smit" wrote:
Hi,

The reason for it being XML escaped is that those characters are not
allowed 'natively' in XML text nodes. (just like the < changes into
<). The encoding you see here is the 'Unicode Character Encoding'
being used.

réttindi => r + UniCodeChar(223) + ttindi

On the other side (client), this text will be XML Unescaped. Therefore
this format is only 'on the wire'.

As long as the Client can display those characters, there should be no
problem.

Hope this helps,

Marvin Smit.

On Wed, 7 Sep 2005 04:35:08 -0700, "Dadi"
<Da**@discussions.microsoft.com> wrote:
Hi,

My native language is Icelandic and I´m making a web service that returns
results that contain many Icelandic characters. This works fine, however,
when I return a soap:Fault, the string in the faultstring element has the
Icelandic characters encoded like "réttindi", where "é" is an
Icelandic accented character.

Does anyone know why? If so, how do I deal with this?

Best regards,
Dadi.


Nov 23 '05 #3

P: n/a
Hi,
Im currently testing this web service with NUnit and my assertion fails due
to this problem.
Does this fail on the general exception being expected or the specific
message in the fault?

Since NUnit is a .Net implementation, and therefor uses the CLR
defined characters & strings (very close to UNICode 3.0), you will
have to use the "original fault message" in your ExpectedException
attribute. What i mean by this is the "native way of writing that text
in .Net".

r + (ALT+223) + ttindi = "rttindi"

(Here we see that the newsgroups do not have the correct codepage to
display the character. In binary format however, this is still the
Chr(223). Unicode however generally uses more than 1 byte to encode a
character.

The easiest thing to do probably is; Generate the error using a
sample/test app. Grab the XML Unescaped text from the fail and
copy-paste that in your NUnit ExpectedException attribute.

In the meantime Im using HttpUtility.Decode to get my test to pass.
Although it obviously circumvented your issue, it is not the
appropriate API for this. The string we're discussing is XML escaped,
not HTTP encoded. If you retrieve the fault info (message) from the
exception, it will be XML unescaped.

When using this, the exception class on the client side will have the
correct text in the node.

Hope this helps,

Marvin Smit.
On Thu, 8 Sep 2005 03:14:03 -0700, "Dadi"
<Da**@discussions.microsoft.com> wrote:
Hi Marvin,

Im currently testing this web service with NUnit and my assertion fails due
to this problem. By your account, should the characters not be unescaped in
the test too?

In the meantime Im using HttpUtility.Decode to get my test to pass.

TIA,
Dadi

"Marvin Smit" wrote:
Hi,

The reason for it being XML escaped is that those characters are not
allowed 'natively' in XML text nodes. (just like the < changes into
<). The encoding you see here is the 'Unicode Character Encoding'
being used.

rttindi => r + UniCodeChar(223) + ttindi

On the other side (client), this text will be XML Unescaped. Therefore
this format is only 'on the wire'.

As long as the Client can display those characters, there should be no
problem.

Hope this helps,

Marvin Smit.

On Wed, 7 Sep 2005 04:35:08 -0700, "Dadi"
<Da**@discussions.microsoft.com> wrote:
>Hi,
>
>My native language is Icelandic and Im making a web service that returns
>results that contain many Icelandic characters. This works fine, however,
>when I return a soap:Fault, the string in the faultstring element has the
>Icelandic characters encoded like "rttindi", where "" is an
>Icelandic accented character.
>
>Does anyone know why? If so, how do I deal with this?
>
>Best regards,
>Dadi.



Nov 23 '05 #4

P: n/a
Hi,
Does this fail on the general exception being expected or the specific
message in the fault?
It fails when I do Assert.AreEqual("...réttindi...", soapException.Message).
Since NUnit is a .Net implementation, and therefor uses the CLR
defined characters & strings (very close to UNICode 3.0), you will
have to use the "original fault message" in your ExpectedException
attribute. What i mean by this is the "native way of writing that text
in .Net".

r + (ALT+223) + ttindi = "r¯ttindi"
You mean something like Assert.AreEqual("...r&amp;#233;ttindi...",
soapException.Message)?
(Here we see that the newsgroups do not have the correct codepage to
display the character. In binary format however, this is still the
Chr(223). Unicode however generally uses more than 1 byte to encode a
character.

The easiest thing to do probably is; Generate the error using a
sample/test app. Grab the XML Unescaped text from the fail and
copy-paste that in your NUnit ExpectedException attribute.
I don´t follow - the string I get from SoapException.Message _is_ XML
escaped, not unescaped?!!?
In the meantime I´m using HttpUtility.Decode to get my test to pass.


Although it obviously circumvented your issue, it is not the
appropriate API for this. The string we're discussing is XML escaped,
not HTTP encoded.


I realize this and I only resorted to this as a temporary solution.
If you retrieve the fault info (message) from the
exception, it will be XML unescaped.

When using this, the exception class on the client side will have the
correct text in the node.
The behaviour you describe here does not match my experience. We must not be
understanding each other here?

Thanks again,
Dadi.
On Thu, 8 Sep 2005 03:14:03 -0700, "Dadi"
<Da**@discussions.microsoft.com> wrote:
Hi Marvin,

I´m currently testing this web service with NUnit and my assertion fails due
to this problem. By your account, should the characters not be unescaped in
the test too?

In the meantime I´m using HttpUtility.Decode to get my test to pass.

TIA,
Dadi

"Marvin Smit" wrote:
Hi,

The reason for it being XML escaped is that those characters are not
allowed 'natively' in XML text nodes. (just like the < changes into
<). The encoding you see here is the 'Unicode Character Encoding'
being used.

réttindi => r + UniCodeChar(223) + ttindi

On the other side (client), this text will be XML Unescaped. Therefore
this format is only 'on the wire'.

As long as the Client can display those characters, there should be no
problem.

Hope this helps,

Marvin Smit.

On Wed, 7 Sep 2005 04:35:08 -0700, "Dadi"
<Da**@discussions.microsoft.com> wrote:

>Hi,
>
>My native language is Icelandic and I´m making a web service that returns
>results that contain many Icelandic characters. This works fine, however,
>when I return a soap:Fault, the string in the faultstring element has the
>Icelandic characters encoded like "réttindi", where "é" is an
>Icelandic accented character.
>
>Does anyone know why? If so, how do I deal with this?
>
>Best regards,
>Dadi.


Nov 23 '05 #5

P: n/a
Hi Dadi,

Just got back from 'another week abroad'.. hence the late reply.

Is there any change you can send the string (as it should be) in a
binary format? (not loosing the special char). This way i could try &
test some myself.

Marvin Smit.

On Thu, 8 Sep 2005 08:55:03 -0700, "Dadi"
<Da**@discussions.microsoft.com> wrote:
Hi,
Does this fail on the general exception being expected or the specific
message in the fault?


It fails when I do Assert.AreEqual("...rttindi...", soapException.Message).
Since NUnit is a .Net implementation, and therefor uses the CLR
defined characters & strings (very close to UNICode 3.0), you will
have to use the "original fault message" in your ExpectedException
attribute. What i mean by this is the "native way of writing that text
in .Net".

r + (ALT+223) + ttindi = "rttindi"


You mean something like Assert.AreEqual("...r&amp;#233;ttindi...",
soapException.Message)?
(Here we see that the newsgroups do not have the correct codepage to
display the character. In binary format however, this is still the
Chr(223). Unicode however generally uses more than 1 byte to encode a
character.

The easiest thing to do probably is; Generate the error using a
sample/test app. Grab the XML Unescaped text from the fail and
copy-paste that in your NUnit ExpectedException attribute.


I dont follow - the string I get from SoapException.Message _is_ XML
escaped, not unescaped?!!?
>In the meantime Im using HttpUtility.Decode to get my test to pass.


Although it obviously circumvented your issue, it is not the
appropriate API for this. The string we're discussing is XML escaped,
not HTTP encoded.


I realize this and I only resorted to this as a temporary solution.
If you retrieve the fault info (message) from the
exception, it will be XML unescaped.

When using this, the exception class on the client side will have the
correct text in the node.


The behaviour you describe here does not match my experience. We must not be
understanding each other here?

Thanks again,
Dadi.
On Thu, 8 Sep 2005 03:14:03 -0700, "Dadi"
<Da**@discussions.microsoft.com> wrote:
>Hi Marvin,
>
>Im currently testing this web service with NUnit and my assertion fails due
>to this problem. By your account, should the characters not be unescaped in
>the test too?
>
>In the meantime Im using HttpUtility.Decode to get my test to pass.
>
>TIA,
>Dadi
>
>"Marvin Smit" wrote:
>
>> Hi,
>>
>> The reason for it being XML escaped is that those characters are not
>> allowed 'natively' in XML text nodes. (just like the < changes into
>> <). The encoding you see here is the 'Unicode Character Encoding'
>> being used.
>>
>> rttindi => r + UniCodeChar(223) + ttindi
>>
>> On the other side (client), this text will be XML Unescaped. Therefore
>> this format is only 'on the wire'.
>>
>> As long as the Client can display those characters, there should be no
>> problem.
>>
>> Hope this helps,
>>
>> Marvin Smit.
>>
>> On Wed, 7 Sep 2005 04:35:08 -0700, "Dadi"
>> <Da**@discussions.microsoft.com> wrote:
>>
>> >Hi,
>> >
>> >My native language is Icelandic and Im making a web service that returns
>> >results that contain many Icelandic characters. This works fine, however,
>> >when I return a soap:Fault, the string in the faultstring element has the
>> >Icelandic characters encoded like "rttindi", where "" is an
>> >Icelandic accented character.
>> >
>> >Does anyone know why? If so, how do I deal with this?
>> >
>> >Best regards,
>> >Dadi.
>>
>>



Nov 23 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.