Specials (Unicode block)
| Specials | |
|---|---|
| Range |
U+FFF0..U+FFFF (16 code points) |
| Plane | BMP |
| Scripts | Common |
| Assigned | 5 code points |
| Unused |
9 reserved code points 2 non-characters |
| Unicode version history | |
| 1.0.0 | 1 (+1) |
| 2.1 | 2 (+1) |
| 3.0 | 5 (+3) |
| Note: [1][2] | |
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:
- U+FFF9 interlinear annotation anchor, marks start of annotated text
- U+FFFA interlinear annotation separator, marks start of annotating text
- U+FFFB interlinear annotation terminator, marks end of annotating text
- U+FFFC  object replacement character, placeholder in the text for another unspecified object, for example in a compound document.
- U+FFFD � replacement character used to replace an unknown or unrepresentable character
- U+FFFE <noncharacter-FFFE> not a character.
- U+FFFF <noncharacter-FFFF> not a character.
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.
Replacement character
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 render 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 (0x66 0xFC 0x72). This file is now opened with a text editor that assumes the input is UTF-8. The first and last byte are valid UTF-8 encodings of ASCII, but the middle byte (0xFC) is not a valid leading byte in UTF-8. Therefore a text editor could replace this byte with the replacement character symbol to produce a valid string of Unicode code points. 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 as "f�r" (see mojibake). Since the replacement is the same for all errors this makes 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. This will allow the text editor to save the original byte sequence, while still showing the error indicator to the user.
It has become increasingly common for software to interpret invalid UTF-8 by guessing the bytes are in another byte-based encoding such as ISO-8859-1. This allows correct display of both valid and invalid UTF-8 pasted together. If a web page uses ISO-8859-1 (or Windows-1252) but specifies the encoding as UTF-8, most web browsers used to display all umlauts, ß's, and accented characters as �, but newer software (including new versions of Internet Explorer)[citation needed] now translate the erroneous bytes individually to characters in Windows-1252, so the replacement character is rarely, if ever, seen.
Unicode chart
| 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
| ||||||||||||||||
See also
External links
- ↑ "Unicode character database". The Unicode Standard. Retrieved 22 March 2013.
- ↑ The Unicode Standard Version 1.0, Volume 1. Addison-Wesley Publishing Company, Inc. 1990, 1991. ISBN 0-201-56788-1.