Bonjour,

je sais que un champs dont le type est CHAR(255) monopolisera 255 octets et théoriquement peux contenir 255 caracteres.

Mais si j'utilise utf8-unicode_ci qui permet notemment d'ecrire des caracteres chinois, sera t il possible de mettre aussi 255 caractères chinois sachant que ceux ci sont utilisent parfois jusque 4 Octets?

Merci d'avance pour ceux qui sauront repondre à cette question 

Bonjour,

Un peu de lecture

http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-utf8.html

http://stackoverflow.com/questions/10081500/mysql-char-varchar-character-sets-storage-sizes

utf8 (pas utf8mb4 = unicode 5.0.0) correspond à la version 3.0.0 d'Unicode donc les points sont codés sur au maximum 3 octets et non 4.

Le type varchar, contrairement à char, ne correspond pas à un octet mais à un point de code ((VAR)CHAR(255) = au plus 3 * 255 points = 765 octets - avec de l'utf8 - plus pour de l'utf8mb4).

-
Edité par julp 7 mai 2013 à 21:20:18

OK merci pour vos informations.

Si je comprends bien...:

j'aurai donc en choisissant VARCHAR sous PHP5 la possiblité de stocker jusque 255 Caractères* par champs.

Chacun de ces caractères utilisera :

• un octet pour les caractères latin de base (ie sans accents)
• deux octets pour les caractères latin accentués, arabe, grec, hebreux...
• trois octets pour les caractères chinois, japonnais...

Exemple:

• VARCHAR (32) pourra contenir 32 caractères, mais suivant que ceux-ci sont en chinois ou en Francais la taille utilisé dans la BDD ne sera pas la meme.
• la phrase"le site du zero est bien pratique" utilisera donc 33 octets (32 caractère espace inclue + 1 octet pour connaitre le nombre de caractere utilisé)
• "很久以 很久以前 有个大富他 有十五个儿子 每天不是吵架就 谁也助谁" = 89 octets (32 caractère: 4 espaces x1octets + 28 caractères chinois X 3octets + 1 octet pour connaitre le nombre de caractere utilisé)

* 65535 caractere sous MySQL 5.5

65535 caractere sous MySQL 5.5

Non, la taille maximale d'une ligne est de 65535 octets depuis MySQL 5.0.3 donc au plus 21844 points de code max [pour de l'utf8]. Mais comme cet espace est +/- partagé, ça impliquerait de n'avoir qu'une colonne VARCHAR en non null. En revanche, les types *TEXT, c'est des limites en octets, pas en points.

Pour le reste :

• PHP n'a rien à voir dans l'histoire, il ne fait récupérer ce qu'on (le SGBD) lui envoie
• c'est ainsi qu'est défini la façon d'encoder un point Unicode en UTF-8 (ce n'est pas propre à MySQL)
• attention à la définition ambiguë de "caractères" (points de code contre graphèmes)

VARCHAR (32) pourra contenir 32 caractères, mais suivant que ceux-ci sont en chinois ou en Francais la taille utilisé dans la BDD ne sera pas la meme

C'est un peu le but de ce type de données (longueur variable) et la définition du jeu utf8 où un point peut être codé sur une longueur variable (de 1 à 3 octets).

Sinon le raisonnement des calculs a l'air correct (la flemme de vérifier et si on considère l'espace total sur une ligne, il faudrait prendre d'autres points en considération)

-
Edité par julp 7 mai 2013 à 21:25:54

OK merci julp.

J'avoue ne pas être familié avec les notions de "points de code" que je découvre.