Qual é a vantagem de escolher a codificação ASCII sobre UTF-8?

Em alguns casos, pode acelerar o acesso a caracteres individuais. Imagine a string str='ABC' codificada em UTF8 e em ASCII (e assumindo que a linguagem / compilador / banco de dados sabe sobre codificação)

Para acessar o terceiro caractere ( C ) desta string usando o operador de acesso à matriz, que é apresentado em muitas linguagens de programação, você faria algo como c = str[2] .

Agora, se a string for codificada em ASCII, tudo o que precisamos fazer é buscar o terceiro byte da string.

Se, no entanto, a string for codificada em UTF-8, devemos primeiro verificar se o primeiro caractere é um caracter de um ou dois bytes, então precisamos realizar a mesma verificação no segundo caractere e só então poderemos acessar o terceiro caractere. A diferença no desempenho será maior, quanto maior a string.

Este é um problema, por exemplo, em alguns mecanismos de banco de dados, onde para localizar um início de uma coluna colocada após um VARCHAR codificado em UTF-8, o banco de dados não precisa apenas verificar quantos caracteres existem no campo VARCHAR. mas também quantos bytes cada um deles usa.

Se você usar apenas o subconjunto US-ASCII (ou ISO 646) do UTF-8, não haverá vantagem real para um ou outro; na verdade, tudo é codificado de forma idêntica.

Se você for além do conjunto de caracteres US-ASCII e usar (por exemplo) caracteres com acentos, caracteres especiais, etc., usados em idiomas típicos da Europa Ocidental, haverá uma diferença - a maioria deles eles ainda podem ser codificados com um único byte na ISO 8859, mas exigirão dois ou mais bytes quando codificados em UTF-8. Há também, é claro, desvantagens: ISO 8859 requer que você use alguns meios fora da banda para especificar a codificação que está sendo usada, e apenas suporta um desses idiomas por vez. Por exemplo, você pode codificar todos os caracteres do alfabeto cirílico (russo, bielorrusso, etc.) usando apenas um byte, mas se você precisar / quiser misturá-los com caracteres franceses ou espanhóis (exceto aqueles no formato US-ASCII / Subconjunto ISO 646) você está praticamente sem sorte - você tem que mudar completamente os conjuntos de caracteres para fazer isso.

A ISO 8859 é realmente útil apenas para alfabetos europeus. Para suportar a maioria dos alfabetos usados na maioria dos alfabetos chineses, japoneses, coreanos, árabes etc., você precisa usar uma codificação completamente diferente. Algumas delas (por exemplo, Shift JIS para japonês) são uma dor absoluta para se lidar. Se houver alguma chance de que você queira apoiá-los, eu consideraria válido usar o Unicode apenas no caso.

ANSI pode ser muitas coisas, a maioria sendo conjuntos de caracteres de 8 bits a esse respeito (como a página de código 1252 no Windows).

Talvez você esteja pensando em ASCII, que é de 7 bits e em um subconjunto adequado de UTF-8. Ou seja qualquer fluxo ASCII válido também é um fluxo UTF-8 válido.

Se você estava pensando em conjuntos de caracteres de 8 bits, uma vantagem muito importante seria que todos os caracteres representáveis são exatamente 8 bits, onde em UTF-8 eles podem ter até 24 bits.

Sim, ainda existem alguns casos de uso em que o ASCII faz sentido: formatos de arquivo e protocolos de rede . Em particular, para usos onde:

• Você tem dados gerados e consumidos por programas de computador, nunca apresentados a usuários finais;
• Mas o que é útil para os programadores poderem ler, para facilitar o desenvolvimento e a depuração.

Ao usar ASCII como sua codificação, você evita a complexidade da codificação de múltiplos bytes, mantendo ao menos alguma legibilidade humana.

Alguns exemplos:

• HTTP é um protocolo de rede definido em termos de sequências de octetos, mas é muito útil (pelo menos para programadores que falam inglês) que estes correspondem à codificação ASCII de palavras como "GET", "POST", "Accept-Language" e assim por diante.
• Os tipos pedaços no formato de imagem PNG consistem em quatro octetos, mas é útil se você ' re programação de um codificador ou decodificador PNG que IDAT significa "dados da imagem" e PLTE significa "paleta".

É claro que você precisa ter cuidado para que os dados realmente não sejam apresentados aos usuários finais, porque se eles ficarem visíveis (como aconteceu no caso das URLs), os usuários esperam, com razão, que os dados estejam em um idioma que eles possam ler.

Primeiro de tudo: seu título usa / d ANSI, enquanto no texto você se refere a ASCII. Por favor, note que ANSI não é igual a ASCII. ANSI incorpora o conjunto ASCII. Mas o conjunto ASCII é limitado aos primeiros 128 valores numéricos (0 - 127).

Se todos os seus dados estiverem restritos a ASCII (7 bits), não importa se você usa UTF-8, ANSI ou ASCII, pois tanto o ANSI quanto o UTF-8 incorporam o conjunto ASCII completo. Em outras palavras: os valores numéricos 0 até e incluindo 127 representam exatamente os mesmos caracteres em ASCII, ANSI e UTF-8.

Se você precisar de caracteres fora do conjunto ASCII, precisará escolher uma codificação. Você pode usar o ANSI, mas depois se depara com problemas de todas as páginas de códigos diferentes. Criar um arquivo na máquina A e lê-lo na máquina B pode / irá produzir textos de aparência engraçada se estas máquinas estiverem configuradas para usar páginas de código diferentes, simples porque o valor numérico nnn representa os diferentes caracteres nestas páginas de código.

Esse "inferno da página de código" é a razão pela qual o padrão Unicode foi definido. O UTF-8 é apenas uma codificação única desse padrão, existem muitos mais. O UTF-16 é o mais usado, já que é a codificação nativa do Windows.

Então, se você precisar suportar qualquer coisa além dos 128 caracteres do conjunto ASCII, meu conselho é seguir com UTF-8 . Dessa forma, não importa e você não precisa se preocupar com qual página de código seus usuários configuraram seus sistemas.