Diferenças de formato Unicode, UTF, ASCII, ANSI

470

Descendo sua lista:

" Unicode " não é uma codificação, embora, infelizmente, muita documentação a utilize imprecisa para se referir à codificação Unicode que esse sistema específico usa por padrão. No Windows e Java, isso geralmente significa UTF-16; em muitos outros lugares, significa UTF-8. Adequadamente, Unicode refere-se ao conjunto de caracteres abstratos em si, não a nenhuma codificação específica.
UTF-16 : 2 bytes por "unidade de código". Esse é o formato nativo de strings no .NET e, geralmente, no Windows e Java. Valores fora do Plano Multilíngue Básico (BMP) são codificados como pares substitutos. Isso costumava ser usado raramente, mas agora muitos aplicativos de consumo precisam estar cientes de caracteres não-BMP para oferecer suporte a emojis.
UTF-8 : codificação de comprimento variável, 1 a 4 bytes por ponto de código. Os valores ASCII são codificados como ASCII usando 1 byte.
UTF-7 : Geralmente usado para codificação de correio. Provavelmente, se você acha que precisa e não está enviando e-mails, está errado. (Essa é apenas a minha experiência de pessoas postando em grupos de notícias etc - correio externo, na verdade não é amplamente utilizado.)
UTF-32 : codificação de largura fixa usando 4 bytes por ponto de código. Isso não é muito eficiente, mas facilita a vida fora do BMP. Eu tenho uma Utf32Stringclasse .NET como parte da minha biblioteca MiscUtil , se você quiser. (Não foi totalmente testado, lembre-se.)
ASCII : codificação de byte único usando apenas os 7 bits inferiores. (O código Unicode aponta 0-127.) Sem detalhes, etc.
ANSI: Não há uma codificação ANSI fixa - existem muitas. Geralmente, quando as pessoas dizem "ANSI", elas significam "a localidade / página de código padrão para o meu sistema", obtida através do Encoding.Default , e geralmente é do Windows-1252, mas pode ser outras localidades.

Há mais na minha página Unicode e dicas para depurar problemas Unicode .

O outro grande recurso de código é o unicode.org, que contém mais informações do que você poderá trabalhar - possivelmente a parte mais útil são os gráficos de código .

— Jon Skeet
fonte

O termo "ANSI" quando aplicado às páginas de código de 8 bits da Microsoft é um nome impróprio. Eles foram baseados em rascunhos enviados para padronização ANSI, mas o próprio ANSI nunca os padronizou. Windows-1252 (a página de código mais comumente referida como "ANSI") é semelhante à ISO 8859-1 (Latina-1), exceto que o Windows-1252 possui caracteres imprimíveis no intervalo 0x80..0x9F, em que ISO 8859-1 possui caracteres de controle nesse intervalo. Unicode também possui caracteres de controle nesse intervalo. pt.wikipedia.org/wiki/Windows_code_page

— Keith Thompson

@ jp2code: eu não faria - mas você precisa distinguir entre "o conteúdo que é enviado de volta via HTTP do servidor da Web" e "o conteúdo que é enviado por e-mail". Não é o conteúdo da página da web que envia o email - é o aplicativo por trás dele, presumivelmente. O conteúdo da web seria melhor em UTF-8; o conteúdo do e-mail pode estar em UTF-7, embora eu suspeite que seja bom mantê-lo em UTF-8 atualmente.

— Jon Skeet

Para UTF-16, IMHO, eu diria "2 bytes por unidade de código", pois um ponto de código fora do BMP será codificado em pares substitutos como 2 unidades de código (4 bytes).

— Ludovic Kuty

Perde as diferenças entre UTF-16LE (no .NET) e BE, bem como a noção de BOM.

— Maarten Bodewes

@ Andrew: Não, não há marcador de codificação (geral). O Windows 1252 não pode representar a BOM Unicode e não faria sentido, pois é apenas uma codificação de um byte por caractere.

— precisa

Algumas leituras para você começar a codificar caracteres: Joel on Software: o mínimo absoluto Todo desenvolvedor de software deve saber absolutamente, positivamente sobre positivamente Unicode e conjuntos de caracteres (sem desculpas!)

A propósito - o ASP.NET não tem nada a ver com isso. Codificações são universais.

— Tomalak
fonte

Respondida aqui 6 anos após a redação do artigo. Eu li 8 anos depois que o post foi escrito. 14 anos depois e ainda é uma boa leitura. Isso é mais da metade da minha vida atrás. Incrível.

— Dave Knise