¿Cuál es la ventaja de elegir la codificación ASCII sobre UTF-8?

En algunos casos, puede acelerar el acceso a caracteres individuales. Imagine la cadena str='ABC' codificada en UTF8 y en ASCII (y suponiendo que el idioma / compilador / base de datos sabe acerca de la codificación)

Para acceder al tercer carácter ( C ) de esta cadena mediante el operador de acceso a la matriz, que aparece en muchos lenguajes de programación, haría algo como c = str[2] .

Ahora, si la cadena está codificada en ASCII, todo lo que tenemos que hacer es recuperar el tercer byte de la cadena.

Si, sin embargo, la cadena está codificada en UTF-8, primero debemos verificar si el primer carácter es de uno o dos bytes, luego debemos realizar la misma verificación en el segundo carácter, y solo entonces podemos acceder al tercer carácter. La diferencia en el rendimiento será mayor cuanto más larga sea la cadena.

Esto es un problema, por ejemplo, en algunos motores de base de datos, donde para encontrar el comienzo de una columna colocada 'después' de un VARCHAR codificado en UTF-8, la base de datos no solo necesita verificar cuántos caracteres hay en el campo VARCHAR, pero también cuántos bytes utiliza cada uno de ellos.

Si va a utilizar solo el subconjunto US-ASCII (o ISO 646) de UTF-8, entonces no hay una ventaja real para uno u otro; de hecho, todo está codificado de forma idéntica.

Si va a ir más allá del conjunto de caracteres US-ASCII y usa (por ejemplo) caracteres con acento, diéresis, etc., que se usan en los idiomas típicos de Europa occidental, entonces hay una diferencia: la mayoría estos aún pueden codificarse con un solo byte en ISO 8859, pero requerirán dos o más bytes cuando estén codificados en UTF-8. Por supuesto, también existen desventajas: la norma ISO 8859 requiere que use algunos medios fuera de banda para especificar la codificación que se está utilizando, y solo admite uno de estos idiomas a la vez. Por ejemplo, puede codificar todos los caracteres del alfabeto cirílico (ruso, bielorruso, etc.) utilizando solo un byte cada uno, pero si necesita / desea mezclarlos con caracteres franceses o españoles (que no sean los de US-ASCII). / ISO 646 subconjunto) no tienes mucha suerte, tienes que cambiar por completo los conjuntos de caracteres para hacerlo.

ISO 8859 es realmente útil solo para alfabetos europeos. Para admitir la mayoría de los alfabetos utilizados en la mayoría de los alfabetos chinos, japoneses, coreanos, árabes, etc., debe utilizar una codificación completamente diferente. Algunos de estos (por ejemplo, Shift JIS para japoneses) son un dolor absoluto con el que lidiar. Si hay alguna posibilidad de que quieras apoyarlos, consideraría que vale la pena usar Unicode por si acaso.

ANSI puede ser muchas cosas, la mayoría son conjuntos de caracteres de 8 bits a este respecto (como la página de códigos 1252 en Windows).

Quizás estaba pensando en ASCII, que es de 7 bits y un subconjunto adecuado de UTF-8. Es decir. cualquier flujo ASCII válido también es un flujo UTF-8 válido.

Si estuviera pensando en conjuntos de caracteres de 8 bits, una ventaja muy importante sería que todos los caracteres representables son exactamente de 8 bits, donde en UTF-8 pueden tener hasta 24 bits.

Sí, todavía hay algunos casos de uso en los que ASCII tiene sentido: formatos de archivo y protocolos de red . En particular, para usos donde:

• Tiene datos generados y consumidos por programas informáticos, que nunca se presentan a los usuarios finales;
• Pero es útil para que los programadores puedan leer, para facilitar el desarrollo y la depuración.

Al utilizar ASCII como su codificación, evita la complejidad de la codificación de múltiples bytes, al tiempo que conserva al menos cierta legibilidad humana.

Un par de ejemplos:

• HTTP es un protocolo de red definido en términos de secuencias de octetos, pero es muy útil (al menos para programadores que hablan inglés) que estos corresponden a la codificación ASCII de palabras como "GET", "POST", "Accept-Language" y así sucesivamente.
• Los tipos de trozos en el formato de imagen PNG constan de cuatro octetos, pero es útil si ' re programando un codificador o decodificador PNG que IDAT significa "datos de imagen", y PLTE significa "paleta".

Por supuesto, debe tener cuidado de que los datos realmente no se presentarán a los usuarios finales, porque si terminan siendo visibles (como sucedió en el caso de las URL), entonces Los usuarios, con razón, van a esperar que los datos estén en un idioma que puedan leer.

Primero que todo: su título usa / d ANSI, mientras que en el texto se refiere a ASCII. Tenga en cuenta que ANSI no es igual a ASCII. ANSI incorpora el conjunto ASCII. Pero el conjunto ASCII está limitado a los primeros 128 valores numéricos (0 - 127).

Si todos sus datos están restringidos a ASCII (7 bits), no importa si usa UTF-8, ANSI o ASCII, ya que tanto ANSI como UTF-8 incorporan el conjunto ASCII completo. En otras palabras: los valores numéricos 0 hasta 127 inclusive representan exactamente los mismos caracteres en ASCII, ANSI y UTF-8.

Si necesita caracteres fuera del conjunto ASCII, deberá elegir una codificación. Podría usar ANSI, pero luego se encuentra con los problemas de todas las páginas de códigos diferentes. Crear un archivo en la máquina A y leerlo en la máquina B puede / producirá textos de aspecto divertido si estas máquinas están configuradas para usar diferentes páginas de códigos, simplemente porque el valor numérico nnn representa diferentes caracteres en estas páginas de códigos.

Este "infierno de página de códigos" es la razón por la cual se definió el estándar de Unicode . UTF-8 no es más que una sola codificación de ese estándar, hay muchas más. UTF-16 es el más utilizado, ya que es la codificación nativa para Windows.

Entonces, si necesita admitir algo más allá de los 128 caracteres del conjunto ASCII, mi consejo es ir con UTF-8 . De esa manera no importa y no tiene que preocuparse por la página de códigos en la que sus usuarios han configurado sus sistemas.