I understand what You are trying to say and You are correct and sorry that I didn’t focused on this. The earlier solution is not good as You have explained correctly.
But I don’t think that haxe has better unicode support yes but there is actually a good unicode support in haxe for html5 with js api in haxe I mean with the help of :
To make it possible without much changes in earlier implementation we need to use/make interface and design and implementation for html5 first and also design fallback for flash like target (this intentionally fails instead of corrupting data).
And let MultiByteEncoding.hx we made as it is for lime.
But important to note is that browser TextEncoder API primarily supports UTF-8 only thus Shift-JIS, GBK, Big5, EUC-KR, etc are not supported but atleast multibyte encoding(emoji and other) and I think the current openfl implementation does the same thing as this browser textencoder api does ?
Supporting this additional Shift-JIS and other require heavy tables, not possible without native libs support and for html5 it is not a good aim therefore I primiraly designed for it,
For supporting this additional multibyte charsets in html/flash best way is to design libs like this one only and that is out of scope of openfl project.
I’m not sure I fully understand the issue. I say that humbly (truly), figuring there may be something I’m missing.
My understanding is UTF-8 is the defacto standard for character encoding and has been for some years now:
All modern OS’ support UTF-8.
Any up-to-date Windows 10 / 11.
Any up-to-date OSX.
Any up-to-date Linux / FreeBSD.
iOS and Android devices.
UTF-8 is dominant for all countries/languages on the internet, is used in most standards, often the only allowed encoding, and is supported by all modern operating systems and programming languages. Wikipedia - UTF-8
If that is the case, and I’m not missing something important (possible!), I’m not sure why one would want to invest time on legacy character encoding implementations?
Thanks to @VibeCoder’s tip about TextDecoder, I was able to add support for readMultiByte() when targeting html5. The commit is in the 9.6.0-dev branch for now.
I also improved our implementation for writeMultiByte() to better match Flash’s behavior when a charset isn’t supported.