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

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

Para acessar o terceiro (C) caractere 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 é codificada em UTF-8, devemos primeiro verificar se o primeiro caractere é um caractere de um ou dois bytes, então precisamos realizar a mesma verificação no segundo caractere, e só então podemos acessar o terceiro personagem. A diferença no desempenho será quanto maior, quanto mais longa a string.

Este é um problema, por exemplo, em alguns mecanismos de banco de dados, onde encontrar o 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.

Comentários

• Se o banco de dados não ‘ armazena a ” contagem de caracteres ” e a ” contagem de bytes “, então eu ‘ d digo ele ‘ tem alguns problemas …
• TBH Eu não conheço nenhum banco de dados que armazenaria …
• @Mchl: como você acha que o banco de dados sabe quando atingiu o final da string?
• Normalmente, atingindo 0x00 ou 0x0000
• @DeanHarding Como a contagem de caracteres indica onde o segundo caractere começa ? Ou o banco de dados deve conter um índice para cada deslocamento de caractere também? Observação: não é ‘ t apenas 2 caracteres, mas pode ter até 4 (a menos que seja ‘ s 6) stackoverflow.com/questions/9533258/… . (Eu acho que ‘ s apenas utf-16 que tinha abominações realmente longas que poderiam destruir seu sistema)

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

Se você for além do conjunto de caracteres US-ASCII e usar (por exemplo) caracteres com acentos, tremas, etc., que são usados em línguas da Europa Ocidental, então há uma diferença – a maioria deles ainda pode ser codificada com um único byte em ISO 8859, mas exigirá dois ou mais bytes quando codificada em UTF-8. Existem 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 só oferece suporte a uma dessas linguagens por vez. Por exemplo, você pode codificar todos os caracteres do cirílico (russo, bielorrusso, etc.) alfabeto usando apenas um byte cada, mas se você precisa / deseja misturar aqueles com caracteres franceses ou espanhóis (exceto aqueles no subconjunto US-ASCII / ISO 646), você “está quase sem sorte – você precisa completamente altere os conjuntos de caracteres para fazer isso.

ISO 8859 é realmente útil apenas para alfabetos europeus. Para suportar a maioria dos alfabetos usados na maioria dos alfabetos chinês, japonês, coreano, árabe, etc., você deve usar algumas codificações completamente diferentes. Algumas delas (por exemplo, Shift JIS para japonês) são uma verdadeira dor de cabeça. Se houver alguma chance de você querer suportá-las, considero que vale a pena usar Unicode apenas em caso.

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

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

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

Comentários

• sim i ‘ estou falando sobre o conjunto ASCII de 7 bits. Você consegue pensar em uma vantagem de que precisaremos salvar algo como ASCII em vez de UTF-8? (já que 7 bits seriam salvos como 8 bits de qualquer maneira, o tamanho do arquivo seria exatamente o mesmo)
• Se você tiver caracteres maiores do que o valor Unicode 127, eles não podem ser salvos em ASCII.
• @Pacerier: Qualquer string ASCII é uma string UTF-8 , portanto, não há diferença . A rotina de codificação pode ser mais rápida dependendo da representação de string da plataforma que você usa, embora eu não ‘ espere uma aceleração significativa, enquanto você tem uma perda significativa em flexibilidade.
• @Thor é exatamente por isso que eu ‘ estou perguntando se salvar como ASCII tem alguma vantagem
• @Pacerier, se você salvar XML como ASCII, você precisa usar, por exemplo, & # 160; para um espaço inquebrável. Isso é mais completo, mas torna seus dados mais resistentes contra erros de codificação ISO-Latin-1 vs UTF-8. Isso é o que fazemos, pois nossa plataforma subjacente faz muita magia invisível com os personagens. Ficar em ASCII torna nossos dados mais robustos.

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

• Você tem dados que são gerados e consumidos por programas de computador, nunca apresentados aos usuários finais;
• Mas para os quais é útil programadores sejam capazes de ler, para facilidade de desenvolvimento e depuração.

Ao usar ASCII como sua codificação, você evita a complexidade da codificação multibyte enquanto mantém pelo 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 correspondam à codificação ASCII de palavras como “GET”, “POST”, “Accept-Language” e assim por diante.
• O tipos de fragmentos no formato de imagem PNG consistem em quatro octetos, mas é útil se você estiver programando um codificador PNG ou decodificador IDAT significa” dados de imagem “e PLTE significa” paleta “.

Claro que você precisa tenha cuidado para que os dados realmente não sejam apresentados aos usuários finais, porque se eles acabam sendo visíveis (como aconteceu no caso dos URLs), os usuários esperam, com razão, esses dados estar em um idioma que eles possam ler.

Comentários

• Muito bem. É ‘ um pouco irônico que o HTTP, o protocolo que transmite a maioria dos Unicode do planeta, precise apenas suportar ASCII. (Na verdade, suponho que o mesmo vale para TCP e IP, suporte binário, suporte ASCII … que ‘ é tudo que você precisa naquele nível da pilha)

Primeiro de tudo: seu título usa / d ANSI, enquanto no texto você se refere a ASCII. Observe 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 ANSI e UTF-8 incorporam o conjunto ASCII completo. Em outras palavras: os valores numéricos de 0 até e incluindo 127 representam exatamente os mesmos caracteres em ASCII, ANSI e UTF-8.

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

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

Portanto, se você precisar oferecer suporte a algo além dos 128 caracteres do conjunto ASCII, meu conselho é usar UTF-8 . Dessa forma, não importa e você não precisa se preocupar com a página de código que seus usuários configuraram em seus sistemas.

Comentários

• se eu não preciso suportar mais de 128 caracteres, qual é a vantagem de escolher a codificação ACSII em vez da codificação UTF8?
• Além de se limitar a esses 128 caracteres? Não muito. O UTF-8 foi projetado especificamente para atender ASCII e a maioria das línguas ocidentais que ” apenas ” precisam de ANSI. Você descobrirá que o UTF-8 codificará apenas um número relativamente pequeno dos caracteres ANSI mais altos com mais de um byte. Há uma razão pela qual a maioria das páginas HTML usa UTF-8 como padrão …
• @Pacerier, se você não ‘ não precisa de codificação acima de 127, escolher ASCII pode valer a pena quando você usa alguma API para codificar / decodificar, porque UTF precisa de verificação de bit adicional para considerar bytes adicionais como o mesmo caractere, pode exigir computação adicional em vez de ASCII puro que apenas lê 8 bits sem verificação. Mas eu só recomendo que você use ASCII se você realmente precisar de um alto nível de otimização em computação grande (big large) e souber o que ‘ está fazendo nessa otimização. Caso contrário, use apenas UTF-8.