| Revision as of 16:44, 23 April 2018 editJc86035 (talk | contribs)Extended confirmed users, Template editors34,237 edits Nominated for deletion; see Misplaced Pages:Articles for deletion/UTF-9 and UTF-18. (TW)← Previous edit |
Revision as of 13:22, 1 May 2018 edit undoSandstein (talk | contribs)Autopatrolled, Administrators188,544 edits Misplaced Pages:Articles for deletion/UTF-9 and UTF-18 closed as redirect (XFDcloser)Tag: New redirectNext edit → |
| Line 1: |
Line 1: |
|
⚫ |
#REDIRECT ] |
|
<!-- Please do not remove or change this AfD message until the discussion has been closed. --> |
|
|
{{Article for deletion/dated|page=UTF-9 and UTF-18|timestamp=20180423164410|year=2018|month=April|day=23|substed=yes|help=off}} |
|
|
<!-- Once discussion is closed, please place on talk page: {{Old AfD multi|page=UTF-9 and UTF-18|date=23 April 2018|result='''keep'''}} --> |
|
|
<!-- End of AfD message, feel free to edit beyond this point --> |
|
|
'''UTF-9''' and '''UTF-18''' (9- and 18-] ], respectively) were two ] joke specifications for encoding Unicode on systems where the ] (nine bit group) is a better fit for the native word size than the ], such as the 36-bit ] and the ]. Both encodings were specified in RFC 4042, written by ] (inventor of ]) and released on April 1, 2005. The encodings suffer from a number of flaws and it is confirmed by their author that they were intended as a joke.<ref>{{cite web|url=http://panda.com/mrc/|title=Mark Crispin's Web Page|accessdate=2006-09-17}} Points out ] for two of his RFCs.</ref> |
|
|
|
|
|
|
|
{{Rcat shell| |
|
However, unlike some of the "specifications" given in other April 1 ], UTF-9 and UTF-18 are actually technically possible to implement, and have in fact been implemented in ] assembly language. They are however not endorsed by the ]. |
|
|
|
{{R to related topic}} |
|
|
|
|
⚫ |
}} |
|
== Technical details == |
|
|
Similarly to ], which uses a ] with ] ''code units'', UTF-9 uses a system of putting the ] of a Unicode ] in the low 8 ] of each output nonet and using the high bit to indicate continuation. This means that ] and ] characters take one nonet each, the rest of the ] characters take two nonets each and non-BMP code points take three. Code points that require multiple nonets are stored starting with the most significant non-zero octet. |
|
|
|
|
|
This table shows the UTF-9 encoding scheme (the x characters are replaced by the bits of the code point): |
|
|
{| class="wikitable" |
|
|
|- |
|
|
!Number<br>of nonets!!Bits for<br>code point!!First<br>code point!!Last<br>code point!!Nonet 1!!Nonet 2!!Nonet 3 |
|
|
|- |
|
|
|style="text-align: center;"|1 |
|
|
|style="text-align: center;"|8 |
|
|
|style="text-align: right;"|U+0000 |
|
|
|style="text-align: right;"|U+00FF |
|
|
|<code>0xxxxxxxx</code> |
|
|
|style="background: darkgray;"| |
|
|
|style="background: darkgray;"| |
|
|
|- |
|
|
|style="text-align: center;"|2 |
|
|
|style="text-align: center;"|16 |
|
|
|style="text-align: right;"|U+0100 |
|
|
|style="text-align: right;"|U+FFFF |
|
|
|<code>1xxxxxxxx</code> |
|
|
|<code>0xxxxxxxx</code> |
|
|
|style="background: darkgray;"| |
|
|
|- |
|
|
|style="text-align: center;"|3 |
|
|
|style="text-align: center;"|21 |
|
|
|style="text-align: right;"|U+10000 |
|
|
|style="text-align: right;"|U+10FFFF |
|
|
|<code>1000xxxxx</code> |
|
|
|<code>1xxxxxxxx</code> |
|
|
|<code>0xxxxxxxx</code> |
|
| ⚫ |
|} |
|
|
|
|
|
The details of the encoding scheme used in UTF-9 differ from ] in a non-ideal way, as UTF-9 is not ]: the end of a longer sequence can be confused with a shorter sequence. For instance, <code>U+0041</code> is represented in octal as <code>101</code> and <code>U+E0041</code> as <code>416 400 101</code>. This stems from the lack of distinction between the beginning of a sequence and the subsequent continuation nonets, as both simply have their most significant bit set, and the lack of distinction between a one-nonet sequence and the last nonet of a multi-nonet sequence. In contrast, in ], the three different kinds of octets are trivially distinguishable from each other, making the scheme self-synchronizing. Searching within a UTF-9 encoded string or splitting one requires special care, as it is always necessary to search backwards to find the beginning of the current sequence. |
|
|
|
|
|
UTF-18 is a fixed length encoding using an 18 bit integer per code point. This allows the representation of four planes, which are mapped to the four planes currently used by Unicode (planes 0–2 and 14). This means that the two private use planes (15 and 16) and the currently unused planes (3–13) are not supported. The UTF-18 specification does not allow the use of surrogates for these code points, arguing that surrogates, as used in ], are complicated. It is unlikely that planes 3–13 will be assigned by Unicode in the foreseeable future. Thus, UTF-18, like ], guarantees a fixed width for all code points currently in use (although not for all glyphs). |
|
|
|
|
|
== See also == |
|
| ⚫ |
* ] |
|
|
* ] |
|
|
* ] |
|
|
* ] |
|
|
* ] |
|
|
* ] |
|
|
|
|
|
== Notes == |
|
|
{{Reflist}} |
|
|
|
|
|
== External links == |
|
|
* RFC 4042: UTF-9 and UTF-18 Efficient Transformation Formats of Unicode |
|
|
* |
|
|
|
|
|
{{character encoding}} |
|
|
{{IETF RFC 1st april}} |
|
|
|
|
|
{{DEFAULTSORT:Utf-09 And Utf-18}} |
|
|
] |
|
|
] |
|
|
] |
|
|
] |
|