Specials is the name of a short Unicode block allocated at the very end of the Basic Multilingual Plane, at U+FFF0–FFFF. Of these 16 codepoints, 5 are assigned as of Unicode 6.0:
FFFE and FFFF are not unassigned in the usual sense, but guaranteed not to be a Unicode character at all. They can be used to guess a text's encoding scheme, since any text containing these is by definition not a correctly encoded Unicode text. The U+FEFF is Unicode's byte-order mark, named "zero-width no-break space" (as inclusion of it in text shall not be noticed). If this character is read in the wrong byte order (for example, due to an endianness bug), it will read 0xFFFE, which is illegal Unicode.
Contents |
The replacement character � (often a black diamond with a white question mark) is a symbol found in the Unicode standard at codepoint U+FFFD in the Specials table. It is used to indicate problems when a system is not able to decode a stream of data to a correct symbol. It is most commonly seen when a font does not contain a character, but is also seen when the data is invalid and does not match any character:
Consider a text file containing the German word für in the ISO-8859-1 encoding. This file is now opened with a text editor that assumes the input is UTF-8. As the first byte (0x66) is within the range 0x00–0x7F, UTF-8 correctly interprets it as an f. The second byte (0xFC) is not a legal value for the start of any UTF-8 encoded character. A text editor could therefore replace the byte with the replacement character symbol to warn the user that something went wrong. The last byte (0x72) is also within the code range 0x00–0x7F and can be decoded correctly. The whole string now displays like this: f�r.
A poorly-implemented text editor might save the replacement in UTF-8 form; the text file data will then look like this: 0x66 0xEF 0xBF 0xBD 0x72, which will be displayed in ISO-8859-1 again as f�r (see mojibake). The replacement also destroys the original byte, making it impossible to recover what character was intended.
A better (but harder to implement) design is to preserve the original bytes, including the error, and only convert to the replacement when displaying the text. Another alternative is to make different replacements for each different error byte; one popular replacement is the (otherwise invalid Unicode) U+DC80 through U+DCFF. Both of these are seeing more common use in modern software: if a web page uses ISO-8859-1 (or Windows-1252) but specifies the encoding as UTF-8, most web browsers display all umlauts, ß's and some other characters in the higher range as � instead (since these bytes are almost certainly arranged to be invalid UTF-8 sequences). Newer software (including new versions of Internet Explorer) now translate the erroneous bytes individually to characters in Windows-1252. This gives a more readable presentation of incorrectly sent pages.
| Specials[1] Unicode.org chart (PDF) |
||||||||||||||||
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | A | B | C | D | E | F | |
| U+FFFx | | | |  | � | |||||||||||
Notes
|
||||||||||||||||