Content deleted Content added
Padgriffin (talk | contribs) →Compatibility issues: Copyedit extremely confusing sentence Tags: Mobile edit Mobile web edit Advanced mobile edit |
|||
Line 8:
A [[UTF-8]] file that contains only [[ASCII]] characters is identical to an ASCII file. Legacy programs can generally handle UTF-8 encoded files, even if they contain non-ASCII characters. For instance, the [[C (programming language)|C]] [[printf]] function can print a UTF-8 string because it only looks for the ASCII '%' character to define a formatting string. All other bytes are printed unchanged.
[[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, character strings representing such files cannot be manipulated by common [[null-terminated string]] handling logic.{{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.{{cn|date=July 2024}}}} The prevalence of string handling using this logic means that, even in the context of UTF-16 systems such as [[Windows]] and [[Java (software platform)|Java]], UTF-16 text files are not commonly used. Rather, older 8-bit encodings such as ASCII or [[ISO-8859-1]] are still used, forgoing Unicode support entirely, or UTF-8 is used for Unicode.{{cn|date=July 2024}} One rare counter-example is the "strings" file introduced in [[Mac OS X Panther|Mac OS X 10.3 Panther]],
[[XML]] is [[de facto|conventionally]] encoded as UTF-8,{{cn|date=July 2024}}
|url=http://www.w3.org/TR/xml/#charencoding
|title=Character Encoding in Entities
| |||