Content deleted Content added
Tags: Mobile edit Mobile web edit Advanced mobile edit |
m →Interlinear annotation: fix misguided link |
||
| (33 intermediate revisions by 14 users not shown) | |||
Line 1:
{{short description|Non-printing format effectors and control codes included in Unicode}}
Many
In the narrowest sense, a ''control
== Category "Cc" control codes (C0 and C1) ==
Line 8:
The control code ranges 0x00–0x1F ("C0") and 0x7F originate from the 1967 edition of [[US-ASCII]]. The standard [[ISO/IEC 2022]] (ECMA-35) defines extension methods for ASCII, including a secondary "C1" range of 8-bit control codes from 0x80 to 0x9F, equivalent to 7-bit sequences of {{ctrl|ESC}} with the bytes 0x40 through 0x5F. Collectively, codes in these ranges are known as the [[C0 and C1 control codes]]. Although ISO/IEC 2022 allows for the existence of multiple control code sets specifying differing interpretations of these control codes, their most common interpretation is specified in [[ISO/IEC 6429]] (ECMA-48).
The [[ISO/IEC 8859]] series of encodings conforms to [[ISO/IEC 4873]] (ECMA-43) level 1, a subset of ISO/IEC 2022 designed for 8-bit character encodings, and therefore
Category "Cc" control codes can serve a variety of purposes, not limited to format effectors: for example, the default ASCII C0 set includes six format effectors ({{ctrl|BS}}, {{ctrl|HT}}, {{ctrl|LF}}, {{ctrl|VT}}, {{ctrl|FF}} and {{ctrl|CR}}), ten transmission controls, four device controls, four information separators and eight other control codes.<ref name="ir001">{{cite iso-ir |sponsor=ISO/TC 97/SC 2 |sponsor-link=ISO/IEC JTC 1/SC 2#History |title=The set of control characters of the ISO 646 |date=1975 |number=1}}</ref> Most of these characters play no explicit role in Unicode text handling, and are used only by higher-level protocols such as those used by [[terminal emulator]]s. Certain characters are commonly used for formatting or [[sentinel value|sentinel]] purposes:
Most of these characters play no explicit role in Unicode text handling, and are used only by higher-level protocols such as those used by [[terminal emulator]]s. The characters {{unichar|0000|note=NUL}}, {{unichar|0009|Horizontal tabulation|nlink=tab key|note=HT}}, {{unichar|000A|Line feed|nlink=newline|note=LF}}, {{unichar|000D|carriage return|note=CR}}, and {{unichar|0085|NEL|note=NEL}} are commonly used in text processing as formatting characters. Unicode only specifies semantics for U+0009—U+000D, U+001C—U+001F, and U+0085. The rest of the control characters are transparent to Unicode and their meanings are left to higher-level protocols, although interpretation as defined in ISO/IEC 6429 is suggested as a default.<ref name="unicode-23-1">{{cite book |url=https://www.unicode.org/versions/Unicode12.0.0/ch23.pdf#page=3 |title=23.1: Control Codes |work=The Unicode Standard |edition=12.0.0 |date=2019 |author=Unicode Consortium |author-link=Unicode Consortium |isbn=978-1-936213-22-1 |pages=868–870}}</ref> Furthermore, certain specialised higher-level protocols, such as transcoded [[Teletext]], may include a [[Teletext character set#Control characters|different interpretation]] of the entire C0 control code range.<ref>{{cite web |url=https://corp.unicode.org/pipermail/unicode/2020-October/009120.html |title=Teletext separated mosaic graphics |work=Unicode Mailing List Archive |last=Ewell |first=Doug |date=2020-10-16 |publisher=[[Unicode Consortium]] |quotation=I reiterate that it was UTC {{bracket|[[Unicode Technical Committee]]}} and Script Ad Hoc who provided the guidance to the group writing the [[Symbols for Legacy Computing]] proposal (and there is a second on the way) that 0x00 through 0x1F in the original teletext set should map to U+0000 through U+001F when converting to Unicode.}}</ref>▼
* {{tt|U+0000}} {{unichar/name|na=NULL}} (used in [[null-terminated string]]s)
* {{tt|U+0009}} {{unichar/name|na=HORIZONTAL TABULATION (HT)}} (inserted by the [[tab key]])
* {{tt|U+000A}} {{unichar/name|na=LINE FEED (LF)}} (used as a [[newline|line break]])
* {{tt|U+000C}} {{unichar/name|na=FORM FEED (FF)}} (denotes a [[page break]] in a plain text file)
* {{tt|U+000D}} {{unichar/name|na=CARRIAGE RETURN (CR)}} (used in some line-breaking conventions)
* {{tt|U+0085}} {{unichar/name|na=NEXT LINE (NEL)}} (sometimes used as a line break in text transcoded from [[EBCDIC]])
▲
== Unicode introduced separators ==
In an attempt to simplify the several [[newline]] characters used in legacy text{{citation needed|date=November 2014}}, Unicode introduces its own newline characters to separate either lines or paragraphs: {{unichar|2028|line separator
Like CR and LF, LS and PS are effectors for text formatting; unlike CR and LF, they are not treated as "control codes" for [[ECMA-35]]/[[ECMA-48]] purposes (category {{code|Cc}}), rather having semantics defined entirely by Unicode itself. They are assigned to ''[[sui generis]]'' [[Unicode character property#General Category|Unicode categories]] {{code|Zl}} and {{code|Zp}} respectively, under the major category {{code|Z}} (separator) used for certain [[whitespace character]]s.
Line 19 ⟶ 26:
== Language tags ==
{{main|Tags (Unicode block)}}
Unicode
These language tag characters would not be displayed themselves. However, they would provide information for text processing or even for the display of other characters. For example, the display of Unihan ideographs might have substituted different glyphs if the language tags indicated Korean than if the tags indicated Japanese. Another example, might have influenced the display of decimal digits 0 through 9 differently depending on the language they appeared in.
The tag characters
Unicode states that "the use of tag characters to represent language tags in a plain text stream is still a deprecated mechanism for conveying language information about text.<ref name="migration" />
== Interlinear annotation ==
Three formatting characters provide support for [[
== Bidirectional text control ==
{{main|
Unicode supports standard bidirectional text without any special characters. In other words Unicode conforming software should display right-to-left characters such as Hebrew letters as right-to-left simply from the properties of those characters. Similarly, Unicode handles the mixture of left-to-right-text alongside right-to-left text without any special characters. For example, one can quote Arabic (“بسم الله”) (translated into English as "Bismillah") right alongside English and the Arabic letters will flow from right-to-left and the Latin letters left-to-right.
However, directionality may not be detected correctly if left-to-right text is quoted at the beginning of a right-to-left paragraph (or ''vice versa''),<ref name="segan"/> and the support for bidirectional text becomes even more complicated when text flowing in opposite directions is embedded hierarchically, for example if * {{unichar|061C|ARABIC LETTER MARK}}
* {{unichar|200E|LEFT-TO-RIGHT MARK}}
* {{unichar|200F|RIGHT-TO-LEFT MARK}}
* {{unichar|202A|LEFT-TO-RIGHT EMBEDDING}}
* {{unichar|202B|RIGHT-TO-LEFT EMBEDDING}}
* {{unichar|202C|POP DIRECTIONAL FORMATTING}}
* {{unichar|202D|LEFT-TO-RIGHT OVERRIDE}}
* {{unichar|202E|RIGHT-TO-LEFT OVERRIDE}}
* {{unichar|2066|LEFT-TO-RIGHT ISOLATE}}
* {{unichar|2067|RIGHT-TO-LEFT ISOLATE}}
* {{unichar|2068|FIRST STRONG ISOLATE}}
* {{unichar|2069|POP DIRECTIONAL ISOLATE}}
== Variation selectors ==
Line 58 ⟶ 76:
{{unicode navigation}}
[[Category:Unicode special code points|Control characters]]
| |||