| Revision as of 18:20, 30 March 2006 edit85.76.170.221 (talk) →Technical details← Previous edit |
Latest revision as of 15:59, 25 November 2018 edit undo174.254.130.36 (talk) Now redirects to the specific section for this RFC.Tag: Redirect target changed |
| (100 intermediate revisions by 73 users not shown) |
| Line 1: |
Line 1: |
|
|
#REDIRECT ] |
|
'''UTF-9''' (9-] ]) and '''UTF-18''' (18-] ]) are two 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 ]. Both encodings were specified in RFC 4042 which was released on ] ]. The encodings suffer from a number of flaws and it is reasonable to assume that they were intended as a joke. However unlike some of the "specifications" given in other ]s they are actually technically possible to implement. They are not endorsed by the ]. |
|
|
|
|
|
|
|
{{Rcat shell| |
|
==Technical details== |
|
|
|
{{R to related topic}} |
|
UTF-9 uses a system of putting an octet in the low 8 ] of each 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 3. Code points that require multiple nonets are stored with the most significant octet in the first nonet (at least according to the examples in the specification; it doesn't actually appear to be stated anywhere). |
|
|
|
{{Rwh}} |
|
|
}} |
|
|
|
|
|
|
{{DEFAULTSORT:Utf-09 And Utf-18}} |
|
UTF-18 is the simpler of the two encodings using a single 18 bit integer per code point. This allows representation of 4 planes which are mapped to the 4 planes currently used by ] (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 doesn't say why they didn't allow surrogates to be used for these code points though when talking about UTF-16 ealier in the RFC they said "This transformation format requires complex surrogates to represent code points outside the BMP". After complaining about their complexity it would have looked a bit hypocritical of them to use them in their new standard. |
|
|
⚫ |
] |
|
|
|
|
⚫ |
] |
|
==Problems== |
|
|
Both specifications suffer from the problem that standard communication protocols are simply not built around nonets, and so it would not be possible to exchange text in these formats without further encoding or specially designed protocols. This alone would probably be sufficient reason to consider their use impractical in most cases. |
|
|
|
|
|
Furthermore, both UTF-9 and UTF-18 have specific problems of their own. UTF-9 requires special care when searching, as a shorter sequence can be found at the end of a longer sequence and UTF-18 cannot represent all Unicode code points (though it can represent all the planes that currently have non-private use code point assignments) making it a bad choice for a system that may develop in the future. |
|
|
|
|
|
==External links== |
|
|
* RFC 4042: UTF-9 and UTF-18 Efficient Transformation Formats of Unicode |
|
|
|
|
| ⚫ |
] |
|
| ⚫ |
] |
|
|
] |
|