3 ms·
Java, NT, .NET, "wide" C and C++ and a few others from the same time frame ended up with WTF-16 because surrogate pairs didn't exist when they were designed. Th
by formerly_proven 2y ago
Java, NT, .NET, "wide" C and C++ and a few others from the same time frame ended up with WTF-16 because surrogate pairs didn't exist when they were designed. They were designed with UCS-2, which is a fixed-length encoding. Unicode 2.0 then extended that to be variable length (16/32-bit) using surrogate pairs and that's where all the systems come from which don't validate surrogate pairs.
- account42 2y ago"Wide" characters in C and C++ do not have a standardized width. On most non-Windows platforms they are actually four bytes so can cover the entirety of Unicode and then some in one wchar_t. Not that that's a more reasonable encoding for most applications than WTF-16.
- wbl 2y agoWhere did they think Cuneiform was going to fit? Even with unihan the BMP was getting consumed fast.
- formerly_proven 2y agoIn the beginning Unicode was only meant to be used for extant languages afaik.
- account42 2y agoYes, the clusterfuck that is CJK unification would not have been done if it was known that Unicode was going to go beyond 16-bit anyway.
- merb 2y agoIs that still true with dotnet? Especially since it has a surrogate pair api and a rune api? https://learn.microsoft.com/de-de/dotnet/api/system.char.issurrogatepair?view=net-9.0 https://learn.microsoft.com/de-de/dotnet/api/system.char.iss... https://learn.microsoft.com/en-us/dotnet/api/system.text.rune?view=net-9.0 https://learn.microsoft.com/en-us/dotnet/api/system.text.run...
- afiori 2y agoSurrogate pairs existed then, they just ignored them