Discussion :

[elcoyotos]

Bonjour,

MYSQL 8.0.35 chez OVH
table : interclassement utf8mb3_unicode_ci
champ : mediumtext utf8mb3_unicode_ci

Je souhaite passer mes champs de utf8mb3_unicode_ci vers utf8mb4_unicode_ci.
Pour certains champs, il n'y a aucun problème.
Pour d'autres, je rencontre une erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
ALTER TABLE `MA_TABLE` CHANGE `CHAMP_A_CONVERTIR` `CHAMP_A_CONVERTIR` BLOB;
MySQL a répondu
#1406 - Data too long for column 'CHAMP_A_CONVERTIR' at row 2057

Au passage, je ne comprends pas pourquoi une conversion de mon champ est effectué de mediumtext vers blob ?

Quelqu'un peut il m'éclairer ?
Question subsidiaire : J'ai lu partout que utf8mb4 était plus performant que utf8mb3. Ca vaut donc le coup de migrer mes champs ?
Merci d'avance ...

[SQLpro]

MySQL que j’appelle couramment MySQmerde est le SGBDR le plus pourri au niveau des performances... On t'as dit que utf8mb4 était plus performant....Penses tu un seul instant que coder les mêmes caractères avec 4 octets (cas de utf8mb4) est plus performant que de coder des caractères sur 3 octets (utf8mb3) ???

Le simple fait que tu passe du mediumtext au BLOB (plus exactement à un CLOB (Character Large OBject) prouve que cela sera pire....

En sus les index de MySQL sont limités en nombre d'octets dans leurs clé.... Tu auras donc moins d'index utilisable en passant d'un encodage de 3 à 4 octets....

Sache que dans les SGBDR d'entreprise on utilise le NVARCHAR qui code la même chose sur 2 octets.... (SQL Server par exemple).

A +

[elcoyotos]

Ok, merci pour ton rapide retour

[Artemus24]

Salut à tous.

Quelle langue utilises tu dans tes tables Mysql ?
Si c'est le français ainsi que l'anglais, le mieux est d'utiliser ISO-8859-1.
Au moins avec ce charset, tu auras un caractère = un octet.

@+

[elcoyotos]

J'utilise le français.

Si c'est le français ainsi que l'anglais, le mieux est d'utiliser ISO-8859-1.
Au moins avec ce charset, tu auras un caractère = un octet.

C'est noté

[Séb.]

Or besoins spécifiques, le mieux est d'utiliser les charset et collation par défaut de MySQL, soient utf8mb4 et utf8mb4_0900_ai_ci.

https://dev.mysql.com/doc/refman/8.0/en/charset.html

Si le problème est toujours d'actualité, donne un échantillon qu'on puisse reproduire la situation et voir comment corriger.

[elcoyotos]

Merci pour ta réponse mais je vais m'arrêter à celle de SQLpro...

[Artemus24]

Son astuce est pour Microsoft SQL Server, or tu es sous MySql et ça n'existe pas.
Mon astuce est en effet de passer au "latin1" qui est l'équivalent du "ISO-8859-1".

[elcoyotos]

Je vais laisser en UTF8 car à l'époque (il y a longtemps) j'avais galéré pour ne pas avoir de caractères bizarres sur mes page PHP. Merci pour tes conseils...

[Séb.]

Je vais laisser en UTF8 car à l'époque (il y a longtemps) j'avais galéré pour ne pas avoir de caractères bizarres sur mes page PHP. Merci pour tes conseils...

Eh bien j'ai l'honneur de t'annoncer que tes galères recommenceront un jour ou l'autre, alors mieux vaut t'y pencher pendant que tu es chaud

https://dev.mysql.com/doc/refman/8.3...code-utf8.html

Note
The recommended character set for MySQL is utf8mb4. All new applications should use utf8mb4.

The utf8mb3 character set is deprecated. utf8mb3 remains supported for the lifetimes of the MySQL 8.0.x and following LTS release series, as well as in MySQL 8.3.

Expect utf8mb3 to be removed in a future major release of MySQL.

Since changing character sets can be a complex and time-consuming task, you should begin to prepare for this change now by using utf8mb4 for new applications. For guidance in converting existing applications which use utfmb3, see Section 12.9.8, “Converting Between 3-Byte and 4-Byte Unicode Character Sets”.

[elcoyotos]

Ok, merci pour cette précision. La réponse de SQLpro était donc à coté de la plaque...
puisque :

you should begin to prepare for this change now by using utf8mb4

j'en reviens à ma question initiale :
Je souhaite passer mes champs de utf8mb3_unicode_ci vers utf8mb4_unicode_ci.
Pour certains champs, il n'y a aucun problème.
Pour d'autres, je rencontre une erreur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 ALTER TABLE `MA_TABLE` CHANGE `CHAMP_A_CONVERTIR` `CHAMP_A_CONVERTIR` BLOB;
MySQL a répondu #1406 - Data too long for column 'CHAMP_A_CONVERTIR' at row 2057

Au passage, je ne comprends pas pourquoi une conversion de mon champ est effectué de mediumtext vers blob ?

[Séb.]

J'en reviens à mon propos :

Si le problème est toujours d'actualité, donne un échantillon qu'on puisse reproduire la situation et voir comment corriger.

Au passage, je ne comprends pas pourquoi une conversion de mon champ est effectué de mediumtext vers blob ?

Peut-être une suite d'octets invalide interprétée comme du binaire.

[Artemus24]

Je vais laisser en UTF8 car à l'époque (il y a longtemps) j'avais galéré pour ne pas avoir de caractères bizarres sur mes page PHP. Merci pour tes conseils...

Justement, tes caractères bizarres, comme tu dis, sont dû à une incohérence des charsets que tu utilises.
Coté MySql, cela concerne la base de données (database) mais aussi les tables et les colonnes en char.
Mais pas quel cela, car il y a aussi le server et le filesystem qui est utilisé par MySql.
Sans oublier le "init-connect='SET NAMES latin1 COLLATE latin1_general_ci'".
Mais aussi au niveau des pages HTML ou PHP, ainsi qu'au niveau d'apache.

Donc non, ce n'est pas à remettre au lendemain car il est inutile d'utiliser de l'UTF8 si tu travailles qu'avec du français.
Mettre de l'UTF8 a un sens quand on utilise du chinois, de l'arabe ou je ne sais quel autre alphabet non latin.

Pour d'autres, je rencontre une erreur :

L'erreur est dû à une méconnaissance de ce que tu fais.
Un caractère est codé de 1 à 3 octets avec "utf8mb3". Si tu passes à "utf8mb4", tes caractères seront codés de 1 à 4 octets.
En tout logique, ta chaîne de caractères stockée sera soit équivalente ou soit plus longues en terme d'octets.
Quel est l'intérêt d'avoir un stockage pplus long ? Réponse : pour se créer des problèmes qui n'ont pas lieu d'être.

Donc pour reprendre le sujet, c'est débile de modifier le charset car cela n'apporte aucun avantage, sinon à voir la volumétrie de tes colonnes en char augmentée.
Et justement, l'une de tes incohérence est ce changement de type en blob.

Si tu ne veux pas suivre nos conseils, on peut se demander ce que tu es venu faire dans ce forum.

[Séb.]

Donc non, ce n'est pas à remettre au lendemain car il est inutile d'utiliser de l'UTF8 si tu travailles qu'avec du français.
Mettre de l'UTF8 a un sens quand on utilise du chinois, de l'arabe ou je ne sais quel autre alphabet non latin.

Le Latin1 MySQL est en réalité le CP1252 Windows (et non ISO-8859-1) agrémenté de quelques extensions.

MySQL's latin1 is the same as the Windows cp1252 character set. This means it is the same as the official ISO 8859-1 or IANA (Internet Assigned Numbers Authority) latin1, except that IANA latin1 treats the code points between 0x80 and 0x9f as “undefined,” whereas cp1252, and therefore MySQL's latin1, assign characters for those positions. For example, 0x80 is the Euro sign. For the “undefined” entries in cp1252, MySQL translates 0x81 to Unicode 0x0081, 0x8d to 0x008d, 0x8f to 0x008f, 0x90 to 0x0090, and 0x9d to 0x009d.

C'est triste de se limiter à un charset doublement propriétaire (Windows / MySQL) ultra-limité et obsolète quand tout tend vers un codage universel et unique, et surtout de militer pour cela

Si tu ne veux pas suivre nos conseils, on peut se demander ce que tu es venu faire dans ce forum.

Le sujet porte sur le passage utf8mb3 => utf8mb4, pas sur la régression utf8mb3 => latin1.

[elcoyotos]

Le sujet porte sur le passage utf8mb3 => utf8mb4, pas sur la régression utf8mb3 => latin1.

Merci Séb., je n'aurai pas mieux dit...

Du coup, j'ai vu une autre option dans PHPMYADMIN.
Plutôt que de passer par modifier sur le champ, je suis passé par l'onglet opérations puis : Interclassement en cochant la case : Changer le classement de toutes les colonnes
J'ai eu le message suivant avant de valider :

Par cette opération, MySQL tente de mapper les valeurs de données entre les classements. Si les jeux de caractères sont incompatibles, il peut y avoir une perte de données et les données perdues peuvent NE PAS être récupérables simplement en changeant la colonne de classement. Pour convertir les données existantes, il est conseillé d'utiliser le mode d'édition de colonne (le lien « Modifier ») sur la page de structure de table.
Faut-il vraiment modifier tous les classements de colonnes et convertir les données ?

J'ai validé, bien sur j'ai fait une sauvegarde avant et, à priori, tout c'est bien passé...

Une idée de comment je peux vérifier que tout est OK dans ma table en sachant que ce n'est que du français ?

Merci Séb. pour ta ténacité

[Séb.]

Tu peux voir l'état actuel de tes colonnes en faisant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
select all table_schema, table_name, column_name, data_type, character_set_name, collation_name
from information_schema.columns
where table_name = 'ta_table'
order by ordinal_position asc;

Change également les charsets/collations par défaut au niveau de la table et de la base de données.
Il y aura peut-être aussi des paramètres côté serveur / PDO à revoir.

Une idée de comment je peux vérifier que tout est OK dans ma table en sachant que ce n'est que du français ?

Je ne sais pas dans quelle mesure phpMyAdmin est bon sur l'exercice.
Affiche les valeurs sur une page ayant en en-tête <meta charset="utf-8">.

[Artemus24]

Le Latin1 MySQL est en réalité le CP1252 Windows (et non ISO-8859-1) agrémenté de quelques extensions.

Les trois charset sont très proche. Il y a quelques petites différentes. Oui et alors ?
Tu ne vas pas me dire que sous windows, ton charset" windows-1252" ne te convient pas.
Si tu ne l'as pas changé, c'est qu'il répond à tes besoins ou bien est-ce que je me trompe ?

C'est triste de se limiter à un charset doublement propriétaire (Windows / MySQL) ultra-limité et obsolète quand tout tend vers un codage universel et unique, et surtout de militer pour cela

Où as tu vu qu'il est obsolète ?
Je n'ai besoin que du français et de l'anglais. Les alphabets autres qua latin ne m'intéressent pas.
Pourquoi devrais-je utiliser UTF8 sachant que la volumétrie serait supérieure à celle que j'ai actuellement.

Le sujet porte sur le passage utf8mb3 => utf8mb4, pas sur la régression utf8mb3 => latin1.

Merci de me le rappeler mais je l'avais bien compris.

Il ne s'agit pas de faire une régression, mais d'identifier les besoins réels et de s'y contraindre.
L'intérêt de l'UTF8 est d'utiliser des alphabets autres que le latin, or ce n'est pas le cas.
Si tu peux avoir 1 caractère = 1 octet pourquoi utiliser un charset qui va augmenter ta volumétrie ?
Désolé de le dire, mais ce n'est pas logique du tout.

[elcoyotos]

charset tables, champs, base de données, PDO -> utf8mb4
charset pages sur mon site->utf-8
Au passage, Artemus24, est ce qu'avec un emoji genre 🌵 1 octet suffit ?
Mes tables avec le passage sur 4 octets ne sont pas plus grosse (elle n'ont pas prit un octet supplémentaires)

[SQLpro]

...
Un caractère est codé de 1 à 3 octets avec "utf8mb3". Si tu passes à "utf8mb4", tes caractères seront codés de 1 à 4 octets.....

Pas tout à fait... Dans MySQL tout est codé sous 3 octets dans utf8mb3 et 4 dans utf8mb4, mais les caractères de padding sont ignorés suivant le code des 2 premiers bits...
Un exemple pour utf8mb4

• si 2 premiers bit = 00 => 3 premiers octets ignorés
• si 2 premiers bit = 01 => 2 premiers octets ignorés
• si 2 premiers bit = 10 => le premier octet ignoré
• si 2 premiers bit = 11 => aucun octet ignoré

A +