Special characters Windows/Linux

[Alex_in_t_Veen]

Hi, we are currently using XData to send data from a Windows client application to a XData server. When running the server on Windows characters like á è ü etc are passed on correct, however when running the server on Linux the special chars aren't processed right.

This is probably caused by the client, which has to send the request in UTF-8 encoding (and is seems to do so in ANSI at the moment since TEncoding.UTF8.GetString(Context.Request.Content) gives "weird" chars and TEncoding.ANSI.GetString(Context.Request.Content) gives the correct ones).

How do we setup the client so it sends UTF-8 request to the server? Several options were tried without any luck so far.

[wlandgraf (Wagner Landgraf)]

Hi, can you please send more information about the client?

What is the client written with? How are you currently sending the allegedly ANSI content to the server? What is the existing code/tool you are using?

In theory, as you said, it's up to the client. It should simply send the content as UTF-8.

[Alex_in_t_Veen]

Hi @wlandgraf, our client is also written in Delphi and uses the TXDataClient in combination with an ILMS10XDataService to send all kinds of objects and lists to the Xdata server.

On the client side our objects are classes containing several fields of the default Delphi string (which is unicode as far as we know). The fields are set using Dataset.FieldByname().AsString.

As mentioned before we tried changing the field properties from string to utf8string and some others, but this gave us similar result. (Using UTF8String a JSONconverter error showed up)

[wlandgraf (Wagner Landgraf)]

@Alex_in_t_Veen

The fields are set using Dataset.FieldByname().AsString

How is that even possible, since XData doesn't use datasets?
Can you please be more specific and provide the code you are using? The method you are using, what is the exact content with the wrong encoding, etc.?

[Alex_in_t_Veen]

Hi @wlandgraf, sorry if things are not clear yet.

First we have our objectclass declaration:

TCountries = Class
protected
private
Fcountriesid : Int64;
Fimportid : Int64;
Fcode : string;
Fdescription : string;
public
property countriesid : Int64 read Fcountriesid write Fcountriesid;
property importid : Int64 read Fimportid write Fimportid;
property code : string read Fcode write Fcode;
property description : string read Fdescription write Fdescription;

At some point such an object is created and populated:
Country := TCountries.Create;
Country.landenid := 0;
Country.importid := 0;
Country.code := Wnet.AllCountrycodes[nCounter].Code_3;
// We tried multiple ways of setting the description
Country.description := Data.ADS.FieldByName('Description').AsString;

And "finally" it will be send to the XData server:
LMSClient := TXDataClient.Create;
Try
LMSClient.Uri := cServer;
LMSXDataService := LMSClient.Service;
LMSXDataService.Countries(Country); // Sends the data to the XData server
Finally
LMSClient.Free;
End;

I hope this will clarify our client situation

[wlandgraf (Wagner Landgraf)]

@Alex_in_t_Veen

Country.description := Data.ADS.FieldByName('Description').AsString;

Have you checked if the data is correct when you set Country.description property?
My guess is that the string is already wrong when you set the description property, so it's not a problem with XData sending wrong data, but reading from the dataset.

[Alex_in_t_Veen]

Hi @wlandgraf, just a heads up. A co-worker seems to have found the problem. As you mentioned XData wasn't causing the problem. The issue is being caused on the server and and was not (direct) client related.
Seems like Embarcadero hasn't fully updated the Firedac source code (yet).

They missed out on adding LINUX as an OS so it seems (from FireDAC.Stan.Param.pas) :

procedure TFDParam.SetAsStrings(AIndex: Integer; const AValue: String);
begin
if not (FDataType in [ftString, ftFixedChar, ftWideString, ftFixedWideChar]) then
FDataType := {$IF DEFINED(IOS) OR DEFINED(ANDROID)} ftWideString {$ELSE} ftString {$ENDIF};
Values[AIndex] := AValue;
end;

When using the setting then Param AsWideString, things are working as expected.

[wlandgraf (Wagner Landgraf)]

Thank you for the follow up.