Conversation

This Tweet was deleted by the Tweet author. Learn more

Replying to

and

can you explain what's happening?

Replying to

HN thread news.ycombinator.com/item?id=279464

Replying to

Seems like preliminary panic. AssemblyScript can move to UTF-8 like everyone else

Replying to

UTF8 doesn't solve security / validation problems: onlineutf8tools.com/validate-utf8 websec.github.io/unicode-securi

ibtimes.co.in

Bug Hits Apple iOS: iPhones, Watch Crash After Receiving Unicode SMS [How to Fix it]

Apple's iOS has been reportedly hit with a bug, which is causing iPhones and Watch to crash upon receiving text message (SMS).

Replying to

It's the standard string encoding in 2021 & good enough. Other encodings should be used for legacy purposes only

Replying to

Dart, C#, Java, JavaScript internally uses UTF16. And They won't be able to change it to UTF8 even in the future. Otherwise it would require a complete re-do of the String API and loose compatibility. Also UTF8 does not solve the security problems like I said

Replying to

Yes, these are the "legacy" uses. At least C# and Java have had discussions about moving to UTF-8, possibly with new Utf8String type

Replying to

Also UTF-8 has problems with uniform representation for POSIX-compatible and Windows-compatible path names . Currently Rust have some workarounds like special arf-strings, OsString and etc

Replying to

That's not accurate. UTF-8, UTF-16 and UTF-32 represent exactly the same set of strings. They're encodings of Unicode. JavaScript is not using UTF-16 but rather has a legacy implementation that's really an array of UCS2 characters which permits invalid Unicode strings.

Replying to

UTF-8 is able to encode every single string that UTF-16 and UTF-32 can encode. Your claims are inaccurate. Rust is not working around any issues with UTF-8 but rather OS path names are usually not guaranteed to be Unicode. NTFS and ext4 paths are allowed to be invalid Unicode.

8:41 PM · Jul 25, 2021Twitter Web App

Replying to

Most *nix filesystems permit paths to be any NUL-terminated C string with a special meaning for the slash character. That's why you can't represent them with Unicode strings. This is not an issue with UTF-8. You can't represent them as UTF-16 or UTF-32 either. You're very wrong.

Replying to

What's specifically wrong with the slash character in a path? At least for UTF8, slash is in the first 128 characters (since slash exists in ASCII as well). Semantically, it carries additional info, but I don't see what's wrong w/ storing it in a UTF8 string.

Show replies