Using \u is wrong in the first place in json_escape, because a command line terminal is always 8 bit (if you don't have some esoteric system), so let the users use whatever encoding they want, be it UTF-8 or ISO-8859-1. But then the parse function in univalue_read.cpp is wrong, because it is no unicode. This patch fixes the problem and transparently sends just the bytes the user specified on the command line to the server.
The change is backward compatible as far as the server is concerned. The new client can only communicate with a new server, if it uses non-ASCII characters, but this should be no problem most of the time.
Test transaction, which shows the right clam speech string, used on a terminal with UTF8 encoding (because khashier uses UTF8) :
http://khashier.com/tx/3b0fd2ecba309e4d5f24b007d9972f2841f4d36aa7a613561be5b648dcffc198
PS: I tested the patch only for Linux (a 64 bit system), not for Windows. Maybe there was a reason in Windows to encode it with \u. I can test the Qt client as well, but have to setup the build environment for it first. Would be cool if someone could enter Chinese etc. in the Qt client in the clam speech field. But I think for compatibility, the format of the speech field in the transaction should be always UTF8.
PPS: I reverted the UTF8 patch, because it broke other RPC clients (like the clamcoin nodejs library), which uses JSON libraries that don't parse "\x". According to RFC4627 there is no "\x". But if I interpret the RFC right, the right solution might be to just send UTF8 bytes instead of trying to encode them as \uxxxx. The clamspeech parameter bugfix for sendtoadress is still valid.
Using \u is wrong in the first place in json_escape, because a command line terminal is always 8 bit (if you don't have some esoteric system), so let the users use whatever encoding they want, be it UTF-8 or ISO-8859-1. But then the parse function in univalue_read.cpp is wrong, because it is no unicode. This patch fixes the problem and transparently sends just the bytes the user specified on the command line to the server. The change is backward compatible as far as the server is concerned. The new client can only communicate with a new server, if it uses non-ASCII characters, but this should be no problem most of the time. Test transaction, which shows the right clam speech string, used on a terminal with UTF8 encoding (because khashier uses UTF8) : http://khashier.com/tx/3b0fd2ecba309e4d5f24b007d9972f2841f4d36aa7a613561be5b648dcffc198
PS: I tested the patch only for Linux (a 64 bit system), not for Windows. Maybe there was a reason in Windows to encode it with \u. I can test the Qt client as well, but have to setup the build environment for it first. Would be cool if someone could enter Chinese etc. in the Qt client in the clam speech field. But I think for compatibility, the format of the speech field in the transaction should be always UTF8.
PPS: I reverted the UTF8 patch, because it broke other RPC clients (like the clamcoin nodejs library), which uses JSON libraries that don't parse "\x". According to RFC4627 there is no "\x". But if I interpret the RFC right, the right solution might be to just send UTF8 bytes instead of trying to encode them as \uxxxx. The clamspeech parameter bugfix for sendtoadress is still valid.