Ahh, sry guys. When it comes to the second page, I often miss that there were new answers. I didn't want to ignore you. Please let me warm up this post again.
My last message said, that I can send utf8 as is, which was only right for unicode letters from u+0000 to u+00FF. I tested the turkish letter "ğ" which is u+011F and the PHP server wasnt able to read it.
And at this point I still dont understand. I can send "ö" as UTF8 "ö" to the server, the server can use for example utf8_decode() to decode it to ISO-8859-1 and then display it as "ö".
However, if I send "ğ" as UTF8 "ÄŸ" to the server, it cant translate it to ISO-8859-1, because u+011F is outside of u+00FF (not in the table). How is the server supposed to get a readable "ğ" (as wxWidgets and this forum can), which format is it supposed to be? Plain unicode codepoint?
Or is the readable "ğ" just "unescaped utf8" and "ÄŸ" is "escaped utf8" and we need to find something to convert the escaping, but not the encoding?
Point is, its not just for displaying. A sign like this in a password causes a missmatch for the two presentations of it...
A second point:
The chilkat method to send my https request takes a " const char * " byte array as body input. But my input is a wide char. Examples:
Code: Select all
wxString s("\u00F6");
wxMessageBox("s: " + s); //out: s: ö - is const char *
wxString s1("\u011F");
wxMessageBox("s1: " + s1); //out: s1: ? - is no const char *
wxString s2(_T("\u011F"));
wxMessageBox("s2: " + s2); //out: s2: ğ - is const wchar_t *
I read my data from a UTF8 formatted file. How can I convert that utf8 data to a "const char *" byte array without loosing the wide chars?
ok, now your points:
doublemax wrote:I'd need more information to be sure, but the resulting string contains '%' characters, if you use it for printf-like functions, these will be interpreted as format identifiers. In a debug build, you should get an assert in that case, not a plain crash.
Tbh for this project, I develop in release. I do not have wxWidgets292 debug build and thought I wouldn't need it. A print like functions causes a crash in this case. But thats my fault.
I guess if we can clarify my problems above, I would use and modify your function to generate the format the server needs.
doublemax wrote:I'm not sure what you mean, there is nothing special wxWidgets' UTF8 encoding.
I was reffering to the escaped or unescaped utf8 formats, which can be found in the net, but I couldn't find a good explanation for it.
At the moment I think I understood: If I can read UTF8, it is "unescaped utf8" and if it has a presentation like "ÄŸ" it is "escaped utf8".
So internally, without the effort to try to make it readable, unescaped utf8 is the real sign, while escaped utf8 is the unicode codepoint (like for c++: \u011F).
Is that about right?
ONEEYEMAN wrote: ↑Fri Jul 12, 2019 2:05 pmWhat about {wx}cURL?
I sometimes used curl.exe as a console test enviroment, but again if I use curl.exe and https it tells me:
Code: Select all
curl: (1) Protocol "https" not supported or disabled in libcurl
Does wxCurl support https? I couldn't find an info at a quick glance.
evstevemd wrote:I dunno about wxJSONValue but iy you think it is library issue try
wxSimpleJSON
I might have a look on it. But I think it is the json format per se.
A simple json would be
If I make a string out of that, it automatically generates escape signs:
I just thought, that might cause a problem here.
Enough text. Thanks!
Natu