le 18/03/2014 à 15:23
Problème sur création table en SQL.
Ce sont souvent les erreurs les plus bêtes qui nous ralentissent le plus !
En ce qui concerne les caractères, il faut être très prudent quand au vocabulaire qu'on emploi. Les caractères sont codés sur 8 bits dans la table ASCII, qui permet donc de coder 2[sup]8[/sup] - 1 caractères au maximum. Parmi tous ces caractères, le format ASCII réserve quelques plages pour des caractères non-imprimables ou spéciaux (retour à la ligne, tabulations, etc).De plus, à la base, ASCII réserver le premier bit pour permettre de contrôler que le byte a été bien passé. Depuis, ce bit est utilisé et permettre d'utiliser un encodage étendu (ISO8859-1 ou latin1). Mais ce n'est toujours pas suffisant, et certaines langues requièrent un encodage plutôt qu'un autre, pensons aux langues cyrilliques, à l'arabe, au chinois, etc.
Depuis on a inventé unicode et UTF-8 (qui en est un sous-ensemble), dont ASCII a lui-même été fait un sous-ensemble. Unicode permet d'encoder tous les caractères en utilisant un encodage à taille variable. Celui que nous utilisons le plus souvent est un encodage sur un ou deux octets, UTF-8.
Ceci est pour le codage dans un fichier.
Il faut que tu différencie ce codage de la représentation graphique (le glyphe) d'un caractère. Le glyphe est fournit par une font, qui est globalement un catalogue de glyphes pour chaque caractère. Donc non, 'm' ou 'n' n'ont pas une taille différente dans la table de caractère. Par contre, leur glyphe peut éventuellement l'être. Mais ça ne nous intéresse pas quand nous écrivons un caractère dans un fichier, une base de données, etc.
Maintenant, en ce qui concerne char ou varchar, la taille que tu fournis indique combien de caractères tu veux pouvoir insérer dans un champ en base. La taille du caractère en lui-même devrait être géré par la base de données (en fonction de l'encodage et de la collation choisie).
Ces quelques éléments devraient te permettre d'y voir plus clair.
En ce qui concerne les caractères, il faut être très prudent quand au vocabulaire qu'on emploi. Les caractères sont codés sur 8 bits dans la table ASCII, qui permet donc de coder 2[sup]8[/sup] - 1 caractères au maximum. Parmi tous ces caractères, le format ASCII réserve quelques plages pour des caractères non-imprimables ou spéciaux (retour à la ligne, tabulations, etc).De plus, à la base, ASCII réserver le premier bit pour permettre de contrôler que le byte a été bien passé. Depuis, ce bit est utilisé et permettre d'utiliser un encodage étendu (ISO8859-1 ou latin1). Mais ce n'est toujours pas suffisant, et certaines langues requièrent un encodage plutôt qu'un autre, pensons aux langues cyrilliques, à l'arabe, au chinois, etc.
Depuis on a inventé unicode et UTF-8 (qui en est un sous-ensemble), dont ASCII a lui-même été fait un sous-ensemble. Unicode permet d'encoder tous les caractères en utilisant un encodage à taille variable. Celui que nous utilisons le plus souvent est un encodage sur un ou deux octets, UTF-8.
Ceci est pour le codage dans un fichier.
Il faut que tu différencie ce codage de la représentation graphique (le glyphe) d'un caractère. Le glyphe est fournit par une font, qui est globalement un catalogue de glyphes pour chaque caractère. Donc non, 'm' ou 'n' n'ont pas une taille différente dans la table de caractère. Par contre, leur glyphe peut éventuellement l'être. Mais ça ne nous intéresse pas quand nous écrivons un caractère dans un fichier, une base de données, etc.
Maintenant, en ce qui concerne char ou varchar, la taille que tu fournis indique combien de caractères tu veux pouvoir insérer dans un champ en base. La taille du caractère en lui-même devrait être géré par la base de données (en fonction de l'encodage et de la collation choisie).
Ces quelques éléments devraient te permettre d'y voir plus clair.