La plupart des gestionnaires de bases de données proposent un type de données caractère dit "national" (NCHAR pour SQL Server / Oracle / MySQL, GRAPHIC pour DB2). Le générateur de tables Adélia utilise ce type de données pour les ALPHA avec l'option "Unicode". Néanmoins, selon l'implémentation de ce type de données, la sémantique n'est pas uniforme ni forcément liée aux caractères Unicode.
A part pour MySQL, lorsqu'une base de données stocke les données caractères dans une page de code multibyte, la longueur du type "CHAR" est toujours exprimée en octets, la longueur du type "NCHAR" pouvant selon le contexte être en octets ou en caractères.
Le tableau suivant récapitule les particularités des types caractères suivant les SGBD :
SGBD |
CHAR |
NCHAR |
SQL Server |
Les caractères sont stockés par défaut dans la page de code Ansi du système. |
Les caractères sont stockés avec un encodage Unicode (UTF-16). |
Oracle |
Les caractères sont stockés dans la page de code de la base de données. Une base Oracle Unicode utilise UTF-8 comme page de codes principale. |
Les caractères sont stockés dans la page de code nationale de la base de données. Une base Oracle Unicode utilise UTF-16 comme page de codes nationale. |
DB2 UDB (base non Unicode) |
Les caractères sont stockés dans la page de code de la base de données (single ou multi-byte). |
Le type NCHAR s'appelle "GRAPHIC". Les caractères sont stockés dans la page de code de la base de données (single ou multi-byte – idem CHAR), mais la longueur est exprimée en caractères et non en octets (en interne, chaque caractère est stocké sur deux octets). Le type de donnée "GRAPHIC" n'est disponible que si la base de données utilise une page de code MBCS. |
DB2 UDB (base Unicode) |
Les caractères sont stockés dans la page de code UTF-8. |
Les caractères sont stockés dans la page de code UTF-16. |
DB2/400 |
Les caractères sont stockés dans la page de code de la table (qui par défaut correspond à la page de code du système). |
Le type NCHAR s'appelle "GRAPHIC" et Adélia le génère avec l'encodage UCS-2. |
MySQL |
Les caractères sont stockés dans la page de code de la base de données. |
Avec MySQL 5, les données sont stockées en UTF-8, avant le type "NCHAR" était considéré comme un synonyme du type "CHAR". Adélia génère une colonne "char character set utf-8" pour assurer la compatibilité avec les deux versions. |
Access |
Les données caractères sont stockées en Unicode. |
Les données caractères sont stockées en Unicode. |
Problème de l'UTF-8 (et des pages de codes MBCS en général)
Les pages de code où les caractères sont encodés avec une longueur variable posent plusieurs problèmes, essentiellement avec DB2 et Oracle :
Sur DB2 UDB le type NCHAR (GRAPHIC) n'est pas forcément disponible. Il faut que la page de code de la base de données soit MBCS. De plus, pour être compatible Unicode, la base DB2 doit explicitement être déclarée Unicode (pages de code UTF-8 pour les CHAR, UTF-16 pour les GRAPHIC), ce qui peut poser problème si vous stockez des caractères non-ASCII dans un champ CHAR (voir ci-dessous).
Sur DB2 UDB et Oracle, la longueur des données de type "CHAR" est exprimée en octets et non en "nombre de caractères". Cela signifie qu'un CHAR(10) peut ne pas être capable de stocker 10 caractères si les caractères sont codés sur plus d'un octet. Cette limite est d'ailleurs aussi valable pour les NCHAR avec Oracle.
La sémantique des instructions manipulant des chaînes de caractères en général peut être affectée par l'encodage. Par exemple LENGTH renvoie par défaut la longueur en octets (DB2, Oracle).
La norme UTF-16 n'est pas de largeur fixe. Néanmoins dans le cas général, on peut assumer un encodage en UCS-2 (sous-ensemble de l'UTF-16 de largeur fixe deux octets), les caractères nécessitant un encodage sur plus de deux octets représentant des cas particuliers (perse ancien, par exemple). La plupart des langues communes, y compris asiatiques, sont représentables en UCS-2.
Conseils d'utilisation :
- Si vous souhaitez utiliser une base de données DB2 UDB ou Oracle purement Unicode (page de code UTF-8), il est recommandé de générer tous les champs pouvant contenir des caractères non-ASCII en Unicode.
- Pour DB2, nous recommandons l'utilisation de la version 9.5 qui permet d'obtenir une sémantique "caractère" pour les fonctions scalaires SQL (longueur, extraction, etc.). Les fonctions scalaires SQL ont une sémantique orientée "octets" sur les versions précédentes, ce qui peut donner des résultats erronés sur un champ UTF-8.
- Pour Oracle, bien que la recommandation pour une base Unicode soit UTF-8 pour la base / UTF-16 pour les caractères nationaux, nous recommandons plutôt d'utiliser une page de code single-byte (ISO8859-1 ou WE8MSWIN1252) pour la base de données et AL16UTF16 pour le jeu de caractères nationaux.