Unicode

• Unele programe (de exemplu, baza de date Oracle ) care își reprezintă intern datele Unicode în format UTF-16 au (sau au experimentat) un defect de conversie în UTF-8: un caracter între U + 10000 și U + 10FFFF, stocat în două 16- cuvinte bit, este convertit în UTF-8 ca o succesiune de două caractere Unicode. Acest lucru a dus la crearea „accidentală” a CESU-8 și are avantajul de a facilita utilizarea Unicode pe platformele de 16 biți.
• Caracterul nul Unicode U + 0000 este codificat în UTF-8 ca un singur octet nul 0x00 . Conform standardului Unicode, acest caracter nu are o semnificație specială; totuși (din motive conceptuale istorice), bibliotecile de procesare a șirurilor de limbaj C consideră că acest caracter de control este un sfârșit de șir, ceea ce complică implementarea unor cazuri de aplicație . În cadrul platformei Java , versiunea „  (ro) UTF-8 modificată  ” s-a născut profitând de portabilitatea „16 biți” a CESU-8 și adăugând posibilitatea codificării U + 0000 sub secvența 0xC0 0x80 (în mod normal interzis în UTF-8): schimbând în acest fel cu bibliotecile native C ale platformei acceptate, platforma poate gestiona cu ușurință toate textele Unicode valide, precum și fișierele de clasă compilate (format alternativ portabil, independent de endianitate și cuvânt mărimea).

UTF-16 este un compromis bun atunci când spațiul de memorie nu este prea mic, pentru că marea majoritate a caracterelor Unicode atribuite scrierile limbilor moderne (inclusiv cele mai frecvent utilizate caractere) sunt în baza planului de mai multe limbi și , prin urmare , poate fi reprezentat pe 16 biți. Versiunea franceză a ISO / IEC 10646 numește aceste cuvinte pe 16 biți „seizets”, dar versiunea internațională le descrie totuși drept cuvinte clasice pe 16 biți compuse din doi octeți și supuse regulilor obișnuite ale endismului .

Punctele de cod ale celor șaisprezece planuri suplimentare necesită o transformare pe două cuvinte pe 16 biți:

• scade 0x10000 din punctul de cod, lăsând un număr de 20 de biți în intervalul 0x00 până la 0xFFFFF;
• cei 10 biți cei mai semnificativi (un număr între 0x00 și 0x3FF) sunt adăugați la 0xD800 și dau prima unitate de cod în jumătatea înaltă ( 0xD800 la 0xDBFF );
• cei 10 biți cel mai puțin semnificativi (un număr între 0x00 și 0x3FF) sunt adăugați la 0xDC00 și dau a doua unitate de cod în jumătatea joasă ( 0xDC00 la 0xDFFF );

Deoarece majoritatea caracterelor utilizate în mod obișnuit se află în planul de bază, codificarea clipurilor suplimentare este adesea prost testată în software, ducând la erori sau probleme de securitate chiar și în software-ul distribuit pe scară largă. Anumite cadre legale, cum ar fi GB 18030 , pot solicita sprijinul unor planuri suplimentare, acestea conținând în special caractere prezente în nume proprii.

Este posibil să se determine începutul secvenței de codare din orice punct al unui text reprezentat în UTF-16 efectuând cel mult o citire suplimentară, numai dacă acest punct de cod este în jumătatea inferioară. Această formă este mai economică și mai ușor de procesat rapid decât UTF-8 pentru reprezentarea textelor care conțin câteva caractere ASCII (U + 0000 până la U + 007F).

Cu toate acestea, această transformare are două scheme de codificare incompatibile care depind de ordonarea octeților în reprezentarea de 16 biți întregi. Pentru a rezolva această ambiguitate și a permite transmiterea între sisteme eterogene, este necesar să adăugați informații care să indice schema de codare utilizată (UTF-16BE sau UTF-16LE) sau să prefixați textul codificat cu reprezentarea punctului de cod. Valid U + FEFF (atribuit caracterului „spațiu neîntrerupt de lățime zero”, un caracter rezervat acum pentru această singură utilizare ca marker de comandă a octetului), deoarece punctul de cod „inversat” U + FFFE valid este un non-caracter, interzis în texte conforme cu Unicode și ISO / IEC 10646 .

Celălalt defect al UTF-16 este că textul transformat odată cu acesta și transmis cu oricare dintre cele două scheme de codificare conține un număr mare de octeți care sunt nuli sau au o valoare care intră în conflict cu valorile d. 'Octeți rezervați de anumite protocoale de schimb.

Aceasta este în special codificarea pe care platforma Java o folosește intern, precum și Windows pentru API-urile sale compatibile Unicode (cu tipul wchar).

UTF-32 este utilizat atunci când spațiul de memorie nu este o problemă și trebuie să aibă acces la caractere în mod direct și fără schimbare în dimensiune ( hieroglife egiptene ).

Avantajul acestei transformări standardizate este că toate elementele de cod au aceeași dimensiune. Prin urmare, nu este necesar să citiți puncte de cod suplimentare pentru a determina începutul reprezentării unui punct de cod.

Cu toate acestea, acest format este deosebit de neeconomic (inclusiv în memorie), deoarece „irosește” inutil cel puțin un octet (întotdeauna zero) pe caracter. Dimensiunea în memorie a unui text are un efect negativ asupra performanței, deoarece necesită mai multe citiri și scrieri pe disc în caz de memorie RAM completă și, de asemenea, reduce performanța memoriei cache a procesoarelor.

Pentru textele scrise în limbile moderne actuale (în afară de anumite caractere rare ale planului ideografic suplimentar) și, prin urmare, folosind numai punctele de cod ale planului de bază multilingv, această transformare dublează cantitatea de memorie necesară în comparație cu UTF-16.

La fel ca UTF-16, UTF-32 are mai multe scheme de codificare în funcție de ordinea octeților care compun un număr întreg de mai mult de 8 biți (două scheme de codare ale UTF-32 sunt standardizate, UTF-32BE și UTF-32LE). Prin urmare, este necesar, de asemenea, să specificați această schemă de codificare sau să o determinați prefixând textul prin reprezentarea în UTF-32 a punctului de cod U + FEFF. La fel ca UTF-16, prezența octeților nuli în schemele de codificare standardizate ale UTF-32 îl face incompatibil cu multe protocoale pentru schimbul între sistemele eterogene.

De asemenea, acest format este utilizat cel mai adesea doar foarte local pentru anumite prelucrări ca o formă intermediară care este mai ușor de manipulat și preferăm deseori transformarea UTF-16, care este adesea mai eficientă pentru procesarea și stocarea unor cantități mari de texte, conversia între cele două fiind foarte simple de realizat și foarte ieftine în ceea ce privește complexitatea procesării.

De fapt, multe biblioteci de procesare a textelor sunt scrise numai cu UTF-16 și sunt mai eficiente decât UTF-32, chiar și atunci când textele conțin caractere de planuri suplimentare (deoarece acest caz de cifră rămâne rar în marea majoritate a cazurilor).

Rețineți, totuși, că transformarea în UTF-32 utilizează puncte de cod pe 32 de biți, dintre care multe nu pot reprezenta niciun punct de cod valid (valori în afara celor două intervale reprezentând punctele de cod valide U + 0000 la U + D7FF și U + De la E000 la U + 10FFFF), prin urmare nu există un caracter valid sau rezervat (orice informație conținută în acesta nu poate fi, prin urmare, text în sens Unicode). Transmiterea textelor care utilizează aceste valori de cod nevalide într-una dintre schemele de codificare standardizate ale UTF-32 este interzisă pentru orice sistem conform Unicode (este necesar să se utilizeze punctele de cod pentru uz privat în loc), deoarece va fi imposibil pentru a le reprezenta într-o altă transformare UTF cu care cele trei UTF standardizate sunt compatibile bijectiv.

Standardul chinezesc GB 18030

Aceasta este o transformare a Unicode care nu este definită de Consorțiul Unicode, ci de administrația standardelor din China, unde suportul său este obligatoriu în aplicații. Din punct de vedere istoric, acesta a fost un set de caractere codificat, care a fost extins pentru a susține întregul repertoriu UCS printr-o transformare algoritmică care completează un tabel mare de corespondență de la cod la cod.

Fonturi Unicode

Afirmarea faptului că Unicode codifică caractere înseamnă a afirma că atribuie un număr simbolurilor abstracte, conform unui principiu de codificare logică. Unicode, pe de altă parte, nu codifică reprezentări grafice ale personajelor, glifelor . Prin urmare, nu există nicio bijecție între reprezentarea personajului și numărul acestuia, deoarece toate variațiile grafice ale stilului sunt unificate.

În plus, spre deosebire de un font clasic ASCII sau latin-1 , selectarea unui glif printr-un cod nu este unică și este adesea contextuală și poate afișa același glif pentru coduri diferite. Astfel, caracterul francez „é” poate fi descris în două moduri: fie folosind direct numărul corespunzător „é”, fie urmând numărul „e” cu cel al accentului acut fără vânătoare. Indiferent de opțiunea pe care o alegeți, va fi afișat același glif. Vom spune despre primul caracter că este precompus, despre al doilea că este o compoziție (două caractere formează un singur glif compus din ambele). Acest lucru este permis și chiar foarte recomandat, deoarece diferitele forme de codificare sunt clasificate de Unicode ca „echivalent canonic”, ceea ce înseamnă că două forme echivalente de codificare ar trebui tratate identic.

Multe caractere compozite sunt în acest caz și pot fi codificate în aceste două moduri (sau mai multe, unele caractere compozite pot fi descompuse în mai multe moduri, mai ales atunci când au mai multe diacritice). Cel mai adesea, caracterul precompus este preferabil pentru codarea textului, dacă acesta există (acesta este cazul grecii politonice , de exemplu, care, codificat în descompunere, poate să nu fie satisfăcător din punct de vedere grafic: în funcție de caracterele fonturilor, diferitele constituenții glifului fiind uneori slab aranjați și dificil de citit). Cu toate acestea, nu toate caracterele compuse au un punct de cod unic pentru forma lor precompusă.

De asemenea, unele sisteme de scriere, cum ar fi Devânagarî , persană sau arabă , necesită un tratament complex al ligaturilor  : grafemele își schimbă forma în funcție de poziția lor sau de vecinii lor (a se vedea varianta contextuală și litera comună ). Selectarea glifului corect necesită procesare pentru a determina ce formă contextuală trebuie selectată în font, chiar dacă toate formele contextuale sunt codificate identic în Unicode.

Din aceste motive, un font Unicode trebuie manipulat cu grijă. De exemplu, un font cu toate glifele existente nu este suficient. De asemenea, este necesar ca sistemul de afișare ( motorul de redare ) să dețină mecanismele capabile să proceseze ligaturi , variante contextuale și forme comune specifice anumitor limbi. Dimpotrivă, un font care reprezintă doar o parte din caractere, dar știe cum să le afișeze corect, merită mai bine titlul de „font Unicode”. În cele din urmă, anumite constrângeri tehnice ale formatelor de fonturi le pot împiedica să accepte întregul director. În practică, este imposibil (în 2009) să găsești un singur font care să susțină întregul director.

Un font de caractere Unicode este deci doar un font care face posibilă afișarea directă a unui text codificat în toate formele autorizate de Unicode și care face posibilă acceptarea unui subset coerent adaptat la una sau mai multe limbi pentru a susține unul sau mai multe scripturi. Niciun tip Unicode nu poate „funcționa” singur, iar suportul complet de scriere necesită suport pentru acestea într-un motor de redare , capabil să detecteze forme de codificare echivalente, să caute forme contextuale în text și să selecteze diferitele glifuri ale unui font codat cu Unicode, folosind tabelele de corespondență incluse în fontul în sine, dacă este necesar.

Detalii tehnice

Biblioteci software

ATI cross-platform biblioteca software - ul vă permite să manipuleze date codificate cu Unicode. Suportul Unicode specific platformei este, de asemenea, integrat de sisteme moderne ( Java , Microsoft Windows , GNU / Linux , biblioteci standard C / C ++ , Python etc.).

Tipurile de utilizat pentru stocarea variabilelor Unicode sunt:

1. În UTF-8
2. Rețineți însă că tipul de wchar_tlimbă C nu permite întotdeauna codificarea tuturor caracterelor Unicode, deoarece standardul acestei limbi nu oferă un număr minim suficient pentru acest tip standard. Cu toate acestea, mulți compilatori ai limbajului definesc wchar_tla 32 de biți (sau chiar 64 de biți pe medii care gestionează numere întregi standard pe 64 de biți), ceea ce este suficient pentru a stoca orice punct de cod Unicode standardizat. Dar alte compilatoare reprezintă wchar_tpe 16 biți (în special sub Windows în mediul de 16 sau 32 de biți), chiar și pe 8 biți (în special în mediile încorporate care nu au un sistem de operare general), deoarece wchar_tpot utiliza aceeași reprezentare ca tipul charcare are un minim de 8 biți.
3. În mod similar cu C și C ++, limbajul Java are un tip de unitate care permite codificarea a 16 biți, dar nu permite codificarea unui singur punct de cod de orice valoare (tipul nativ chareste doar un număr întreg pozitiv de 16 biți) . Pentru a manipula caracterele standardizate în prim-plan, trebuie să utilizați o pereche de puncte de cod, fiecare conținând o valoare egală cu cele două puncte de cod definite de formularul UTF-16. De asemenea, tipurile de obiecte Stringsau char[2]sunt cele mai potrivite pentru reprezentarea unui caracter Unicode. De la Java 1.4.1 , biblioteca standard oferă suport Unicode complet datorită tipului nativ int(care este un număr întreg definit pe 32 de biți) și metodelor statice ale clasei standard Character(totuși un obiect instanțiat de acest tip Characternu permite, la fel ca tipul nativ char, pentru a stoca orice punct de cod).
4. JavaScript are diferite implementări nestandardizate, unele mai vechi care acceptă nu mai mult de 16 biți pe caracter și uneori doar 8 biți. Cu toate acestea, standardul ECMAScript al acestui limbaj definește o clasă de utilitate Characterpe 32 de biți (de fapt bazată pe clasă Number) care trebuie să suporte toate punctele de cod ale celor 17 planuri standardizate, în timp ce șirurile de caractere folosesc caractere codate obligatoriu pe 16 biți (dar fără restricție consolidând împerecherea unităților de cod UTF-16, șirurile de tip ECMAScript Stringnefiind restrânse la singura codificare UTF-16 ci fiind vectori de constante întregi codificate pe 16 biți fără restricții, pentru a asigura (interoperabilitatea cu Java și alte limbi care, de asemenea, nu aplică restricțiile de conformitate UTF-16 în tipurile lor de date native). Aceste două limbaje nu acceptă tastarea explicită a variabilelor, tipul fiind definit dinamic de valorile atribuite acestora (de asemenea, sunt posibile mai multe reprezentări interne, diferențele lor fiind în mod normal transparente pentru programator).

Unicode, totuși, încă suferă de un suport slab pentru expresiile regulate de către unele programe, deși bibliotecile precum ICU și Java le pot suporta. Un astfel de suport nu a fost încă standardizat pentru ECMAScript și este furnizat numai cu ajutorul bibliotecilor create cu limbajul sau interfețele pentru interoperabilitate cu alte sisteme (în special cu CORBA , COM ) sau limbaje (în special C ++ și Java ).

Partiționare

Partiționarea actualizată poate fi găsită pe site-ul oficial Unicode. Cu toate acestea, având în vedere rolul important al Unicode-ului de astăzi ( ISO / IEC 10646 ), blocurile de caractere principale vor fi descrise aici. Numele franceze sunt numele oficiale ale ISO / IEC 10646 , standardul bilingv internațional care folosește aceleași caractere ca Unicode. Sunt la fel de oficiali ca numele englezești.

Vechiul standard Unicode 1.0 este învechit și incompatibil cu ISO / IEC 10646 și Unicode 1.1 și toate versiunile sale ulterioare; principala incompatibilitate este aceea a blocurilor de caractere Hangul utilizate pentru scrierea limbii coreene care au schimbat poziția și ale căror puncte de cod vechi au fost atribuite de atunci altor blocuri. Tabelul de mai jos este compatibil cu ISO / IEC 10646 (toate versiunile) și Unicode 1.1 (sau o versiune ulterioară).

NB Cazul numelor de blocuri nu este normativ. „Latinul de bază” este deci echivalent cu „LATINUL DE BAZĂ”.

În tabelele următoare, orice nume de bloc cu o notă referitoare la un PDF Unicode oficial înseamnă că pagina Wikipedia asociată blocului respectiv este inexistentă sau incorectă.