File transfer: support of Unicode and extended-length path

[jonathanpoelen]

Currently, uvnc uses what I believe to be the native code page, which is an 8-bit character set and therefore extremely limited (for example, CP1252). Since Windows 10, many Windows APIs support an extended path length of up to 32,767 characters, including null.

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

Current problem:

• If a file name contains a character that cannot be represented in the code page used, it is replaced by ? or ?? when displayed (🚀 is 4 bytes in utf16, so 2 characters in 8-bit encoding).
• Since ? is a prohibited character in a path name, it is not possible to transfer the file. In any case, the file will probably not be found.
• Navigating to a folder with a name that is too long results in an error. In fact, without special configuration, this is also the case with the file explorer. In addition, the limit for a folder name is smaller than MAX_PATH (247). So I haven't really tested this case.

[RudiDeVos]

This isn't a simple fix.
This almost rewriting the whole FT and with backward compatibility a huge job.
Nice addon but current no time for it

[jonathanpoelen]

For compatibility, I think the server can send a new contentType after FileTransferProtocolVersion and the client responds with the same. Since older versions of the client ignore unknown packets, this should work.

But I fully understand that this requires a lot of work.