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 (1991) | 1 (+1) |
| 2.1 (1998) | 2 (+1) |
| 3.0 (1999) | 5 (+3) |
| Unicode documentation | |
| Code chart ∣ Web page | |
| Note: [1][2] | |
Specials is a short Unicode block of characters allocated at the very end of the Basic Multilingual Plane, at U+FFF0–FFFF, containing these code points:
- U+FFF9 INTERLINEAR ANNOTATION ANCHOR, marks start of annotated text
- U+FFFA INTERLINEAR ANNOTATION SEPARATOR, marks start of annotating character(s)
- U+FFFB INTERLINEAR ANNOTATION TERMINATOR, marks end of annotation block
- 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, unrecognised, or unrepresentable character
- U+FFFE <noncharacter-FFFE> not a character.
- U+FFFF <noncharacter-FFFF> not a character.
U+FFFE <noncharacter-FFFE> and U+FFFF <noncharacter-FFFF> are noncharacters, meaning they are reserved but do not cause ill-formed Unicode text. Versions of the Unicode standard from 3.1.0 to 6.3.0 claimed that these characters should never be interchanged, leading some applications to use them to guess text encoding by interpreting the presence of either as a sign that the text is not Unicode. However, Corrigendum #9 later specified that noncharacters are not illegal and so this method of checking text encoding is incorrect.[3] An example of an internal usage of U+FFFE is the CLDR algorithm; this extended Unicode algorithm maps the noncharacter to a minimal, unique primary weight.[4]
Unicode's U+FEFF ZERO WIDTH NO-BREAK SPACE character can be inserted at the beginning of a Unicode text as a byte order mark to signal its endianness: a program reading a text encoded in for example UTF-16 and encountering U+FFFE <noncharacter-FFFE> would then know that it should switch the byte order for all the following characters.
Its block name in Unicode 1.0 was Special.[5]
Replacement character
[edit source]
The replacement character � (often displayed as a rhombus with a question mark) is a symbol found in the Unicode standard at code point U+FFFD in the Specials table. It is used to indicate problems when a system is unable to render a stream of data to correct symbols.[6]
As an example, an E-mail message that is encoded in Windows-1252 and contains non-breaking spaces in it will contain the byte 0xA0 for each non-breaking space. The message is then opened in a client that assumes the input is UTF-8. Since bytes between 0x80 and 0xFF are not valid as standalone bytes in UTF-8, the client opening this message could replace these bytes with the replacement character to produce a valid string of Unicode code points for display.[7]
If the sender's Internet service provider is using poorly-implemented text processing programs, the replacement character (0xEF 0xBF 0xBD) may get written out into the message; these three bytes will then replace 0xA0 bytes used for non-breaking spaces, along with all standalone bytes between 0x80 and 0xFF. Then, since the message is still declaring Windows-1252 as its encoding, the recipient's client will display � (this is called mojibake).[7] As all non-ASCII characters are likely turned into the same replacement character, it is impossible to recover the original text.
At one time, the replacement character was often used when there was no glyph available in a font for that character, as in font substitution. However, most modern text rendering systems instead use a font's .notdef character, which in most cases is an empty box, or a ? or X in a box[8] (this browser displays for U+10FFEE), sometimes called a "tofu". There is no Unicode code point for this symbol.
Thus the replacement character is now only seen for encoding errors. Some software programs translate invalid UTF-8 bytes to matching characters in Windows-1252 (since that is the most common source of these errors), so that the replacement character is never seen.[citation needed]
Unicode chart
[edit source]| 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 | IAA | IAS | IAT |  | � | |||||||||||
Notes
| ||||||||||||||||
History
[edit source]The following Unicode-related documents record the purpose and process of defining specific characters in the Specials block:
| Version | Final code points[a] | Count | UTC ID | L2 ID | WG2 ID | Document |
|---|---|---|---|---|---|---|
| 1.0.0 | U+FFFD | 1 | (to be determined) | |||
| U+FFFE..FFFF | 2 | (to be determined) | ||||
| L2/01-295R | Moore, Lisa (2001-11-06), "Motion 88-M2", Minutes from the UTC/L2 meeting #88 | |||||
| L2/01-355 | N2369 (html, doc) | Davis, Mark (2001-09-26), Request to allow FFFF, FFFE in UTF-8 in the text of ISO/IEC 10646 | ||||
| L2/02-154 | N2403 | Umamaheswaran, V. S. (2002-04-22), "9.3 Allowing FFFF and FFFE in UTF-8", Draft minutes of WG 2 meeting 41, Hotel Phoenix, Singapore, 2001-10-15/19 | ||||
| 2.1 | U+FFFC | 1 | UTC/1995-056 | Sargent, Murray (1995-12-06), Recommendation to encode a WCH_EMBEDDING character | ||
| UTC/1996-002 | Aliprand, Joan; Hart, Edwin; Greenfield, Steve (1996-03-05), "Embedded Objects", UTC #67 Minutes | |||||
| N1365 | Sargent, Murray (1996-03-18), Proposal Summary – Object Replacement Character | |||||
| N1353 | Umamaheswaran, V. S.; Ksar, Mike (1996-06-25), "8.14", Draft minutes of WG2 Copenhagen Meeting # 30 | |||||
| L2/97-288 | N1603 | Umamaheswaran, V. S. (1997-10-24), "7.3", Unconfirmed Meeting Minutes, WG 2 Meeting # 33, Heraklion, Crete, Greece, 20 June – 4 July 1997 | ||||
| L2/98-004R | N1681 | Text of ISO 10646 – AMD 18 for PDAM registration and FPDAM ballot, 1997-12-22 | ||||
| L2/98-070 | Aliprand, Joan; Winkler, Arnold, "Additional comments regarding 2.1", Minutes of the joint UTC and L2 meeting from the meeting in Cupertino, February 25-27, 1998 | |||||
| L2/98-318 | N1894 | Revised text of 10646-1/FPDAM 18, AMENDMENT 18: Symbols and Others, 1998-10-22 | ||||
| 3.0 | U+FFF9..FFFB | 3 | L2/97-255R | Aliprand, Joan (1997-12-03), "3.D Proposal for In-Line Notation (ruby)", Approved Minutes – UTC #73 & L2 #170 joint meeting, Palo Alto, CA – August 4-5, 1997 | ||
| L2/98-055 | Freytag, Asmus (1998-02-22), Support for Implementing Inline and Interlinear Annotations | |||||
| L2/98-070 | Aliprand, Joan; Winkler, Arnold, "3.C.5. Support for implementing inline and interlinear annotations", Minutes of the joint UTC and L2 meeting from the meeting in Cupertino, February 25-27, 1998 | |||||
| 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-286 | N1703 | Umamaheswaran, V. S.; Ksar, Mike (1998-07-02), "8.14", Unconfirmed Meeting Minutes, WG 2 Meeting #34, Redmond, WA, USA; 1998-03-16--20 | ||||
| L2/98-270 | Hiura, Hideki; Kobayashi, Tatsuo (1998-07-29), Suggestion to the inline and interlinear annotation proposal | |||||
| L2/98-281R (pdf, html) | Aliprand, Joan (1998-07-31), "In-Line and Interlinear Annotation (III.C.1.c)", 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-372 | N1884R2 (pdf, doc) | Whistler, Ken; et al. (1998-09-22), Additional Characters for the UCS | ||||
| L2/98-416 | N1882.zip | Support for Implementing Interlinear Annotations, 1998-09-23 | ||||
| L2/98-329 | N1920 | Combined PDAM registration and consideration ballot on WD for ISO/IEC 10646-1/Amd. 30, AMENDMENT 30: Additional Latin and other characters, 1998-10-28 | ||||
| L2/98-421R | Suignard, Michel; Hiura, Hideki (1998-12-04), Notes concerning the PDAM 30 interlinear annotation characters | |||||
| L2/99-010 | N1903 (pdf, html, doc) | Umamaheswaran, V. S. (1998-12-30), "8.2.15", Minutes of WG 2 meeting 35, London, U.K.; 1998-09-21--25 | ||||
| L2/98-419 (pdf, doc) | Aliprand, Joan (1999-02-05), "Interlinear 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/99-176R | Moore, Lisa (1999-11-04), "W3C Liaison Statement on Annotation Characters", Minutes from the joint UTC/L2 meeting in Seattle, June 8-10, 1999 | |||||
| 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 | |||||
| ||||||
See also
[edit source]References
[edit source]- ↑ "Unicode character database". The Unicode Standard. Retrieved 2023-07-26.
- ↑ "Enumerated Versions of The Unicode Standard". The Unicode Standard. Retrieved 2023-07-26.
- ↑ "Corrigendum #9: Clarification About Noncharacters". The Unicode Standard. Archived from the original on Jun 10, 2023. Retrieved 2023-06-07.
- ↑ "Unicode Technical Standard #35". Unicode Locale Data Markup Language (LDML). Retrieved 2024-08-27.
- ↑ "3.8: Block-by-Block Charts" (PDF). The Unicode Standard. Version 1.0. Unicode Consortium. Archived (PDF) from the original on 2021-02-11. Retrieved 2020-09-30.
- ↑ Wichary, Marcin (September 29, 2020). "When fonts fall". Figma. Archived from the original on 13 June 2021. Retrieved 6 June 2021.
- 1 2 "Why do my sent messages magically add "�" at the end of my sentences?". 6 December 2017. Retrieved 2 August 2026.
- ↑ "Recommendations for OpenType Fonts (OpenType 1.7) - Typography". Microsoft Learn. Archived from the original on 19 October 2020. Retrieved 18 October 2020.
