You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When connecting to a TightVNC server, clipboard sync is still in latin-1 and ends up with question marks or garbage text.
To Reproduce
Connect to a TightVNC server, and try to copy unicode text from or to the remote device.
Expected Behavior
Unicode text remains the same across clipboards.
Logs/Backtraces
n/a
Your environment (please complete the following information):
OS and version: Arch Linux x86_64, remmina or krdc with libvncserver 0.9.14
Compiler and version: GCC 13.2.1
Additional context
TightVNC supports UTF-8 since version 2.8.53. Copied from its changelog:
Added support for Unicode clipboard transfers (UTF-8). The latest public version of the standard RFB protocol (3.8) does not support Unicode text, so we implemented this via a new TightVNC protocol extension. This feature will work when supported at both ends of the connection.
So probably an additional protocol extension is needed for this?
I have looked through its source code and found something that should be related:
The text was updated successfully, but these errors were encountered:
libvncserver and tigervnc implements the Extended Clipboard pseudo-encoding (from UltraVNC in 2010) which supports UTF-8. It looks like tightvnc has introduced yet another cut-text protocol. The Extended Clipboard pseudo-encoding does not introduce new client/server message numbers like in the screenshot, but instead modifies the behaviour of 3/6.
Describe the bug
When connecting to a TightVNC server, clipboard sync is still in latin-1 and ends up with question marks or garbage text.
To Reproduce
Connect to a TightVNC server, and try to copy unicode text from or to the remote device.
Expected Behavior
Unicode text remains the same across clipboards.
Logs/Backtraces
n/a
Your environment (please complete the following information):
Additional context
TightVNC supports UTF-8 since version 2.8.53. Copied from its changelog:
So probably an additional protocol extension is needed for this?
I have looked through its source code and found something that should be related:
The text was updated successfully, but these errors were encountered: