.\" Hey Emacs! This file is -*- nroff -*- source. .\" .\" Copyright (C) Markus Kuhn, 1996 .\" .\" This is free documentation; you can redistribute it and/or .\" modify it under the terms of the GNU General Public License as .\" published by the Free Software Foundation; either version 2 of .\" the License, or (at your option) any later version. .\" .\" The GNU General Public License's references to "object code" .\" and "executables" are to be interpreted as the output of any .\" document formatting or typesetting system, including .\" intermediate and printed output. .\" .\" This manual is distributed in the hope that it will be useful, .\" but WITHOUT ANY WARRANTY; without even the implied warranty of .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the .\" GNU General Public License for more details. .\" .\" You should have received a copy of the GNU General Public .\" License along with this manual; if not, write to the Free .\" Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111, .\" USA. .\" .\" 1995-11-26 Markus Kuhn .\" First version written .\" .TH UTF-8 7 "1995-11-26" "Linux" "Linux Programmer's Manual" .SH NÉV UTF-8 \- ASCII kompatíbilis több bájtos Unicode kódolás .SH LEÍRÁS Az .B Unicode karakterkészlet 16 bites kódteret foglal el. A legkézenfekvőbb Unicode kódolás (az .BR 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 .B UCS-2 nem megfelelő az .B Unicode kódolására fájlnevekben, szövegfájlokban, környezeti változókban, stb. Az .BR "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ő .B UCS-4 kódolás (32 bites szavak sorozata) erre a karakterkészletre ugyanezeket a problémákat veti fel. Az .B Unicode és az .B UCS UTF-8 típusú kódolása mentes ezektől a problémáktól, ezért ez a követendő út a .B Unicode karakterkészlet használatára a Unix-szerű operációs rendszerek alatt. .SH TULAJDONSÁGOK Az .B UTF-8 kódolás a következő jó tulajdonságokkal rendelkezik: .TP 0.2i * Az 0x00000000-tól 0x0000007f-ig terjedő .B UCS karakterek (a klasszikus .B 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 .BR ASCII és UTF-8 alatt azonos lesz. .TP * Minden 0x7f-nél nagyobb kódú .B 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 '/'. .TP * Az .B UCS-4 karakterláncok ábécérendje megmarad. .TP * A 2^31 darab lehetséges kód bármelyike megadható az .BR UTF-8 segítségével. .TP * A 0xfe és 0xff bájtokat nem használja az .B UTF-8 kódolás. .TP * Egy nem-ASCII .B 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. .TP * Az .B UTF-8 kódolású .B UCS karakterek akár hat bájlt hosszúak is lehetnek, de a .B Unicode karakterek csak legfeljebb három bájt hosszúak. Mivel a Linux csak a 16 bites .B Unicode részhalmazát használja az .BR UCS -nek, ezért Linux alatt az .B UTF-8 több bájtos sorozatok csak egy, két vagy három bájt hosszúak lehetnek. .SH KÓDOLÁS A következő bájtsorozatok reprezentálnak egy karaktert. A használandó sorozat függ a karakter UCS kódjától. .TP 0.4i 0x00000000 - 0x0000007F: .RI 0 xxxxxxx .TP 0x00000080 - 0x000007FF: .RI 110 xxxxx .RI 10 xxxxxx .TP 0x00000800 - 0x0000FFFF: .RI 1110 xxxx .RI 10 xxxxxx .RI 10 xxxxxx .TP 0x00010000 - 0x001FFFFF: .RI 11110 xxx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .TP 0x00200000 - 0x03FFFFFF: .RI 111110 xx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .TP 0x04000000 - 0x7FFFFFFF: .RI 1111110 x .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .RI 10 xxxxxx .PP Az .I 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. .SH PÉLDÁK A .BR Unicode -os 0xa9 = 1010 1001 karakter (a copyright jel) UTF-8-as kódolása: .PP .RS 11000010 10101001 = 0xc2 0xa9 .RE .PP A 0x2260 = 0010 0010 0110 0000 karakter (a "nem egyenlő" szimbólum) kódolása: .PP .RS 11100010 10001001 10100000 = 0xe2 0x89 0xa0 .RE .SH BIZTONSÁG 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. .PP 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. .SH SZABVÁNYOK ISO 10646, Unicode 1.1, XPG4, Plan 9. .SH SZERZŐ Markus Kuhn .SH "LÁSD MÉG" .B unicode(7) .SH MAGYAR FORDÍTÁS Tímár András