In my opinion, GB18030 is a outdated standard (even in China), most of Chinese websites use UTF-8 today. And GB18030 is only a subset of Unicode. Emoji in SMP are not including in it, so if your app use this charset , all the emoji would be lost.
I agree always use UTF-8 instead of the current locale. 发自我的 iPhone > 在 2019年5月14日，22:56，Andrew Robinson <arobinso...@cox.net> 写道： > > Ola, > > Don't you just love how UNICODE is not haphazardly implemented? That was > sarcasm, by the way. My solution for all this UNIversal lack of communication > and understanding of UNICODE implementation, was to create a few function > calls of my own to translate on-the-fly between UTF-16 and UTF-8, and between > UTF-8 and GB18030. Why UTF-16? Because it has the most native support from > Microsoft and much of the Windows internals are in UTF-16 (NTFS especially > comes to mind). Why GB18030? Because GB18030 is the only UNICODE > implementation so far that has actually been standardized in at least one > country (China, with an audience of 1.5 billion customers). I wish IUP would > directly support GB18030 so I could eliminate half of the translations needed > (Antonio tells me that IUP will contain a GB18030 preprocessor flag for > providing GB18030 support). Why UTF-8? Because UTF-8 is a central part of > this translation process because IUP does directly support UTF-8 with the > following commands: > > UTF8MODE [Windows and GTK Only]. By default IUP uses strings in the current > locale (See FONT attribute). To use UTF-8 strings set this attribute to Yes. > Default: NO. > > UTF8MODE_FILE [Windows Only]. By default IUP uses file names in the current > locale, even when UTF8MODE=Yes. To use UTF-8 file names set this attribute to > Yes. Default: NO. > > Gracias, > Andrew > > On 2019-05-14 at 5:45 AM, Antonio Scuri <antonio.sc...@gmail.com> wrote: > Hi, > > Interesting. I saw that you did this: > > if (sizeof(ImWchar) == 2) > cp = 0xFFFD; > > We use the TCHAR definition which is a 16 bits value when UNICODE is > defined (the default in IUP), i.e. sizeof==2 by default. So we don't actually > need the "Surrogate" variable storage but just to replace the surrogate pair > by 0xFFFD. Is that correct? > > Best, > Scuri > > >> Em qui, 9 de mai de 2019 às 04:45, 云风 Cloud Wu <clou...@gmail.com> escreveu: >> IupGLText can't handle surrogate pairs ( >> https://en.wikipedia.org/wiki/UTF-16 ) now. >> >> In windows, a unicode above U+10000 (For example U+1F604 😀 ) will be >> separated into two WM_CHAR messages. If we got a WM_CHAR with WPARAM >> between 0xD800 to 0xDBFF , we should wait for another part of >> surrogate pair, and combine them into one unicode code point. >> >> btw, I fix the same issue for imgui . This patch ( >> https://github.com/ocornut/imgui/pull/2541/commits/fc2dff0ab602e77628a97edd983f03f6f571487a >> ) is for your reference. >> >> -- >> http://blog.codingnow.com >> >> >> _______________________________________________ >> Iup-users mailing list >> Iup-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/iup-users > > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users
