Last Change: 2018-09-07, 16:50
powered by manpag.es
UTF-8 − ASCII kompatíbilis több bájtos Unicode kódolás
Az Unicode karakterkészlet 16 bites kódteret foglal el. A legkézenfekvőbb Unicode kódolás (az UCS-2) 16 bites szavak sorozatából áll. Az ilyen karakterláncok olyan bájtokat is tartalmazhatnak egyes 16 bites karakterek részeként, mint a ’\0’ vagy a ’/’, amelyeknek speciális jelentésük van fájlnevekben és különféle C könyvtári függvények paramétereiben. Ráadásul a UNIX-os segédprogramok többsége ASCII fájlokat vár, és nem tudja a 16 bites szavakat karakterként feldolgozni jelentős módosítások nélkül. Ezért az UCS-2 nem megfelelő az Unicode kódolására fájlnevekben, szövegfájlokban, környezeti változókban, stb. Az ISO 10646 Universal Character Set (UCS), amely tartalmazza részhalmazként az Unicode-ot, már 31 bites kódtéren helyezkedik el, és a kézenfekvő UCS-4 kódolás (32 bites szavak sorozata) erre a karakterkészletre ugyanezeket a problémákat veti fel.
Az Unicode és az UCS UTF-8 típusú kódolása mentes ezektől a problémáktól, ezért ez a követendő út a Unicode karakterkészlet használatára a Unix-szerű operációs rendszerek alatt.
Az UTF-8 kódolás a következő jó tulajdonságokkal rendelkezik:
|
* |
Az 0x00000000-tól 0x0000007f-ig terjedő UCS karakterek (a klasszikus US-ASCII karakterek) egyszerűen a 0x00-tól 0x7f-ig egy bájton tárolódnak. (ASCII kompatibilitás.) Ez azt jelenti, hogy ha egy fájlban vagy karakterláncban csak 7 bites ASCII karakterek fordulnak elő, akkor a kódolásuk ASCIIésUTF-8 alatt azonos lesz. |
||
|
* |
Minden 0x7f-nél nagyobb kódú UCS karaktert olyan több bájtból álló sorozat kódol, amelyben minden bájt 0x80 és 0xfd közé esik, tehát nem jelenhet meg egy ASCII bájt, mint egy másik karakter része, ezért nem okozhat problémát például a ’\0’ vagy a ’/’. |
||
|
* |
Az UCS-4 karakterláncok ábécérendje megmarad. |
||
|
* |
A 2^31 darab lehetséges kód bármelyike megadható az UTF-8segítségével. |
||
|
* |
A 0xfe és 0xff bájtokat nem használja az UTF-8 kódolás. |
||
|
* |
Egy nem-ASCII UCS karaktert reprezentáló több bájtos sorozat első bájtja mindig 0xc0 és 0xfd közé esik, és egyben megadja, hogy milyen hosszú a több bájtos sorozat. Az ezt követő bájtok valamennyien a 0x80-tól 0xbf-ig terjedő tartományba esnek. Ez lehetővé teszi az újraszinkronizálást, és a kódolást ellenállóvá teszi a hiányzó bájtokkal szemben. |
||
|
* |
Az UTF-8 kódolású UCS karakterek akár hat bájlt hosszúak is lehetnek, de a Unicode karakterek csak legfeljebb három bájt hosszúak. Mivel a Linux csak a 16 bites Unicode részhalmazát használja az UCS-nek, ezért Linux alatt az UTF-8 több bájtos sorozatok csak egy, két vagy három bájt hosszúak lehetnek. |
A következő bájtsorozatok reprezentálnak egy karaktert. A használandó sorozat függ a karakter UCS kódjától.
0x00000000 - 0x0000007F:
0xxxxxxx
0x00000080 - 0x000007FF:
110xxxxx 10xxxxxx
0x00000800 - 0x0000FFFF:
1110xxxx 10xxxxxx 10xxxxxx
0x00010000 - 0x001FFFFF:
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0x00200000 - 0x03FFFFFF:
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0x04000000 - 0x7FFFFFFF:
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
Az xxx bitpozíciókat azokkal a bitekkel kell feltölteni, amelyek a karakter kódját alkotják kettes számrendszerbeli reprezentációban. Csak a legrövidebb több bájtos reprezentációt szabad használni a több lehetséges variáció közül.
A Unicode-os 0xa9 = 1010 1001 karakter (a copyright jel) UTF-8-as kódolása:
11000010 10101001 = 0xc2 0xa9
A 0x2260 = 0010 0010 0110 0000 karakter (a "nem egyenlő" szimbólum) kódolása:
11100010 10001001 10100000 = 0xe2 0x89 0xa0
Az Unicode specifikáció megköveteli, hogy az UTF-8 kódokat előállítók a legrövidebb lehetséges formát válasszák, például egy olyan kétbájtos sorozat, amelynek az első bájtja 0xc0, nem szabályos. Az Unicode kiadta az UTF-8 Corrigendum című dokumentumot, amelyben megtiltja a szabványt betartó programoknak, hogy elfogadjanak olyan kódokat, amelyek nem a legrövidebb formájukban érkeznek. Ennek biztonsági okai vannak: ha a felhasználó által beadott kódsorozatot ellenőrzik a biztonság érdekében, az ellenőrzés valószínűleg az "/../", ";" vagy NUL értékek ASCII formátumára terjedne csak ki, és esetleg nem gondolnak arra, hogy számos más módon lehet ezeket a jeleket az UTF-8 kódolás segítségével nem ASCII formátumban reprezentálni. Lásd még az IETF RFC 2279-et.
Néhány rendszer (amelyek a NUL-t a karakterlánc végeként értelmezik) ennek ellenére használja a C0 80 kódot a NUL (ASCII 00) karakter belső ábrázolására.
ISO 10646, Unicode 1.1, XPG4, Plan 9.
Markus Kuhn <mskuhn AT cip DOT informatik DOT uni-erlangen DOT de>
Tímár András <timar_a AT freemail DOT hu>