Jump to content

Cannot Transfer Higher values like Chr(65470)

Recommended Posts



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);
  FRcvdLine:WideString ;  // AnsiString does not work either
  FRcvdLine := TSSLWSocket(Sender).ReceiveStrA  ;
Hi ??



Share this post

Link to post

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

To send anything, use Send like this:

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


Share this post

Link to post

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  ;

Share this post

Link to post

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. 




Share this post

Link to post

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.

Share this post

Link to post

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.


Share this post

Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now