Unicode

• Egyes programok (például az Oracle adatbázis ), amelyek Unicode-adataikat UTF-16 formátumban képviselik, rendelkeznek (vagy tapasztaltak) átalakítási hibát UTF-8-ra: egy U + 10000 és U + 10FFFF közötti karakter, két 16- bites szavak, két Unicode karakter sorozataként UTF-8-vá konvertálódik. Ez a CESU-8 "véletlenszerű" létrehozásához vezetett, és előnye, hogy megkönnyíti az Unicode használatát 16 bites platformokon.
• Az U + 0000 Unicode null karaktert az UTF-8 egyetlen nullx bájton kódolja 0x00 . Az Unicode szabvány szerint ennek a karakternek nincs különösebb jelentése; ugyanakkor (történelmi elvi okokból) a C nyelvű karakterlánc-feldolgozó könyvtárak ezt a vezérlő karaktert a karakterlánc végének tekintik, ami bonyolítja egyes alkalmazási esetek végrehajtását . A Java platform alatt az „  (en) Modified UTF-8  ” verzió úgy született meg, hogy kihasználta a CESU-8 „16 bites” hordozhatóságának előnyeit és hozzáadta az U + 0000 kódolásának lehetőségét a 0xC0 0x80 sorrendben. (az UTF-8-ban általában tiltott): ily módon cserélve a támogatott platform natív C könyvtárakkal, a platform könnyen kezelheti az összes érvényes Unicode-szöveget, valamint az összeállított osztályfájlokat (hordozható alternatív formátum, függetlenül az endiától és a szótól. méret).

Az UTF-16 jó kompromisszum, ha a memóriaterület nem túl kicsi, mert a modern nyelvek írásaihoz rendelt Unicode-karakterek túlnyomó többsége (beleértve a leggyakrabban használt karaktereket is) a többnyelvű tervalapban található, ezért képviselhető 16 biten. Az ISO / IEC 10646 francia változata ezeket a 16 bites szavakat "lefoglalásoknak" nevezi, de a nemzetközi változat mindazonáltal két bájtból álló klasszikus 16 bites szavakként írja le őket, és az endizmus szokásos szabályainak betartásával .

A tizenhat további sík kódpontjai két 16 bites szó átalakítását igénylik:

• vonjon le 0x10000 értéket a kódpontról, 20 bites számot hagyva a 0x00 és 0xFFFFF tartományban;
• a 10 legjelentősebb bitet (0x00 és 0x3FF közötti számot) hozzáadjuk a 0xD800-hoz, és megadjuk az első kódegységet a magas félzónában ( 0xD800-tól 0xDBFF-ig );
• a 10 legkevésbé szignifikáns bitet (0x00 és 0x3FF közötti számot) hozzáadjuk a 0xDC00-hoz, és a második kódegységet adjuk az alacsony félzónában ( 0xDC00-tól 0xDFFF-ig );

Mivel a legtöbb általánosan használt karakter az alapsíkon helyezkedik el, a további klipek kódolását gyakran rosszul tesztelik a szoftverek, ami hibákhoz vagy biztonsági problémákhoz vezet még a széles körben elterjedt szoftverekben is. Bizonyos jogi keretek, például a GB 18030 , további tervek támogatását kérhetik, amelyek nevezetesen a tulajdonnevekben szereplő karaktereket tartalmazzák.

A kódoló szekvencia kezdetét az UTF-16-ban ábrázolt szöveg bármely pontjáról meg lehet határozni legfeljebb egy további olvasat végrehajtásával, csak akkor, ha ez a kódpont az alsó félterületen van. Ez az űrlap gazdaságosabb és könnyebben feldolgozható, mint az UTF-8, kevés ASCII karaktert tartalmazó szövegek ábrázolásához (U + 0000 - U + 007F).

Ennek az átalakításnak azonban két inkompatibilis kódolási sémája van, amelyek a bájtok sorrendjétől függenek a 16 bites egész ábrázolásban. Ennek a kétértelműségnek a feloldása és a heterogén rendszerek közötti átvitel lehetővé tétele érdekében hozzá kell adni a használt kódolási sémát (UTF-16BE vagy UTF-16LE) jelző információt, vagy a kódolt szöveget előtaggal kell ellátni a kódpont ábrázolásával. Érvényes U + FEFF (a "nulla szélességű, nem törő tér" karakterhez van rendelve, egy olyan karakterhez, amelyet most csak erre a célra használnak bájtsorrend-jelölőként), mivel az érvényes "megfordított" U + FFFE kódpont nem karakteres, a szövegekben tilos megfelel az Unicode és az ISO / IEC 10646 szabványoknak .

Az UTF-16 másik hibája, hogy a vele átalakított és a két kódolási séma bármelyikével továbbított szöveg nagyszámú bájtot tartalmaz, amelyek semlegesek vagy olyan értékkel bírnak, amelyek ütköznek a d értékekkel. Bizonyos csereprotokollok fenntartják a bájtokat.

Ez a kódolás, amelyet a Java platform belsőleg használ , valamint a Windows az Unicode-kompatibilis API-khoz (a típussal wchar).

Az UTF-32 akkor használható, ha a memóriaterület nem jelent problémát, és közvetlenül és méretváltozás nélkül kell hozzáférnünk a karakterekhez ( egyiptomi hieroglifák ).

Ennek a szabványos átalakításnak az az előnye, hogy az összes kódelem azonos méretű. Ezért nem szükséges további kódpontokat olvasni a kódpont ábrázolásának kezdetének meghatározásához.

Ez a formátum azonban különösen gazdaságtalan (beleértve a memóriát is), mivel feleslegesen "pazarolja" karakterenként legalább egy bájtot (mindig nulla). A szöveg memóriájának mérete negatívan befolyásolja a teljesítményt, mivel teljes RAM esetén több olvasást és írást igényel a lemezre , és csökkenti a processzorok memória gyorsítótárának teljesítményét is.

A jelenlegi modern nyelveken írt szövegeknél (a kiegészítő ideográfiai sík bizonyos ritka karaktereitől eltekintve), ezért csak az alapvető többnyelvű sík kódpontjait használva ez az átalakítás megduplázza a szükséges memória mennyiségét az UTF-16-hoz képest.

Az UTF-16-hoz hasonlóan az UTF-32-nek is több kódolási sémája van, a bájtok sorrendjétől függően, amelyek 8 bitnél nagyobb egész számot alkotnak (az UTF-32 két kódolási sémája szabványosított, az UTF-32BE és az UTF-32LE). Ezért szükséges megadni ezt a kódolási sémát, vagy meg kell határozni úgy, hogy a szöveget az U + FEFF kódpont UTF-32-ben való ábrázolásával előretold. Az UTF-16-hoz hasonlóan az üres bájtok jelenléte az UTF-32 szabványosított kódolási sémáiban inkompatibilisvé teszi a heterogén rendszerek közötti csere sok protokolljával.

Szintén ezt a formátumot használják gyakran csak nagyon helyileg bizonyos feldolgozáshoz, mint könnyebben kezelhető köztes formát, és gyakran előnyben részesítjük az UTF-16 transzformációt, amely gyakran hatékonyabb nagy mennyiségű szöveg feldolgozásához és tárolásához, az a kettő végrehajtása nagyon egyszerű, és a feldolgozás bonyolultsága szempontjából nagyon olcsó.

Valójában sok szövegszerkesztő könyvtár csak UTF-16-tal íródott, és hatékonyabb, mint az UTF-32, még akkor is, ha a szövegek további síkok karaktereit tartalmazzák (mert ez az ábraeset az esetek döntő többségében ritka marad).

Ne feledje azonban, hogy az UTF-32-re történő átalakítás 32 bites kódpontokat használ, amelyek közül sok nem feltétlenül képvisel érvényes kódpontot (az U + 0000 - U + D7FF és U + érvényes kódpontokat képviselő két intervallumon kívüli értékek) E000-től U + 10FFFF-ig), ezért nincs érvényes vagy fenntartott karakter (ezért az abban foglalt információk nem lehetnek szövegek Unicode-értelemben). Az érvénytelen kódértékeket használó szövegek továbbítása az UTF-32 szabványos kódolási sémáinak egyikében tilos minden Unicode-kompatibilis rendszer számára (a kódpontokat magáncélra kell használni), mivel lehetetlen lesz hogy képviselje őket egy másik UTF transzformációban, amellyel a három standardizált UTF kompakt módon kompatibilis.

Kínai szabvány GB 18030

Ez az Unicode átalakulása, amelyet nem az Unicode Konzorcium határoz meg, hanem a kínai szabványigazgatás, ahol támogatása kötelező az alkalmazásokban. Történelmileg ez egy kódolt karakterkészlet volt, amelyet kibővítettek az egész FKR repertoár támogatására egy algoritmikus transzformációval, amely kitöltött egy nagy kód-kód megfeleltetési táblázatot.

Unicode betűtípusok

Annak az állítása, hogy az Unicode kódolja a karaktereket, azt jelenti, hogy azt állítja, hogy az absztrakt szimbólumokhoz számot rendel, a logikai kódolás elvének megfelelően. Az Unicode viszont nem kódolja a karakterek, karakterjelek grafikus ábrázolását . Ezért nincs bijekciót közötti képviselete a jellegét és számát, mivel minden grafikai változatai stílus egységes.

Ezenkívül, ellentétben a klasszikus ASCII vagy Latin-1 betűtípussal , a karakterjel kóddal történő kiválasztása nem egyedi, és gyakran kontextuális, és ugyanazt a karakterjelet is megjelenítheti különböző kódok esetén. Így az "é" francia karakter kétféleképpen írható le: vagy az "é" -nek megfelelő szám közvetlen felhasználásával, vagy az "e" számának követésével az akut akcentussal vadászat nélkül. Bármelyik lehetőséget is választja, ugyanaz a karakterjel jelenik meg. Az első karakterről azt mondjuk, hogy előkomponálva van, a másodikról azt, hogy kompozícióról van szó (két karakter egyetlen karakterjelet alkot mindkettőből). Ez megengedett, sőt erősen ajánlott, mert a kódolás különböző formáit az Unicode „kanonikusan egyenértékűnek” minősíti, ami azt jelenti, hogy a kódolás két egyenértékű formáját azonos módon kell kezelni.

Sok összetett karakter van ebben az esetben, és ezen a két módon lehet kódolni (vagy több, egyes összetett karaktereket többféleképpen is szét lehet bontani, különösen, ha több diakritikusuk van). Leggyakrabban az előre megkomponált karakter előnyösebb a szöveg kódolásához, ha létezik (ez a helyzet például a politonikus görög esetében, amely bontásban kódolva grafikusan nem lehet kielégítő: a betűtípusoktól függően a különböző karakterek a karakterjel alkotói néha rosszul vannak elrendezve és nehezen olvashatók). Ugyanakkor nem minden összetett karakter rendelkezik egyedi kódponttal az előkomponált formájához.

Hasonlóképpen, egyes írási rendszerek, például a Devânagarî , a perzsa vagy az arab , a ligatúrák komplex kezelését igénylik  : a grafémák alakjukat megváltoztatják helyzetüktől vagy szomszédaiktól függően (lásd: Kontextusváltozat és Közös levél ). A helyes karakterjel kiválasztása feldolgozást igényel annak meghatározásához, hogy melyik kontextuális alakzatot válassza ki a betűtípusban, annak ellenére, hogy az összes kontextuális alakzatot azonos módon kódolja az Unicode.

Ezen okok miatt az Unicode betűtípust körültekintően kell kezelni. Például az összes létező karakterjelű betűtípus nem elegendő. Szükség van továbbá arra, hogy a megjelenítő rendszer (a renderelő motor ) rendelkezzen olyan mechanizmusokkal, amelyek képesek feldolgozni a ligatúrákat , a kontextusváltozatokat és az egyes nyelvekre jellemző ízületi formákat. Ezzel szemben egy olyan betűtípus, amely csak a karakterek egy részét képviseli, de tudja, hogyan kell helyesen megjeleníteni őket, jobban megérdemli az "Unicode betűtípus" címet. Végül a betűtípusok bizonyos technikai korlátai megakadályozhatják, hogy a teljes könyvtárat támogassák. A gyakorlatban lehetetlen (2009-ben) egyetlen betűtípust találni, amely az egész könyvtárat támogatja.

Az Unicode karakterkészlet tehát csak olyan betűtípus, amely lehetővé teszi az Unicode által engedélyezett összes formában kódolt szöveg közvetlen megjelenítését, és lehetővé teszi egy vagy több nyelvhez igazított koherens részhalmaz támogatását egy vagy több szkript támogatásához. Egyetlen Unicode betűtípus sem képes önmagában "működni", és a teljes írási támogatás ezek támogatását igényli egy renderelő motorban , amely képes azonos kódolási formák detektálására, szöveges kontextusformák keresésére és az Unicode-tal kódolt betűkészlet különböző karakterjeleinek kiválasztására ha szükséges, magában a betűtípusban található levelezési táblázatokat használja.

Műszaki információk

Szoftverkönyvtárak

Az ICU cross-platform szoftverkönyvtár lehetővé teszi az Unicode kódolású adatok manipulálását. A platform-specifikus Unicode támogatást a modern rendszerek is integrálják ( Java , Microsoft Windows , GNU / Linux , szabványos C / C ++ könyvtárak , Python stb.).

Az Unicode változók tárolásához használatos típusok:

1. UTF-8-ban
2. Vegye figyelembe, hogy a wchar_tC nyelvtípus nem mindig teszi lehetővé az összes Unicode karakter kódolását, mert ennek a nyelvnek a szabványa nem biztosít elegendő minimális számot ehhez a szabványos típushoz. A nyelv sok fordítója azonban wchar_t32 bites (vagy akár 64 bites szabványos 64 bites egész számokat kezelő környezeteknél) meghatározást jelent, ami elegendő a szabványosított Unicode kód bármely pontjának tárolásához. De más fordítók képviseli wchar_t16 bit (különösen a Windows 16 vagy 32 bit környezet), még a 8 bites egyetlen (különösen a beágyazott rendszereket nem rendelkező általános operációs rendszer), mert wchar_thasználhatja ugyanazt állítja, a típus char, amely minimum 8 bit.
3. A C és C ++ -hoz hasonlóan a Java nyelvnek van egy egységtípusa, amely 16 bit kódolását teszi lehetővé, de nem engedélyez egyetlen értékű kódpont kódolását (a natív típus charcsak pozitív 16 bites egész szám) . A szabványosított karakterek előtérből történő manipulálásához egy pár kódpontot kell használnia, amelyek mindegyike az UTF-16 űrlap által definiált két kódpontnak megfelelő értéket tartalmaz. Szintén az objektumtípusok Stringvagy char[2]a legalkalmasabbak Unicode karakter ábrázolására. A Java 1.4.1 óta a standard könyvtár teljes Unicode támogatást nyújt a natív típusnak int(ami egy 32 biten definiált egész szám) és a standard osztály statikus módszereinek köszönhetően Character(azonban egy ilyen típusú példányos objektum Characternem teszi lehetővé, csakúgy, mint a natív típus charbármely kódpont tárolásához).
4. JavaScript számos nem szabványosított megvalósítással rendelkezik, néhány régebbi, amelyek karakterenként legfeljebb 16, és néha csak 8 bitet támogatnak. Ennek a nyelvnek az ECMAScript szabványa azonban Character32 biten (valójában az osztály alapján Number) meghatároz egy segédosztályt, amelynek támogatnia kell a 17 szabványosított terv összes kódpontját, míg a karakterláncok kötelezően kódolt karaktereket használnak 16 biten (de anélkül korlátozás, amely megerősíti az UTF-16 kódegységek párosítását, az ECMAScript típusú karakterláncok Stringnem korlátozódnak az egyetlen UTF-16 kódolásra, hanem korlátozás nélkül 16 biten kódolt egész konstansok vektorai, a (Java-val és más másokkal való interoperabilitás) biztosítása érdekében. nyelvek, amelyek szintén nem érvényesítik az UTF-16 megfelelőségi korlátozásokat natív adattípusaikban). Ez a két nyelv nem támogatja a változók kifejezett tipizálását, a típust dinamikusan határozzák meg a hozzájuk rendelt értékek (emellett több belső reprezentáció is lehetséges, eltéréseik általában átláthatóak a programozó számára).

Az Unicode azonban továbbra is gyenge a szoftveres reguláris kifejezések gyenge támogatásában , bár az olyan könyvtárak, mint az ICU és a Java , támogatják őket. Ilyen támogatást még nem szabványosítottak az ECMAScript számára, és csak a nyelvvel vagy interfészekkel létrehozott könyvtárak segítségével nyújtják az együttműködést más rendszerekkel (különösen a CORBA-val , COM- mal ) vagy nyelvekkel (különösen a C ++ és a Java ).

Felosztás

A naprakész particionálás megtalálható az Unicode hivatalos webhelyén. Tekintettel azonban az Unicode mai fontos szerepére ( ISO / IEC 10646 ), a fő karakterblokkok itt kerülnek ismertetésre. A francia nevek az ISO / IEC 10646 , a kétnyelvű nemzetközi szabvány hivatalos nevei, amelyek ugyanazokat a karaktereket használják, mint az Unicode. Ugyanolyan hivatalosak, mint az angol nevek.

A régi Unicode 1.0 szabvány elavult, és nem kompatibilis az ISO / IEC 10646 és az Unicode 1.1 verzióval, valamint minden későbbi verziójával; a fő inkompatibilitás a koreai nyelv írásához használt Hangul karakterblokkoké, amelyek megváltoztatták a helyzetüket, és amelyek régi kódpontjait azóta más blokkokhoz rendelték. Az alábbi táblázat kompatibilis az ISO / IEC 10646 (minden verzió) és az Unicode 1.1 (vagy újabb) verzióval .

Megjegyzés: A blokknevek esete nem normatív. Az "alap latin" tehát egyenértékű az "ALAP LATIN" szóval.

A következő táblázatokban a hivatalos Unicode PDF fájlra vonatkozó megjegyzéssel ellátott blokknév azt jelenti, hogy az adott blokkhoz társított Wikipedia oldal nem létezik vagy helytelen.