Hello Francois, And of course do not forget to escape the escape sequence itself if it is already present in your original data.
You could also do a two-pass sending, first one send a position table of delimiters located in your data, other send binary data with delimiter replaced with #0. Once received you simply refill the #0#0 according to position table. To give an idea, I counted #13#10 in different kind of files and a 47MB installshield EXE contained 1521 sequences, a 15.8MB TIFF contained 300, a 4.3MB PDF contained 170, a unknown 8.4MB .DAT file contained 294. So if you send a first ascii position table in HEX 8 DWORD records it would just add less than 10KB of data to total sending for 50MB. regards. >> OK, I'll try the Base64 method.... FP> It is more efficient to use a simple escape mechanism. FP> Let's say your delimiter is #13#10 (this is handy if you test with telnet). FP> The select another character which is likely to be infrequently use in your FP> binary data. Let's assume it is #127. FP> Then it is enough to scan all you binary data, check for #13, #10 or #127 FP> characters and replace them by - respectively - #127 'M', #127 'J' and #127 FP> '/' (or any other couple you like). FP> The nul char is also frequently escaped. Si replace #0 by #127 '0'. FP> At the other side, just do the reverse: scan data to find #127, then examine FP> next character to know which one to use instead of the pair which is the FP> 'escaped value'. FP> -- FP> [EMAIL PROTECTED] FP> http://www.overbyte.be -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
