[hs] MySQL : utf8_general_ci ou utf8_unicode_ci ou utf8mb4_unicode_ci

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--KXxoqEWMmb097sRxLgfKk8iW6nnK0uaDQ
Content-Type: multipart/mixed; boundary="baEqwrIuQi214JC9BuDDbIPr2WN4nFlrx";
protected-headers="v1"
From: Safranil <safranil@safranil.fr>
To: Dominique Asselineau <asseline@telecom-paristech.fr>,
Debian User French <debian-user-french@lists.debian.org>
Message-ID: <90ffeefd-686b-6008-caaf-42b4ed6f7f84@safranil.fr>
Subject: Re: [hs] MySQL : utf8_general_ci ou utf8_unicode_ci ou
utf8mb4_unicode_ci
References: <20170129155414.GA30658@telecom-paristech.fr>
In-Reply-To: <20170129155414.GA30658@telecom-paristech.fr>

--baEqwrIuQi214JC9BuDDbIPr2WN4nFlrx
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Bonjour,

En fait l'UTF-8 de MySQL ne respecte pas la norme Unicode et ne supporte
que les caractères codés sur 3 octets (plan de base de l'Unicod e), d'où
l'ajout de l'utf8-mb4 (multibytes 4) pour supporter complétement la
norme. À priori, cela ne vous posera pas de problème de choisir la
version non mb4 mais je conseil tout de même d'utiliser l'utf8-mb4 p ar
soucis de respect des normes.

Le fait que vous soyez sur Debian ou non ne changera en rien la gestion
des caractères dans MySQL, le système ne fourni que le stockage des
bases de données et non l'interprétation des caractères co ntenu à
l'intérieur, rôle joué par le moteur de bases de donné es.

Pour la collation, j'utilise utf8mb4_bin car la comparaison des chaines
de caractères sont effectué bit à bit (donc sensible à la casse) alors
que les utf8mb4_xxx_ci compare les chaînes de caractères indà ©pendamment
de la casse (et accents il me semble) en appliquant des règles
spécifiques à la langue. Si vous êtes dans le second cas, je vous
conseil l'utf8mb4_general_ci qui gère parfaitement la langue franà §aise.

En espérant avoir répondu à vos questions.

Bonne soirée.

Le 29/01/2017 à 16:54, Dominique Asselineau a écrit :

Bonjour,

Je souhaite passer mes bases de donnéeds en UTF-8 et je remarque
plusieurs régblages possibles. D'après ce que je lis, il sem ble que le
réglage utf8mb4_unicode_ci soit le plus puissant et complet mais p as
sûr que ce soit le mieux adapté dans un environnement Debian.

Ce serveur ne tourne qu'en localhost, pas d'accès de client extà ©rieur
donc. Il est seulement dépendant de l'environnement et locales de
Debian. Toutefois des données peuvent entrer via des formuliares web.

quelqu'un aurait-il un avis sur un réglage approprié des char acter set
et collation ?

A+

dom

--baEqwrIuQi214JC9BuDDbIPr2WN4nFlrx--

--KXxoqEWMmb097sRxLgfKk8iW6nnK0uaDQ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYjnTWAAoJEOrqwJdGVNWmgFgQAIqVEPMEkzQihNhycHUCJQlx
LtSp+UN0ExrjQn6pPGq9g60bRbwTkxxT1QXPgHkldwthEEzZHWrv832B7z6KN/1c
maxVf9pwv2gp4lXOYbGi30YUPgjbzf7RlezcVUQ7KxVinH4MmyQyaZbDxvqAT2WD
VA3ltbyqwqqNME0DjBSnzcuX0iXjcX/h8eCc32DBqy1mX+Avpmq4mT7FHpX46htc
JCb5ugcPFTBtOpLT2nEVYf9+5bAAtY5tMsMozx+vH50SeDoXnAHFDmBhnMEj1TA+
LimG+rsYDXubRZzTrcI6ZzacVSsTB0WRimxScsA2WdKDwU18Ks+eAM3FLHrUdZ7A
Pu+E1X1/UHOf9k0cmEPqaKGYztFvVcQQUNDPJhmAKNQyKv4jwqGu1vkKzP+CskR6
Ykc56mhKxoqkMtHYpVXvrQxNwQ6RTSMYKSPz5m1hQzRCdeevww9QiwM5ALKWwo6H
O0eQYPHBVEMYGh8ljwBYrLYGCrcELvM7I8cyDkwUazDnfNvl9fBDaxPgRiQiBU7l
+ul/FSpHsmpTkBucUDbA9PrBbuP2tGkouTo/7hIGrq8hub9w5LDzqgu2JTMf4L7r
gI3yzD5/j4YKvM9DqC4DV0k1heiDDeLRvGqa7H/829QbNjchc1ylChb2+08vvm/J
884MLBfZ6v82QMUT25ky
=RLnB
-----END PGP SIGNATURE-----

--KXxoqEWMmb097sRxLgfKk8iW6nnK0uaDQ--

Bonjour et merci de ces précisions.

Le contexte serait un peu plus large que le français mais ça resterait
parmi les langues européennes. Dans ce cas utf8mb4_general_ci
serait-il toujours performant ?

Merci.

Dominique


Safranil wrote on Mon, Jan 30, 2017 at 12:03:41AM +0100

Bonjour,

En fait l'UTF-8 de MySQL ne respecte pas la norme Unicode et ne supporte
que les caractères codés sur 3 octets (plan de base de l'Unicode), d'où
l'ajout de l'utf8-mb4 (multibytes 4) pour supporter complétement la
norme. À priori, cela ne vous posera pas de problème de choisir la
version non mb4 mais je conseil tout de même d'utiliser l'utf8-mb4 par
soucis de respect des normes.

Le fait que vous soyez sur Debian ou non ne changera en rien la gestion
des caractères dans MySQL, le système ne fourni que le stockage des
bases de données et non l'interprétation des caractères contenu à
l'intérieur, rôle joué par le moteur de bases de données.

Pour la collation, j'utilise utf8mb4_bin car la comparaison des chaines
de caractères sont effectué bit à bit (donc sensible à la casse) alors
que les utf8mb4_xxx_ci compare les chaînes de caractères indépendamment
de la casse (et accents il me semble) en appliquant des règles
spécifiques à la langue. Si vous êtes dans le second cas, je vous
conseil l'utf8mb4_general_ci qui gère parfaitement la langue française.

En espérant avoir répondu à vos questions.

Bonne soirée.

Le 29/01/2017 à 16:54, Dominique Asselineau a écrit :
> Bonjour,
>
> Je souhaite passer mes bases de donnéeds en UTF-8 et je remarque
> plusieurs régblages possibles. D'après ce que je lis, il semble que le
> réglage utf8mb4_unicode_ci soit le plus puissant et complet mais pas
> sûr que ce soit le mieux adapté dans un environnement Debian.
>
> Ce serveur ne tourne qu'en localhost, pas d'accès de client extérieur
> donc. Il est seulement dépendant de l'environnement et locales de
> Debian. Toutefois des données peuvent entrer via des formuliares web.
>
> quelqu'un aurait-il un avis sur un réglage approprié des character set
> et collation ?
>
> A+
>
> dom
>

--

Le 30/01/17 à 14:55, Dominique Asselineau <asseline@telecom-paristech. fr> a écrit :
DA> Bonjour et merci de ces précisions.
DA>
DA> Le contexte serait un peu plus large que le français mais ça resterait
DA> parmi les langues européennes. Dans ce cas utf8mb4_general_ci
DA> serait-il toujours performant ?

Que veux-tu dire par performant ?

Si tu parle de la rapidité d'une application qui utiliserait une base mysql, je doute que le
changement de charset / collation soit perceptible.

Donc réponse courte :
- si c'est une appli web, prend le charset de tes pages web et du langage q ue tu utilises
(utf8mb4_ est plus conforme à la norme, mais utf8_ reste un choix pe rtinent, et c'est facile
de passer de l'un à l'autre).
- La collation ne sert que pour les requêtes sql comme where truc = "aeiou" qui va sélectionner
aussi du "ÀêïOù" avec une collation *_ci (avec du _cs je crois que "é"="e"), donc choisi _ci
ou _cs ou _bin en fonction de ce qui t'arrange pour tes résultats de requêtes.



Réponse détaillée :

Certaines collations sont un peu plus rapides, mais c'est en géné ral négligeable devant le reste
(la lecture des données et les jointures).

Attention quand même si tu utilises plusieurs langues, utf8_general_ci est plus "laxiste" que

utf8_general_ci :
n = ñ
ß = s

utf8_unicode_ci :
n ≠ ñ
ß = ss

Et attention aux collations spécifiques à une langue, par ex avec une collation spanish "ll"
est un caractère séparé entre l et n, donc "ll" > "lz" (à §a parait très logique à un espagnol où
ll a une entrée séparée dans le dictionnaire).

Cf https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-sets.html


Avec une collation plus stricte (comme le _bin ou les _cs), les index prenn ent un peu plus de
place (plus d'entrées distinctes), mais c'est rarement un problèm e.

Pour le charset, celui que tu choisis doit contenir tous les caractère s que tu veux pouvoir
stocker, mais à priori c'est le cas de tous les charset classiques pou r les langues européennes
(utf8_*, latin1_*, …), et il peut influer sur la taille occupé e par les données (donc espace
disque et dans une moindre mesure RAM occupée), mais ça changera pas grand choses sur la vitesse
d'exécution d'une requête.

Si tu veux vraiment économiser qq octets de disque et de RAM, le chars et le plus économique
sera probablement latin1_general_ci, c'est pour ça que plein de gens c ontinuent de l'utiliser
(aussi parce qu'ils n'ont jamais migré n'en éprouvant pas le beso in) sur des systèmes pourtant
en utf8.
Mais utiliser du mysql latin1 sur un OS utf8 oblige à préciser le charset lors de la connexion
à la base (pas mal de client vont le préciser d'office à la connexion), et depuis une appli
web ça peut être pénible (suivant que le charset de la page les post sont utf8 ou pas, et il
faudra décoder / encoder en entrée et sortie de la base suivant l e charset de connexion, sinon
tu te retrouveras avec des trucs comme é sur tes pages web ou da ns la base ou les deux).

C'est pour ça que c'est quand même plus simple d'avoir tout en ut f8, qui est l'encodage par
défaut de pas mal de langages (et par ex le seul pour échanger de s données en json).

Donc utf8mb4_general_c(i ou s) est probablement le meilleur choix pour la p érennité,
utf8_general_c(i|s) reste efficace avec une appli web utf8 et latin1_genera l_c(i|s) avec une
appli web iso8859 (charset des pages html en latin1), et _bin si tu veux de s comparaisons
strictes (ou si les μs économisées sont importantes).

--
Daniel

Un jour Dieu me dit « cette chemise va t'aller » et "oh my Gad, E lmaleh"

On lundi 30 janvier 2017 00:03:41 CET Safranil wrote:

Si vous êtes dans le second cas, je vous
conseil l'utf8mb4_general_ci qui gère parfaitement la langue franà §aise.

D'après Tom Christieansen [1], utf8mb4_general_ci est cassé. Il faut utiliser
utf8mb4_unicode_ci.

utf8mb4_general_ci est peut-être suffisant pour le Français, ma is dans le doute,
le plus simple est d'utiliser utf8mb4_unicode_ci

HTH

[1] http://stackoverflow.com/questions/766809/whats-the-difference-between- utf8-general-ci-and-utf8-unicode-ci#766996

--001a1143c3f2bbeeef0548525340
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

utf8mb4_general_ci est peut-être >suffisant pour le Français, mais dans

le >doute,

le plus simple est d'utiliser >utf8mb4_unicode_ci

Bonjour, en fait le français aussi utilise un caractère composà © : œ comme
dans œil ou œuf. Donc (je n'ai pas testé, mais il est probab le que les
approximations de général_ci soient visibles en français.

--001a1143c3f2bbeeef0548525340
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir="auto"><div class="gmail_extra" dir="auto"><div class="gma il_quote">&gt;utf8mb4_general_ci est peut-être &gt;suffisant pour le Français, mais dans le &gt;doute,</div><div class="gmail_quote" dir ="auto">&gt;le plus simple est d&#39;utiliser &gt;utf8mb4_unicode_ci</div ><div class="gmail_quote" dir="auto">Bonjour, en fait le français aussi utilise un caractère composé : œ comme dans œil o u œuf. Donc (je n&#39;ai pas testé, mais il est probable que les approximations de général_ci soient visibles en français.  </div></div></div>

--001a1143c3f2bbeeef0548525340--

Eric Degenetais wrote on Sun, Feb 12, 2017 at 09:55:11AM +0000

>utf8mb4_general_ci est peut-être >suffisant pour le Français, mais dans
le >doute,
>le plus simple est d'utiliser >utf8mb4_unicode_ci
Bonjour, en fait le français aussi utilise un caractère composé : œ comme
dans œil ou œuf. Donc (je n'ai pas testé, mais il est probable que les
approximations de général_ci soient visibles en français.

Justement, avec utf8mb4_general_ci, l'ordre alphabétique n'est pas
correct. Le œ est rejeté à la fin de l'alphabet. Le ß semble
toutefois être bien placé.

mb4_unicode_ci semble être plus précis sur l'ordre alphabétique. Les
ligatures œ et ß sont normalement assimilés à oe et ss et placés en
conséquence.



--