On Mon, 17 Aug 2009, Adam Tkac wrote:
+Clients and servers are encouraged to send UTF-8 strings unless that +particular part of the protocol mandates another encoding. They should +however be prepared to receive invalid UTF-8 sequences at all times. +Such sequences should be handled gracefully by e.g. stripping the +invalid portions or trying to interpret the string using common +encodings such as ISO 8859-1 or Windows code page 1252. +Hm, it is easy to say "invalid portions of UTF-8" string but it is _very_ hard to create an algorithm which will determine if a part of string is valid or invalid. If you are using UTF-8 users might create strings with "obscure" characters. I think this kind of heuristic should not be included in protocol. If an implementation sends strings in, for example, the ISO 8859-* encoding it will end with crippled characters but we have to live with it, there is probably no algorithm to solve this problem.
+1. That part needs to be rephrased.Regards, ---
Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.com Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00
------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
