Chapitre 10. Jeux de caractères et Unicode
Précédent |  | Suivant

## Chapitre 10. Jeux de caractères et Unicode

L'amélioration du support des jeux de caractères est un des progrès de MySQL en version 4.1. Ce chapitre couvre :

- Ce que sont les jeux de caractères et les collations

- Le système par défaut à plusieurs niveaux

- Nouvelle syntaxe en MySQL 4.1

- Fonctions et opérations affectées

- Support d'Unicode

- La signification de chaque jeu de caractères et collation

Le support des jeux de caractères est inclus dans les tables `MySISAM`, `MEMORY` (`HEAP`), et depuis MySQL 4.1.2, `InnoDB`. Le moteur de table `ISAM` n'inclut pas le support des jeux de caractères, et il n'y a pas de plan pour le faire car `ISAM` est abandonnée.

## 10.1. Jeux de caractères et collation : généralités

Un jeu de caractères est un ensemble de symboles et de codes. Une collation est un ensemble de règles permettant la comparaisons de caractères dans un jeu. Pour rendre ces définitions plus concrètes, voici un exemple avec un alphabet imaginaire.

Supposons que nous avons un alphabet de 4 lettres : ‘`A`’, ‘`B`’, ‘`a`’, ‘`b`’. Nous assignons à chaque lettre un nombre comme ceci : ‘`A`’ = 0, ‘`B`’ = 1, ‘`a`’ = 2, ‘`c`’ = 3. La lettre ‘`A`’ est un symbole, le chiffre 0 est le code de ‘`A`’, et la combinaison des quatre lettres et de leur code forme le jeu de caractères.

Maintenant, supposons que nous voulions comparer deux chaînes de caractères : ‘`A`’ et ‘`B`’. Le plus simple pour cela est de regarder leurs codes : 0 pour ‘`A`’ et 1 pour ‘`B`’, et comme 0 est inférieure à 1, nous pouvons dire que ‘`A`’ est plus petit que ‘`B`’. Ce que nous venons de faire est une collation pour notre jeu de caractères. la collation est un ensemble de règle, qui se résume à ceci dans notre cas : ``compare les codes''. Cette règle est la plus simple collation binaire.

Si nous devons différentier les majuscules des minuscules, nous aurons au moins deux règles : (1) traiter les minuscules ‘`a`’ et ‘`b`’ comme des équivalents de ‘`A`’ et ‘`B`’; (2) puis comparer leurs codes respectifs. Nous appelons cette règle une collation sensible à la casse. C'est un peu plus complexe que la règle précédente.

En réalité, la plupart des jeux de caractères ont de nombreux caractères : ce n'est pas simplement ‘`A`’ et ‘`B`’ mais des alphabets entiers, ou des systèmes d'écriture orientaux avec des milliers de caractères, incluant des caractères spéciaux et la ponctuation. Dans la vraie vie, une collation a de très nombreuses règles, concernant la sensibilité à la casse ou encore l'insensibilité aux accents (un accent est une marque attachée aux lettres comme le ‘`Ö`’) allemand) et les caractères multiples comme le e dans l'o ‘`œ`’ = ‘`oe`’ de l'une des deux collations allemandes.

MySQL 4.1 peut faire cela pour vous :

- Stocker des chaînes dans différents jeux de caractères

- Comparer des chaînes à l'aide de différentes collations

- Mélanger différents jeux de caractères et collations sur le même serveur, la même base ou même la même table.

- Permettre la spécification du jeu de caractère et de la collation à n'importe quel niveau

Sous cet angle, MySQL 4.1 est bien plus souple que MySQL 4.0 et que les autres bases de données. Mais, pour pouvoir utiliser ces nouvelles fonctionnalités, vous devez savoir quels sont les jeux de caractères et les collations disponibles, comment les modifier ou comment les utiliser avec les opérateurs.

## 10.2. Jeux de caractères et collation dans MySQL

Un jeu de caractères a toujours au moins une collation. Pour lister les jeux de caractères disponibles, utilisez la commande `SHOW CHARACTER SET` :

    mysql> SHOW CHARACTER SET;
    +----------+-----------------------------+---------------------+
    | Charset  | Description                 | Default collation   |
    +----------+-----------------------------+---------------------+
    | big5     | Big5 Traditional Chinese    | big5_chinese_ci     |
    | dec8     | DEC West European           | dec8_swedish_ci     |
    | cp850    | DOS West European           | cp850_general_ci    |
    | hp8      | HP West European            | hp8_english_ci      |
    | koi8r    | KOI8-R Relcom Russian       | koi8r_general_ci    |
    | latin1   | ISO 8859-1 West European    | latin1_swedish_ci   |
    | latin2   | ISO 8859-2 Central European | latin2_general_ci   |
    ...

Le résultat inclut en réalité une autre colonne, qui n'est pas présentée dans cette page, à des fins de publication.

Tout jeu de caractères a toujours au moins une collation. Il peut en avoir plusieurs.

Pour lister les collations d'un jeu de caractères, utilisez la commande `SHOW COLLATION`. Par exemple, pour afficher les collations du jeu de caractères `latin1` (``ISO-8859-1 West European''), utilisez cette commande, et recherchez les noms de collation qui commencent par `latin1` :

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

Les collations `latin1` ont les significations suivantes :

Collation | Signification
`latin1_bin` | Binaire, suivant l'encodage `latin1`
`latin1_danish_ci` | Danois/Norvégien
`latin1_general_ci` | Multilingue
`latin1_general_cs` | Multilingue, sensible à la casse
`latin1_german1_ci` | Allemand DIN-1
`latin1_german2_ci` | Allemand DIN-2
`latin1_spanish_ci` | Espagnol moderne
`latin1_swedish_ci` | Suédois/Finlandais

Les collations ont les caractéristiques suivantes :

- Deux jeux de caractères différents ne peuvent pas avoir la même collation.

- Chaque jeu de caractère a une collation qui est la collation par défaut. Par exemple, la collation par défaut de `latin1` est `latin1_swedish_ci`.

- Il y a une convention pour les noms de collation : elles commencent par le nom du jeu de caractères auquel elles sont associées; elles incluent généralement un nom de langue, et finissent par `_ci` (`case insensitive`, insensible à la casse), `_cs` (`case sensitive`, sensible à la casse), `_bin` (binaire), ou `_uca` (Algorithme Unicode, Unicode Collation Algorithm).

## 10.3. Déterminer le jeu de caractères et la collation par défaut

Il y a une configuration par défaut pour chaque jeu de caractères et collation à quatre niveaux : serveur, base de données, table, connexion. La description suivante peut paraître complexe, mais il a été montré qu'en pratique la mise par défaut par niveaux multiples mène à des résultats simples et évidents.

### 10.3.1. Jeu de caractères et collation serveur

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 :

- En fonction de l'option de configuration active quand le serveur démarre.

- En fonction des valeurs de configuration à l'exécution.

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.

### 10.3.2. Jeu de caractères et collation de base de données

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 :

- Si les deux clauses `CHARACTER SET X` et `COLLATE Y` ont été spécifiées, alors leurs valeurs sont utilisées.

- Si `CHARACTER SET X` a été spécifiée sans `COLLATE`, alors le jeu de caractères est `X` et sa collation par défaut.

- Sinon, le jeu de caractères et la collation par défaut du serveur sont utilisés.

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é.

### 10.3.3. Jeu de caractères de tables et collation

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 :

- Si `CHARACTER SET X` et `COLLATE Y` sont précisés tous les deux, alors on adopte le jeu de caractères `X` et la collation `Y`.

- Si `CHARACTER SET X` était précisé sans `COLLATE`, alors on adopte le jeu de caractères `X` et sa collation par défaut.

- Sinon, le jeu de caractères et la collation de la base de données sont utilisés.

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.

### 10.3.4. Jeu de caractères de colonne et collation

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 :

- Si `CHARACTER SET X` et `COLLATE Y` sont spécifiés, alors le jeu de caractères est `X` et la collation `Y`.

- Si `CHARACTER SET X` a été spécifié sans la clause `COLLATE`, alors le jeu de caractères est `X` et la collation est sa collation par défaut.

- Sinon, MySQL utilise le jeu de caractères et la collation par défaut.

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

### 10.3.5. Exemples d'attribution de jeu de caractères et collation

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`.

### 10.3.6. Jeux de caractères et collations de connexion

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 :

- Le jeu de caractères et la collation sont disponibles dans les variables `character_set_server` et `collation_server`.

- Le jeu de caractères et la collation par défaut de la base de données sont disponibles dans `character_set_database` et `collation_database`.

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 :

- Dans quel jeu de caractères est la requête lorsqu'elle quitte le client?

  Le serveur utilise la variable `character_set_client` pour connaître le jeu de caractères des requêtes émises par le client.

- dans quel jeu de caractère le serveur devrait il traduire la requête après l'avoir re¸ue?

  Pour cela, `character_set_connection` et `collation_connection` sont utilisées par le serveur. Il convertit les requêtes envoyées par le client de `character_set_client` en `character_set_connection` (hormis les chaînes littérales qui sont précédées de `_latin1` ou `_utf8`). `collation_connection` est importante pour les comparaisons de chaînes littérales. Pour les comparaisons de chaînes avec des colonnes, la collation de la colonne a la priorité.

- Dans quel jeu de caractères le serveur devrait-il traduire les résultats ou messages d'erreur avant de les renvoyer au client?

  La variable `character_set_results` indique le jeu de caractères que le serveur utilise pour retourner les résultats aux clients. Cela inclut les données telles que les noms de colonnes ou les meta-données.

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;

### 10.3.7. Jeu de caractères et collation des chaînes littérales

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 :

- Si, à la fois `_X` et `COLLATE Y` ont été précisés, alors le jeu de caractères est `X` et la collation littérale est `Y`.

- Si `_X` est précisé mais que `COLLATE` ne l'est pas, alors le jeu de caractères de la chaîne littérale est `X` et la collation est la collation par défaut du jeu de caractères `X`.

- Sinon, on utilise le jeu de caractères et la collation par défaut de la connexion.

Exemples:

- Une chaîne avec le jeu de caractères `latin1` et la collation `latin1_german1_ci` :

      SELECT _latin1'Müller' COLLATE latin1_german1_ci;

- Une chaîne avec le jeu de caractères `latin1` et sa collation par défaut, c'est à dire `latin1_swedish_ci`:

      SELECT _latin1'Müller';

- Une chaîne avec le jeu de caractère et la collation connexion/littérale :

      SELECT 'Müller';

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

### 10.3.8. Clause `COLLATE` dans différentes parties d'une requête 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 :

- Avec `ORDER BY` :

      SELECT k
      FROM t1
      ORDER BY k COLLATE latin1_german2_ci;

- Avec `AS` :

      SELECT k COLLATE latin1_german2_ci AS k1
      FROM t1
      ORDER BY k1;

- Avec `GROUP BY` :

      SELECT k
      FROM t1
      GROUP BY k COLLATE latin1_german2_ci;

- Avec les fonctions d'agrégation :

      SELECT MAX(k COLLATE latin1_german2_ci)
      FROM t1;

- Avec `DISTINCT` :

      SELECT DISTINCT k COLLATE latin1_german2_ci
      FROM t1;

- Avec `WHERE` :

      SELECT *
      FROM t1
      WHERE _latin1 'Müller' COLLATE latin1_german2_ci = k;

- Avec `HAVING` :

      SELECT k
      FROM t1
      GROUP BY k
      HAVING k = _latin1 'Müller' COLLATE latin1_german2_ci;

### 10.3.9. `COLLATE` clause de précédence

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

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

### 10.3.10. Opérateur `BINARY`

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.

### 10.3.11. Quelques cas spéciaux où la détermination de la collation est difficile

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 :

- Une clause explicite `COLLATE` a pour priorité 4.

- Une concaténation de deux chaînes avec des collations différentes à pour priorité 3.

- La collation d'une colonne a priorité 2.

- La collation d'une chaîne littérale a pour priorité 1.

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

- Utiliser la collation qui a la précédence la plus élevée.

- Si les deux opérandes ont une collation de même priorité, alors il y a erreur si les collations ne sont pas les mêmes.

Exemples :

`column1 = 'A'` | Utilise la collation de la colonne `column1`
`column1 = 'A' COLLATE x` | Utilise la collation de `'A'`
`column1 COLLATE x = 'A' COLLATE y` | Erreur

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 ».

### 10.3.12. Les collation doivent correspondre au bon jeu de caractères

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 s`utf8` :

    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`.

### 10.3.13. Un exemple de l'effet de collation

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 :

`latin1_swedish_ci` | `latin1_german1_ci` | `latin1_german2_ci`
Muffler | Muffler | Müller
MX Systems | Müller | Muffler
Müller | MX Systems | MX Systems
MySQL | MySQL | MySQL

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.

- La première colonne montre le résultat de `SELECT` en utilisant la collation Suédoise/Finlandaise, qui dit que le u-tréma est trié comme le Y

- La seconde colonne montre le résultat de `SELECT` en utilisant la règle German DIN-1, qui dit que le U-tréma est trié comme le U.

- La troisième colonne montre le résultat de `SELECT` en utilisant la règle German DIN-2 qui dit que le u-tréma est trié comme le UE.

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.

## 10.4. Opérations affectées par le support de jeux de caractères.

Cette section décrit des opérations qui prennent maintenant en compte des informations sur le jeu de caractères.

### 10.4.1. Chaînes résultats

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 :

- Si `COLLATE X` est explicitement donné, alors on utilise `X`.

- Si `COLLATE X` et `COLLATE Y` sont explicitement donnés, alors erreur.

- Sinon, si toutes les collations sont la même collation `X`, alors utilise `X`.

- Sinon, le résultat n'a pas de collation.

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()`.

### 10.4.2. `CONVERT()`

`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.

### 10.4.3. `CAST()`

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`.

### 10.4.4. Commande `SHOW`

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` ».

## 10.5. Support de Unicode

Depuis la version 4.1 de MySQL, il y deux nouveaux jeux de caractères pour stocker des données Unicode :

- `ucs2`, le jeu de caractères Unicode UCS-2.

- `utf8`, l'encodage UTF-8 du jeu de caractères Unicode.

En UCS-2 (`binary Unicode representation`) chaque caractère est représenté par un code Unicode de deux octets avec l'octet le plus significatif en premier. Par exemple : "LATIN CAPITAL LETTER A" a le code 0x0041 et est stocké comme une séquence à deux octets `0x00 0x41`. "CYRILLIC SMALL LETTER YERU" (Unicode 0x044B) est stocké comme une séquence à deux octets `0x04 0x4B`. Pour les caractères Unicode et leurs codes veuillez consulter Unicode Home Page.

Restriction temporaire : UCS-2 ne peut pas (encore) être utilisé comme jeu de caractères client. Cela signifie que `SET NAMES ucs2` ne fonctionnera pas.

Le jeu de caractères UTF8 (`transform Unicode representation`) est une alternative pour stocker les données Unicode. il est implémenté selon la RFC 2279. L'idée du jeu de caractères UTF-8 est que différents caractères Unicode soient représentés par des séquences de différentes longueurs.

- les lettres, chiffres et caractères de ponctuation latins de base utilisent un octet.

- La plupart des lettres européennes et moyen-orientales sont stockées avec une séquence à deux octets : les lettres latines étendues (avec les tildes, macrons, accents graves, aigus et autres accents), cyrilliques, grecques, arméniennes, hébreues, arabes, syriaques et autres.

- Les idéographes coréens, chinois et japonais utilisent des séquences à trois octets.

Actuellement, MySQL UTF8 ne supporte pas les séquences à 4 octets.

Conseil : pour économiser de l'espace avec UTF-8, utilisez `VARCHAR` au lieu de `CHAR`. Sinon, MySQL doit réserver 30 octets pour une colonne `CHAR(10) CHARACTER SET utf8` parce que c'est la longueur maximale à accepter.

## 10.6. UTF8 pour les meta-données

Les meta-données sont les données sur les données. Tout ce qui décrit la base de données, par opposition au contenu de la base de données, sont des meta-données. Ainsi, les noms de colonnes, les noms de bases de données, les noms d'utilisateur, les noms de version et la plupart des résultats chaînes de `SHOW`, sont des meta-données.

La représentation des meta-données doit satisfaire les contraintes suivantes :

- Toutes les meta-données doivent être dans le même jeu de caractères. Sinon `SHOW` ne fonctionnerait pas correctement, car des lignes différentes de la même colonne seraient dans des jeux de caractères différents.

- Les meta-données doivent inclure tous les caractères de toutes les langues. Sinon, les utilisateurs ne pourraient pas nommer les colonnes et les tables dans leur langue.

Pour atteindre ces deux objectifs, MySQL enregistre les meta-données dans un jeu de caractères Unicode, nommé UTF8. Cela ne causera pas de perturbation si vous n'utilisez jamais de caractères accentués; mais si vous les utilisez, sachez que les meta-données sont en UTF8.

Cela signifie que les fonctions `USER()` et ses synonymes, `SESSION_USER()` et `SYSTEM_USER()`), `CURRENT_USER()`, et `VERSION()` auront le jeu de caractères UTF8 par défaut.

Le serveur assigne la variable système `character_set_system` avec le jeu de caractères des méta-données :

    mysql> SHOW VARIABLES LIKE 'character_set_system';
    +----------------------+-------+
    | Variable_name        | Value |
    +----------------------+-------+
    | character_set_system | utf8  |
    +----------------------+-------+

Le stockage des méta-données utilisant Unicode ne signifie pas que les entêtes et les résultats de la fonction `DESCRIBE` seront dans le jeu de caractères `character_set_system`. Lorsque vous envoyez la commande `SELECT column1 FROM t`, le nom de la colonne `column1` sera retourné par le serveur vers le client dans le jeu de caractères déterminer par la commande `SET NAMES`. Plus spécifiquement, le jeu de caractères est déterminé par la valeur de la variable système `character_set_results`. Si cette variable vaut `NULL`, aucune conversion n'est effectuée, et le serveur retourne les données dans leur jeu de caractères original (tel qu'indiqué par `character_set_system`).

Si vous voulez que le serveur affiche les résultats des meta-données dans un jeu de caractères autre que UTF8, alors utilisez `SET CHARACTER SET` pour forcer le serveur faire la conversion (see Section 10.3.6, « Jeux de caractères et collations de connexion »), ou configurez le client pour qu'il fasse la conversion. Il est toujours plus efficace de configurer le client pour qu'il fasse la conversion, mais ce choix ne sera pas toujours possible pour de nombreux clients jusqu'à tard dans le cycle des produits MySQL 4.x.

Si vous utilisez seulement, par exemple, la fonction `USER()` pour une comparaison ou une assignation dans une seule commande... ne vous inquiétez pas. MySQL fera des conversions automatiques pour vous.

    SELECT * FROM Table1 WHERE USER() = latin1_column;

Ceci fonctionnera, car le contenu de `latin1_column` est automatiquement converti en UTF8 avant la comparaison.

    INSERT INTO Table1 (latin1_column) SELECT USER();

Ceci fonctionnera car le contenu de `USER()` est automatiquement converti en `latin1` avant l'assignation. La conversion automatique n'est pas encore complètement implémentée, mais devrait fonctionner correctement dans une version ultérieure.

Bien que la conversion automatique ne soit pas un standard SQL, le document de standard SQL dit que chaque jeu de caractères est (en termes de caractères supportés) un "sous-jeu" de l'Unicode.

Comme c'est un principe bien connu que "ce qui s'applique à un super-jeu peut s'appliquer à un sous-jeu", nous croyons que la collation d'Unicode peut s'appliquer à des comparaisons avec des chaînes non-Unicode.

## 10.7. Compatibilité avec d'autres bases de données

Pour la compatibilité avec SAP DB, les deux commandes suivantes sont identiques :

    CREATE TABLE t1 (f1 CHAR(n) UNICODE);
    CREATE TABLE t1 (f1 CHAR(n) CHARACTER SET ucs2);

## 10.8. Nouveau format de fichier de configuration de jeux de caractères

En MySQL version 4.1, la configuration du jeu de caractères est stockée dans des fichiers XML : un fichier par jeu de caractères. Dans les versions précédentes, cette information était stockée dans les fichiers `.conf`.

## 10.9. Jeux de caractères national

En MySQL version 4.x et plus ancien, `NCHAR` et `CHAR` étaient synonymes. ANSI définit `NCHAR` ou `NATIONAL CHAR` comme une manière de définir le jeu de caractère par défaut d'une colonne de type `CHAR`. MySQL utilise `utf8` comme jeu de caractère prédéfini. Par exemple, les définitions de ces colonnes sont identiques :

    CHAR(10) CHARACTER SET utf8
    NATIONAL CHARACTER(10)
    NCHAR(10)

de même que :

    VARCHAR(10) CHARACTER SET utf8
    NATIONAL VARCHAR(10)
    NCHAR VARCHAR(10)
    NATIONAL CHARACTER VARYING(10)
    NATIONAL CHAR VARYING(10)

Vous pouvez utiliser `N'literal'` pour indiquer qu'une chaîne utilise le jeu de caractère national.

Ces deux commandes sont équivalentes :

    SELECT N'some text';
    SELECT _utf8'some text';

## 10.10. Préparer le passage de version 4.0 en 4.1

Que faut-il faire pour mettre à jour MySQL au niveau des jeux de caractères? MySQL 4.1 est presque totalement compatible avec les versions 4.0 et plus ancien, pour la simple raison que toutes les fonctionnalités sont nouvelles, et ne peuvent entrer en conflit avec une version plus ancienne. Cependant, il y a quelques différences qu'il faut avoir en tête.

Le plus important : Le ``jeu de caractères de MySQL 4.0'' a les caractéristiques des ``jeux de caractères de MySQL 4.1'' et des ``collations MySQL 4.1.'' Vous devez désapprendre cela. Par conséquent, nous n'allons pas rassembler les jeux de caractères et les collations dans le même objet agglomérant.

Il n'y a pas de traitement spéciaux pour les jeux de caractères nationaux de MySQL 4.1. `NCHAR` n'est pas le même que `CHAR`, et les littéraux `N'...'` sont différents des littéraux `'...'`.

Finalement, il y a un format de fichier différent pour stocker les informations sur les jeux de caractères et les collations. Assurez-vous d'avoir installé le dossier `/share/mysql/charsets/` qui contient les nouveaux fichiers de configuration.

Si vous voulez lancer `mysqld` dans une installation 4.1.x avec les données de MySQL 4.0, lancez le serveur avec le même jeu de caractères et collation que lancier serveur. Dans ce cas, vous n'aurez pas besoin de réindexer vos données.

Voici deux moyens de le faire :

    shell> ./configure --with-character-set=... --with-collation=...
    shell> ./mysqld --default-character-set=... --default-collation=...

Si vous utilisez `mysql` avec, par exemple, le jeux de caractères MySQL 4.0 `danois`, vous devez utiliser maintenant le jeu de caractères `latin1` avec la collation `latin1_danish_ci` :

    shell> ./configure --with-character-set=latin1
               --with-collation=latin1_danish_ci
    shell> ./mysqld --default-character-set=latin1
               --default-collation=latin1_danish_ci

Utilisez la table de la section Section 10.10.1, « Jeux de caractères 4.0 et binômes de jeux de caractères/collations 4.1 correspondants » pour retrouver les anciens jeux de caractères 4.0 et leur équivalent 4.1 en jeu de caractère et collation.

Si vous avez des données non-`latin1` qui sont stockées dans une table 4.0 `latin1` et que vous voulez convertir la table pour que les définitions reflètent le véritable jeu de caractères, utilisez les instructions de la section Section 10.10.2, « Conversion de colonnes version 4.0 en version 4.1 ».

### 10.10.1. Jeux de caractères 4.0 et binômes de jeux de caractères/collations 4.1 correspondants

ID | Jeu de caractères 4.0 | Jeu de caractères 4.1 | Collation 4.1
1 | `big5` | `big5` | `big5_chinese_ci`
2 | `czech` | `latin2` | `latin2_czech_ci`
3 | `dec8` | `dec8` | `dec8_swedish_ci`
4 | `dos` | `cp850` | `cp850_general_ci`
5 | `german1` | `latin1` | `latin1_german1_ci`
6 | `hp8` | `hp8` | `hp8_english_ci`
7 | `koi8_ru` | `koi8r` | `koi8r_general_ci`
8 | `latin1` | `latin1` | `latin1_swedish_ci`
9 | `latin2` | `latin2` | `latin2_general_ci`
10 | `swe7` | `swe7` | `swe7_swedish_ci`
11 | `usa7` | `ascii` | `ascii_general_ci`
12 | `ujis` | `ujis` | `ujis_japanese_ci`
13 | `sjis` | `sjis` | `sjis_japanese_ci`
14 | `cp1251` | `cp1251` | `cp1251_bulgarian_ci`
15 | `danish` | `latin1` | `latin1_danish_ci`
16 | `hebrew` | `hebrew` | `hebrew_general_ci`
17 | `win1251` | `(removed)` | `(removed)`
18 | `tis620` | `tis620` | `tis620_thai_ci`
19 | `euc_kr` | `euckr` | `euckr_korean_ci`
20 | `estonia` | `latin7` | `latin7_estonian_ci`
21 | `hungarian` | `latin2` | `latin2_hungarian_ci`
22 | `koi8_ukr` | `koi8u` | `koi8u_ukrainian_ci`
23 | `win1251ukr` | `cp1251` | `cp1251_ukrainian_ci`
24 | `gb2312` | `gb2312` | `gb2312_chinese_ci`
25 | `greek` | `greek` | `greek_general_ci`
26 | `win1250` | `cp1250` | `cp1250_general_ci`
27 | `croat` | `latin2` | `latin2_croatian_ci`
28 | `gbk` | `gbk` | `gbk_chinese_ci`
29 | `cp1257` | `cp1257` | `cp1257_lithuanian_ci`
30 | `latin5` | `latin5` | `latin5_turkish_ci`
31 | `latin1_de` | `latin1` | `latin1_german2_ci`

### 10.10.2. Conversion de colonnes version 4.0 en version 4.1

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;

## 10.11. Les jeux de caractères et collation supportés par MySQL.

Voici une liste annotée de jeux de caractères et de collations que MySQL supporte. Puisque les options et configurations d'installation diffèrent, certains sites n'auront pas tous ces éléments dans leur liste, et certains sites auront des éléments qui ne sont pas sur la liste car la définition de nouveaux jeux de caractères ou collations est directe.

MySQL supporte plus de 70 collations pour plus de 30 jeux de caractères.

    mysql> SHOW CHARACTER SET;
    +----------+-----------------------------+---------------------+--------+
    | Charset  | Description                 | Default collation   | Maxlen |
    +----------+-----------------------------+---------------------+--------+
    | big5     | Big5 Traditional Chinese    | big5_chinese_ci     |      2 |
    | dec8     | DEC West European           | dec8_swedish_ci     |      1 |
    | cp850    | DOS West European           | cp850_general_ci    |      1 |
    | hp8      | HP West European            | hp8_english_ci      |      1 |
    | koi8r    | KOI8-R Relcom Russian       | koi8r_general_ci    |      1 |
    | latin1   | ISO 8859-1 West European    | latin1_swedish_ci   |      1 |
    | latin2   | ISO 8859-2 Central European | latin2_general_ci   |      1 |
    | swe7     | 7bit Swedish                | swe7_swedish_ci     |      1 |
    | ascii    | US ASCII                    | ascii_general_ci    |      1 |
    | ujis     | EUC-JP Japanese             | ujis_japanese_ci    |      3 |
    | sjis     | Shift-JIS Japanese          | sjis_japanese_ci    |      2 |
    | cp1251   | Windows Cyrillic            | cp1251_bulgarian_ci |      1 |
    | hebrew   | ISO 8859-8 Hebrew           | hebrew_general_ci   |      1 |
    | tis620   | TIS620 Thai                 | tis620_thai_ci      |      1 |
    | euckr    | EUC-KR Korean               | euckr_korean_ci     |      2 |
    | koi8u    | KOI8-U Ukrainian            | koi8u_general_ci    |      1 |
    | gb2312   | GB2312 Simplified Chinese   | gb2312_chinese_ci   |      2 |
    | greek    | ISO 8859-7 Greek            | greek_general_ci    |      1 |
    | cp1250   | Windows Central European    | cp1250_general_ci   |      1 |
    | gbk      | GBK Simplified Chinese      | gbk_chinese_ci      |      2 |
    | latin5   | ISO 8859-9 Turkish          | latin5_turkish_ci   |      1 |
    | armscii8 | ARMSCII-8 Armenian          | armscii8_general_ci |      1 |
    | utf8     | UTF-8 Unicode               | utf8_general_ci     |      3 |
    | ucs2     | UCS-2 Unicode               | ucs2_general_ci     |      2 |
    | cp866    | DOS Russian                 | cp866_general_ci    |      1 |
    | keybcs2  | DOS Kamenicky Czech-Slovak  | keybcs2_general_ci  |      1 |
    | macce    | Mac Central European        | macce_general_ci    |      1 |
    | macroman | Mac West European           | macroman_general_ci |      1 |
    | cp852    | DOS Central European        | cp852_general_ci    |      1 |
    | latin7   | ISO 8859-13 Baltic          | latin7_general_ci   |      1 |
    | cp1256   | Windows Arabic              | cp1256_general_ci   |      1 |
    | cp1257   | Windows Baltic              | cp1257_general_ci   |      1 |
    | binary   | Binary pseudo charset       | binary              |      1 |
    +----------+-----------------------------+---------------------+--------+
    33 rows in set (0.01 sec)

Note : Tous les jeux de caractères sont une collation binaire. Nous n'avons pas inclus cette collation dans les descriptions qui suivent.

### 10.11.1. Les jeux de caractère Unicode

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.

- Collations `ucs2` (UCS-2 Unicode) :

  - `ucs2_bin`

  - `ucs2_general_ci` (par défaut)

  - `ucs2_general_uca`

- Collations `utf8` (UTF-8 Unicode) :

  - `utf8_bin`

  - `utf8_general_ci` (par défaut)

### 10.11.2. Les jeux de caractères d'Europe de l'Ouest.

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.

- Collations `ascii` (US ASCII) :

  - `ascii_bin`

  - `ascii_general_ci` (par défaut)

- Collations `cp850` (DOS West European) :

  - `cp850_bin`

  - `cp850_general_ci` (par défaut)

- Collations `dec8` (DEC West European) :

  - `dec8_bin`

  - `dec8_swedish_ci` (par défaut)

- Collations `hp8` (HP West European) :

  - `hp8_bin`

  - `hp8_english_ci` (par défaut)

- Collations `latin1` (ISO 8859-1 West European) :

  - `latin1_bin`

  - `latin1_danish_ci`

  - `latin1_general_ci`

  - `latin1_general_cs`

  - `latin1_german1_ci`

  - `latin1_german2_ci`

  - `latin1_spanish_ci`

  - `latin1_swedish_ci` (par défaut)

  Le jeu de caractères `latin1` est le jeu de caractères par défaut. La collation `latin1_swedish_ci` est la collation par défaut qui est probablement utilisée par la majorité des clients de MySQL. Il est souvent dit que ceci est basé sur les règles de collation suédoises/finlandaises mais vous trouverez des suèdois et des finlandais qui ne sont pas d'accord avec cette affirmation.

  Les collations `latin1_german1_ci` et `latin1_german2_ci` sont basées sur les standards DIN-1 and DIN-2, où DIN signifie `Deutsches Institut für Normung` (c'est la contrepartie allemande de ANSI). DIN-1 est appelée la collation dictionnaire et DIN-2 est appelée la collation annuaire.

  - règles `latin1_german1_ci` (dictionnaire) :

    ‘`Ä`’ = ‘`A`’, ‘`Ö`’ = ‘`O`’, ‘`Ü`’ = ‘`U`’, ‘`ß`’ = ‘`s`’

  - règles `latin1_german2_ci` (annuaire) :

    ‘`Ä`’ = ‘`AE`’, ‘`Ö`’ = ‘`OE`’, ‘`Ü`’ = ‘`UE`’, ‘`ß`’ = ‘`ss`’

  Dans la collation `latin1_spanish_ci`, ‘`Ñ`’ (N-tilde) est une lettre séparée entre ‘`N`’ et ‘`O`’.

- Collations `macroman` (Mac West European) :

  - `macroman_bin`

  - `macroman_general_ci` (par défaut)

- Collations `swe7` (7 bits Swedish) :

  - `swe7_bin`

  - `swe7_swedish_ci` (par défaut)

### 10.11.3. Les jeux de caractères d'Europe Centrale

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

- collations `cp1250` (Windows Central European) :

  - `cp1250_bin`

  - `cp1250_czech_ci`

  - `cp1250_general_ci` (par défaut)

- collations `cp852` (DOS Central European) :

  - `cp852_bin`

  - `cp852_general_ci` (par défaut)

- collations `keybcs2` (DOS Kamenicky Czech-Slovak) :

  - `keybcs2_bin`

  - `keybcs2_general_ci` (par défaut)

- collations `latin2` (ISO 8859-2 Central European) :

  - `latin2_bin`

  - `latin2_croatian_ci`

  - `latin2_czech_ci`

  - `latin2_general_ci` (par défaut)

  - `latin2_hungarian_ci`

- collations `macce` (Mac Central European) :

  - `macce_bin`

  - `macce_general_ci` (par défaut)

### 10.11.4. Jeu de caractères pour l'Europe du Sud et le Moyen-Orient

- Collations `armscii8` (ARMSCII-8 Armenian) :

  - `armscii8_bin`

  - `armscii8_general_ci` (par défaut)

- Collations `cp1256` (Windows Arabic) :

  - `cp1256_bin`

  - `cp1256_general_ci` (par défaut)

- Collations `geostd8` (GEOSTD8 Georgian) :

  - `geostd8_bin`

  - `geostd8_general_ci` (par défaut)

- Collations `greek` (ISO 8859-7 Greek) :

  - `greek_bin`

  - `greek_general_ci` (par défaut)

- Collations `hebrew` (ISO 8859-8 Hebrew) :

  - `hebrew_bin`

  - `hebrew_general_ci` (par défaut)

- Collations `latin5` (ISO 8859-9 Turkish) :

  - `latin5_bin`

  - `latin5_turkish_ci` (par défaut)

### 10.11.5. Les jeux de caractères baltes

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 :

- Collations `cp1257` (Windows Baltic) :

  - `cp1257_bin`

  - `cp1257_general_ci` (par défaut)

  - `cp1257_lithuanian_ci`

- Collations `latin7` (ISO 8859-13 Baltic) :

  - `latin7_bin`

  - `latin7_estonian_cs`

  - `latin7_general_ci` (par défaut)

  - `latin7_general_cs`

### 10.11.6. Les jeux de caractère cyrilliques

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

- Collations `cp1251` (Windows Cyrillic) :

  - `cp1251_bin`

  - `cp1251_bulgarian_ci`

  - `cp1251_general_ci` (par défaut)

  - `cp1251_general_cs`

  - `cp1251_ukrainian_ci`

- Collations `cp866` (DOS Russian) :

  - `cp866_bin`

  - `cp866_general_ci` (par défaut)

- Collations `koi8r` (KOI8-R Relcom Russian) :

  - `koi8r_bin`

  - `koi8r_general_ci` (par défaut)

- Collations `koi8u` (KOI8-U Ukrainian) :

  - `koi8u_bin`

  - `koi8u_general_ci` (par défaut)

### 10.11.7. Les jeux de caractères asiatiques

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.

- Collations `big5` (Big5 Traditional Chinese) :

  - `big5_bin`

  - `big5_chinese_ci` (par défaut)

- Collations `euckr` (EUC-KR Korean) :

  - `euckr_bin`

  - `euckr_korean_ci` (par défaut)

- Collations `gb2312` (GB2312 Simplified Chinese) :

  - `gb2312_bin`

  - `gb2312_chinese_ci` (par défaut)

- Collations `gbk` (GBK Simplified Chinese) :

  - `gbk_bin`

  - `gbk_chinese_ci` (par défaut)

- Collations `sjis` (Shift-JIS Japanese) :

  - `sjis_bin`

  - `sjis_japanese_ci` (par défaut)

- Collations `tis620` (TIS620 Thai) :

  - `tis620_bin`

  - `tis620_thai_ci` (par défaut)

- Collations `ujis` (EUC-JP Japanese) :

  - `ujis_bin`

  - `ujis_japanese_ci` (par défaut)

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

Précédent |  | Suivant
Chapitre 9. Structure du langage | Sommaire | Chapitre 11. Types de colonnes