plucky (7) utf-8.7.gz

Provided by: manpages-ro_4.25.1-1_all bug

NUME

       UTF-8 - o codificare Unicode multiocteți compatibilă cu ASCII

DESCRIERE

       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.

   Proprietăți
       Codificarea UTF-8 are următoarele proprietăți atractive:

       •  Caracterele UCS de la 0x00000000 la 0x0000007f (caracterele US-ASCII clasice) sunt codificate  pur  și
          simplu  ca  octeți  de  la  0x00 la 0x7f (compatibilitate ASCII). Acest lucru înseamnă că fișierele și
          șirurile de caractere care conțin numai caractere ASCII pe 7  biți  au  aceeași  codificare  atât  sub
          ASCII, cât și sub UTF-8.

       •  Toate caracterele UCS mai mari de 0x7f sunt codificate ca o secvență de mai mulți octeți formată numai
          din octeți din intervalul 0x80 până la 0xfd, astfel încât niciun octet ASCII nu poate apărea ca  parte
          a unui alt caracter și nu există probleme cu, de exemplu, „\0” sau „/”.

       •  Ordinea de sortare lexicografică a șirurilor UCS-4 este păstrată.

       •  Toate codurile UCS 2^31 posibile pot fi codificate utilizând UTF-8.

       •  Octeții 0xc0, 0xc1, 0xfe și 0xff nu sunt niciodată utilizați în codificarea UTF-8.

       •  Primul  octet  al  unei  secvențe de mai mulți octeți care reprezintă un singur caracter UCS non-ASCII
          este întotdeauna cuprins între 0xc2 și 0xfd și indică lungimea acestei secvențe de mai  mulți  octeți.
          Toți ceilalți octeți ai unei secvențe multioctet sunt în intervalul 0x80 - 0xbf. Acest lucru permite o
          resincronizare ușoară și face ca codificarea să fie „apatridă” (să nu depindă configurarea regională a
          sistemului) și rezistentă la octeți lipsă.

       •  Caracterele  UCS  codificate  în  UTF-8  pot  avea o lungime de până la șase octeți; cu toate acestea,
          standardul Unicode nu specifică niciun caracter mai mare de 0x10ffff, astfel încât caracterele Unicode
          pot avea o lungime maximă de patru octeți în UTF-8.

   Codificarea
       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:

       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

       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.

   Exemplu
       Caracterul Unicode 0xa9 = 1010 1001 (semnul de drepturi de autor) este codificat în UTF-8 sub forma

              11000010 10101001 = 0xc2 0xa9

       iar caracterul 0x2260 = 0010 0010 0110 0110 0000 (simbolul „nu este egal”) este codificat ca:

              11100010 10001001 10100000 = 0xe2 0x89 0xa0

   Note de aplicare
       Utilizatorii trebuie să selecteze o configurare regională UTF-8, de exemplu cu

              export LANG=en_GB.UTF-8

       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

              setlocale(LC_CTYPE, "")

       iar programatorii pot apoi testa expresia, folosind

              strcmp(nl_langinfo(CODESET), "UTF-8") == 0

       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/IEC 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/IEC 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/IEC 2022 (cum ar fi cele pentru  comutarea  seturilor
       G0 și G1) nu se aplică în modul UTF-8.

   Securitate
       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ă.

   Standarde
       ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.

CONSULTAȚI ȘI

       locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)

TRADUCERE

       Traducerea    în   limba   română   a   acestui   manual   a   fost   făcută   de   Remus-Gabriel   Chelu
       <remusgabriel.chelu@disroot.org>

       Această  traducere  este  documentație  gratuită;  citiți  Licența  publică  generală  GNU  Versiunea   3
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  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⟩.