Cannot Transfer Higher values like Chr(65470)

[AllanF 0]

Hi,

 

I am using ICS Components with Delphi Seattle to send text between Server to Client and vice versa.
But when using higher values like Chr(65470) the transfer does not happen correctly.

 

Server Side:  TSslWSocketServer 
  Client : TClientConnection;
  Client.SendText('Hi '+Chr(65445)+Chr(65470)+#13#10);

 

 

Client Side:  TSSLWSocket
procedure Tform_ClientSocket.SockClient_SsrvClientDataAvailable(Sender: TObject; ErrCode: Word);
var
  FRcvdLine:WideString ;  // AnsiString does not work either
begin
  FRcvdLine := TSSLWSocket(Sender).ReceiveStrA  ;
Hi ??

 

Regards
Allan

[FPiette 385]

TWSocket makes a conversion to AnsiString when using SendText. This is intended to implement higher level protocols.

To send anything, use Send like this:

var
    S : String;
begin
    S := 'Hi ' + Chr(65445) + Chr(65470) + #13#10;
    WSocket1.Send(PChar(S), Length(S) * SizeOf(Char));
end;

 

[AllanF 0]

In this way I can't seem to capture from the Client side using below method. Will the Client side code be different too ?

  FRcvdLine := TSSLWSocket(Sender).ReceiveStr  ;

[Angus Robertson 577]

Sockets stream single bytes, so each end needs to agree on whether single or double byte characters are being sent,  and handle them the same way. 

 

It is relatively unusual to send two byte characters over the internet, due to most western languages having a lot of one byte Unicode characters.  So generally conversion to UTF-8 is more efficient.  To avoid Delphi doing it's own code page conversions it is better to use TBytes to send and receive data, then functions IcsMoveStrinngToTbytes and IcsMoveTBytesToString with your desired CodePage. 

 

Angus

 

[FPiette 385]

ReceiveStr is aimed at AnsiString and use - by default - CR/LF (Two 8 bit ASCII characters, $0D and $0A) as delimiter.

 

I'm not sure that in Unicode, two consecutive bytes are not allowed to be $0D and $0A which are the CR/LF. Probably LineMode would also work if you use $0D, $00, $0A, $00 as LineEnd. But you'll have to provide your own routine to convert the Unicode received as an AnsiString correctly as Angus said above.

 

I have no idea what you are doing and so I cannot advice you better. You should explain what you intend to do. It looks you are designing your own protocol, quit unusually compared to most protocols (FTP, HTTP, SMTP, POP3 and many others) which use ANSI or UTF-8 or Binary or a combination of two.

[AllanF 0]

Since my application is already in use at few customer's installations and is running smoothly, I did not have the courage to make major changes.

It is actually the user passwords that I is saved in my databases with some basic encryption that were giving this problem.

Putting both your valuable advice together I did make a routine that goes thru the String prior to the Send operation, character by character and recognizes Ord(...) > 65375.

I am now converting that Password into Simple text and upon reaching destination reversing it again. Since my String's are made of a Tagged parts it is simple to extract the problem areas.

Thank You for the support.