Encoding problem

Remoting SDK
,
1

Hello, I’ve upgraded SDK from .NetFramework version to newest .NET CORE version (10.*).
After creating new Intf class/service iI’m issuing response encoding problems with polish characters. ‘ł’ letter is being ? char. I’ve tried to set DefaultStringEncoding to Win1250 on BinMessage, also set SerializerInstance to ‘new BinSerializer(Encoding.GetEncoding(1250))’ but problem appears as well. What can I do to solve this issue?

2

Are you using WideString or String type in your RODL (if your server is RODL based)?

8-bit Strings are inherently unsafe these days, unless you can be 100% sure both sides use there same default code page and/or you’re only transferring plain ASCII data (the latter you clearly are not ;), so I winkled recommend using Utf8String or 16-bit WideString (UTF-16), for all String parameters, if you can.

3

I’m using AnsiString as parameters

4

That’s your problem, then, yeah. Are you in a position where you can change to WideString (without wore compatibility with existing clients in the wild to worry about? If so, I suggest to do that.

If not, Changing to Utf8Stirng should be safe-ish, as it will remain wire-compatible with AniString, and the breakage you get for old clients wont be “worse” than the issues you have now with code page mismatches.

6

Setting SerializerInstance directly won’t have any effect (actually this property should not be used at all and will be removed in the next releases).

Setting DefaultStringEncoding is the way you need to use. However you need to use correct encoding to be able to read non-ANSI chars sent as 8-bit string. You need to set here encoding that is used by the client host.

The code that reads the string is similar to this:

		public String StringFromBuffer(Byte[] buffer, Encoding encoding)
		{
			return encoding.GetString(buffer, 0, buffer.Length);
		}

Additionally, .NET Core / .NET 5.0 / .NET 6.0 platforms doesn’t provide built-in support for non-default Encodings (including 1250) at all.

One have to reference the package System.Text.Encoding.CodePages and to register code page providers at app startup using code like

Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
7 
 var message =  new BinMessage
            {
                DefaultStringEncoding = Encoding.GetEncoding(1250),
                EnforceMaxMessageSize = false
            };

I’ve set DefaultStringEncoding to Win-1250 as shown, but problem with polish chars still occurs

8

This means that your client app uses code page different from 1250 to send the data.

What is the shar in question? How is it represented on the client side? Mean, which exactly char code is used to represent this char client-side?

9

Today I came across exactly the same problem as OP in my legacy application that uses RemObjects SDK version 9.7.115.1441. I created .NET 7 (.NET Core) client that connects to RODL based service written in Delphi 7 and provides Windows-1250 encoded string in its interface via AnsiString type.

I used the same code that targeted .NET Framework, but the encoding was mangled in .NET Core application. I quickly found out that .NET Core doesn’t support ANSI encoding by default and that I needed to register provider for that. However setting DefaultStringEncoding on BinMessage instance didn’t work for me.

After further debugging of disassembled code of RemObjects.SDK.dll I discovered that my Intf proxy class has its CloneMessage property initialized to true by default, which creates new instance of message based on original instance that was provided as an argument of proxy class constructor. At tis point I noticed that the value of DefaultStringEncoding property of cloned message instance was a System.Text.ASCIIEncoding.ASCIIEncodingSealed instance. After inspecting BinMessage.Clone() method I found out that DefaultStringEncoding is excluded from cloning process. When I changed proxy’s CloneMessage property to false, the encoding problems were gone.

I consider this a bug, because I think that BinMessage.Clone() should at least copy reference or even clone original encoding.

I didn’t check whether the problem persists in the latest version of RemObjects SDK.

Edit:
Now I see that the bug was filed recently in Converting RODL-based to code-first.

10

Hi,

you can use workaround from Converting RODL-based to code-first - #6 by EvgenyK for your legacy app