On Mon, 17 Aug 2009, Adam Tkac wrote:
Yes, something like that sounds better for me. I attached improved (I
hope it is an improvement ;)) specification of strings.
If a string has errors according to UTF-8, try to treat it as ISO 8859-1
and then as Windows-1252. If the string can be converted to none of
UTF-8, ISO 8859-1 or Windows-1252 then decision how to handle the string
depends on implementation.
Personally I think the best solution would be to avoid mentioning any
alternate encoding whatsoever, especially since there's no evidence that
the encodings mentioned above actually are in use.
I also don't want the protocol to require clients to support both UTF-8,
ISO-8859-1, and Windows-1252, but since "try" is used rather than SHOULD
or MUST, I guess this is OK with me.
There's one strange thing with the proposed text, however: A
interpretation of an octet sequence as ISO-8859-1 or Windows-1252 can
always be done; it can never fail. Only UTF-8 can be invalid, since it's a
multi-octet encoding with specific rules. So it really doesn't make sense
to, say, try UTF-8, Latin1, and then 1252 in order. In that case, 1252
would never be used.
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
