En MySQL, si je crée un nouveau champ VARCHAR(32) dans une table UTF-8, est-ce que cela signifie que je peux stocker 32 octets de données dans ce champ ou 32 caractères (multi-octets) ?
Cette réponse est apparue en haut des résultats de recherche Google mais n'était pas correcte.
La confusion est probablement due à différentes versions de MySQL en test.
Voici la citation de la documentation officielle de MySQL 5 documentation:
MySQL interprète les spécifications de longueur dans les définitions de colonnes de caractères en unités de caractères. (Avant MySQL 4.1, les longueurs de colonnes étaient interprétées en octets.) Cela s'applique aux types CHAR, VARCHAR et TEXT.
Intéressant (je n'y avais pas pensé), la longueur maximale d'une colonne VARCHAR est affectée par utf8 comme suit :
La longueur maximale effective d'un VARCHAR dans MySQL 5.0.3 et ultérieur est soumise à la taille de rangée maximale (65 535 octets, qui est partagée entre toutes les colonnes) et l'ensemble de caractères utilisé. Par exemple, les caractères utf8 peuvent nécessiter jusqu'à trois octets par caractère, donc une colonne VARCHAR qui utilise l'ensemble de caractères utf8 peut être déclarée pour un maximum de 21 844 caractères.
M Brown, merci d'avoir mentionné cela. Un champ VARCHAR(10) (utilisant utf8mb4) peut stocker "" (10 tas de crottes), cela représente 10 caractères mais 40 octets.
Cela. C'est la seule bonne réponse. Trop de gens croient en la version 4 comme si c'était l'évangile.
La réponse acceptée est également correcte pour MySQL 5 -- les chiffres insérés faisaient en réalité partie de l'ensemble de caractères pleine largeur et sont des caractères unicode multi-octets, comme l'a également mentionné l'auteur qu'il a inséré "32 données multioctets". C'est dommage que tant de gens aient mal compris.
Cela vous permettrait de stocker 32 caractères multi-octets
Pour économiser de l'espace avec UTF-8, utilisez VARCHAR au lieu de CHAR. Sinon, MySQL doit réserver trois octets pour chaque caractère dans une colonne CHAR CHARACTER SET utf8 car c'est la longueur maximale possible. Par exemple, MySQL doit réserver 30 octets pour une colonne CHAR(10) CHARACTER SET utf8.
Je n'utilise presque jamais CHAR et quand je le fais, ce n'est pas dans le but de stocker des caractères multi-octets, donc je suis en sécurité. Et pour VARCHAR, es-tu sûr que la limite est définie en caractères multi-octets et non en caractères mono-octets ?
@jspcal : UTF-8 utilise un maximum de 4 octets par caractère, pas 3. Ou est-ce que MySQL ne prend pas en charge les 4 octets ?
@RemyLebeau Tu as raison à propos de utf8, mais pas pour MySQL. Les divers jeux de caractères utf8_xxx sont au maximum de 3 octets. Les utf8mb4_xxx prennent en charge des caractères de 4 octets. dev.mysql.com/doc/refman/5.5/en/charset-unicode-utf8mb4.html
En standard UTF-8, les caractères ASCII ne seront stockés que sur un seul octet - pour tester vraiment cela, vous devez réellement utiliser des caractères multioctets (c'est-à-dire non-ascii) dans votre chaîne de test.
C'est faux, du moins pour MySQL 5+. Lorsque vous spécifiez la taille de colonne pour varchar ou char, elle est spécifiée en termes de caractères. Je crois que la taille réelle d'une colonne VARCHAR(32) serait de 32x3+1=97 octets.
Ce n'est pas une réponse, mais je ne peux pas commenter sans aucune réputation :P
Il semble que MySQL supporte plus de types Unicode à partir de la version 5.5 et plus.
De MySQL 5.5 http://dev.mysql.com/doc/refman/5.5/fr/charset-unicode.html
Il est préférable d'utiliser "char" pour les tables à mises à jour fréquentes car la longueur totale des données de la ligne sera fixe et rapide. Les colonnes Varchar rendent les tailles de données de ligne dynamiques. Ce n'est pas bon pour MyISAM, mais je ne sais pas pour InnoDB et les autres. Par exemple, si vous avez une colonne "type" très étroite, il peut être préférable d'utiliser char(2) avec un jeu de caractères latin1 pour ne réclamer qu'un espace minimal.
J'ai lu que si UNE colonne dans une table est varchar, alors vous perdez tous les avantages d'avoir des colonnes char. Fondamentalement, il semble que vous devez utiliser uniquement varchar ou uniquement char dans une table pour en tirer le maximum d'avantages. Je ne sais pas si c'est vrai, cependant.
Pour MyISAM, il y a certains arguments en faveur de CHAR. Pour InnoDB, tellement d'autres choses se passent que le débat sur la "taille de ligne dynamique/fixe" est essentiellement sans importance.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
@naXa : Je ne l'ai pas fait. Tu penses que je devrais ?
0 votes
Je ne sais pas.) C'est votre question, et c'est à vous de décider. Je voulais juste dire "une autre réponse semble plus complète".
0 votes
@robsch La réponse acceptée précédente était simple et correcte. Mais en raison de la demande populaire, j'ai accepté celle que vous souhaitez.