From: <je...@fo...> - 2025-07-08 13:06:04
|
On 2025-07-08 07:40, John Selverian wrote: > I try this: > > const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL > = unescape("\U0001E05F"); > > and > > const FXString UnicodeXmlHTMLSpecialChars::UNICODE_SUBSCRIPT_y_SYMBOL > = \U0001E05F"; > > IN both cases I get this warning on compiling in VS2022: > > “warning C4566: character represented by universal-character-name > '\U0001E05F' cannot be represented in the current code page (1252)” > > and it displays as ‘??’ in all fonts I try. Please note, on Windows, wide characters are not as wide (only 16-bit). Thus, surrogate pairs would be needed to compile into 16-bit wide character strings; wchar_t on windows is 16-bit. This is partially why FXString can handle both 32-bit wide character strings as well as 16-bit wide character strings. So the same code: const wchar_t some_string[]=L"blablabla"; is therefore different sizes in Windows vs Linux. Its OK, FXString can be initialized from both of these, converting them to utf8 immediately. Needless to say, if you let the compiler unescape escaped characters in the string, then look at how your compiler does that. FXString::unescape() can also perform unescaping, but then you [at least for now] need to use surrogate pairs. -- JVZ |