Vés al contingut

UTF-7

De la Viquipèdia, l'enciclopèdia lliure

UTF-7(7-bitUnicode Transformation Format) és una codificació de caràcters de longitud variable que va ser proposada per representar text codificat ambUnicodeutilitzant un flux de caràctersASCII,per ser usat, per exemple en missatges decorreu electrònicd'Internet.Malgrat el nom, UTF-7 no és un format de transformació i no forma part de l'estàndardUnicode.

El protocol bàsic de transport de missatges decorreu electrònicaInternet,SMTPespecifica que el format de transmissió ésASCIIi no permet valors de bytes fora d'aquest rang.MIMEproveeix una manera d'especificar unconjunt de caràcters,permetent l'ús de diferents conjunts de caràcters incloentUTF-8iUTF-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,base64té el problema de fer illegibles fins i tot els caràctersASCIIi la combinació deUTF-8ambQuoted-Printableprodueix un format molt ineficient, ja que requereixen entre 6 a 9 bytes per cada caràcter noASCIIdins deBMPi 12 bytes per a caràcters fora deBMP.

Seguint les regles de codificació de UTF-7 és possible enviar text en uncorreu electrònicsense necessitat d'utilitzar untransfer encodingdeMIMEdiferent, però tot i així ha de ser explícitament identificat amb el conjunt de caràcters del text. Si és utilitzat en capçaleres decorreu electròniccom "Subject:" UTF-7 ha de ser contingut dins d'unencoded wordidentificant el conjunt de caràcters. Atès queencoded wordobliga a l'ús dequoted-printableobase64,UTF-7 està dissenyat per no fer servir el símbol "=" com uncaràcterd'escapament per evitar conflictes quan es combini ambquoted-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ït8BITMIMEamb 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-8ja sigui ambquuoted-printableobase64,elIMCno recomana la seva ús.

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

Descripció

[modifica]

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

Alguns conjunts de caràcters poden ser representats directament amb bytes únics deASCII.El primer conjunt és conegut com a "caràcters directes" i conté tots els 62 caràctersalfanumèricsi 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 rangU+0020-U+007Eexcepte# \+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 deportes d'enllaçde correu mal configurades, a més, pot requerir caràcters d'ECAP extra quan es combina ambencoded word.

L'espai,latabulació,elretorn de carroi el caràcter denova líniapoden ser usats també directament com bytes simples d'ASCII.No obstant això, si el text codificat ha de ser usat en uncorreu 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 enUTF-16i després enbase64 modificat.L'inici d'aquests blocs debase64 modificat,que van codificats enUTF-16s'indica amb un símbol+.El final s'indica amb qualsevol caràcter que no pertanyi al conjunt debase64 modificat.Com a cas especial, si el caràcter després del blocbase64 modificatés un-llavors aquest es consumeix. Com un altre cas especial, els caràcters literals+podenser codificats com+-i han de ser codificats usantbase64 modificattambé.

Exemples

[modifica]
  • "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 codiUnicodeper al símbol de lliura és O+00A3 (el qual és00A316en UTF-16), es converteix enModified Base64com es mostra a la taula a continuació. Dosbitsqueden fora i són emplenats amb 0's.
Dígit Hexadecimal 0 0 A 3
Patró de Bit 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 1 0 0
Index 0 10 12
Base64 A K M

Algorisme per a codificar i descodificar UTF-7 manualment

[modifica]

Codificar

[modifica]

Primerament un codificador ha de decidir quins caràcters representar directament enASCIIi quins posar en blocs de caràctersunicode.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üènciaunicode.

Una vegada que les seqüènciesunicodes'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 nombresUnicode(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 sisbits,començant per l'esquerra:
    0000 0000 1010 0011 → 000000 001010 001100 100000 001000 00
  4. Si l'últim grup té menys de sisbits,afegir zeros al final:
    0000 0000 1010 0011 → 000000 001010 001100 100000 001000 000000
  5. Substitueix cada grup de sisbitsper la seva respectiu códigooBase64:
    000000 001010 001100 100000 001000 000000 → AKMgIA

Decodificar

[modifica]

Primerament el missatge ha de ser separat en:text plaASCIIi blocsunicodecom es va esmentar en la secció dedescripció,un cop fet això els blocsunicodehan de ser decodificats usant el següent procediment (s'utilitza el resultat de la codificació a lasecció anterior)

  1. Expressar cada codiBase64com la seqüència debitsque representa:
    AKMgIA → 000.000 001.010 001.100 100.000 001.000 000.000
  2. Reagrupar els valors binaris en grups de 16bits, 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 quatrebitsobre conté algun un, el codi és invàlid):
    0000000010100011 0010000000100000
  4. Cada grup de 16 bits és un número de caràcterUnicode(UTF-16) que pot ser expressat en altres formes:
    0000 0000 1010 0011 ≡ 0x00A3 ≡ 16310

Seguretat

[modifica]

UTF-7 permet moltes representacions del mateix text font, això s'aconsegueix intercanviant la manerabase64múltiples vegades. Els transports moderns de correu i altres poden manejarUTF-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.

Encara no desenvolupats: UTF-6 i UTF-5

[modifica]

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 ambPunycode.

Referències

[modifica]
  1. Seng, James,UTF -5, un format de transformació deUnicodeiISO 10646,Gener 28 de 2000, pres 23 agost 2007
  2. Welter,Mark; Brian W. Spolarich, Walid, Inc. «UTF-6 - Yet Another ASCII-Compatible Encoding for IDN».Internet Engineering Task Force (IETF) INTERNET-DRAFT,16-11-2000. [Consulta: 28 agost 2007].