UTF-7

UTF-7 (7-bit Unicode Transformation Format) és una codificació de caràcters de longitud variable que va ser proposada per representar text codificat amb Unicode utilitzant un flux de caràcters ASCII, per ser usat, per exemple en missatges de correu electrònic d'Internet. Malgrat el nom, UTF-7 no és un format de transformació i no forma part de l'estàndard Unicode.

El protocol bàsic de transport de missatges de correu electrònic a Internet, SMTP especifica que el format de transmissió és ASCII i no permet valors de bytes fora d'aquest rang. MIME proveeix una manera d'especificar un conjunt de caràcters, permetent l'ús de diferents conjunts de caràcters incloent UTF-8 i UTF-16. No obstant això, la infraestructura de transmissió subjacent encara no garanteix suport per a 8 bits i, per tant, és necessari codificar el contingut per poder transmetre-ho. Per desgràcia, base64 té el problema de fer illegibles fins i tot els caràcters ASCII i la combinació de UTF-8 amb Quoted-Printable produeix un format molt ineficient, ja que requereixen entre 6 a 9 bytes per cada caràcter no ASCII dins de BMP i 12 bytes per a caràcters fora de BMP.

Seguint les regles de codificació de UTF-7 és possible enviar text en un correu electrònic sense necessitat d'utilitzar un transfer encoding de MIME diferent, però tot i així ha de ser explícitament identificat amb el conjunt de caràcters del text. Si és utilitzat en capçaleres de correu electrònic com "Subject:" UTF-7 ha de ser contingut dins d'un encoded word identificant el conjunt de caràcters. Atès que encoded word obliga a l'ús de quoted-printable o base64, UTF-7 està dissenyat per no fer servir el símbol "=" com un caràcter d'escapament per evitar conflictes quan es combini amb quoted-printable.

UTF-7 generalment no s'utilitza com una representació nativa dins d'aplicacions, ja que és un procés bastant difícil de manejar. També s'ha introduït 8BITMIME amb propòsits similars, aquest redueix la necessitat de codificar missatges amb format 7-bit. Tot i els avantatges de mida que presenta sobre la combinació d'UTF-8 ja sigui amb quuoted-printable o base64, el IMC no recomana la seva ús.

En el protocol de recuperació de missatges IMAP actualment s'utilitza una forma modificada de UTF-7. Vegeu la secció 5.1.3 de RFC 3501 per més detalls.

UTF-7 va ser proposat inicialment com un protocol experimental a la RFC 1642, A Mail-Safe Transformation Format of Unicode (Un Format de Transformació d'Unicode Amigable per Correu). Aquesta RFC ha quedat obsoleta per RFC 2152, una RFC informativa la qual mai es va convertir en estàndard. Segons s'expressa clarament en la RFC 2152, la RFC "no especifica cap mena d'estàndard d'Internet". Tot i això la RFC 2152 és citada com la definició d'UTF-7 a la llista de conjunts de caràcters de la IANA. UTF-7 tampoc és un estàndard d'Unicode. L'estàndard d'Unicode 5.0 només llista UTF-8, UTF-16 i UTF-32.

Alguns conjunts de caràcters poden ser representats directament amb bytes únics de ASCII. El primer conjunt és conegut com a "caràcters directes" i conté tots els 62 caràcters alfanumèrics i 9 símbols: '(), -./: . Els caràcters directes són considerats molt segurs per a ser inclosos literalment. L'altre conjunt principal, conegut com a "caràcters directes opcionals", conté tots els altres caràcters imprimibles en el rang U+0020-U+007E excepte # \+ i el caràcter espai. Usant els caràcters directes opcionals es redueix la mida i es millora la llegibilitat per als éssers humans, però, també s'incrementen les possibilitats d'errors a conseqüència de portes d'enllaç de correu mal configurades, a més, pot requerir caràcters d'ECAP extra quan es combina amb encoded word.

L'espai, la tabulació , el retorn de carro i el caràcter de nova línia poden ser usats també directament com bytes simples d'ASCII. No obstant això, si el text codificat ha de ser usat en un correu electrònic, cal anar amb compte a garantir que aquests caràcters siguin usats de manera que no requereixin codificació addicional perquè siguin adequats per a aquest fi.

Altres caràcters han de ser codificats en UTF-16 i després en base64 modificat. L'inici d'aquests blocs de base64 modificat, que van codificats en UTF-16 s'indica amb un símbol +. El final s'indica amb qualsevol caràcter que no pertanyi al conjunt de base64 modificat. Com a cas especial, si el caràcter després del bloc base64 modificat és un - llavors aquest es consumeix. Com un altre cas especial, els caràcters literals + poden ser codificats com +- i han de ser codificats usant base64 modificat també.

• " Hola Món ! " és codificat com " Hola Món ! "
• " 1" 1 = 2 "és codificat com" 1+- 1 = 2 "
• " £ 1 " és codificat com "+AKM-1 ". El codi Unicode per al símbol de lliura és O+00A3 (el qual és 00A3 ₁₆ en UTF-16), es converteix en Modified Base64 com es mostra a la taula a continuació. Dos bits queden fora i són emplenats amb 0's.

Primerament un codificador ha de decidir quins caràcters representar directament en ASCII i quins posar en blocs de caràcters unicode. Un codificat simple pot codificar tots els caràcters que consideri segur codificar directament. No obstant això, el cost de construir un bloc unicode per representar un únic caràcter i després obtenir-lo de tornada és de 3 a 3 ⅔ bytes, és a dir més que els 2 ⅔ bytes necessaris per representar aquest caràcter com a part d'una seqüència unicode.

Una vegada que les seqüències unicode s'han decidit, aquestes han de ser codificades usant el següent procediment i després envoltades amb els delimitadors apropiats

S'usarà la seqüència de caràcters £ ! (0x00A3) (0x2020) com a exemple

1. Expressar els nombres Unicode (UTF-16) dels caràcters en binari:
   0x00A3 → 0.000 0.000 1.010 0.011
0x2020 → 0.010 0.000 0.010 0.000
2. Concatenar les seqüències binàries
   0000 0000 1010 0011 i 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
3. Reagrupar els valors binaris en grups de sis bits, començant per l'esquerra:
   0000 0000 1010 0011 → 000000 001010 001100 100000 001000 00
4. Si l'últim grup té menys de sis bits, afegir zeros al final:
   0000 0000 1010 0011 → 000000 001010 001100 100000 001000 000000
5. Substitueix cada grup de sis bits per la seva respectiu códigoo Base64:
   000000 001010 001100 100000 001000 000000 → AKMgIA

Primerament el missatge ha de ser separat en: text pla ASCII i blocs unicode com es va esmentar en la secció de descripció, un cop fet això els blocs unicode han de ser decodificats usant el següent procediment (s'utilitza el resultat de la codificació a la secció anterior)

1. Expressar cada codi Base64 com la seqüència de bits que representa:
   AKMgIA → 000.000 001.010 001.100 100.000 001.000 000.000
2. Reagrupar els valors binaris en grups de 16 bit s, començant per la izquireda:
   000.000 001.010 001.100 → 0000000010100011 0010000000100000 0000
3. Si queda algun grup incomplet al final, aquest es descarta (Si el grup incomplet conté més de quatre bit sobre conté algun un, el codi és invàlid):
   0000000010100011 0010000000100000
4. Cada grup de 16 bits és un número de caràcter Unicode (UTF-16) que pot ser expressat en altres formes:
   0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 ₁₀

UTF-7 permet moltes representacions del mateix text font, això s'aconsegueix intercanviant la manera base64 múltiples vegades. Els transports moderns de correu i altres poden manejar UTF-8, així que l'ús d'UTF-7 ja no és requerit com ho va ser històricament. Les aplicacions modernes poden considerar suportar altres codificacions més segures en el seu lloc.

Algunes propostes han tingut lloc cap a UTF-6 i UTF-5 per a entorns de radiotelegrafia,^[1][2] però fins a 2006 no s'havia formalitzat un estàndard UTF.

• Aquestes propostes no estan relacionades amb Punycode.