Por que o Windows 7 funciona com Unicode e não com UTF-8?
Terminologia
Unicode e UTF-8 não são o mesmo tipo de coisa: Unicode é um conjunto de caracteres que define um conjunto de caracteres (um repertório) e números cessionários (pontos de código) para cada um desses personagens. UTF ‑ 8 é uma das várias codificações que podem ser usadas para representar um fluxo de caracteres Unicode no disco ou na transmissão. O mesmo fluxo de caracteres Unicode também pode ser codificado como UTF-16, UTF-32 ou UTF-7, por exemplo.
No entanto, Notepad ofertas você "Codificação" opções, incluindo ANSI, Unicode, Unicode big-endiane UTF-8. Os desenvolvedores da Microsoft que escreveram isso usaram os termos errados. Quando eles dizem "Unicode", eles provavelmente significam " UTF-16
little-endian ". Quando dizem "ANSI", significam a Página de Código 1252 (CP-1252).
Bloco de notas da Microsoft
Acredito que o bloco de notas da Microsoft grava UTF-16 com uma marca de ordem de bytes ( BOM ) e esse bloco de notas procura a lista técnica ao ler um arquivo de texto. A BOM informa ao aplicativo que o arquivo é UTF-16 e indica se é big endian ou little-endian.
Se o Bloco de notas não encontrar a lista técnica, ele chamará uma função de biblioteca IsTextUnicode, que analisa os dados e tenta adivinhar qual codificação foi usada. Às vezes (inevitavelmente) adivinha incorretamente. Às vezes, ele acha que um arquivo "ANSI" é "Unicode". Tentar interpretar um arquivo UTF-16 ou UTF-8 como o Código Página 1252 faria com que ele exibisse os glifos errados e não conseguisse encontrar glifos para renderizar alguns valores de 8 bits - eles seriam mostrados como quadrados.
Como harrymc diz em sua resposta , existem melhores alternativas para o Bloco de Notas. Mas o Bloco de notas permite escolher explicitamente a codificação ao abrir um arquivo (em vez de deixar o Bloco de notas para tentar adivinhar).
Marcas de ordem de bytes
De acordo com o consórcio Unicode, as Marcas de Pedido de Byte (BOMs) são opcionais. No entanto, o Windows conta com BOMs para distinguir entre algumas codificações.
Então, resumindo, talvez seus arquivos não tenham uma lista técnica por algum motivo? Talvez a lista técnica tenha sido perdida em algum momento durante o processo de atualização?
Se você ainda tiver os arquivos originais exibidos como quadrados, poderá fazer um dump hexadecimal deles para ver se eles contêm uma BOM.
Padrões de arquivo de texto sem formatação
O problema é que não há efetivamente nenhum - nenhum padrão universal para arquivos de texto simples. Em vez disso, temos várias incompatibilidades e incógnitas.
Como foram marcados os finais de linha? Algumas plataformas usam os caracteres de controle Carriage Return (CR) seguidos por Line Feed (LF), alguns usam CR sozinho e outros usam LF sozinho.
Os terminadores ou separadores acima são? Isso tem efeito no final de um arquivo e é conhecido por causar problemas.
Tratamento de guias e outros caracteres de controle. Podemos supor que uma guia seja usada para alinhar a um múltiplo de 8 larguras de caracteres padrão desde o início da linha, mas, na verdade, não há certeza disso. Muitos programas permitem que as posições das guias sejam alteradas.
Conjunto de caracteres e codificação? Não há um padrão universal para indicar quais desses foram usados para o texto no arquivo. O mais próximo que temos é procurar a presença de uma lista técnica que indica que a codificação é uma daquelas usadas para Unicode. No valor da BOM, o programa que lê o arquivo pode distinguir entre UTF-8 e UTF-16, etc., e entre as variantes Little-Endian e Big-Endian de UTF-16, etc. Não existe um padrão universal para indicar que um arquivo é codificado em qualquer outra codificação popular, como CP-1252 ou KOI-8.
E assim por diante. Nenhum dos metadados acima é gravado no arquivo de texto - portanto, o usuário final deve informar o programa ao ler o arquivo. O usuário final precisa conhecer os valores de metadados para qualquer arquivo específico ou correr o risco de que seu programa use os valores errados de metadados.
Bush escondeu os fatos
Tente isso no Windows XP.
- Abra o bloco de notas.
- Defina a fonte como Arial Unicode MS. (Pode ser necessário instalá-lo primeiro; se não o encontrar no menu, clique em "Mostrar mais fontes".)
- Digite o texto "Bush escondeu os fatos".
- Escolha
Save As. No Encodingmenu, selecione ANSI.
- Feche o bloco de notas.
- Reabra o documento (por exemplo, usando
Start, My Recent Documents).
- Você verá 獴 桳 栠 摩 敨 映 捡 獴 em vez de "Bush escondeu os fatos".
Isso ilustra que a IsTextUnicodefunção usada pelo Bloco de Notas supõe incorretamente que o texto ANSI (realmente Código Página 1252) é Unicode UTF-16LE sem uma BOM. Não há lista técnica em um arquivo salvo como ANSI.
Windows 7
Com o Windows 7, a Microsoft ajustou-se IsTextUnicodepara que isso não aconteça. Na ausência de uma lista técnica, agora é mais provável adivinhar ANSI (CP 1252) do que Unicode (UTF-16LE). Com o Windows 7, espero que você seja mais propensos a ter o problema inverso: Um arquivo que contém caracteres Unicode com pontos de código maiores do que 255, mas sem BOM, é agora mais provável de ser imaginado como sendo ANSI - e, portanto, exibido incorretamente.
Evitando problemas de codificação
Atualmente, a melhor abordagem parece ser usar UTF-8 em qualquer lugar. Idealmente, você recodificaria todos os arquivos de texto antigos no UTF-8 e salvaria apenas os arquivos de texto como UTF-8. Existem ferramentas como recode e iconv que podem ajudar com isso.