Faut-il utiliser Latin-1 sur UTF-8 pour la configuration de la base de données?
Nous utilisons MySQL dans l'entreprise pour laquelle je travaille, et nous construisons des applications clientes et internes en utilisant Ruby on Rails.
Quand j'ai commencé à travailler ici, j'ai rencontré un problème que je n'avais jamais rencontré auparavant; la base de données sur le serveur de production est définie sur Latin-1, ce qui signifie que la gemme MySQL lève une exception chaque fois qu'il y a une entrée utilisateur où l'utilisateur copie et colle des caractères UTF-8.
Mon patron appelle ces "mauvais personnages" car la plupart d'entre eux sont des caractères non imprimables, et dit que nous devons les supprimer. J'ai trouvé quelques façons de le faire, mais finalement nous nous sommes retrouvés dans une situation où un personnage UTF-8 était nécessaire. De plus, c'est un peu compliqué, d'autant plus qu'il semble que la seule solution que j'ai jamais lue pour ce problème soit de simplement définir la base de données sur UTF-8 (cela a du sens pour moi).
Le seul argument que j'ai entendu pour s'en tenir à Latin-1 est que permettre les caractères UTF-8 non imprimables peut perturber les recherches de texte/texte intégral dans MySQL. Est-ce vraiment vrai?
Y a-t-il d'autres raisons pour lesquelles on devrait utiliser Latin-1 sur UTF-8? C'est ma compréhension qu'il est supérieur et devient plus omniprésent.
Unicode est certainement difficile, et l'encodage UTF-8 a quelques propriétés gênantes. Cependant, UTF-8 est devenu le codage standard de facto sur le Web, dépassant ASCII, Latin-1, UCS-2 et UTF-16. Juste tilisez UTF-8 partout .
La raison la plus importante pour laquelle vous devriez prendre en charge Unicode est que vous ne devez pas faire d'hypothèses inutiles sur les entrées utilisateur. Je n'ai aucune idée de ce qu'est votre domaine, mais des choses comme les noms d'utilisateur hébreux, un article de blog sur la Chine, un commentaire avec Emoji, ou tout simplement un texte bien stylé - comme "ceci" - devraient être possibles ... Oh, c'étaient des guillemets typographiquement corrects ( “” plutôt que ""), des tirets en largeur et des points de suspension, qui sont des caractères courants dans le texte anglais, mais non pris en charge par ASCII ou Latin-1. Par conséquent, la prise en charge d'autres scripts n'est pas juste un gros f * ck vous à d'autres cultures, mais s'en tenir au latin-1 ne vous permet même pas d'écrire l'anglais correct.
La notion selon laquelle Unicode n'autorise que les "mauvais caractères" est fausse. Oui, le texte est vraiment compliqué et Unicode ne vous le cachera pas. Votre patron peut penser à des caractères composés, où un point de code de base tel que a est modifié par des points de code ultérieurs qui, par exemple représentent des signes diacritiques pour former un caractère visuel tel que á. Cela ne vous gêne pas vraiment lorsque vous essayez de faire des recherches si vous effectuez une sorte de normalisation. Par exemple, vous pouvez stocker tout le texte sous la forme NFC qui réduit ces compositions dans leur forme précomposée si une est disponible. Lorsque vous effectuez une recherche, vous pouvez également supprimer tous les caractères de composition du texte, mais cela peut changer considérablement leur signification dans certaines langues.
Unicode ajoute également beaucoup de caractères non imprimables - mais même ASCII en a beaucoup. Allez-vous gérer un NUL au milieu d'une chaîne? Que diriez-vous de 0x1C, un "séparateur de fichiers"? I ' ve jamais vu la moitié de ceux-ci . Latin-1 ajoute un trait d'union doux qui indique les possibilités de coupure de Word, mais est autrement invisible. Est-ce que cela casse également votre recherche de texte intégral? En d'autres termes, même ASCII et Latin-1 vous permettent d'interrompre complètement votre saisie si vous supposez que ce n'est que du texte imprimable!
Je pense qu'au-delà de la question technique, votre patron n'a peut-être pas le temps de se tenir au courant des normes actuelles.
Étant donné que sa position n'est pas complètement à l'heure du déjeuner, juste obsolète, respectez sa position lorsque vous discutez de cette question (et vous devez vous rappeler de discuter, ne discutez pas), et essayez de résoudre les problèmes qu'il a en ce qui concerne UTF-8. Je soupçonne que le problème sous-jacent n'est pas un problème technique et peut nécessiter un certain niveau de négociation de compétences générales.
Lequel d'entre nous a raison?
Il était une fois votre patron. Mais avec le temps, les choses changent. De nos jours, vous êtes (mais avant de courir vers votre patron, assurez-vous de lire aussi la réponse de Nelson ).
Les anciennes versions de MySQL, et les anciennes versions de presque tout, traitaient beaucoup mieux avec l'ancien Latin1/ISO-8859-1 (5) qu'avec UTF8.
Il y a une raison pour laquelle UTF8 a été créé, évolué et poussé presque partout: s'il est correctement implémenté, il fonctionne beaucoup mieux. Il existe des problèmes de performances et de stockage dus au fait qu'un caractère Latin1 fait 8 bits, tandis qu'un caractère UTF8 peut avoir une longueur de 8 à 32 bits. Ainsi, lorsque vous planifiez VARCHAR, vous devez en tenir compte. Et vos routines de recherche seront un peu plus lentes. Ils seront capables de faire plus de choses (par exemple des recherches avec sensibilité aux accents ou sans . Ne peuvent pas faire ceux en Latin1 sans un travail approfondi), mais ils le feront prendre un un peu plus de temps.
Mais d'un autre côté, le stockage est bon marché, le réaliste surcharge de taille de fichier est inférieur à 2-3%, la puissance de calcul est également bon marché et devient moins chère en bon accord avec la loi de Moore; tandis que votre temps et les attentes de vos clients définitivement aren 't.
Vous pourriez avoir à vous soucier des outils de recherche, etc. si vous étiez le seul à développer de tels outils. Mais vous ne l'êtes probablement pas. Vous utilisez ces outils; même ceux qui n'étaient pas complètement conformes à UTF8 hier (comme les anciens MySQL ne l'étaient pas), le sont aujourd'hui ou le seront bientôt (par exemple MySQL avec le support utf8mb4).
Donc, en planifiant et en implémentant soigneusement UTF8 dans le bon sens ( et non en le frappant sur Latin1 après coup), vous pouvez avoir un code qui est très raisonnablement à l'épreuve du temps, ce qui, si vous prévoyez de faire des affaires avec n'importe quel pays asiatique, est une très bonne chose. Et si vous n'avez pas de tels plans, d'autres personnes en auront, et ces personnes pourraient être vos clients, fournisseurs ou partenaires.
Ainsi, quand ils commenceront à vous envoyer des données UTF8, vous devrez configurer un machin compliqué pour convertir en latin Latin1 et gérer les cas insolubles.
Lorsque vous tenez compte du budget, le coût de plusieurs escarmouches contre les ninjas maléfiques mojibake , et considérez que ils ne vont pas disparaître - comme vous l'avez déjà découvert - alors vous vous rendrez compte qu'aller UTF8 est non seulement plus simple, mais aussi moins cher.
Certaines situations où restreindre le jeu de caractères uniquement à ASCII peut avoir un sens est pour les champs à choix limité, par exemple les champs d'état, parce que vous contrôlez strictement les valeurs qui peuvent être là, et les clés étrangères/références à externe système, car il y a rarement des raisons pour qu'ils aient autre chose que des caractères alphanumériques et quelques symboles.
Pour tout autre texte, utilisez simplement UTF-8.
Pour commencer avec la réponse, peu importe comment votre serveur est configuré. L'encodage de caractères dans MySQL peut être configuré par colonne (cela signifie que la même table peut contenir des caractères dans plusieurs encodages, c'est facile). C'est à dire. mon serveur (et un certain nombre de bases de données héritées) est configuré par défaut pour cp1251 pour les anciens clients qui ne peuvent pas définir un classement correct lors de la connexion (différents clients matériels), mais les bases de données principales en production utilisent toutes UTF-8.
En parlant de "gaspillage d'espace" - vous ne pouvez pas, de façon réaliste, appeler des données importantes un gaspillage, n'est-ce pas? L'augmentation de l'espace de stockage, cependant, sera différente selon la langue dans laquelle vos données sont. De l'augmentation insignifiante (moins de 1%) si votre site est principalement en anglais et jusqu'à 100%, s'il s'agit de mailny utilisant des caractères en dehors du ASCII plage. Et encore plus, si vous vous déplacez vers l'est. Les spécifications UTF-8 ultérieures (appelées UTF8mb4) autorisent jusqu'à 4 octets par point de code.
Et à "qui a raison"… La vérité est que c'est une question sociale plus que technique. Il peut y avoir des raisons valables pour des configurations de serveur spécifiques, mais vous devez connaître les implications. Mais si vous me demandez, il n'y a aucune raison de ne pas utiliser UTF-8. C'est le genre unique pour gouverner tous les textes du monde.
Expliquez-lui simplement que l'UTF-8 est la valeur par défaut pour le trafic Web. Et tout utilisateur peut entrer n'importe quel caractère Unicode valide dans son navigateur.
Il est beaucoup plus facile d'avoir utf-8/unicode de bout en bout que de traiter les nombreux problèmes qui résultent de utf-8-> latin-1-> utf-8.