UTF-7 (fra det engelske 7-bit Unicode Transformation Format - "Unicode transformation format, 7 bits") Unicode-tekstkodningsformat med en variabel længde af tegnord til en ASCII-tegnsekvens. Oprindeligt beregnet til at kode Unicode-tekst i internet-e-mail-beskeder, hvilket var mere effektivt end at kombinere UTF-8 med citeret-printbar.
Den nuværende MIME-e-mail-formatstandard forbyder kodning af overskrifter ved hjælp af byteværdier over ASCII-området. Selvom MIME tillader, at meddelelsesteksten kodes i forskellige tegnsæt (bredere end ASCII), garanterer den underliggende transmissionsinfrastruktur (SMTP, den primære e-mail-transmissionsstandard) stadig ikke 8-bit renhed. Derfor er det i tvivlstilfælde nødvendigt at bruge ikke-triviel kodning af det transmitterede indhold. Desværre har Base64 den ulempe, at selv US-ASCII-tegn ikke kan læses af ikke-MIME-klienter. På den anden side er UTF-8 kombineret med citeret-printbar et meget ineffektivt format, der kræver 6-9 bytes for ikke-ASCII-tegn fra BMP (Basic Multilingual Plane) og 12 bytes for ikke-BMP-tegn.
Hvis visse regler følges under kodningen, kan UTF-7-kodet tekst sendes via e-mail uden at bruge den underliggende MIME-overførselskodning, men skal udtrykkeligt markeres som et teksttegnsæt. Desuden, hvis de bruges i e-mail-headere såsom "Emne: ", skal UTF-7 være indeholdt i de MIME-kodede ord, der identificerer tegnsættet. Da kodede ord bruger enten de citerede-udskrivbare eller Base64-sæt, blev UTF-7 designet med muligheden for ikke at bruge lighedstegnet = som et escape-tegn for at undgå dobbeltspring, når det kombineres med citeret-udskrivbare (eller dens variant, i RFC 2047 /1522 ?Q?-kodningsoverskrifter).
UTF-7 bruges som regel ikke i sin oprindelige form i applikationer, da det er meget ubelejligt at behandle. Selvom UTF-7 har forrang over kombinationer af UTF-8 med citeret-udskrivbar eller Base64, har det nu hedengangne Internet Mail Consortium anbefalet at bruge UTF-7-kodning. [en]
8BITMIME blev også introduceret for at reducere behovet for at kode meddelelsestekster i 7-bit format.
En modificeret form for UTF-7 (mUTF-7, UTF-7 IMAP) bruges i øjeblikket af IMAP -e-mail-protokollen til at slå postkassenavne op [2] .
UTF-7 blev oprindeligt foreslået som en eksperimentel protokol i RFC 1642 "A Mail-Safe Transformation Format of Unicode". Denne RFC er forældet fra RFC 2152 , en informativ RFC, der aldrig var en standard. Som angivet i RFC 2152 , "RFC'en definerer ikke en internetstandard af nogen art." Uanset hvad er RFC 2152 nævnt som definitionen af UTF-7 i IANA-kodningslisten. UTF-7 er heller ikke en Unicode-standard. Unicode Standard 5.0 viser kun UTF-8, UTF-16 og UTF-32. Der er også en modificeret version, specificeret i RFC 2060 , som nogle gange identificeres som UTF-7.
Nogle tegn kan repræsenteres direkte som enkelte ASCII-bytes. De danner en gruppe af såkaldte "direkte tegn" på 52 latinske bogstaver, 10 tal og 9 tegnsætningstegn ' ( ) , - . / : ?:. Direkte tegn er sikre, når de vises bogstaveligt. Den anden hovedgruppe, kendt som "valgfri direkte tegn", indeholder alle andre udskrivbare tegn i området U+0020—U+007Eundtagen ~ \ +mellemrummet. Brugen af valgfri videresendelsestegn reducerer størrelsen og forbedrer læsbarheden, men øger også chancen for, at information beskadiges af faktorer som dårligt designede mail-gateways, og det kan kræve yderligere escape, når du bruger valgfrie videresendtegn i kodede ord til overskriftsfelter.
Mellemrum, tabulator, vognretur og linjeskift kan også repræsenteres direkte som enkelt ASCII-bytes. Men hvis kodet tekst skal bruges i e-mail, skal man sørge for, at disse tegn ikke kræver yderligere kodning af det transmitterede indhold, der er egnet til e-mail. Plustegnet +kan kodes som +-.
Andre tegn skal først kodes i UTF-16 (tegn med koder fra U+10000og over vil blive kodet i surrogater) big-endian (høje bits i slutningen) og derefter modificeret til Base64-koder. Begyndelsen af sådanne blokke af tegn kodet i UTF-16 og modificeret i Base64 er angivet med +. Slutningen af blokke er angivet med ethvert tegn, der ikke er en del af Base64-modifikatorsættet. Hvis tegnet efter at være blevet ændret til Base64 er -(bindestreg-minus ASCII), så springes det over af dekoderen, og afkodningen genoptages ved det næste tegn. Ellers genoptages afkodningen med et tegn efter Base64.
8BITMIME blev også introduceret for at reducere behovet for at kode meddelelsestekster i 7-bit format.
| Hexadecimal
koden |
0 | 0 | EN | 3 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| binær kode | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | en | 0 | en | 0 | 0 | 0 | en | en | 0 | 0 |
| Indeks | 0 | ti | 12 | |||||||||||||||
| Base64 kode | EN | K | M | |||||||||||||||
Først skal indkoderen bestemme, hvilke tegn der kan repræsenteres direkte i ASCII-format, bortset fra plustegnet +, som er kodet som +-, og hvilke tegn der skal markeres som Unicode-tegnblokke. En simpel indkoder kan direkte kode alle tegn, den anser for sikre til direkte kodning. Det er dog en god idé at afslutte en Unicode-sekvens med ét tegn direkte i ASCII og derefter starte en anden Unicode-sekvens, der indeholder 3 til 3⅔ bytes. Dette er mere end de 2⅔ bytes, der kræves for at repræsentere et tegn som en del af en Unicode-sekvens.
Hver sekvens af Unicode-tegn skal kodes ved hjælp af følgende procedure og derefter omgivet af de relevante afgrænsningstegn. For eksempel bruger vi rækkefølgen af symboler £† ( U+00A3 U+2020):
0x00A3 → 0000 0000 1010 0011
Først skal de kodede data adskilles i almindelige ASCII-tekststykker (inklusive plustegn efterfulgt af en bindestreg +-) og ikke-tomme Unicode-blokke, som angivet i beskrivelsesafsnittet. Når dette er gjort, skal hver Unicode-blok afkodes med følgende procedure (ved hjælp af resultatet af kodningseksemplet ovenfor):
En Unicode-markør (ofte omtalt som et "BOM" - byte-order-mærke) er en valgfri speciel sekvens af bytes helt i begyndelsen af en strøm eller fil, der, selvom det ikke er data i sig selv, angiver den kodning, der bruges til efterfølgende data; markøren bruges, når der ikke er nogen metadata, der angiver kodningen. For et givet kodningsskema er signaturen repræsentationen af skemaet ved et Unicode-kodepunkt U+FEFF, det såkaldte BOM-tegn.
Mens en Unicode-markør generelt er en enkelt fast sekvens af bytes, introducerer UTF-7-specificiteten 5 variationer: de sidste 2 bits af den 4. byte af UTF-7-kodningen U+FEFFrefererer til det næste tegn, hvilket resulterer i 4 mulige bitmønstre og dermed , 4 forskellige mulige bytes i 4. position. Den femte variation er nødvendig for at gøre det tilfælde, hvor ingen tegn følger markøren overhovedet. Se Bestemmelse af kodning efter bytesekvensmarkør .
UTF-7 tillader flere repræsentationer af den samme kildestreng. Især ASCII-tegn kan repræsenteres som en del af Unicode-blokke. Således, hvis standard ASCII-baserede escape- eller autentificeringsalgoritmer bruges til strenge, der senere kan fortolkes som UTF-7, kan Unicode-blokke bruges til at injicere ondsindede strenge, der frit passerer gennem validering. For at løse dette problem bør valideringssystemer udføre afkodning før validering og bør ikke forsøge automatisk at detektere UTF-7.
Ældre versioner af Internet Explorer kan narre til at fortolke siden som UTF-7. Dette kan bruges til at angribe cross-site scripting, da tjenestetegn <og >kan kodes som +ADw-i +AD4-UTF-7, som de fleste validatorer videregiver som almindelig tekst.