UTF -7 - UTF-7

UTF-7
Jazyk (y) Mezinárodní
Standard RFC  2152
Klasifikace Transformační formát Unicode , brnění ASCII , kódování s proměnnou šířkou , stavové kódování
Transformuje / kóduje Unicode
Předchází HZ-GB-2312
Uspěl UTF-8 přes 8 BITMIME

UTF-7 ( 7bitový formát transformace Unicode ) je zastaralé kódování znaků s proměnnou délkou pro reprezentaci textu Unicode pomocí proudu znaků ASCII . Původně měl poskytnout způsob kódování textu Unicode pro použití v internetových e-mailových zprávách, který byl účinnější než kombinace UTF-8 s tiskem v uvozovkách .

UTF-7 (podle RFC) není „ formát transformace Unicode “, protože definice může kódovat pouze body kódu v BMP (prvních 65536 bodů kódu Unicode, které nezahrnují emodži a mnoho dalších znaků). Pokud je však překladač UTF-7 do/z UTF-16, pak může (a pravděpodobně ano) kódovat každou náhradní polovinu, jako by to byl 16bitový kódový bod, a tak může kódovat všechny kódové body. Není jasné, zda to podporuje další software UTF-7 (například překladače do UTF-32 nebo UTF-8).

UTF-7 nikdy nebyl oficiálním standardem Unicode Consortium . Je známo, že má problémy se zabezpečením, a proto byl software změněn, aby bylo zakázáno jeho používání. Je zakázáno v HTML 5 .

Motivace

MIME , moderní standard formátu elektronické pošty, zakazuje kódování záhlaví pomocí bajtových hodnot nad rozsah ASCII. Ačkoli MIME umožňuje kódování těla zprávy v různých znakových sadách (širších než ASCII), základní přenosová infrastruktura ( SMTP , hlavní standard přenosu e-mailů) stále není zaručena jako 8bitová čistota . V případě pochybností proto musí být použito netriviální kódování přenosu obsahu. Base64 má bohužel nevýhodu v tom, že dokonce i znaky US-ASCII jsou u klientů jiných než MIME čitelné. Na druhou stranu UTF-8 v kombinaci s tiskem v uvozovkách vytváří velmi neefektivní formát, který vyžaduje 6–9 bytů pro znaky jiné než ASCII z BMP a 12 bytů pro znaky mimo BMP.

Za předpokladu, že jsou během kódování dodržována určitá pravidla, lze UTF-7 odesílat e-mailem bez použití základního kódování přenosu MIME , ale přesto musí být explicitně identifikováno jako textová znaková sada. Pokud je navíc použit v záhlavích e-mailů, jako je například „Předmět:“, musí být UTF-7 obsažena ve slovech kódovaných MIME identifikujících znakovou sadu. Protože kódovaná slova vynucují použití buď citovaného tisku nebo base64 , UTF-7 byl navržen tak, aby se vyhnul použití znaku = jako únikového znaku, aby se zabránilo dvojitému úniku, pokud je kombinován s tisknutelným tiskem (nebo jeho variantou, RFC 2047/1522 „Q?-kódování záhlaví).

UTF-7 se obecně nepoužívá jako nativní reprezentace v aplikacích, protože zpracování je velmi nepříjemné. I přes svou velikostní výhodu oproti kombinaci UTF-8 s nabídkou pro tisk v uvozovkách nebo base64, dnes již zaniklé Internet Mail Consortium doporučilo jeho použití.

Byl také představen 8BITMIME , který snižuje potřebu kódování těl zpráv v 7bitovém formátu.

V protokolech pro získávání e-mailů IMAP pro názvy poštovních schránek se v současné době používá upravená forma UTF-7 (někdy přezdívaná 'mUTF-7') .

Popis

UTF-7 byl poprvé navržen jako experimentální protokol v RFC 1642, Mail-Safe Transformation Format of Unicode . Tento RFC byl zastaralý RFC 2152, informačním RFC, který se nikdy nestal standardem. Jak jasně uvádí RFC 2152, RFC „neurčuje žádný internetový standard“. Navzdory tomu je RFC 2152 citován jako definice UTF-7 v seznamu znakových sad IANA. UTF-7 není ani standardem Unicode. Unicode Standard 5.0 uvádí pouze UTF-8, UTF-16 a UTF-32. K dispozici je také upravená verze, specifikovaná v RFC 2060, která je někdy označována jako UTF-7.

Některé znaky mohou být reprezentovány přímo jako jednotlivé bajty ASCII. První skupina je známá jako „přímé znaky“ a obsahuje 62 alfanumerické znaky a symboly 9: ' ( ) , - . / : ?. Přímé postavy lze bezpečně zahrnout doslova. Druhá hlavní skupina, známá jako „volitelné přímé znaky“, obsahuje všechny ostatní tisknutelné znaky v rozsahu U+ 0020 –U+ 007E kromě ~ \ +a mezery (znaky \a ~jsou vyloučeny z důvodu předefinování ve „variantách ASCII“, jako je JIS- Roman ). Použití volitelných přímých znaků zmenšuje velikost a zvyšuje čitelnost pro člověka, ale také zvyšuje šanci na poškození věcmi, jako jsou špatně navržené poštovní brány, a může vyžadovat zvláštní únik při použití v kódovaných slovech pro pole záhlaví.

Prostor, záložka, návrat na začátek řádku a posuv řádku mohou být také reprezentovány přímo jako jednotlivé bajty ASCII. Má-li být však kódovaný text použit v e-mailu, je třeba dbát na to, aby tyto znaky byly používány způsoby, které nevyžadují další kódování přenosu obsahu, aby bylo vhodné pro e-maily. Znak plus ( +) může být kódován jako +-.

Ostatní znaky musí být zakódovány v UTF-16 (tedy U+10 000 a vyšší by byly zakódovány do dvou náhrad) a poté v upraveném Base64 . Začátek těchto bloků upraveného UTF-16 kódovaného Base64 je označen +znaménkem. Konec je označen libovolným znakem, který není v upravené sadě Base64. Pokud je znak za upraveným Base64 -( pomlčka ASCII -minus ), pak je spotřebován dekodérem a dekódování pokračuje s dalším znakem. Jinak se dekódování obnoví se znakem za base64.

Příklady

  • Hello, World!“ je kódováno jako „ Hello, World+ACE-
  • 1 + 1 = 2“ je kódováno jako „ 1 +- 1 +AD0- 2
  • £1“ je kódováno jako „ +AKM-1“. Bod kódu Unicode pro znak libry je U+00A3, který se převádí na upravený Base64, jak je uvedeno v tabulce níže. Zbývají dva bity, které jsou polstrovány na 0.
Hex číslice 0 0 A 3  
Bitový vzor 0 0 0 0 0 0 0 0 1 0 1 0 0 0 1 1 0 0
Index 0 10 12
Zakódováno Base64 A K M

Algoritmus pro kódování a dekódování

Kódování

Kodér se nejprve musí rozhodnout, které znaky budou přímo reprezentovat ve formě ASCII, které +musí být uniklé jako +-a které umístit do bloků znaků Unicode. Jednoduchý kodér může přímo kódovat všechny znaky, které považuje za bezpečné pro přímé kódování. Náklady na ukončení sekvence Unicode, výstup jednoho znaku přímo v ASCII a spuštění další sekvence Unicode jsou však 3 až 3+2 / 3 bajty. To je více než 2+2 / 3 bajty potřebné k reprezentaci znaku jako součást sekvence Unicode. Každá sekvence Unicode musí být kódována pomocí následujícího postupu a poté obklopena příslušnými oddělovači.

Jako příklad použijte sekvenci znaků £ † (U+00A3 U+2020):

  1. Vyjádřete čísla Unicode postavy (UTF-16) binárně:
  2. Zřetězte binární sekvence:
    0000 0000 1010 0011 a 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
  3. Seskupte binární soubor do skupin po šesti bitech, počínaje zleva:
    0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00
  4. Pokud má poslední skupina méně než šest bitů, přidejte koncové nuly:
    000000 001010 001100 100000 001000 00 → 000000 001010 001100 100000 001000 000000
  5. Nahraďte každou skupinu šesti bitů příslušným kódem Base64:
    000000 001010 001100 100000 001000 000000 → AKMgIA

Dekódování

Nejprve musí být kódovaná data rozdělena na obyčejné textové bloky ASCII (včetně + es následovaných pomlčkou) a neprázdné bloky Unicode, jak je uvedeno v části popisu. Jakmile to bude hotové, každý blok Unicode musí být dekódován následujícím postupem (pomocí výsledku výše uvedeného příkladu kódování jako našeho příkladu)

  1. Každý kód Base64 vyjádřete jako bitovou sekvenci, kterou představuje:
    AKMgIA → 000000 001010 001100 100000 001000 000000
  2. Seskupte binární soubor do skupin po šestnácti bitech, počínaje zleva:
    000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
  3. Pokud je na konci neúplná skupina obsahující pouze nuly, zrušte ji (pokud neúplná skupina nějaké obsahuje, kód je neplatný):
    0000000010100011 0010000000100000
  4. Každá skupina 16 bitů je znakové číslo Unicode (UTF-16) a může být vyjádřeno jinými formami:
    0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 10

Bajtová značka objednávky

Značka pořadí bajtů (BOM) je volitelná speciální bajtová sekvence na samém začátku proudu nebo souboru, která, aniž by byla samotnými daty, označuje kódování použité pro následující data; lze jej použít bez metadat, která označují kódování. Pro dané schéma kódování je to reprezentace tohoto schématu bodu kódu Unicode U+FEFF.

I když je to obvykle jedna, pevná bajtová sekvence, v UTF-7 se mohou objevit čtyři varianty, protože poslední 2 bity 4. bajtu kódování UTF-7 U+FEFFpatří následujícímu znaku, což má za následek 4 možné bitové vzory a tedy 4 různé možné bajty na 4. pozici. Viz položka UTF-7 v tabulce značek pořadí bajtů Unicode .

Bezpečnostní

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 jsou tedy na řetězcích, které mohou být později interpretovány jako UTF-7, použity standardní únikové nebo ověřovací procesy založené na ASCII, pak lze bloky Unicode použít k proklouznutí škodlivých řetězců kolem nich. Aby se tento problém zmírnil, systémy by měly provést dekódování před validací a neměly by se pokoušet o automatické zjišťování UTF-7.

Starší verze aplikace Internet Explorer lze přimět, aby stránku interpretovaly jako UTF-7. To lze použít pro skriptovací útok mezi weby, protože značky <a >mohou být kódovány jako +ADw-a +AD4-v UTF-7, což většina validátorů propustila jako jednoduchý text.

UTF-7 je považován za zastaralý, přinejmenším pro software společnosti Microsoft (.NET), přičemž cesty kódu, které jej dříve podporovaly, byly záměrně přerušeny (aby se předešlo problémům se zabezpečením) v .NET 5 v roce 2020.

Reference

Viz také