Il BOM è opzionale per UTF-16 e UTF-32?

Question

Il BOM è opzionale per UTF-16 e UTF-32?

#1 da (4 voti)

3

Ero solito pensare che il BOM fosse opzionale per UTF-8, ma obbligatorio per UTF-16 e UTF-32.

Tuttavia, ho letto quanto segue (in questo articolo ):

Let's look just at the ones that Notepad supports.

8-bit ANSI (of which 7-bit ASCII is a subset). These have no BOM; they just dive right in with bytes of text. They are also probably the most common type of text file.

UTF-8. These usually begin with a BOM but not always.

Unicode big-endian (UTF-16BE). These usually begin with a BOM but not always.

Unicode little-endian (UTF-16LE). These usually begin with a BOM but not always.

Quindi il blocco note non è conforme allo standard Unicode o lo standard Unicode dice che il BOM è opzionale per UTF-16?

unicode character-encoding

posta user9002947 28.04.2018 - 07:11

fonte

1 risposta

Leggi altre domande sui tag unicode character-encoding

Come si verifica I / O per file di dati di grandi dimensioni? Come far fronte a progetti molto simili

score 4 · Answer 1

Il BOM è completamente opzionale. Tuttavia, per decodificare UTF-16 è necessario conoscere l'ordine dei byte corretto. Se decodifichi con l'ordine dei byte errato, generalmente riceverai anche dei codepoint validi. Per conoscere l'ordine dei byte corretto, noi

o conosce l'ordine dei byte da una fonte esterna, ad es. documentazione che afferma "questo strumento produrrà sempre output UTF-16LE",
o il testo codificato contiene una BOM.

Ad esempio, lo standard XML è definito in modo tale i documenti XML possono facoltativamente iniziare con una distinta materiali, ma la dichiarazione <?xml all'inizio può anche essere utilizzata per determinare la codifica.

Gli editor o i browser Web devono lavorare ragionevolmente anche quando mancano le distinte base e la codifica è ambigua. Possono utilizzare dati statistici, ad es. sulle frequenze dei caratteri attesi per indovinare, ma alla fine l'utente dovrebbe essere in grado di sovrascrivere la codifica.

Se osserviamo le specifiche Unicode (versione 10.0), allora la sezione 2.6 Schemi di codifica afferma:

When a higher-level protocol supplies mechanisms for handling the endianness of integral data types, it is not necessary to use Unicode encoding schemes or the byte order mark. In those cases Unicode text is simply a sequence of integral data types.

vale a dire. come spiegato sopra, il BOM non è necessario quando disponiamo di informazioni esterne sull'ordine dei byte. Tuttavia, è necessario che una distinta materiali debba essere compresa da alcuni software che gestiscono Unicode. Dalla sezione 23.8 Speciali :

Where the byte order is explicitly specified, such as in UTF-16BE or UTF-16LE, then all U+FEFF characters—even at the very beginning of the text—are to be interpreted as zero width no-break spaces. Similarly, where Unicode text has known byte order, initial U+FEFF characters are not required, but for backward compatibility are to be interpreted as zero width no-break spaces. […]

Systems that use the byte order mark must recognize when an initial U+FEFF signals the byte order. In those cases, it is not part of the textual content and should be removed before processing, because otherwise it may be mistaken for a legitimate zero width no-break space.

Nella sezione 3.10 Schemi di codifica , vengono definite varie codifiche UTF. Qui, UTF-16LE, UTF16BE e UTF-16 sono diverse codifiche . Le varianti LE e BE non hanno una distinta base. Per UTF-16:

The UTF-16 encoding scheme may or may not begin with a BOM. However, when there is no BOM, and in the absence of a higher-level protocol, the byte order of the UTF-16 encoding scheme is big-endian.

Equivalentemente per UTF-32LE, UTF-32BE e UTF-32.

Quindi lo standard Unicode stabilisce che il BOM è facoltativo e impone come il software deve gestire la presenza o l'assenza di una BOM in varie circostanze. Il software compatibile con Unicode che non gestisce il testo codificato senza BOM è rotto.