Comparison of Unicode encodings: Difference between revisions

Revision as of 12:45, 28 August 2022

Revision as of 22:12, 24 October 2022

Line 10:

[[UTF-16]] and [[UTF-32]] are incompatible with ASCII files, and thus require [[Unicode]]-aware programs to display, print and manipulate them, even if the file is known to contain only characters in the ASCII subset. Because they contain many zero bytes, the strings cannot be manipulated by normal [[null-terminated string]] handling for even simple operations such as copy.{{efn|ASCII software ''not'' using null characters to terminate strings would handle UTF-16 and UTF-32 encoded files correctly (such files, if containing only ASCII-subset characters, would appear as normal ASCII padded with [[null character]]s), but such software is not common.}}

Therefore, even on most UTF-16 systems such as [[Windows]] and [[Java (software platform)|Java]], UTF-16 text files are not common; older 8-bit encodings such as ASCII or [[ISO-8859-1]] are still used, forgoing Unicode support; or UTF-8 is used for Unicode. One rare counter-example is the "strings" file used by [[macOS]] ([[Mac OS X]] (Panther|Mac OS X 10.3 Panther]] and later) applications for lookup of internationalized versions of messages which defaults to UTF-16, with "files encoded using UTF-8 ... not guaranteed to work."<ref>[https://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Articles/StringsFiles.html Apple Developer Connection: Internationalization Programming Topics: Strings Files]</ref>

[[XML]] is, by default, encoded as UTF-8{{Dubious|UTF-8 Default?|date=April 2022}}, and all XML processors must at least support UTF-8 (including US-ASCII by definition) and UTF-16.<ref>{{cite web

|url=http://www.w3.org/TR/xml/#charencoding

|title=Character Encoding in Entities