UTF-7 (din engleză 7-bit Unicode Transformation Format - „Unicode transformation format, 7 bits”) Format de codificare a textului Unicode cu o lungime variabilă a cuvintelor de caractere într-o secvență de caractere ASCII. Inițial, intenționat să codifice textul Unicode în mesajele de e-mail de pe Internet, ceea ce era mai eficient decât combinarea UTF-8 cu ghilimele imprimabile.
Standardul actual de format de e-mail MIME interzice codificarea antetelor folosind valori de octeți peste intervalul ASCII. Deși MIME permite codificarea corpului mesajului în seturi de caractere diferite (mai largi decât ASCII), infrastructura de transmisie de bază (SMTP, principalul standard de transmisie a e-mailului) încă nu garantează puritatea de 8 biți. Prin urmare, în caz de îndoială, este necesar să se folosească o codificare non-trivială a conținutului transmis. Din păcate, Base64 are dezavantajul că nici măcar caracterele US-ASCII nu pot fi citite de clienții non-MIME. Pe de altă parte, UTF-8 combinat cu ghilimele imprimabile este un format foarte ineficient, necesitând 6-9 octeți pentru caracterele non-ASCII din BMP (Basic Multilingual Plane) și 12 octeți pentru caracterele non-BMP.
Dacă sunt respectate anumite reguli în timpul codificării, textul codificat UTF-7 poate fi trimis prin e-mail fără a utiliza codarea de transfer MIME subiacentă, dar trebuie să fie marcat în mod explicit ca un set de caractere text. De asemenea, dacă sunt utilizate în anteturile de e-mail, cum ar fi „Subiect:”, UTF-7 trebuie să fie conținut în cuvintele codificate MIME care identifică setul de caractere. Deoarece cuvintele codificate folosesc fie seturile cu ghilimele imprimabile, fie seturile Base64, UTF-7 a fost conceput cu opțiunea de a nu folosi semnul egal = ca caracter de evadare pentru a evita sărirea dublă atunci când este combinat cu ghilimele imprimabile (sau varianta acestuia, în RFC 2047 /1522 ?anteturi de codificare Q?).
UTF-7, de regulă, nu este utilizat în forma sa nativă în aplicații, deoarece este foarte incomod pentru procesare. Deși UTF-7 are prioritate față de combinațiile de UTF-8 cu ghilimele imprimabile sau Base64, acum defunctul Internet Mail Consortium a recomandat să nu utilizeze codificarea UTF-7. [unu]
8BITMIME a fost, de asemenea, introdus pentru a reduce nevoia de a codifica corpurile de mesaje în format de 7 biți.
O formă modificată a UTF-7 (mUTF-7, UTF-7 IMAP) este utilizată în prezent de protocolul de e-mail IMAP pentru a căuta numele cutiei poștale [2] .
UTF-7 a fost propus inițial ca protocol experimental în RFC 1642 „A Mail-Safe Transformation Format of Unicode”. Acest RFC este învechit din RFC 2152 , un RFC informațional care nu a fost niciodată un standard. După cum se precizează în RFC 2152 , „RFC nu definește un standard de internet de niciun tip”. Indiferent, RFC 2152 este citat ca definiție a UTF-7 în lista de codificare IANA. De asemenea, UTF-7 nu este un standard Unicode. Unicode Standard 5.0 listează numai UTF-8, UTF-16 și UTF-32. Există, de asemenea, o versiune modificată, specificată în RFC 2060 , care este uneori identificată ca UTF-7.
Unele caractere pot fi reprezentate direct ca un singur octet ASCII. Ele formează un grup de așa-numite „caractere directe” din 52 de litere latine, 10 numere și 9 caractere de punctuație: ' ( ) , - . / : ?. Caracterele directe sunt sigure atunci când sunt afișate literal. Celălalt grup principal, cunoscut ca „caractere directe opționale”, conține toate celelalte caractere imprimabile din interval, U+0020—U+007Ecu excepția ~ \ +spațiului. Utilizarea caracterelor de redirecționare opționale reduce dimensiunea și îmbunătățește lizibilitatea, dar crește și șansa ca informațiile să fie corupte de factori precum gateway-uri de e-mail prost proiectate și poate necesita evadare suplimentară atunci când se utilizează caractere de redirecționare opționale în cuvintele codificate pentru câmpurile de antet.
Spațiul, tabulația, întoarcerea căruciorului și avansul de linie pot fi reprezentate direct ca octeți ASCII unici. Cu toate acestea, dacă textul codificat urmează să fie utilizat în e-mail, trebuie avut grijă să se asigure că aceste caractere nu necesită codificare suplimentară a conținutului transmis adecvat pentru e-mail. Semnul plus +poate fi codificat ca +-.
Alte caractere trebuie mai întâi codificate în UTF-16 (caracterele cu coduri de la U+10000și mai sus vor fi codificate în surogate) big-endian (biți înalți la sfârșit) și apoi modificate la coduri Base64. Începutul unor astfel de blocuri de caractere codificate în UTF-16 și modificate în Base64 este notat cu +. Sfârșitul blocurilor este indicat de orice caracter care nu face parte din setul de modificatori Base64. Dacă caracterul după ce a fost modificat în Base64 este -(cratima-minus ASCII), atunci este sărit de decodor și decodificarea se reia la următorul caracter. În caz contrar, decodificarea se reia cu un caracter după Base64.
8BITMIME a fost, de asemenea, introdus pentru a reduce nevoia de a codifica corpurile de mesaje în format de 7 biți.
| hexazecimal
Codul |
0 | 0 | A | 3 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| cod binar | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | unu | 0 | unu | 0 | 0 | 0 | unu | unu | 0 | 0 |
| Indici | 0 | zece | 12 | |||||||||||||||
| Codul Base64 | A | K | M | |||||||||||||||
În primul rând, codificatorul trebuie să determine ce caractere pot fi reprezentate direct în format ASCII, altele decât semnul plus +, care este codificat ca +-și care caractere trebuie marcate ca blocuri de caractere Unicode. Un codificator simplu poate codifica direct toate caracterele pe care le consideră sigure pentru codificarea directă. Cu toate acestea, este o idee bună să terminați o secvență Unicode cu un caracter direct în ASCII și apoi să începeți o altă secvență Unicode care conține 3 până la 3⅔ octeți. Acesta este mai mult decât cei 2⅔ octeți necesari pentru a reprezenta un caracter ca parte a unei secvențe Unicode.
Fiecare secvență de caractere Unicode trebuie să fie codificată utilizând următoarea procedură și apoi înconjurată de delimitatorii corespunzători. De exemplu, folosim succesiunea de simboluri £† ( U+00A3 U+2020):
0x00A3 → 0000 0000 1010 0011
În primul rând, datele codificate trebuie separate în bucăți de text simplu ASCII (inclusiv semnele plus urmate de o cratimă +-) și blocuri Unicode nevide, așa cum este specificat în secțiunea de descriere. Odată făcut acest lucru, fiecare bloc Unicode trebuie decodat cu următoarea procedură (folosind rezultatul exemplului de codificare de mai sus):
Un marcator Unicode (deseori denumit „BOM” - marca de ordine a octetilor) este o secvență specială opțională de octeți la începutul unui flux sau fișier care, deși nu este date în sine, specifică codificarea utilizată pentru datele ulterioare; markerul este utilizat atunci când nu există metadate care să denote codificarea. Pentru o anumită schemă de codificare, semnătura este reprezentarea schemei într-un punct de cod Unicode U+FEFF, așa-numitul caracter BOM.
În timp ce un marcator Unicode este în general o singură secvență fixă de octeți, specificitatea UTF-7 introduce 5 variații: ultimii 2 biți ai celui de-al 4-lea octet al codificării UTF-7 U+FEFFse referă la următorul caracter, rezultând 4 modele de biți posibile și, prin urmare, , 4 octeți diferiți posibili în a 4-a poziție. A cincea variație este necesară pentru a dezambigua cazul în care niciun caracter nu urmează marcajul. Consultați Determinarea codificării prin marcatorul secvenței de octeți .
UTF-7 permite reprezentări multiple ale aceluiași șir sursă. În special, caracterele ASCII pot fi reprezentate ca parte a blocurilor Unicode. Astfel, dacă se folosesc algoritmi standard de evadare sau de autentificare bazați pe ASCII pentru șiruri care pot fi interpretate ulterior ca UTF-7, atunci blocurile Unicode pot fi folosite pentru a injecta șiruri rău intenționate care trec liber prin validare. Pentru a remedia această problemă, sistemele de validare ar trebui să efectueze decodare înainte de validare și nu ar trebui să încerce să detecteze automat UTF-7.
Versiunile mai vechi de Internet Explorer pot fi păcălite să interpreteze pagina ca UTF-7. Acest lucru poate fi folosit pentru a ataca scripturile între site-uri, deoarece caracterele de serviciu <și >pot fi codificate ca +ADw-în +AD4-UTF-7, pe care majoritatea validatorilor îl transmit ca text simplu.