¿Debe utilizarse Latin-1 sobre UTF-8 cuando se trata de la configuración de la base de datos?

Unicode es ciertamente difícil, y la codificación UTF-8 tiene un par de propiedades inconvenientes. Sin embargo, UTF-8 se ha convertido en la codificación estándar de facto en la web, superando a ASCII, Latin-1, UCS-2 y UTF-16. Solo use UTF-8 en todas partes .

La razón más importante por la que debe ser compatible con Unicode es que no debe hacer suposiciones innecesarias sobre la entrada del usuario. No tengo idea de cuál es su dominio, pero cosas como los nombres de usuario en hebreo, una publicación en el blog sobre China, un comentario con Emoji o simplemente un texto con un buen estilo, como "esto", deberían ser posibles ... Oh, esas eran comillas tipográficas correctas ( “” en lugar de "" ), guiones completos y puntos suspensivos, que son caracteres comunes en el texto en inglés, pero no son compatibles con ASCII o Latin-1. Así que no admitir otros scripts no es solo un gran problema para otras culturas, sino que seguir con Latin-1 ni siquiera te permite escribir el inglés adecuado.

La idea de que Unicode solo permite "caracteres malos" es incorrecta. Sí, el texto es realmente complicado, y Unicode no te lo ocultará. Su jefe puede estar pensando en caracteres compuestos, donde un punto de código base como a se modifica por puntos de código posteriores que, por ejemplo, Representa los signos diacríticos para formar un carácter visual como á . Esto realmente no se interpone en tu camino cuando intentas realizar búsquedas si realizas algún tipo de normalización. Por ejemplo, puede almacenar todo el texto en la forma NFC que colapsa dichas composiciones en su forma precompuesta si hay una disponible. Al realizar una búsqueda, también puede eliminar todos los caracteres de composición del texto, pero esto puede cambiar sustancialmente su significado en algunos idiomas.

Unicode también agrega muchos caracteres no imprimibles, pero incluso ASCII tiene muchos de ellos. ¿Manejarás un NUL en medio de una cuerda? ¿Qué tal 0x1C, un "separador de archivos"? Nunca he visto la mitad de esos . Latin-1 agrega un guión suave que indica oportunidades de salto de palabras, pero es invisible por lo demás. ¿Eso también rompe tu búsqueda de texto completo? En otras palabras, incluso ASCII y Latin-1 le permiten romper por completo su entrada si asume que todo es solo texto imprimible.

Creo que más allá de la pregunta técnica, es posible que su jefe no tenga tiempo para mantenerse actualizado sobre los estándares actuales.

Ya que su postura no está completamente fuera de lugar para el almuerzo, solo está desactualizada, respete su posición al discutir este asunto (y debe recordar discutir , no discutir), e intente trabajar preocupaciones que tiene con respecto a UTF-8. Sospecho que el problema subyacente no es un problema técnico y puede requerir algún nivel de negociación de habilidades blandas.

  

¿Cuál de nosotros tiene razón?

Érase una vez, tu jefe fue. Pero a medida que pasa el tiempo, las cosas cambian. Hoy en día, lo eres (pero antes de correr hacia tu jefe, asegúrate de leer también la respuesta de Nelson ).

Las versiones anteriores de MySQL, y las versiones antiguas de casi todo , se manejaban mucho mejor con el Latin1 / ISO-8859-1 (5) más antiguo que con UTF8.

Hay una razón por la que se ha creado, evolucionado y distribuido UTF8 principalmente en todas partes: si se implementa correctamente, funciona mucho mejor . Existen algunos problemas de rendimiento y almacenamiento derivados del hecho de que un carácter Latin1 tiene 8 bits, mientras que un carácter UTF8 puede tener una longitud de 8 a 32 bits. Así que cuando planifica VARCHAR necesita tener esto en cuenta. Y tus rutinas de búsqueda serán un poco más lentas. Podrán hacer más cosas (por ejemplo, búsquedas con sensibilidad de acento o sin . No puedo hacer eso en Latin1 sin un trabajo extenso), pero tomará un poco más de tiempo.

Pero, por otro lado, el almacenamiento es barato , la sobrecarga realista en el tamaño de los archivos es inferior al 2-3%, la potencia de cómputo también es barata y se hace más barata en buen acuerdo con la Ley de Moore; mientras que su tiempo y las expectativas de sus clientes definitivamente no lo son .

Es posible que tenga que preocuparse por las herramientas de búsqueda, etc. si fuera usted quien desarrollara dichas herramientas. Pero probablemente no lo eres. Usted usa esas herramientas; incluso aquellos que no eran completamente compatibles con UTF8 ayer (como no lo eran los MySQL anteriores), son hoy, o pronto lo serán (por ejemplo, MySQL con soporte para utf8mb4).

Entonces, al planear e implementar con cuidado UTF8 de la manera correcta ( no dándole una palmada en Latin1 como una idea de último momento), puede tener un código que es muy razonable a prueba de futuro , que Si planeas hacer negocios con cualquier país asiático, es algo muy bueno. Y si no tiene dichos planes, otras personas lo tendrán, y esas personas podrían ser sus clientes, proveedores o socios.

Entonces, cuando empiecen a enviarte datos UTF8, tendrás que configurar una cosa complicada para convertir hacia y desde Latin1, y lidiar con casos sin solución.

Cuando se toma en cuenta el presupuesto, el costo de varias escaramuzas contra los ninja del mojibake maligno , y considera que no van a desaparecer , como ya descubrió, entonces se dará cuenta de que utilizar UTF8 no solo es más sencillo, sino que también será más barato .

Algunas situaciones en las que restringir el conjunto de caracteres solo a ASCII puede tener sentido es para campos de elección limitada, por ejemplo, campos de estado, porque usted controla estrictamente los valores que pueden estar allí, y clave / referencias externas al sistema externo, porque rara vez hay razones para que tengan algo más que caracteres alfanuméricos y algunos símbolos.

Para cualquier otro texto, solo usa UTF-8.

Para comenzar con la respuesta, no importa cómo esté configurado su servidor . La codificación de caracteres en MySQL podría configurarse por columna (es decir, la misma tabla podría contener caracteres en varias codificaciones, fácil). Es decir. mi servidor (y varias bases de datos heredadas en él) está configurado para cp1251 de forma predeterminada para clientes antiguos que no pueden establecer la intercalación correcta al conectarse (clientes de hardware diferentes), pero las principales bases de datos en producción utilizan UTF-8.

Hablando de "espacio desperdiciado": no se puede llamar realísticamente un desperdicio de datos importantes, ¿verdad? Sin embargo, el aumento del espacio de almacenamiento será diferente según el idioma en el que se encuentren sus datos. A partir del aumento insignificante (menos del 1%) si su sitio está principalmente en inglés y hasta el 100%, si es por correo usando caracteres fuera del rango ASCII . Y aún más, si te mueves hacia el este. Las especificaciones posteriores de UTF-8 (también llamadas UTF8mb4) permiten hasta 4 bytes por punto de código.

Y para "quién tiene razón" ... La verdad es que esta es una cuestión social más que técnica. Puede haber razones válidas para configuraciones de servidor específicas, pero debe conocer las implicaciones. Pero si me preguntas, no hay razón para no usar UTF-8. Es el único para gobernar todos los textos del mundo.

Solo explícale que UTF-8 es el valor predeterminado para el tráfico web. Y cualquier usuario puede ingresar cualquier carácter Unicode válido en su navegador.

Es mucho más fácil tener utf-8 / unicode de principio a fin que tratar los muchos y diversos problemas que resultan de utf-8- > latín-1 > utf-8.