TF-8 est préparé à la domination du monde, Latin1 ne l'est pas.
Si vous essayez de stocker des caractères non latins comme le chinois, le japonais, l'hébreu, le russe, etc. en utilisant le codage Latin1, ils se retrouveront sous la forme mojibake . Vous pouvez trouver le texte d'introduction de cet article utile (et même plus si vous connaissez un peu Java).
Notez que la prise en charge complète de UTF-8 sur 4 octets n’a été introduite que dans MySQL 5.5. Avant cette version, elle ne dépassait pas 3 octets par caractère, pas 4 octets par caractère. Ainsi, il ne supportait que le plan BMP et pas par exemple le plan Emoji. Si vous souhaitez une prise en charge intégrale du format UTF-8 sur 4 octets, mettez à niveau MySQL vers au moins la version 5.5 ou optez pour un autre SGBDR comme PostgreSQL. Dans MySQL 5.5+, il est appelé utf8mb4 .
En latin1, chaque caractère a exactement un octet de long. Dans utf8, un caractère peut être composé de plusieurs octets. En conséquence, utf8 a plus de caractères que latin1 (et les caractères qu’ils ont en commun ne sont pas nécessairement représentés par le même octet/octet).