Značka objednávky bytu - Byte order mark - Wikipedia

„FEFF“ přeadresuje tady. Informace o letišti ve Středoafrické republice s kódem letiště FEFF viz Mezinárodní letiště Bangui M'Poko. Program používaný v rentgenové absorpční spektroskopii viz FEFF (software). Název U + FEFF v Unicode a alternativní použití jako neporušeného prostoru s nulovou šířkou viz Slovo truhlář.

The značka pořadí bytů (Kusovníku) je zvláštní použití speciálu Unicode charakter, U + FEFF ZNAČKA OBJEDNÁVKY BYTE, jejíž vzhled jako magické číslo na začátku textového proudu může signalizovat několik věcí do a program čtení textu:[1]

  • Pořadí bajtů nebo endianismus, textového proudu v případě 16bitového a 32bitového kódování;
  • Skutečnost, že kódování textového proudu je Unicode, s vysokou mírou jistoty;
  • Které kódování znaků Unicode se používá.

Použití kusovníku je volitelné. Jeho přítomnost narušuje použití UTF-8 softwarem, který na začátku souboru neočekává bajty jiné než ASCII, ale který by jinak mohl zpracovat textový proud.

Unicode lze kódovat v jednotkách 8bitových, 16bitových nebo 32bitových celých čísel. U 16- a 32bitových reprezentací musí počítač přijímající text z libovolných zdrojů vědět, do kterého bajtového pořadí jsou celá čísla zakódována. Kusovník je kódován ve stejném schématu jako zbytek dokumentu a stává se bez charakteru Bod kódu Unicode, pokud jsou zaměněny jeho bajty. Proces, který přistupuje k textu, tedy může prozkoumat těchto prvních několik bajtů, aby určil endiannost, aniž by vyžadoval nějakou smlouvu nebo metadata mimo samotný textový proud. Přijímající počítač obecně v případě potřeby vymění bajty podle své vlastní endianity a již nebude potřebovat kusovník pro zpracování.

Sekvence bajtů kusovníku se liší podle kódování Unicode (včetně těch, které jsou mimo standard Unicode, například UTF-7 viz tabulka níže ) a žádná ze sekvencí se pravděpodobně neobjeví na začátku textových proudů uložených v jiných kódováních. Proto umístění kódovaného kusovníku na začátek textového proudu může znamenat, že text je Unicode, a identifikovat použité kódovací schéma. Toto použití znaku Kusovníku se nazývá „podpis Unicode“.[2]

Používání

Pokud se znak kusovníku objeví uprostřed datového proudu, Unicode říká, že by měl být interpretován jako „nerozbitný prostor s nulovou šířkou "(inhibuje zalomení řádku mezi slovními glyfy). V Unicode 3.2 je toto použití zastaralé ve prospěch" "Slovo truhlář "znak, U + 2060.[1] To umožňuje použití U + FEFF pouze jako kusovníku.

UTF-8

The UTF-8 reprezentace kusovníku je (hexadecimální ) sekvence bajtů 0xEF, 0xBB, 0xBF.

Standard Unicode umožňuje kusovník v UTF-8,[3] ale nevyžaduje ani nedoporučuje jeho použití.[4] Pořadí bytů nemá v UTF-8 žádný význam,[5] takže jeho jediným použitím v UTF-8 je signalizovat na začátku, že textový proud je kódován v UTF-8, nebo že byl převeden na UTF-8 z proudu, který obsahoval volitelný kusovník. Standard také nedoporučuje odebrání kusovníku, když je tam, aby obousměrné vypnutí mezi kódováním neztratilo informace a aby kód, který se na něj spoléhá, ​​pokračoval v práci.[6][7] IETF doporučuje, že pokud protokol buď (a) vždy používá UTF-8, nebo (b) má nějaký jiný způsob, jak označit, jaké kódování se používá, pak „BY MĚLO zakázat použití U + FEFF jako podpisu“.[8]

Nepoužívání kusovníku umožňuje, aby byl text zpětně kompatibilní s některým softwarem, který nepodporuje Unicode. Mezi příklady patří programovací jazyky, které umožňujíASCII bajtů v řetězcové literály ale ne na začátku souboru.

UTF-8 je řídké kódování v tom smyslu, že velká část možných bajtových kombinací nevede k platnému textu UTF-8. Binární data a text v jakémkoli jiném kódování pravděpodobně obsahují sekvence bajtů, které jsou neplatné jako UTF-8. Prakticky jedinou výjimkou jsou případy, kdy se text skládá čistě z bajtů rozsahu ASCII. Protože všechna moderní kódování používají k reprezentaci znaků ASCII bajty v rozsahu ASCII, text pouze pro ASCII lze bezpečně interpretovat jako UTF-8 bez ohledu na to, jaké kódování bylo zamýšleno systémem, který emitoval bajty. Z těchto důvodů může heuristická analýza s vysokou spolehlivostí detekovat, zda se používá UTF-8, aniž by vyžadoval kusovník.

Microsoft překladače[9] a tlumočníci a mnoho dalšího softwaru Microsoft Windows jako poznámkový blok zacházejte s kusovníkem podle potřeby magické číslo spíše než používat heuristiku. Tyto nástroje přidávají kusovník při ukládání textu jako UTF-8 a nemohou interpretovat UTF-8, pokud není k dispozici kusovník nebo soubor obsahuje pouze ASCII. Windows PowerShell (až 5,1) přidá kusovník, když uloží dokumenty XML UTF-8. PowerShell Core 6 však přidal přepínač -Encoding na některé rutiny zvané utf8NoBOM, takže lze dokument uložit bez kusovníku. Google dokumenty také přidá kusovník při převodu dokumentu na prostý text soubor ke stažení.

UTF-16

v UTF-16, kusovník (U + FEFF) může být umístěn jako první znak souboru nebo znakového streamu k označení endianity (pořadí bajtů) všech 16bitových kódových jednotek souboru nebo streamu. Dojde-li k pokusu o přečtení tohoto streamu s nesprávnou endianitou, dojde k výměně bajtů, čímž se doručí znak U + FFFE, který je definováno Unicode jako „neznak“, který by se nikdy neměl objevit v textu.

  • Pokud jsou 16bitové jednotky zastoupeny v big-endian pořadí bajtů, kusovník se zobrazí v pořadí bajtů jako 0x FE 0xFF
  • Pokud 16bitové jednotky používají malý Endian pořadí, kusovník se zobrazí v pořadí bajtů jako 0xFF 0xFE

Ani jedna z těchto sekvencí není platná UTF-8, takže jejich přítomnost naznačuje, že soubor není v UTF-8 zakódován.

Pro IANA registrované znakové sady UTF-16BE a UTF-16LE by se neměla používat značka pořadí bytů, protože názvy těchto znakových sad již určují pořadí bytů. Pokud narazíte kdekoli v takovém textovém proudu, U + FEFF má být interpretován jako „prostor bez přerušení s nulovou šířkou“.

Pokud není k dispozici kusovník, je možné uhodnout, zda je text UTF-16 a jeho bajtové pořadí, hledáním ASCII znaků (tj. 0 bajtů sousedících s bajty v rozsahu 0x20-0x7E, také 0x0A a 0x0D pro CR a LF). Velké číslo (tj. Mnohem vyšší než náhodná náhoda) ve stejném pořadí je velmi dobrou indikací pro UTF-16 a to, zda je 0 v sudých nebo lichých bajtech, označuje pořadí bajtů. To však může mít za následek oba falešně pozitivní a falešně negativní.

Ustanovení D98 o shodě (část 3.10) standardu Unicode uvádí: „Schéma kódování UTF-16 může nebo nemusí začínat kusovníkem. Pokud však žádný kusovník neexistuje a při absenci protokolu vyšší úrovně se pořadí bytů v kódovacím schématu UTF-16 je big-endian. " Zda je či není v platnosti protokol vyšší úrovně, lze interpretovat. Například u souborů, které jsou lokální v počítači, pro který je nativní řazení bajtů malé, může být argumentováno, že jsou implicitně kódovány jako UTF-16LE. Proto je domněnka big-endianu široce ignorována. The W3C /WHATWG standard kódování používaný v HTML5 specifikuje, že obsah označený buď „utf-16“ nebo „utf-16le“ má být interpretován jako „malý endian“ pro řešení nasazeného obsahu “.[10] Pokud je však přítomna značka pořadí bajtů, je třeba s touto kusovníkem zacházet jako s „autoritativnějším než cokoli jiného“.[11]

Programy, které interpretují UTF-16 jako bajtové kódování, mohou zobrazovat zkomolený nepořádek znaků, ale znaky ASCII by byly rozpoznatelné, protože dolní bajt reprezentace UTF-16 je stejný jako kód ASCII, a proto by se zobrazoval stejně . Horní bajt 0 může být zobrazen jako nic, prázdné místo, tečka nebo nějaký jiný neměnný glyf.

UTF-32

Kusovník lze použít s UTF-32, toto kódování se pro přenos používá jen zřídka. Jinak stejná pravidla jako pro UTF-16 jsou použitelné.

Kusovník pro malý endian UTF-32 je stejný vzor jako kusovník malý-endian UTF-16, za nímž následuje znak NUL, neobvyklý příklad kusovníku je stejný vzor ve dvou různých kódováních. Programátoři využívající kusovník k identifikaci kódování budou muset rozhodnout, zda je pravděpodobnější UTF-32 nebo první znak NUL.

Značky pořadí bajtů kódováním

Tato tabulka ukazuje, jak je znak kusovníku reprezentován jako bajtová sekvence v různých kódováních a jak se tyto sekvence mohou objevit v textovém editoru, který interpretuje každý bajt jako starší kódování (CP1252 a stříška stříška pro Ovládací prvky C0 ):

KódováníZastoupení (hexadecimální )Zastoupení (desetinný )Bajty jako CP1252 znaků
UTF-8[A]EF BB BF239 187 191ï »¿
UTF-16 (BÝT )FE FF254 255tvůj
UTF-16 (LE )FF FE255 254ÿþ
UTF-32 (BÝT)00 00 FE FF0 0 254 255^ @ ^ @ þÿ (^@ je nulový znak )
UTF-32 (LE)FF FE 00 00255 254 0 0ÿþ ^ @ ^ @ (^@ je prázdný znak)
UTF-7[A]2B 2F 76[b]43 47 118+ / v
UTF-1[A]F7 64 4C247 100 76÷ dL
UTF-EBCDIC[A]DD 73 66 73221 115 102 115"Šéfové."
SCSU[A]0E FE FF[C]14 254 255^ Nþÿ (^ N je znak „posunutí“ )
BOCU-1[A]FB EE 28251 238 40ûî (
GB-18030[A]84 31 95 33132 49 149 51„1•3
  1. ^ A b C d E F G Toto není doslovně značka „pořadí bajtů“, protože kódová jednotka v těchto kódováních je jeden bajt, a proto nemůže mít bajty v „nesprávném“ pořadí. Kusovník lze nicméně použít k označení kódování textu, který za ním následuje.[5][12]
  2. ^ Následován 38, 39, 3Anebo 3B (ASCII 8, 9, : nebo ;), v závislosti na tom, jaký je další znak.
  3. ^ SCSU umožňuje další kódování U + FEFF, zobrazený formulář je podpis doporučený v UTR # 6.[13]

Viz také

Reference

  1. ^ A b „FAQ - UTF-8, UTF-16, UTF-32 & BOM“. Unicode.org. Citováno 2017-01-28.
  2. ^ „Standardní verze Unicode® 9.0“ (PDF). Konsorcium Unicode.
  3. ^ „Standard Unicode 5.0, Kapitola 2: Obecná struktura“ (PDF). str. 36. Citováno 2009-03-29. Tabulka 2-4. Sedm schémat kódování Unicode
  4. ^ „Standard Unicode 5.0, Kapitola 2: Obecná struktura“ (PDF). str. 36. Citováno 2008-11-30. Použití kusovníku se pro UTF-8 ani nevyžaduje, ani se nedoporučuje, ale může se s ním setkávat v kontextech, kde se data UTF-8 převádějí z jiných kódovacích forem, které používají kusovník, nebo kde se kusovníček používá jako podpis UTF-8
  5. ^ A b „Často kladené dotazy - UTF-8, UTF-16, UTF-32 a kusovník: Může datový proud UTF-8 obsahovat znak kusovníku (ve formě UTF-8)? Pokud ano, mohu stále předpokládat zbývající bajty UTF-8 jsou v pořadí big-endian? “. Unicode.org. Citováno 2009-01-04.
  6. ^ „Re: pre-HTML5 and the BOM from Asmus Freytag on 2012-07-13 (Unicode Mail List Archive)“. Unicode.org. Citováno 2012-07-14.
  7. ^ „Bug ID: JDK-6378911 UTF-8 decoder handling of byte-order mark has changed“. Bugs.sun.com. Citováno 2017-01-28.
  8. ^ Yergeau, Francois (listopad 2003). UTF-8, transformační formát ISO 10646. IETF. doi:10.17487 / RFC3629. RFC 3629. Citováno 15. května 2014.
  9. ^ Alf P. Steinbach (2011). „Unicode část 1: Přístupy I / O konzoly Windows“. Citováno 24. března 2012. Protože však zdrojový kód C ++ byl kódován jako UTF-8 bez kusovníku (jak je v Linuxu obvyklé), kompilátor Visual C ++ chybně předpokládal, že zdrojový kód byl kódován jako Windows ANSI.
  10. ^ „UTF-16LE“. Standard kódování. WHATWG.
  11. ^ "Dekódovat". Standard kódování. WHATWG.
  12. ^ „RFC 3629 - UTF-8, transformační formát ISO 10646“. Tools.ietf.org. 2003-11-08. Citováno 2017-01-28.
  13. ^ Markus Scherer. „UTS # 6: Compression Scheme for Unicode“. Unicode.org. Citováno 2017-01-28.

externí odkazy