UTF-7 (z anglického 7-bit Unicode Transformation Format - “Unicode transformační formát, 7 bitů”) Formát kódování textu Unicode s proměnnou délkou znakových slov do sekvence znaků ASCII. Původně zamýšlel kódovat text Unicode v internetových e-mailových zprávách, což bylo efektivnější než kombinace UTF-8 s uvozovkami-tisknutelnými.
Současný standard e-mailového formátu MIME zakazuje kódování záhlaví pomocí bajtových hodnot nad rozsahem ASCII. Přestože MIME umožňuje kódování těla zprávy do různých znakových sad (širších než ASCII), základní přenosová infrastruktura (SMTP, hlavní standard pro přenos e-mailů) stále nezaručuje 8bitovou čistotu. Proto je v případě pochybností nutné použít netriviální kódování přenášeného obsahu. Bohužel Base64 má tu nevýhodu, že ani znaky US-ASCII nejsou čitelné pro klienty, kteří nejsou MIME. Na druhou stranu je UTF-8 v kombinaci s uvozovkami-tisknutelnými formáty velmi neefektivní, vyžadující 6-9 bajtů pro ne-ASCII znaky z BMP (Basic Multilingual Plane) a 12 bajtů pro ne-BMP znaky.
Pokud jsou během kódování dodržena určitá pravidla, lze text v kódování UTF-7 odeslat e-mailem bez použití základního kódování přenosu MIME, ale musí být výslovně označen jako textová znaková sada. Také, pokud jsou použity v hlavičkách e-mailů, jako je "Předmět:", musí být UTF-7 obsaženo ve slovech kódovaných MIME, která identifikují znakovou sadu. Protože kódovaná slova používají buď sady pro tisk v uvozovkách nebo Base64, bylo UTF-7 navrženo s možností nepoužívat znak rovná se = jako znak escape, aby se zabránilo dvojitému přeskočení v kombinaci s uvozovkami-tisknutelnými (nebo její variantou v RFC ). 2047 /1522 ?Q?-kódování záhlaví).
UTF-7 se v aplikacích zpravidla nepoužívá ve své nativní podobě, protože je velmi nepohodlné pro zpracování. Ačkoli UTF-7 má přednost před kombinacemi UTF-8 s uvozovkami pro tisk nebo Base64, dnes již neexistující Internet Mail Consortium nedoporučuje používat kódování UTF-7. [jeden]
8BITMIME byl také představen, aby se snížila potřeba kódování těla zpráv v 7bitovém formátu.
Upravenou formu UTF-7 (mUTF-7, UTF-7 IMAP) v současnosti používá e-mailový protokol IMAP pro vyhledávání názvů poštovních schránek [2] .
UTF-7 byl původně navržen jako experimentální protokol v RFC 1642 „A Mail-Safe Transformation Format of Unicode“. Tento RFC je zastaralý z RFC 2152 , informačního RFC, který nikdy nebyl standardem. Jak je uvedeno v RFC 2152 , "RFC nedefinuje internetový standard žádného typu." Bez ohledu na to je RFC 2152 citován jako definice UTF-7 v seznamu kódování IANA. UTF-7 také není standard Unicode. Unicode Standard 5.0 uvádí pouze UTF-8, UTF-16 a UTF-32. Existuje také upravená verze, specifikovaná v RFC 2060 , která je někdy identifikována jako UTF-7.
Některé znaky mohou být reprezentovány přímo jako jednotlivé ASCII bajty. Tvoří skupinu tzv. "přímých znaků" 52 latinských písmen, 10 číslic a 9 interpunkčních znaků: ' ( ) , - . / : ?. Přímé znaky jsou bezpečné, když jsou zobrazeny doslova. Druhá hlavní skupina, známá jako "volitelné přímé znaky", obsahuje všechny ostatní tisknutelné znaky v rozsahu U+0020—U+007Ekromě ~ \ +mezery. Použití volitelných dopředných znaků zmenšuje velikost a zlepšuje čitelnost, ale také zvyšuje pravděpodobnost, že informace budou poškozeny faktory, jako jsou špatně navržené poštovní brány, a může vyžadovat další escapování při použití volitelných dopředných znaků v kódovaných slovech pro pole záhlaví.
Mezera, tabulátor, návrat vozíku a posun řádku mohou být také reprezentovány přímo jako jednotlivé bajty ASCII. Pokud však má být v e-mailu použit kódovaný text, je třeba dbát na to, aby tyto znaky nevyžadovaly dodatečné kódování přenášeného obsahu vhodného pro e-mail. Znaménko plus +lze zakódovat jako +-.
Ostatní znaky musí být nejprve zakódovány v UTF-16 (znaky s kódy od U+10000a výše budou zakódovány v zástupných kódech) big-endian (vysoké bity na konci) a poté upraveny na kódy Base64. Začátek takových bloků znaků kódovaných v UTF-16 a upravených v Base64 je označen +. Konec bloků je označen libovolným znakem, který není součástí sady modifikátorů Base64. Pokud je znak po úpravě na Base64 -(pomlčka-minus ASCII), pak je dekodérem přeskočen a dekódování pokračuje dalším znakem. Jinak se dekódování obnoví znakem po Base64.
8BITMIME byl také představen, aby se snížila potřeba kódování těla zpráv v 7bitovém formátu.
| Hexadecimální
kód |
0 | 0 | A | 3 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| binární kód | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | jeden | 0 | jeden | 0 | 0 | 0 | jeden | jeden | 0 | 0 |
| Indexy | 0 | deset | 12 | |||||||||||||||
| Base64 kód | A | K | M | |||||||||||||||
Nejprve musí kodér určit, které znaky mohou být reprezentovány přímo ve formátu ASCII, kromě znaménka plus +, které je zakódováno jako +-, a které znaky je třeba označit jako bloky znaků Unicode. Jednoduchý kodér může přímo zakódovat všechny znaky, které považuje za bezpečné pro přímé kódování. Je však dobré ukončit sekvenci Unicode jedním znakem přímo v ASCII a poté začít další sekvenci Unicode obsahující 3 až 3⅔ bajtů. To je více než 2⅔ bajtů potřebné k reprezentaci znaku jako součásti sekvence Unicode.
Každá sekvence znaků Unicode musí být zakódována pomocí následujícího postupu a poté ohraničena příslušnými oddělovači. Například použijeme posloupnost symbolů £† ( U+00A3 U+2020):
0x00A3 → 0000 0000 1010 0011
Nejprve musí být zakódovaná data rozdělena na prosté části textu ASCII (včetně znamének plus následovaných pomlčkou +-) a neprázdných bloků Unicode, jak je uvedeno v části popisu. Jakmile to uděláte, každý blok Unicode musí být dekódován následujícím postupem (s použitím výsledku výše uvedeného příkladu kódování):
Značka Unicode (často označovaná jako "BOM" - značka pořadí bajtů) je volitelná speciální sekvence bajtů na samém začátku toku nebo souboru, která, i když sama o sobě není daty, určuje kódování použité pro následující data; značka se používá, když neexistují žádná metadata označující kódování. Pro dané schéma kódování je podpis reprezentací schématu v bodě kódu Unicode U+FEFF, tzv. znak kusovníku.
Zatímco značka Unicode je obecně jediná pevná sekvence bajtů, specifičnost UTF-7 zavádí 5 variant: poslední 2 bity 4. bajtu kódování UTF-7 U+FEFFodkazují na další znak, což vede ke 4 možným bitovým vzorům, a tedy , 4 různé možné bajty na 4. pozici. Pátá varianta je potřebná k vyjasnění případu, kdy za značkou nenásledují vůbec žádné znaky. Viz Určení kódování podle značky bajtové sekvence .
UTF-7 umožňuje více reprezentací stejného zdrojového řetězce. Zejména znaky ASCII mohou být reprezentovány jako součást bloků Unicode. Pokud se tedy pro řetězce, které mohou být později interpretovány jako UTF-7, používají standardní escapovací nebo ověřovací algoritmy založené na ASCII, pak lze bloky Unicode použít k vložení škodlivých řetězců, které volně procházejí validací. K vyřešení tohoto problému by ověřovací systémy měly provést dekódování před ověřením a neměly by se pokoušet automaticky detekovat UTF-7.
Starší verze Internet Exploreru lze oklamat, aby stránku interpretovaly jako UTF-7. To lze použít k útoku na skriptování napříč weby, protože servisní znaky <a >mohou být kódovány jako +ADw-v +AD4-UTF-7, které většina validátorů předává jako prostý text.