español - utf8_decode mysql

UTF-8: ¿General? ¿Compartimiento? Unicode?

Question

Estoy tratando de averiguar qué compilación debería estar usando para varios tipos de datos. El 100% del contenido que almacenaré es enviado por el usuario.

Mi entendimiento es que debería usar UTF-8 General CI (mayúsculas y minúsculas) en lugar de UTF-8 Binary. Sin embargo, no puedo encontrar una distinción clara entre el CI general de UTF-8 y el CI de Unicode de UTF-8.

1. ¿Debo almacenar el contenido enviado por el usuario en las columnas UTF-8 General o UTF-8 Unicode CI?
2. ¿A qué tipo de datos sería aplicable el binario UTF-8?

Answer 1

En general, utf8_general_ci es más rápido que utf8_unicode_ci , pero menos correcto.

Aquí está la diferencia:

Para cualquier conjunto de caracteres Unicode, las operaciones realizadas utilizando la intercalación _general_ci son más rápidas que las de la intercalación _unicode_ci . Por ejemplo, las comparaciones para la compilación utf8_general_ci son más rápidas, pero ligeramente menos correctas, que las comparaciones para utf8_unicode_ci. La razón de esto es que utf8_unicode_ci admite mapeos como expansiones; es decir, cuando un carácter se compara como igual a combinaciones de otros caracteres. Por ejemplo, en alemán y en algunos otros idiomas, "ß" es igual a "ss". utf8_unicode_ci también admite contracciones y caracteres ignorables. utf8_general_ci es una compilación heredada que no admite expansiones, contracciones ni caracteres ignorables. Solo puede hacer comparaciones uno a uno entre los personajes.

Citado en: http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

Para una explicación más detallada, lea la siguiente publicación de los foros de MySQL: http://forums.mysql.com/read.php?103,187048,188748

En cuanto a utf8_bin: tanto utf8_general_ci como utf8_unicode_ci realizan una comparación que no distingue entre mayúsculas y minúsculas. En contraste, utf8_bin distingue entre mayúsculas y minúsculas (entre otras diferencias), porque compara los valores binarios de los caracteres.

Answer 2

Realmente, probé los valores de guardado como ''é'' y ''e'' en la columna con un índice único y causan un error duplicado en ''utf8_unicode_ci'' y ''utf8_general_ci''. Puede guardarlos solo en la columna compaginada ''utf8_bin''.

Y los documentos de mysql (en http://dev.mysql.com/doc/refman/5.7/en/charset-applications.html ) sugieren en sus ejemplos el conjunto ''utf8_general_ci'' colación.

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci

Answer 3

También debe tener en cuenta el hecho de que con utf8_general_ci cuando se usa un campo varchar como único o primario, la inserción de 2 valores como ''a'' y ''á'' daría un error de clave duplicada.

Answer 4

• utf8_bin compara los bits a ciegas. No se dobla la caja, no se quita el acento.
• utf8_general_ci compara un byte con un byte. Se hace el plegado de casos y la eliminación de acentos, pero no hay comparaciones de 2 caracteres: ij no es igual ij en esta intercalación.
• utf8_*_ci es un conjunto de reglas específicas del idioma, pero por lo demás como unicode_ci . Algunos casos especiales: Ç , Č , ch , ll
• utf8_unicode_ci sigue un antiguo estándar de Unicode para las comparaciones. ij = ij , pero ae ! = æ
• utf8_unicode_520_ci sigue un estándar Unicode más nuevo. ae = æ

Consulte la tabla de colación para obtener detalles sobre qué es igual a qué en varias colaciones utf8.

utf8 , según lo definido por MySQL, está limitado a los códigos utf8 de 1 a 3 bytes. Esto deja fuera a Emoji y algunos de los chinos. Así que realmente deberías cambiar a utf8mb4 si quieres ir mucho más allá de Europa.

Los puntos anteriores se aplican a utf8mb4 , después del cambio de ortografía adecuado. Más adelante, se prefieren utf8mb4 y utf8mb4_unicode_520_ci .

• utf16 y utf32 son variantes en utf8; Prácticamente no hay uso para ellos.
• ucs2 está más cerca de "Unicode" que de "utf8"; No hay prácticamente ningún uso para ello.