Add UTF-8 clipboard support

Changes:

• Use rfbSendServerCutTextUTF8() to send clipboard text in UTF-8, falling back to Latin1 if UTF-8 is not supported.
• Implement setXCutTextUTF8() to handle received UTF-8 clipboard content.

CCBUG: 430339

Initial behaviour

issue

When using KRDC as VNC client connected to Krfb server, copying text containing 五十音, "Fifty Sounds" results in:

• The server clipboard syncs correctly
• The client clipboard shows two entries:
  • First entry: truncated as 五十音, "Fifty S
  • Second entry: correct

Reason

The bug exists in Krfb's RfbServer::krfbSendServerCutText:

rfbSendServerCutText(d->screen, text.toLocal8Bit().data(), text.length());

Should be corrected to:

rfbSendServerCutText(d->screen, text.toLocal8Bit().data(), text.toLocal8Bit().length());

Analysis:

• Each CJK character occupies 3 bytes in UTF-8. Therefore, length miscalculation causes 6 English characters to be truncated.
• KRDC sends clipboard to Krfb. Then Krfb receives it properly, but echoes back incorrect text. The mismatch results in duplicate entries on the client.

Changed behaviour

issue

After copying 五十音, "Fifty Sounds":

• The server clipboard becomes ???, "Fifty Sounds"
• The client clipboard shows two entries:
  • First entry: ???, "Fifty Sounds"
  • Second entry: correct

Reason

In KRDC Merge Request 12, Latin1 is used to encode and decode according to RFC 6143. Thus, each CJK character is converted to ? in Latin1.

Solution

LibVNCServer 0.9.15 supports UTF-8 clipboard on both server and client sides

• This Merge Request adds UTF-8 clipboard support to Krfb.
• KRDC Merge Request 182 adds client-side support.

Limitation

Krfb still echoes clipboard after receiving clipboard from the client. This still results in two clipboard entries on clients, if the client does not support UTF-8 clipboard.