Den 2009-06-04 13:34 skrev Pierre Ossman:
> On Fri, 29 May 2009 10:51:14 +0200 Pierre Ossman wrote:
>
>> Has anyone done a survey of how implementations treat this extension
>> and the name field in the server init? If there are no existing
>> implementations that prevent it, then I'd like to specify UTF-8 for at
>> least the extension.
>>
>
> I've been digging through the RealVNC source and string handling is
> just a complete clusterfuck. The implementation uses the all too
> familiar approach of sticking one's head in the sand and hoping that
> all encoding issues will just sort themselves out.
>
> This is the reality of things:
>
> 1. Unix server
>
> Uses whatever encoding the parameters are in when invoking Xvnc or
> vncconfig. Since most Linux distributions these days use UTF-8, so the
> desktop name will in turn mostly be UTF-8.
Ok, so ASCII compatible.
> 2. Windows server
>
> Uses the ACP (Active Code Page). Can really be a lot of things, though
> most often cp1252 (almost 8859-1) in the west.
I think all ACPs are supersets of ASCII.
> 3. Unix client
>
> Passes the string unmodified to XSetName(). Looking at the xlib
> reference documentation, this uses "Host Portable Character Encoding"
> which in turn uses a lot of weasel wording and doesn't really define
> that much at all. Looking at the ICCCM though and how xlib
> implementations behave in practice, this encoding is 8859-1.
>
> IOW, the Unix client assumes the name is in 8859-1.
s/XSetName/XStoreName/ ???
On the contrary, it's rather clearly specified as "the set of
graphic characters in 7-bit ASCII plus [space, tab and newline]".
The graphic characters being:
a..z A..Z 0..9 !"#$%&'()*+,-./:;<=>?...@[\]^_`{|}~
However, what values these characters have is not specified. Assuming
something ASCII compatible is the only sane choise. My point is that
ASCII is much closer than ISO 8859-1.
> 4. Window client
>
> Like the Windows server, it assumes that things are in ACP.
I still think all ACPs are supersets of ASCII :-)
> So to summarise, the only part that has some idea of what encoding it
> wants is the Unix client. Everything else is basically random and
> dependent on the system settings. ASCII should be fairly safe to use,
> but I'm not 100% sure of even that.
>
> Given that most of the systems (except for the Unix server) have been
> using 8859-1 (or cp1252, which is close) in practice, I'd say we define
> the desktop name to be 8859-1 and nothing else.
I say we define it as ASCII and have existing code continue working. If
you want anything else, use the DesktopName encoding (which I think we
should define as UTF-8).
Cheers,
Peter
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
