Chapitre 10 Jeux de caractères et Unicode

Le serveur MySQL a un jeu de caractères et une collation serveur, qui ne peuvent pas être nuls.

MySQL détermine le jeu de caractères et la collation serveurs comme suit :

A ce niveau, la décision est simple. Le jeu de caractères serveur et sa collation dépendent des options que vous utilisez au démarrage de mysqld. Vous pouvez utiliser --default-character-set=character_set_name comme jeu de caractères et vous pouvez en même temps ajouter --default-collation=collation_name pour la collation. Si vous n'indiquez pas de jeu de caractères, cela revient à dire --default-character-set=latin1. Si vous indiquez un jeu de caractères (par exemple, latin1) mais pas de collation, cela revient à dire : --default-charset=latin1 --collation=latin1_swedish_ci car latin1_swedish_ci est la collation par défaut de latin1. par conséquent, les trois commandes suivantes ont toutes le même effet :

shell> mysqld
shell> mysqld --default-character-set=latin1
shell> mysqld --default-character-set=latin1
           --default-collation=latin1_swedish_ci

Une fa¸on de changer la configuration par défaut est de recompiler MySQL. Si vous voulez changer le jeu de caractères et la collation par défaut du serveur quand vous compilez depuis les sources, utilisez --with-character-set et --with-collation comme arguments pour configure. Par exemple :

shell> ./configure --with-character-set=latin1

ou :

shell> ./configure --with-character-set=latin1
           --with-collation=latin1_german1_ci

mysqld et configure vérifient aussi que la combinaison jeu de caractères/collation est valide. Ces programmes affichent un message erreur et se terminent si la combinaison n'est pas valide.

Toute base de données a un jeu de caractères de base de données et une collation de base de données, qui ne peuvent pas être nulles. Les commandes CREATE DATABASE et ALTER DATABASE permettent de utiliser optionnellement ces deux attributs :

CREATE DATABASE db_name
   [DEFAULT CHARACTER SET character_set_name [COLLATE collation_name]]

ALTER DATABASE db_name
    [DEFAULT CHARACTER SET character_set_name [COLLATE collation_name]]

Exemple :

CREATE DATABASE db_name
   DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

MySQL choisit le jeu de caractères et la collation de base de données comme ceci :

La syntaxe MySQL CREATE DATABASE ... DEFAULT CHARACTER SET ... est analogue à la syntaxe du standard SQL CREATE SCHEMA ... CHARACTER SET .... Il est donc possible de créer des bases de données avec différents jeux de caractères et collations, sur le même serveur MySQL.

Le jeu de caractères et la collation sont utilisées comme valeur par défaut pour les tables, lorsque ces informations ne sont pas spécifiées dans les commandes CREATE TABLE. Elles n'ont pas d'autres utilité.

Chaque table a un jeu de caractères et une collation de table qui ne peut pas être nulle. Les commandes CREATE TABLE et ALTER TABLE ont maintenant des options pour préciser le jeu de caractères et la collation :

CREATE TABLE table_name ( column_list )
   [DEFAULT CHARACTER SET character_set_name [COLLATE collation_name]]

ALTER TABLE table_name
   [DEFAULT CHARACTER SET character_set_name] [COLLATE collation_name]

Exemple :

CREATE TABLE t1 ( ... ) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;

MySQL choisit le jeu de caractère et la collation :

Le jeu de caractères et la collation sont utilisés comme valeurs par défaut si ces deux attributs ne sont pas précisés par la définition d'une colonne. Le jeu de caractères et la collation sont des extensions MySQL : il n'y a pas de telles fonctionnalités en SQL standard.

Chaque colonne de ``character'' (c'est à dire les colonnes de type CHAR, VARCHAR, ou TEXT) a un jeu de caractères de colonne et une collation de colonne qui ne peut pas être nulle. La syntaxe de définition de colonne a maintenant des clauses optionnelles pour préciser le jeu de caractères de colonne et la collation :

column_name {CHAR | VARCHAR | TEXT} (column_length)
    [CHARACTER SET character_set_name [COLLATE collation_name]]

Exemple :

CREATE TABLE Table1
(
   column1 VARCHAR(5) CHARACTER SET latin1 COLLATE latin1_german1_ci
);

MySQL choisit le jeu de caractères et la collation de colonne comme ceci :

Les clauses CHARACTER SET et COLLATE font partie du standard SQL.

Les exemples suivants montrent comment MySQL détermine le jeu de caractère par défaut et les valeurs de collation.

Exemple 1 : définition de table et colonne

CREATE TABLE t1
(
  c1 CHAR(10) CHARACTER SET latin1 COLLATE latin1_german1_ci
) DEFAULT CHARACTER SET latin2 COLLATE latin2_bin;

Vous avez ici une colonne avec un jeu de caractères latin1 et une collation latin1_german1_ci. La définition est explicite, c'est donc direct. Veuillez noter qu'il n'y a pas de problème à stocker une colonne latin1 dans une table latin2.

Exemple 2 : définition de table et colonne

CREATE TABLE t1
(
   c1 CHAR(10) CHARACTER SET latin1
) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;

Cette fois-ci nous avons une colonne avec un jeu de caractères latin1 et une collation par défaut. Maintenant, bien que cela puisse sembler naturel, la collation par défaut n'est pas spécifiée au niveau de la table. A la place, comme la collation par défaut de latin1 est toujours latin1_swedish_ci, la colonne c1 aura la collation latin1_swedish_ci (et non latin1_danish_ci).

Exemple 3 : définition de table et colonne

CREATE TABLE t1
(
   c1 CHAR(10)
) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;

Nous avons une colonne avec un jeu de caractères par défaut et une collation par défaut. Dans ces conditions, MySQL regarde au niveau de la table pour déterminer le jeu de caractères et la collation. Par conséquent le jeu de caractères de la colonne c1 est latin1 et sa collation est latin1_danish_ci.

Exemple 4: définition de base, table et colonne

CREATE DATABASE d1 DEFAULT CHARACTER SET latin2 COLLATE latin2_czech_ci;
USE d1;
CREATE TABLE t1
(
   c1 CHAR(10)
);

Nous créons une colonne sans préciser son jeu de caractère ni sa collation. Nous ne spécifions pas non plus de jeu de caractères ni de collation au niveau de la table. Dans ces conditions, MySQL cherche au niveau de la base de données. (La configuration de la base de donnée devient celle de la table, et par conséquent celle de la colonne.) Donc le jeu de caractères de colonne c1 est latin2 et sa collation est latin2_czech_ci.

Plusieurs variables contrôlent les jeux de caractères et collation du système pour un client. Certaines ont déjà été mentionnées précédemment :

D'autres variables et collations sont impliquées dans la gestion des connexions entre un client et un serveur. Chaque client a un jeu de caractères et une collation attitrés.

Pensez à ce qu'est une "connexion" : c'est ce que vous faites lorsque vous vous connectez au serveur. Le client envoie des SQL commandes comme des requêtes, au travers de la connexion, vers le serveur. Le serveur renvoie des réponses, comme des jeux de résultats, au client, au travers de la connexion. Ceci mène à plusieurs questions telles que :

Vous pouvez configurez ces options là, ou vous pouvez vous fier aux configurations par défaut (auquel cas vous pouvez sauter cette section).

Il y a deux commandes qui permettent de modifier le jeu de caractères de la connexion :

SET NAMES 'charset_name'
SET CHARACTER SET charset_name

SET NAMES indique ce qui est dans la commande SQL que le client envoie. Par conséquent, SET NAMES cp1251 indique au serveur : ``les futurs messages fournis par ce client seront dans le jeu de caractères cp1251'' et le serveur est libre de les traduire dans son propre jeu de caractères, éventuellement.

La commande SET NAMES 'x' est équivalente à ces trois commandes :

mysql> SET character_set_client = x;
mysql> SET character_set_results = x;
mysql> SET character_set_connection = x;

SET CHARACTER SET est similaire, mais spécifie le jeu de caractères et la collation par défaut des bases pour la connexion. Une commande SET CHARACTER SET x est équivalente à :

mysql> SET character_set_client = x;
mysql> SET character_set_results = x;
mysql> SET collation_connection = @@collation_database;

Lorsque vous exécutez la commande SET NAMES ou SET CHARACTER SET, vous changez aussi la collation de la connexion. Cependant, la collation de connexion existe uniquement par cohérence. Généralement sa valeur n'a pas d'importance.

Avec le client mysql, il n'est pas nécessaire d'exécuter la commande SET NAMES à chaque démarrage. Vous pouvez ajouter l'option --default-character-set-name dans la ligne de commande de mysql, ou dans le fichier d'options. Par exemple, la ligne suivante est exécutée automatiquement à chaque démarrage de mysql :

[mysql]
default-character-set=koi8r

EXEMPLE : supposez que column1 est défini par CHAR(5) CHARACTER SET latin2. Si vous n'indiquez pas SET CHARACTER SET, alors la commande SELECT column1 FROM t retournera les valeurs de la colonne column1 en utilisant le jeu de caractères latin2. Si, d'un autre coté, vous utilisez la commande SET CHARACTER SET latin1, le serveur va alors convertir le résultat de latin2 en latin1 juste avant de l'envoyer. De telles conversion sont lentes.

Si vous ne voulez pas que le serveur fasse des conversions, utilisez la valeur NULL à character_set_results :

mysql> SET character_set_results = NULL;

Chaque chaîne de caractères littérale a un jeu de caractères et une collation qui ne peut pas être nulle.

Une chaîne de caractères littérale peut avoir un spécificateur optionnel de jeu de caractères optionnel et une clause COLLATE :

[_character_set_name]'string' [COLLATE collation_name]

Exemples :

SELECT 'string';
SELECT _latin1'string';
SELECT _latin1'string' COLLATE latin1_danish_ci;

La simple commande SELECT 'string' utilise le jeu de caractères par défaut de la connexion.

L'expression _character_set_name est formellement appelée un spécificateur (introducer). Elle indique à l'analyseur : "la chaîne qui va suivre utilise le jeu de caractère X.'' Cela a été source de confusions par le passé; aussi nous insistons sur le fait qu'un spécificateur ne provoque pas de conversion. C'est strictement une indication, qui ne change pas la valeur de la chaîne. Un spécificateur est aussi autorisé avant des notations littérales hexadécimale et numérique (x'literal' et 0xnnnn), et avant ? (qui est une substitution de paramètre lorsque l'on utilise des commandes préparées avec une interface de langage de programmation).

Exemples :

SELECT _latin1 x'AABBCC';
SELECT _latin1 0xAABBCC;
SELECT _latin1 ?;

MySQL détermine le jeu de caractères et la collation de la fa¸on suivante :

Exemples:

Les introducteurs de jeux de caractères et la clause COLLATE sont implémentés selon les spécifications standard SQL.

Avec la clause COLLATE, vous pouvez remplacer la collation par défaut, quelle qu'elle soit, par une comparaison. COLLATE peut être utilisé dans différentes parties des requêtes SQL. Voici quelques exemples :

La clause COLLATE a précédence (plus haute que ||), donc les expressions suivantes sont équivalentes :

x || y COLLATE z
x || (y COLLATE z)

L'opérateur BINARY est un raccourci pour une clause COLLATE. Par exemple BINARY 'x' est équivalent à 'x' COLLATE y, où y est le nom d'une collation binaire appropriée. Par exemple, si nous supposons que a appartient au jeu de caractères latin1, les deux requêtes suivantes ont le même effet :

SELECT * FROM t1 ORDER BY BINARY a;
SELECT * FROM t1 ORDER BY a COLLATE latin1_bin;

Note : Chaque jeu de caractères a une collation binaire.

Dans la grande majorité des requêtes, la collation utilisée par MySQL pour résoudre une comparaison est évidente. Par exemple, dans les cas suivants, il devrait être clair que la collation sera "la collation de colonne de la colonne x'' :

SELECT x FROM T ORDER BY x;
SELECT x FROM T WHERE x = x;
SELECT DISTINCT x FROM T;

Cependant, quand des opérandes multiples sont, en jeu il peut y avoir des ambiguïtés. Par exemple :

SELECT x FROM T WHERE x = 'Y';

Cette requête devrait elle utiliser la collation de la colonne x, ou celle de la chaîne littérale 'Y'?

Le standard SQL résout de telles questions en utilisant ce qui portait le nom de règles coercitives (``coercibility''). L'essence de la question est : puisque x et 'Y' ont tous deux des collations différentes, laquelle a priorité? C'est une question complexe, mais ces règles devraient résoudre la plupart des situations :

Ces règles résolvent les ambiguités de la fa¸on suivante :

Exemples :

La fonction COERCIBILITY() peut être utilisée pour déterminer la coercibilité d'une chaîne :

mysql> SELECT COERCIBILITY('A' COLLATE latin1_swedish_ci);
        -> 0
mysql> SELECT COERCIBILITY('A');
        -> 3

See Section 12.8.3, « Fonctions d'informations ».

Souvenez-vous que chaque jeu de caractères a une ou plusieurs collations, et que chaque collation est associée à un et un seul un jeu de caractères. Par conséquent, la commande suivante engendre un message erreur car la collation latin2_bin n'est pas autorisée avec le jeu de caractères latin1 :

mysql> SELECT _latin1 'x' COLLATE latin2_bin;
ERROR 1251: COLLATION 'latin2_bin' is not valid
for CHARACTER SET 'latin1'

Dans certaines cas, les expressions qui fonctionnaient avant MySQL 4.1 échoueront en MySQL 4.1 si vous ne prenez pas en compte les collations et jeux de caractères. Par exemple, avant la version 4.1, cette commande fonctionnait comme :

mysql> SELECT SUBSTRING_INDEX(USER(),'@',1);
+-------------------------------+
| SUBSTRING_INDEX(USER(),'@',1) |
+-------------------------------+
| root                          |
+-------------------------------+

Après une mise à jour en MySQL 4.1, la commande échoue :

mysql> SELECT SUBSTRING_INDEX(USER(),'@',1);
ERROR 1267 (HY000): Illegal mix of collations
(utf8_general_ci,IMPLICIT) and (latin1_swedish_ci,COERCIBLE)
for operation 'substr_index'

La raison à cela est que les noms d'utilisateurs sont stockées en UTF8 (see Section 10.6, « UTF8 pour les meta-données »). Par conséquent, la fonction USER() et la chaîne littérale '@' ont des jeux de caractères différents et des collations différentes :

mysql> SELECT COLLATION(USER()), COLLATION('@');
+-------------------+-------------------+
| COLLATION(USER()) | COLLATION('@')    |
+-------------------+-------------------+
| utf8_general_ci   | latin1_swedish_ci |
+-------------------+-------------------+

Un moyen pour corriger cela est de dire à MySQL qu'il doit interpréter les chaînes littérales avec le jeu de caractères sutf8 :

mysql> SELECT SUBSTRING_INDEX(USER(),_utf8'@',1);
+------------------------------------+
| SUBSTRING_INDEX(USER(),_utf8'@',1) |
+------------------------------------+
| root                               |
+------------------------------------+

Un autre moyen est de changer le jeu de caractères et la collation de la connexion en utf8. Vous pouvez aussi utiliser la commande SET NAMES 'utf8' ou les variables système character_set_connection et collation_connection.

Supposons que la colonne X dans la table T a ces valeurs de colonne latin1 :

Muffler
Müller
MX Systems
MySQL

Et supposons que les valeurs de la colonne soient récupérées en utilisant la commande suivante :

SELECT X FROM T ORDER BY X COLLATE collation_name;

L'ordre résultant des valeurs pour différentes collations est montré dans cette table :

Cette table est un exemple qui montre quel effet cela aurait si l'on utilisait des collations différentes dans une clause ORDER BY. Le caractère qui pose problème dans cet exemple est le U avec deux points dessus. Les allemands l'appellent U-umlaut, mais nous l'appellerons U-tréma.

Trois collations différentes engendrent trois résultats différents. MySQL est là pour gérer cela. En utilisant la collation appropriée, vous pouvez choisir l'ordre de tri que vous voulez.

MySQL a de nombreux opérateurs et fonctions qui retournent une chaîne. Cette section répond à la question : quels sont le jeu de caractères et la collation d'une telle chaîne?

Pour des fonctions simples qui prennent une chaîne en entrée et renvoient une chaîne comme résultat en sortie, le jeu de caractères du résultat et sa collation sont les mêmes que deux de l'argument principal. Par exemple, UPPER(X) renvoie une chaîne dont la chaîne de caractères et la collation sont les mêmes que celles de X.

Le même concept s'applique à : INSTR(), LCASE(), LOWER(), LTRIM(), MID(), REPEAT(), REPLACE(), REVERSE(), RIGHT(), RPAD(), RTRIM(), SOUNDEX(), SUBSTRING(), TRIM(), UCASE(), UPPER(). Veuillez aussi noter que la fonction REPLACE(), contrairement à toutes les autres fonctions, ignore la collation de la chaîne d'entrée et effectue une comparaison insensible à la casse à chaque fois.

Pour des opérations qui combinent des entrées de chaînes multiples et renvoient une chaîne seule en sortie, les "règles d'agrégation" du standard SQL99 s'appliquent. Les règles sont :

Par exemple, avec CASE ... WHEN a THEN b WHEN b THEN c COLLATE X END, la collation résultante est X. L'exemple s'applique à : CONCAT(), GREATEST(), IF(), LEAST(), CASE, UNION, ||, ELT().

Pour des opérations qui convertissent vers des données caractères, le jeu de caractères de la chaîne résultante et sa collation sont dans le jeu de caractères de connexion et ont la collation de connexion.

Ceci s'applique à : CHAR(), CAST(), CONV(), FORMAT(). HEX(), SPACE().

CONVERT() fournit une méthode pour convertir des données entre différents jeux de caractères. La syntaxe est :

CONVERT(expr USING transcoding_name)

Avec MySQL, les nom de conversions sont les mêmes que les noms des jeux caractères correspondants.

Exemples :

SELECT CONVERT(_latin1'Müller' USING utf8);
INSERT INTO utf8table (utf8column)
   SELECT CONVERT(latin1field USING utf8) FROM latin1table;

CONVERT(... USING ...) est implémenté selon le standard SQL-99.

Vous pouvez aussi utiliser CAST() pour convertir une chaîne dans un jeu de caractères différent. Le nouveau format est :

CAST ( character_string AS character_data_type
    CHARACTER SET character_set_name )

Exemple :

SELECT CAST(_latin1'test' AS CHAR CHARACTER SET utf8);

Vous ne pouvez pas utiliser une clause COLLATE dans un CAST(), mais vous pouvez l'utiliser en dehors. Cela revient à dire que CAST(... COLLATE ...) est interdit mais CAST(...) COLLATE ... est autorisé.

Exemple :

SELECT CAST(_latin1'test' AS CHAR CHARACTER SET utf8) COLLATE utf8_bin;

Si vous utilisez CAST() sans préciser CHARACTER SET, alors le jeu de caractères et la collation résultants sont le jeu de caractères de la connexion et sa collation par défaut. Si vous utilisez CAST() avec CHARACTER SET X, alors le jeu de caractères résultant est X et la collation résultante est la collation par défaut de X.

Plusieurs commandes SHOW sont nouvelles ou modifiées en MySQL 4.1 pour fournir de nouvelles informations sur les jeux de caractères. SHOW CHARACTER SET, SHOW COLLATION et SHOW CREATE DATABASE sont nouveaux. SHOW CREATE TABLE et SHOW COLUMNS sont modifiés.

La commande SHOW CHARACTER SET affiche tous les jeux de caractères disponibles. Elle accepte la clause optionnelle LIKE qui indique quel noms de caractères rechercher. Par exemple :

mysql> SHOW CHARACTER SET LIKE 'latin%';
+---------+-----------------------------+-------------------+--------+
| Charset | Description                 | Default collation | Maxlen |
+---------+-----------------------------+-------------------+--------+
| latin1  | ISO 8859-1 West European    | latin1_swedish_ci |      1 |
| latin2  | ISO 8859-2 Central European | latin2_general_ci |      1 |
| latin5  | ISO 8859-9 Turkish          | latin5_turkish_ci |      1 |
| latin7  | ISO 8859-13 Baltic          | latin7_general_ci |      1 |
+---------+-----------------------------+-------------------+--------+

See Section 13.5.3.1, « Commande SHOW CHARACTER SET ».

Le résultat de SHOW COLLATION inclut tous les jeux de caractères disponibles. Elle accepte la clause optionnelle LIKE qui indique quels nom de collation rechercher. Par exemple :

mysql> SHOW COLLATION LIKE 'latin1%';
+-------------------+---------+----+---------+----------+---------+
| Collation         | Charset | Id | Default | Compiled | Sortlen |
+-------------------+---------+----+---------+----------+---------+
| latin1_german1_ci | latin1  |  5 |         |          |       0 |
| latin1_swedish_ci | latin1  |  8 | Yes     | Yes      |       0 |
| latin1_danish_ci  | latin1  | 15 |         |          |       0 |
| latin1_german2_ci | latin1  | 31 |         | Yes      |       2 |
| latin1_bin        | latin1  | 47 |         | Yes      |       0 |
| latin1_general_ci | latin1  | 48 |         |          |       0 |
| latin1_general_cs | latin1  | 49 |         |          |       0 |
| latin1_spanish_ci | latin1  | 94 |         |          |       0 |
+-------------------+---------+----+---------+----------+---------+

See Section 13.5.3.2, « Syntaxe de SHOW COLLATION ».

SHOW CREATE DATABASE affiche la commande CREATE DATABASE qui va créer la base de données. Le résultat inclut toutes les options de bases de données. DEFAULT CHARACTER SET et COLLATE sont supportés. Toutes les options sont stockées dans un fichier texte, appelée db.opt qui peut être trouvé dans le fichier de base de données.

mysql> SHOW CREATE DATABASE a\G
*************************** 1. row ***************************
       Database: a
Create Database: CREATE DATABASE `a`
                 /*!40100 DEFAULT CHARACTER SET macce */

See Section 13.5.3.4, « Syntaxe de SHOW CREATE DATABASE ».

SHOW CREATE TABLE est similaire, mais affiche la commande CREATE TABLE pour créer une table donnée. Les définitions de colonnes incluent maintenant toutes les spécifications de jeu de caractères, et les options de tables aussi.

See Section 13.5.3.5, « Syntaxe de SHOW CREATE TABLE ».

La commande SHOW COLUMNS affiche la collation des colonnes d'une table, lorsqu'elle est appelée avec SHOW FULL COLUMNS. Les colonnes de type CHAR, VARCHAR et TEXT ont des collations de type non-NULL. Les valeurs numériques et non-caractères on des collations NULL. Par exemple :

mysql> SHOW FULL COLUMNS FROM t;
+-------+---------+------------+------+-----+---------+-------+
| Field | Type    | Collation  | Null | Key | Default | Extra |
+-------+---------+------------+------+-----+---------+-------+
| a     | char(1) | latin1_bin | YES  |     | NULL    |       |
| b     | int(11) | NULL       | YES  |     | NULL    |       |
+-------+---------+------------+------+-----+---------+-------+

Le jeu de caractères ne fait pas partie de l'affichage. Le nom du jeu de caractère est lié à la collation.

See Section 13.5.3.3, « Syntaxe de SHOW COLUMNS ».

Normalement, votre serveur utilise le jeu de caractères par défaut latin1. Si vous avez stocké des données qui sont dans un autre jeu de caractères que ceux supportés par la version 4.1, vous pouvez convertir la colonne. Cependant, vous devriez éviter de convertir directement les colonnes de latin1 vers un "vrai" jeu de caractère. Cela peut conduire à des pertes de données. Au lieu de cela, convertissez la colonne en un type de colonne binaire, avec le jeu de caractères voulu. La conversion avec un format binaire conservera les données intactes. Par exemple, supposez que vous avez une table version 4.0, avec trois colonnes qui sont utilisées pour stocker des valeurs avec les jeux de caractères latin1, latin2 et utf8 :

CREATE TABLE t
(
    latin1_col CHAR(50),
    latin2_col CHAR(100),
    utf8_col CHAR(150)
);

Après mise à jour en MySQL version 4.1, vous pouvez convertir cette table pour qu'elle laisse intacte la colonne latin1_col mais modifie les colonnes latin2_col et utf8_col pour qu'elles utilisent les jeux de caractères latin2 et utf8. D'abord, sauvez votre table, puis convertissez les colonnes comme ceci :

ALTER TABLE t MODIFY latin2_col BINARY(100);
ALTER TABLE t MODIFY utf8_col BINARY(150);
ALTER TABLE t MODIFY latin2_col CHAR(100) CHARACTER SET latin2;
ALTER TABLE t MODIFY utf8_col CHAR(150) CHARACTER SET utf8;

La première commande ``supprime'' les informations de jeux de caractères des colonnes latin2_col et utf8_col. Les deux autres commandes assignent le bon jeu de caractère aux deux colonnes.

Si vous voulez, vous pouvez combiner les deux conversions en une seule commande :

ALTER TABLE t
    MODIFY latin2_col BINARY(100),
    MODIFY utf8_col BINARY(150);
ALTER TABLE t
    MODIFY latin2_col CHAR(100) CHARACTER SET latin2,
    MODIFY utf8_col CHAR(150) CHARACTER SET utf8;

Il y a deux jeux de caractères Unicode. Vous pouvez stocker des textes dans près de 650 langues en utilisant ces jeux de caractères. Nous n'avons pas encore ajouté un grand nombre de collations pour ces deux nouveaux jeux, mais cela se fera bientôt. Actuellement, ils ont des collations par défaut pour l'insensibilité à la casse et aux accents, plus une collation binaire.

Actuellement, la collation ucs2_general_uca ne supporte que partiellement l'algorithme de collations d'Unicode. Certains jeux de caractères ne sont pas supportés.

Les jeux de caractères de l'Europe de l'ouest recouvrent la plupart des langues d'Europe de l'ouest comme le fran¸ais, l'espagnol, le catalan, le basque, le portugais, l'italien, l'albanais, le néerlandais, l'allemand le danois, le suédois, le norvégien, le finlandais, le faroe, l'islandais, l'Irlandais, l'écossais, et l'anglais.

MySQL supporte les jeux de caractères utilisés en République Tchèque, en Slovakie, Hongrie, Roumanie, SLovénie, Croatie, et Pologne.

Les jeux de caractères baltes couvrent les langues estonienne, lette et lituanienne. Il y a actuellement deux jeux de caractères baltiques supportés :

Voici les jeux de caractères cyrilliques et les collations à utiliser avec les langues suivantes : biélorusse, bulgare, russe, ukrainien.

Les jeux de caractères asiatiques que nous supportons incluent le chinois, le japonais, le coréen et le thailandais. Ces jeux peuvent être compliqués. Par exemple, les jeux chinois doivent permettre des milliers de caractères différents.