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
We're currently using UTF-8, UTF-16 (Windows) and ISO 8859-1 (VNC clipboard) that I know of. There may be others - if you can think of any please comment on this issue.
At some stage post v1.x I'll do a quick analysis of what we are using where, and what we need to do with all of these. Whether we can do this stuff locally, or whether we should be using something like ICU isn't yet clear to me at the moment.
This was reported by @howudodat on Gitter
Pasting this string from Windows into an RDP session results in the clipboard temporarily locking up:-
Simple Test.😥
Trying to view the string with
xclip -o -selection clipboard -t STRING
orxclip -o -selection clipboard -t UTF8_STRING
results inxclip
hanging.An analysis shows that the string from windows breaks down as the following UTF-16 characters in the CB_FORMAT_DATA_RESPONSE:-
This string is passed to
g_wcstombs()
:-xrdp/sesman/chansrv/clipboard.c
Line 1351 in 42be576
which returns -1
If the string is pasted without the emoji, the paste succeeds.
Problem seems to be that the encoding of U+1F625 as the surrogate pair "0xd83d 0xde25" is a windows extension :-
https://en.wikipedia.org/wiki/UTF-16#Code_points_from_U+010000_to_U+10FFFF
A fix to this will avoid use of the
wcstombs()
andmbstowcs()
callsEdit: 2023-10-20. Surrogate pairs are NOT a Windows extension - they're part of the UTF-16 spec.
The text was updated successfully, but these errors were encountered: