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 a short Unicode block allocated at the very end of the Basic Multilingual Plane, at U+FFF0FFFF. Of these 16 code points, five are assigned as of Unicode 10.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. Unicode's U+FEFF Byte order mark character can be inserted at the beginning of a Unicode text to signal its endianness: a program reading such a text and encountering 0xFFFE would then know that it should switch the byte order for all the following characters.

Replacement character

Replacement character

The replacement character � (often a black diamond with a white question mark or an empty square box) 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 unable to render a stream of data to a correct symbol. It is usually 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 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 the original character. 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 non-ASCII characters as �, but newer browsers translate the erroneous bytes individually to characters in Windows-1252, so the replacement character is less frequently seen.

Unicode chart

Specials[1][2][3]
Official Unicode Consortium code chart (PDF)
  0 1 2 3 4 5 6 7 8 9 A B C D E F
U+FFFx  IA 
A
 IA 
S
 IA 
T
 OBJ 
Notes
1.^ As of Unicode version 10.0
2.^ Grey areas indicate non-assigned code points
3.^ Black areas indicate noncharacters - Unicode will never use these codepoints for encoding characters

History

The following Unicode-related documents record the purpose and process of defining specific characters in the Specials block:

Version Final code points[lower-alpha 1] Count UTC ID L2 ID WG2 ID Document
1.0.0 U+FFFD 1 (to be determined)
2.1 U+FFFC 1 (to be determined)
3.0 U+FFF9..FFFB 3 L2/98-055 Freytag, Asmus (1998-02-22), Support for Implementing Inline and Interlinear Annotations 
L2/98-099 N1727 Freytag, Asmus (1998-03-18), Support for Implementing Interlinear Annotations as used in East Asian Typography 
L2/98-158 Aliprand, Joan; Winkler, Arnold (1998-05-26), "Inline and Interlinear Annotations", Draft Minutes - UTC #76 & NCITS Subgroup L2 #173 joint meeting, Tredyffrin, Pennsylvania, April 20-22, 1998 
L2/98-270 Hiura, Hideki; Kobayashi, Tatsuo (1998-07-29), Suggestion to the inline and interlinear annotation proposal 
L2/98-281R Aliprand, Joan (1998-07-31), "In-Line and Interlinear Annotation", Unconfirmed Minutes - UTC #77 & NCITS Subgroup L2 # 174 JOINT MEETING, Redmond, WA -- July 29-31, 1998 
L2/98-363 N1861 Sato, T. K. (1998-09-01), Ruby markers 
L2/98-416 N1882 Support for Implementing Interlinear Annotations, 1998-09-23 
L2/98-312 Whistler, Ken (1998-09-29), "8", Resolutions from SC2/WG2 meeting in London with comments from Ken Whistler 
L2/98-421R Suignard, Michel; Hiura, Hideki (1998-12-04), Notes concerning the PDAM 30 interlinear annotation characters 
L2/98-419 Aliprand, Joan (1999-02-05), "nterlinear Annotation Characters", Approved Minutes -- UTC #78 & NCITS Subgroup L2 # 175 Joint Meeting, San Jose, CA -- December 1-4, 1998 
UTC/1999-021 Duerst, Martin; Bosak, Jon (1999-06-08), W3C XML CG statement on annotation characters 
L2/01-301 Whistler, Ken (2001-08-01), "E. Indicated as "strongly discouraged" for plain text interchange", Analysis of Character Deprecation in the Unicode Standard 
  1. Proposed code points and characters names may differ from final code points and names

See also

References

  1. "Unicode character database". The Unicode Standard. Retrieved 2016-07-09.
  2. "Enumerated Versions of The Unicode Standard". The Unicode Standard. Retrieved 2016-07-09.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.