[
https://issues.apache.org/jira/browse/GUACAMOLE-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman reopened GUACAMOLE-2268:
--------------------------------------
As reported on the mailing list, the build is broken on libvncclient versions
prior to 0.9.15, which do not contain the UTF8 functions.
> VNC: add UTF-8 (Unicode) support.
> ---------------------------------
>
> Key: GUACAMOLE-2268
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2268
> Project: Guacamole
> Issue Type: Improvement
> Components: VNC
> Reporter: Bradley Bennett
> Priority: Minor
> Fix For: 1.6.1 [staging]
>
>
> The {*}libvncserver *client library supports UTF-8 clipboard text through
> *SendClientCutTextUTF8(){*}, but Guacamole does not currently use it. This
> supplements {*}SendClientCutText(){*}, which only supports ISO-8859-1 text.
> UTF-8 supports multibyte sequences. For example, Japanese characters commonly
> use 3 bytes each. Without Guacamole support for SendClientCutTextUTF8(),
> sending the 5-character Japanese word for “hello”:
> {code:java}
> こんにちは
> {code}
> with UTF-8 clipboard encoding selected, this yields:
> {code:java}
> ã) ã( ã)«ã)¡ã)-{code}
> Each byte of the multibyte UTF-8 sequence is interpreted as a separate
> ISO-8859-1 character.
> With the default ISO-8859-1 clipboard encoding selected, pasting yields:
> {code:java}
> ?????{code}
> Each Japanese character is replaced with the unknown/replacement character
> because ISO-8859-1 cannot represent Japanese text.
> With SendClientCutTextUTF8() support implemented, and UTF-8 encoding
> selected, pasting will yield the actual Japanese characters.
> Support will also be added for logging the VNC protocol version of security
> type when a connection is established.
> {code:java}
> Connected using RFB 3.8, security: VeNCrypt (19), sub-security:
> VeNCrypt/TLSVNC (258). {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
