unicode - without - Qual é a diferença entre UTF-8 e UTF-8 sem BOM?




utf 8 encoding with bom (14)

O que há de diferente entre UTF-8 e UTF-8 sem uma BOM ? Qual é melhor?


O que há de diferente entre UTF-8 e UTF-8 sem BOM?

Resposta curta: Em UTF-8, uma BOM é codificada como os bytes EF BB BF no início do arquivo.

Resposta longa:

Originalmente, esperava-se que o Unicode fosse codificado em UTF-16 / UCS-2. A lista de materiais foi projetada para este formulário de codificação. Quando você tem unidades de código de 2 bytes, é necessário indicar em que ordem esses dois bytes estão, e uma convenção comum para isso é incluir o caractere U + FEFF como uma "Marca de Ordem de Byte" no início dos dados. O caractere U + FFFE é permanentemente não atribuído para que sua presença possa ser usada para detectar a ordem errada de byte.

O UTF-8 tem a mesma ordem de byte, independentemente da capacidade da plataforma, portanto, uma marca de ordem de byte não é necessária. No entanto, pode ocorrer (como a seqüência de byte EF BB FF ) em dados que foi convertido em UTF-8 de UTF-16 ou como uma "assinatura" para indicar que os dados são UTF-8.

Qual é melhor?

Sem. Como Martin Cote respondeu, o padrão Unicode não recomenda isso. Isso causa problemas com software sem reconhecimento de BOM.

Uma maneira melhor de detectar se um arquivo é UTF-8 é executar uma verificação de validade. O UTF-8 tem regras estritas sobre quais seqüências de bytes são válidas, portanto, a probabilidade de um falso positivo é insignificante. Se uma sequência de bytes se parece com o UTF-8, provavelmente é.


Pergunta: O que há de diferente entre UTF-8 e UTF-8 sem uma lista técnica? Qual é melhor?

Aqui estão alguns trechos do artigo da Wikipedia sobre a marca de ordem de byte (BOM) que acredito oferecer uma resposta sólida para esta pergunta.

Sobre o significado do BOM e UTF-8:

O Padrão Unicode permite a BOM em UTF-8 , mas não requer nem recomenda seu uso. A ordem de bytes não tem significado em UTF-8, portanto, seu uso exclusivo em UTF-8 é sinalizar no início que o fluxo de texto está codificado em UTF-8.

Argumento para NÃO usar uma lista de materiais:

A principal motivação para não usar uma BOM é a compatibilidade com software que não é compatível com Unicode ... Outra motivação para não usar uma BOM é encorajar a UTF-8 como a codificação "padrão".

Argumento PARA usar uma BOM:

O argumento para usar uma BOM é que, sem ela, a análise heurística é necessária para determinar qual codificação de caractere um arquivo está usando. Historicamente, essa análise, para distinguir várias codificações de 8 bits, é complicada, propensa a erros e às vezes lenta. Várias bibliotecas estão disponíveis para facilitar a tarefa, como o Mozilla Universal Charset Detector e o International Components for Unicode.

Os programadores assumem equivocadamente que a detecção de UTF-8 é igualmente difícil (não é por causa da grande maioria das seqüências de bytes serem UTF-8 inválidos, enquanto as codificações que essas bibliotecas estão tentando distinguir permitem todas as possíveis seqüências de bytes). Portanto, nem todos os programas compatíveis com Unicode executam essa análise e, em vez disso, confiam na BOM.

Em particular, os compiladores e intérpretes da Microsoft e muitas partes do software no Microsoft Windows, como o Bloco de Notas, não lerão corretamente o texto UTF-8, a menos que tenha apenas caracteres ASCII ou inicie com a BOM e adicionará uma BOM ao início ao salvar texto como UTF-8. O Google Docs adicionará uma lista de materiais quando um documento do Microsoft Word for baixado como um arquivo de texto simples.

Em qual é melhor, com ou sem o BOM:

O IETF recomenda que, se um protocolo (a) sempre usa UTF-8, ou (b) tem alguma outra maneira de indicar qual codificação está sendo usada, então “deve-se proibir o uso de U + FEFF como assinatura”.

Minha conclusão:

Use o BOM somente se a compatibilidade com um aplicativo de software for absolutamente essencial.

Observe também que, embora o artigo da Wikipédia de referência indique que muitos aplicativos da Microsoft dependem do BOM para detectar corretamente o UTF-8, esse não é o caso de todos os aplicativos da Microsoft. Por exemplo, como apontado por @barlop , ao usar o Prompt de Comando do Windows com UTF-8 , comandos desse type e more não esperam que o BOM esteja presente. Se a lista técnica estiver presente, ela pode ser problemática, como em outras aplicações.

† O comando chcp oferece suporte para UTF-8 ( sem a lista de materiais) por meio da página de códigos 65001 .


A BOM UTF-8 é uma sequência de Bytes no início de um fluxo de texto (EF BB BF) que permite ao leitor adivinhar um arquivo de forma mais confiável como sendo codificado em UTF-8.

Normalmente, a BOM é usada para sinalizar o endianness de uma codificação, mas como a endianness é irrelevante para UTF-8, a BOM é desnecessária.

De acordo com o padrão Unicode , a BOM para arquivos UTF-8 não é recomendada :

2.6 Esquemas de Codificação

... O uso de uma BOM não é obrigatório nem recomendado para UTF-8, mas pode ser encontrado em contextos nos quais os dados UTF-8 são convertidos de outros formulários de codificação que usam uma BOM ou onde a BOM é usada como assinatura UTF-8 . Consulte a subseção "Byte Order Mark" na Seção 16.8, Specials , para mais informações.


As outras respostas excelentes já responderam que:

  • Não há diferença oficial entre UTF-8 e BOM-ed UTF-8
  • Uma string UTF-8 BOM-ed será iniciada com os três bytes seguintes. EF BB BF
  • Esses bytes, se presentes, devem ser ignorados ao extrair a string do arquivo / fluxo.

Mas, como informação adicional para isso, a BOM para UTF-8 poderia ser uma boa maneira de "cheirar" se uma string fosse codificada em UTF-8 ... Ou poderia ser uma string legítima em qualquer outra codificação ...

Por exemplo, os dados [EF BB BF 41 42 43] poderiam ser:

  • A legítima cadeia ISO-8859-1 "ï» ¿ABC "
  • A legítima string UTF-8 "ABC"

Portanto, embora seja legal reconhecer a codificação de um conteúdo de arquivo observando os primeiros bytes, você não deve confiar nisso, como mostra o exemplo acima

As codificações devem ser conhecidas, não divinizadas.


Citado na parte inferior da página da Wikipedia na BOM: http://en.wikipedia.org/wiki/Byte-order_mark#cite_note-2

"O uso de uma BOM não é obrigatório nem recomendado para UTF-8, mas pode ser encontrado em contextos nos quais os dados UTF-8 são convertidos de outras formas de codificação que usam uma BOM ou onde a BOM é usada como uma assinatura UTF-8"


Deve-se notar que, para alguns arquivos, você não deve ter a BOM, mesmo no Windows. Exemplos são arquivos SQL*plus ou VBScript . Caso esses arquivos contenham um BOM, você receberá um erro quando tentar executá-los.


Eu vejo isso de uma perspectiva diferente. Eu acho que o UTF-8 com BOM é melhor , pois fornece mais informações sobre o arquivo. Eu uso UTF-8 sem BOM somente se eu enfrentar problemas.

Eu estou usando vários idiomas (até mesmo Cyrillic ) em minhas páginas por um longo tempo e quando os arquivos são salvos sem BOM e cherouvim -los para edição com um editor (como cherouvim também observou), alguns caracteres estão corrompidos.

Observe que o Notepad clássico do Windows salva automaticamente os arquivos com uma BOM quando você tenta salvar um arquivo recém-criado com a codificação UTF-8.

Pessoalmente, salvo arquivos de script do lado do servidor (.asp, .ini, .aspx) com arquivos BOM e .html sem BOM .


Existem pelo menos três problemas com a colocação de uma lista de materiais em arquivos codificados em UTF-8.

  1. Os arquivos que não contêm texto não estão mais vazios porque sempre contêm a lista de materiais.
  2. Os arquivos que retêm o texto que está dentro do subconjunto ASCII de UTF-8 não são mais eles mesmos ASCII porque a BOM não é ASCII, o que faz com que algumas ferramentas existentes sejam quebradas, e pode ser impossível para os usuários substituírem essas ferramentas legadas.
  3. Não é possível concatenar vários arquivos juntos porque cada arquivo agora tem uma lista de materiais no início.

E, como outros já mencionaram, não é suficiente nem necessário ter uma BOM para detectar que algo é UTF-8:

  • Não é suficiente porque uma sequência de bytes arbitrários pode começar com a sequência exata que constitui a lista de materiais.
  • Não é necessário porque você pode apenas ler os bytes como se fossem UTF-8; se isso for bem sucedido, é, por definição, válido UTF-8.

Quando você quiser exibir informações codificadas em UTF-8, você não poderá enfrentar problemas. Declarar, por exemplo, um documento HTML como UTF-8 e você terá tudo exibido no seu navegador que está contido no corpo do documento.

Mas esse não é o caso quando temos arquivos de texto, CSV e XML, no Windows ou no Linux.

Por exemplo, um arquivo de texto no Windows ou Linux, uma das coisas mais fáceis imagináveis, não é (geralmente) UTF-8.

Salve como XML e declare-o como UTF-8:

<?xml version="1.0" encoding="UTF-8"?>

Ele não será exibido (não será lido) corretamente, mesmo que seja declarado como UTF-8.

Eu tinha uma série de dados contendo letras em francês, que precisavam ser salvos como XML para distribuição. Sem criar um arquivo UTF-8 desde o início (alterando opções no IDE e "Criar novo arquivo") ou adicionando a lista de materiais no início do arquivo

$file="\xEF\xBB\xBF".$string;

Não consegui salvar as letras francesas em um arquivo XML.


UTF-8 com BOM é melhor identificado. Cheguei a essa conclusão da maneira mais difícil. Eu estou trabalhando em um projeto onde um dos resultados é um arquivo CSV , incluindo caracteres Unicode.

Se o arquivo CSV for salvo sem um BOM, o Excel considerará o ANSI e exibirá conteúdo sem sentido. Depois de adicionar "EF BB BF" na frente (por exemplo, salvando-o novamente usando o Bloco de notas com UTF-8; ou o Notepad ++ com UTF-8 com BOM), o Excel abre bem.

A pré-adição do caractere BOM aos arquivos de texto Unicode é recomendada pela RFC 3629: "UTF-8, um formato de transformação de ISO 10646", novembro de 2003 em http://tools.ietf.org/html/rfc3629 (esta última informação encontrada em: http://www.herongyang.com/Unicode/Notepad-Byte-Order-Mark-BOM-FEFF-EFBBBF.html )


Uma diferença prática é que, se você escrever um script de shell para o Mac OS X e salvá-lo como UTF-8 simples, receberá a resposta:

#!/bin/bash: No such file or directory

em resposta à linha shebang especificando qual shell você deseja usar:

#!/bin/bash

Se você salvar como UTF-8, nenhuma BOM (digamos no BBEdit ) ficará bem.


A FAQ da Marca de Ordem de Byte Unicode (BOM) fornece uma resposta concisa:

P: Como devo lidar com as listas de materiais?

A: Aqui estão algumas diretrizes a seguir:

  1. Um protocolo específico (por exemplo, convenções da Microsoft para arquivos .txt) pode exigir o uso da BOM em determinados fluxos de dados Unicode, como arquivos. Quando você precisa estar em conformidade com esse protocolo, use uma BOM.

  2. Alguns protocolos permitem BOMs opcionais no caso de texto não marcado. Nesses casos,

    • Onde um fluxo de dados de texto é conhecido por ser texto simples, mas de codificação desconhecida, a BOM pode ser usada como uma assinatura. Se não houver BOM, a codificação pode ser qualquer coisa.

    • Onde um fluxo de dados de texto é conhecido por ser um texto simples em Unicode (mas não em qual endian), o BOM pode ser usado como uma assinatura. Se não houver BOM, o texto deve ser interpretado como big-endian.

  3. Alguns protocolos orientados por byte esperam caracteres ASCII no início de um arquivo. Se o UTF-8 for usado com esses protocolos, o uso do BOM como codificação de assinatura de formulário deve ser evitado.

  4. Onde o tipo preciso do fluxo de dados é conhecido (por exemplo, Unicode big-endian ou Unicode little-endian), a BOM não deve ser usada. Em particular, sempre que um fluxo de dados é declarado como UTF-16BE, UTF-16LE, UTF-32BE ou UTF-32LE, uma BOM não deve ser usada.


De http://en.wikipedia.org/wiki/Byte-order_mark :

A marca de ordem de bytes (BOM) é um caractere Unicode usado para sinalizar o endianness (ordem de bytes) de um arquivo de texto ou fluxo. Seu ponto de código é U + FEFF. O uso de BOM é opcional e, se usado, deve aparecer no início do fluxo de texto. Além de seu uso específico como um indicador de ordem de bytes, o caractere BOM também pode indicar em qual das várias representações Unicode o texto está codificado.

Sempre usar uma lista de materiais no seu arquivo garantirá que ela sempre abra corretamente em um editor que suporte UTF-8 e BOM.

Meu problema real com a ausência de BOM é o seguinte. Suponha que tenhamos um arquivo que contenha:

abc

Sem o BOM, isso é aberto como ANSI na maioria dos editores. Então, outro usuário deste arquivo abre e acrescenta alguns caracteres nativos, por exemplo:

abg-αβγ

Ops ... Agora o arquivo ainda está em ANSI e adivinhe, "αβγ" não ocupa 6 bytes, mas 3. Isso não é UTF-8 e isso causa outros problemas mais tarde na cadeia de desenvolvimento.


UTF com BOM é melhor se você usar UTF-8 em arquivos HTML, se você usar o cirílico sérvio, latim sérvio, alemão, húngaro ou algo exótico na mesma página. Essa é a minha opinião (30 anos de computação e indústria de TI).





byte-order-mark