C# Xamarin euro sign

We have a Delphi server with remoting SDK.
Besides a Delphi client, we also have two c# clients.
One client, is a WPF client which is used for windows clients on a touch screen, the other one is a Xamarin client.

We have a complextype object, with a field “Description” of the type AnsiString. This contains a string with a euro sign (“foo € bar”)
In the Delphi and WPF client, the data is received in the correct way.
However, in the Xamarin client, it’s received (when I expect the object, right after I received the data from the server) as a question mark (“foo ? bar”).

The Xamarin project, uses a .NET standard library where the connection and data retrieval is done.
I have the exact same setup in the WPF project.

We use a IpSuperTcpClientChannel with a BinMessage to communicate to the server.

Any clue what can cause this problem?

Is the parameter or field used to pass this string back declared as WideString or 8-bit Ansi String? In there latter case, it will only be safe to send 7-bit ASCII characters, unless yo can be sure both client and server use the same default code page (which it seems Xamarin might not be doing).

I would recommend to use WideString for anything, these days.

I return a complextype, which contains a AnsiString field

Ok, that’s your problem then. Essentially you just got lucky s far that all your systems were on the same code page.

Two options to fix this:

(a) change the field to WideString — which will break wire compatibility, so you’d need to update all clients and the server to match, in one go.
(b) change the field to Utf8String — which won’t change wire compatibility but will break “logical” compatibility of what older clients will expect in strings. Essentially tally, and clients won’t know to decode the Utf8 and might shoe garage characters instead — but then, that’s really no more broken than it already is, if you’re sending above-7-bit characters ;).

I suggest going for option (b).

Actually, not exactly the same. The WPF project runs on desktop, so .NET Framework can read locale and default code page used on the host. So it is able to correctly convert received 8-bit value to a UTF-16 char representing euro sign. That said, if/when the client host will have different code page settings than the server host, WPF and Delphi clients will receive incorrect values instead of as well .

Xamarin app cannot read the required code page, so the string value there cannot be properly decoded from the very beginning.

Solution is to help the binary serializer to decode the value. The BinMessage instance you use has a property named DefaultStringEncoding. Set it to the value matching the code page used by the server app host.

The easiest way to do this is to create a console app and check there value of this property: https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.windowscodepage?view=netframework-4.8

Them you’ll need this code page value to create text encoding object using this constructor https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.-ctor?view=netframework-4.8#System_Text_Encoding__ctor_System_Int32_ . Then assign this value to the message’s DefaultStringEncoding property and the issue should go away.

Note 1: I would strongly recommend to set this property in the WPF app as well. Otherwise you’ll have issues with it once someone will start it using a different locale (and thus a different code page)

Note 2: If your server also exposes Data Abstract service(s) and the schema contains AnsiString-typed fields, then you’ll need to set similar property of the Bin2DataStreamer as well.

Changing it to WideString solves the problem indeed. I tried to set the DefaultStringEncoding, but this didn’t worked