UTF-8(7) | Miscellaneous Information Manual | UTF-8(7) |
UTF-8 - o codificare Unicode multiocteți compatibilă cu ASCII
Setul de caractere Unicode 3.0 ocupă un spațiu de cod de 16 biți. Cea mai evidentă codificare Unicode (cunoscută sub numele de UCS-2) constă într-o secvență de cuvinte pe 16 biți. Astfel de șiruri de caractere pot conține—ca parte a mai multor caractere pe 16 biți—octeți, cum ar fi '\0' sau '/', care au o semnificație specială în numele fișierelor și în alte argumente ale funcțiilor bibliotecii C. În plus, majoritatea instrumentelor UNIX se așteaptă la fișiere ASCII și nu pot citi cuvinte pe 16 biți ca fiind caractere fără modificări majore. Din aceste motive, UCS-2 nu este o codificare externă adecvată pentru Unicode în nume de fișiere, fișiere text, variabile de mediu și așa mai departe. Setul universal de caractere ISO/IEC 10646 (UCS), un superset al Unicode, ocupă un spațiu de codare și mai mare—31 biți—iar codificarea evidentă UCS-4 pentru acesta (o secvență de cuvinte pe 32 de biți) are aceleași probleme.
Codificarea UTF-8 a Unicode și UCS nu are aceste probleme și reprezintă modul obișnuit de utilizare a Unicode pe sistemele de operare de tip UNIX.
Codificarea UTF-8 are următoarele proprietăți atractive:
Următoarele secvențe de octeți sunt utilizate pentru a reprezenta un caracter. Secvența care trebuie utilizată depinde de numărul de cod UCS al caracterului:
Pozițiile bitului xxx sunt completate cu biții numărului de cod al caracterului în reprezentare binară, cu bitul cel mai semnificativ primul (big-endian). Se poate utiliza numai cea mai scurtă secvență multiocteți posibilă care poate reprezenta numărul de cod al caracterului.
Valorile de cod UCS 0xd800–0xdfff (surogate UTF-16), precum și 0xfffe și 0xffff (non-caractere UCS) nu trebuie să apară în fluxurile conforme cu UTF-8. În conformitate cu RFC 3629, nu ar trebui utilizat niciun punct peste U+10FFFF, care limitează caracterele la patru octeți.
Caracterul Unicode 0xa9 = 1010 1001 (semnul de drepturi de autor) este codificat în UTF-8 sub forma
iar caracterul 0x2260 = 0010 0010 0110 0110 0000 (simbolul "nu este egal") este codificat ca:
Utilizatorii trebuie să selecteze o configurare regională UTF-8, de exemplu cu
pentru a activa suportul UTF-8 în aplicații.
Aplicațiile software care trebuie să fie conștiente de codificarea caracterelor utilizate ar trebui să definească întotdeauna configurația regională cu, de exemplu
iar programatorii pot apoi testa expresia, folosind
pentru a determina dacă a fost selectată o configurație regională UTF-8 și dacă, prin urmare, toate intrările și ieșirile standard în clar, comunicarea prin terminal, conținutul fișierelor în clar, numele fișierelor și variabilele de mediu sunt codificate în UTF-8.
Programatorii obișnuiți cu codificările cu un singur octet, cum ar fi US-ASCII sau ISO 8859, trebuie să fie conștienți de faptul că două dintre ipotezele făcute până acum nu mai sunt valabile în limbajul UTF-8. În primul rând, un singur octet nu mai corespunde neapărat unui singur caracter. În al doilea rând, deoarece emulatoarele moderne de terminale în modul UTF-8 acceptă, de asemenea, caractere chinezești, japoneze și coreene cu lățime dublă, precum și caractere combinate fără spațiere, emiterea unui singur caracter nu avansează neapărat cursorul cu o poziție, așa cum se întâmpla în ASCII. Funcțiile de bibliotecă, cum ar fi mbsrtowcs(3) și wcswidth(3) ar trebui să fie utilizate de acum înainte pentru a număra caracterele și pozițiile cursorului.
Secvența ESC oficială pentru a trece de la o schemă de codificare ISO 2022 (utilizată, de exemplu, de terminalele VT100) la UTF-8 este ESC % G ("\x1b%G"). Secvența corespunzătoare de revenire de la UTF-8 la ISO 2022 este ESC % @ ("\x1b%@"). Alte secvențe ISO 2022 (cum ar fi cele pentru comutarea seturilor G0 și G1) nu se aplică în modul UTF-8.
Standardele Unicode și UCS prevăd că producătorii de UTF-8 trebuie să utilizeze cea mai scurtă formă posibilă; de exemplu, producerea unei secvențe de doi octeți cu primul octet 0xc0 este neconformă. Unicode 3.1 a adăugat cerința potrivit căreia programele conforme nu trebuie să accepte formele care nu sunt cele mai scurte la intrare. Acest lucru se datorează unor motive de securitate: dacă datele de intrare ale utilizatorului sunt verificate pentru posibile încălcări ale securității, un program ar putea verifica doar versiunea ASCII a "/../" sau ";" sau NUL și să treacă cu vederea faptul că există multe moduri non-ASCII de a reprezenta aceste lucruri într-o codificare UTF-8 care nu este cea mai scurtă.
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.
locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)
Traducerea în limba română a acestui manual a fost creată de Remus-Gabriel Chelu <remusgabriel.chelu@disroot.org>
Această traducere este documentație gratuită; citiți Licența publică generală GNU Versiunea 3 sau o versiune ulterioară cu privire la condiții privind drepturile de autor. NU se asumă Nicio RESPONSABILITATE.
Dacă găsiți erori în traducerea acestui manual, vă rugăm să trimiteți un e-mail la translation-team-ro@lists.sourceforge.net.
10 februarie 2023 | Pagini de manual de Linux 6.03 |