Documentation PostgreSQL 8.0.25 | ||||
---|---|---|---|---|
Précédent | Arrière rapide | Chapitre 20. Localisation | Avance rapide | Suivant |
Le support des jeux de caractères dans PostgreSQL vous permet de rentrer du texte dans plusieurs jeux de caractères, dont des jeux de caractères à un octet tels que la série ISO 8859 et des jeux de caractères multi-octets tel que EUC (Extended Unix Code), Unicode et le code interne de Mule. Tous les jeux de caractères peuvent être utilisés de façon transparente au travers du serveur. (Si vous utilisez des fonctions d'extension d'autres sources, cela dépend de la qualité du code.) Le jeu de caractères par défaut est sélectionné pendant l'initialisation de votre cluster de base de données PostgreSQL avec initdb. Le choix peut être outrepassé lorsqu'on crée une base de données en utilisant createdb ou en utilisant la commande SQL CREATE DATABASE. Vous pouvez donc avoir de multiples bases chacune avec un jeux de caractères différents.
Le Tableau 20-1 montre les jeux de caractères disponibles à l'utilisation sur le serveur.
Tableau 20-1. Jeux de Caractères Serveur
Nom | Description |
---|---|
SQL_ASCII | ASCII |
EUC_JP | Japonais EUC |
EUC_CN | Chinois EUC |
EUC_KR | Coréen EUC |
JOHAB | Coréen EUC (base Hangle) |
EUC_TW | Taiwanais EUC |
UNICODE | Unicode (UTF-8) |
MULE_INTERNAL | Code interne de Mule |
LATIN1 | ISO 8859-1/ECMA 94 (Alphabet latin no.1) |
LATIN2 | ISO 8859-2/ECMA 94 (Alphabet latin no.2) |
LATIN3 | ISO 8859-3/ECMA 94 (Alphabet latin no.3) |
LATIN4 | ISO 8859-4/ECMA 94 (Alphabet latin no.4) |
LATIN5 | ISO 8859-9/ECMA 128 (Alphabet latin no.5) |
LATIN6 | ISO 8859-10/ECMA 144 (Alphabet latin no.6) |
LATIN7 | ISO 8859-13 (Alphabet latin no.7) |
LATIN8 | ISO 8859-14 (Alphabet latin no.8) |
LATIN9 | ISO 8859-15 (Alphabet latin no.9) |
LATIN10 | ISO 8859-16/ASRO SR 14111 (Alphabet latin no.10) |
ISO_8859_5 | ISO 8859-5/ECMA 113 (Latin/Cyrillique) |
ISO_8859_6 | ISO 8859-6/ECMA 114 (Latin/Arabe) |
ISO_8859_7 | ISO 8859-7/ECMA 118 (Latin/Grec) |
ISO_8859_8 | ISO 8859-8/ECMA 121 (Latin/Hébreu) |
KOI8 | KOI8-R(U) |
ALT | Windows CP866 |
WIN874 | Windows CP874 (Thai) |
WIN1250 | Windows CP1250 |
WIN | Windows CP1251 |
WIN1256 | Windows CP1256 (Arabe) |
TCVN | TCVN-5712/Windows CP1258 (Vietnamien) |
Important : Avant PostgreSQL 7.2, LATIN5 signifiait, à tort, ISO 8859-5. A partir de 7.2, LATIN5 signifie ISO 8859-9. Si vous avez une base LATIN5 créée sur une version 7.1 ou antérieure et vous voulez migrer vers 7.2 ou une version plus récente, vous devriez faire attention à ce changement.
Tout les APIs ne supportent pas les jeux de caractères de la liste. Par exemple, le pilot JDBC de PostgreSQL ne supporte pas MULE_INTERNAL, LATIN6, LATIN8 et LATIN10.
initdb définit le jeu de caractères par défaut pour un cluster PostgreSQL. Par exemple,
initdb -E EUC_JP
paramètre le jeu de caractères (codage) à EUC_JP (Extended Unix Code for Japanese). Vous pouvez utiliser l'option --encoding au lieu de -E si vous préférez saisir les noms d'options longs. Si aucune option -E ou --encoding n'est donnée, SQL_ASCII est utilisé.
Vous pouvez créer une base de données avec un jeu de caractère différent:
createdb -E EUC_KR korean
Ceci va créer une base de données appelée korean qui utilisera le jeu de caractère EUC_KR. Un autre moyen de réaliser ceci est d'utiliser cette commande SQL :
CREATE DATABASE korean WITH ENCODING 'EUC_KR';
L'encodage pour une base de données est conservé dans le catalogue système pg_database. Vous pouvez voir ceci en utilisant l'option -l ou la commande \l de psql.
$ psql -l List of databases Database | Owner | Encoding ---------------+---------+--------------- euc_cn | t-ishii | EUC_CN euc_jp | t-ishii | EUC_JP euc_kr | t-ishii | EUC_KR euc_tw | t-ishii | EUC_TW mule_internal | t-ishii | MULE_INTERNAL regression | t-ishii | SQL_ASCII template1 | t-ishii | EUC_JP test | t-ishii | EUC_JP unicode | t-ishii | UNICODE (9 rows)
Important : Bien que vous pouvez spécifier tout codage que vous souhaitez pour une base de données, il est déconseillé de choisir un codage qui n'est pas attendu par la locale sélectionnée. Les paramètres LC_COLLATE et LC_CTYPE impliquent un codage particulier, et les opérations dépendantes de la locale (comme le tri) pourraient mal interpréter les données qui sont dans un codage incompatible.
Comme ces paramètres de locale sont gelés par initdb, la flexibilité apparente pour utiliser différents codages dans les différentes bases de données d'un groupe est plus théorique que réel. Il est probable que ces mécanismes soient revus dans les prochaines versions de PostgreSQL.
Une façon d'utiliser les codages multiples en toute sûreté est de configurer la locale à C ou POSIX lors d'initdb, désactivant toute connaissance réelle de la locale.
PostgreSQL supporte les conversions automatiques de jeu de caractères entre client et serveur pour certains jeux de caractères. Les informations de conversion sont conservés dans le catalogue système pg_conversion. Vous pouvez créer une nouvelle conversion en utilisant la commande SQL CREATE CONVERSION. PostgreSQL est livré avec certaines conversions prédéfinies. Ils sont listés dans Tableau 20-2.
Tableau 20-2. Conversion de Jeux de Caractères Client/Serveur
Jeu de Caractères Serveur | Jeux de Caractères Clients Disponibles |
---|---|
SQL_ASCII | SQL_ASCII, UNICODE, MULE_INTERNAL |
EUC_JP | EUC_JP, SJIS, UNICODE, MULE_INTERNAL |
EUC_CN | EUC_CN, UNICODE, MULE_INTERNAL |
EUC_KR | EUC_KR, UNICODE, MULE_INTERNAL |
JOHAB | JOHAB, UNICODE |
EUC_TW | EUC_TW, BIG5, UNICODE, MULE_INTERNAL |
LATIN1 | LATIN1, UNICODE MULE_INTERNAL |
LATIN2 | LATIN2, WIN1250, UNICODE, MULE_INTERNAL |
LATIN3 | LATIN3, UNICODE, MULE_INTERNAL |
LATIN4 | LATIN4, UNICODE, MULE_INTERNAL |
LATIN5 | LATIN5, UNICODE |
LATIN6 | LATIN6, UNICODE, MULE_INTERNAL |
LATIN7 | LATIN7, UNICODE, MULE_INTERNAL |
LATIN8 | LATIN8, UNICODE, MULE_INTERNAL |
LATIN9 | LATIN9, UNICODE, MULE_INTERNAL |
LATIN10 | LATIN10, UNICODE, MULE_INTERNAL |
ISO_8859_5 | ISO_8859_5, UNICODE, MULE_INTERNAL, WIN, ALT, KOI8 |
ISO_8859_6 | ISO_8859_6, UNICODE |
ISO_8859_7 | ISO_8859_7, UNICODE |
ISO_8859_8 | ISO_8859_8, UNICODE |
UNICODE | EUC_JP, SJIS, EUC_KR, UHC, JOHAB, EUC_CN, GBK, EUC_TW, BIG5, LATIN1 to LATIN10, ISO_8859_5, ISO_8859_6, ISO_8859_7, ISO_8859_8, WIN, ALT, KOI8, WIN1256, TCVN, WIN874, GB18030, WIN1250 |
MULE_INTERNAL | EUC_JP, SJIS, EUC_KR, EUC_CN, EUC_TW, BIG5, LATIN1 to LATIN5, WIN, ALT, WIN1250, BIG5, ISO_8859_5, KOI8 |
KOI8 | ISO_8859_5, WIN, ALT, KOI8, UNICODE, MULE_INTERNAL |
ALT | ISO_8859_5, WIN, ALT, KOI8, UNICODE, MULE_INTERNAL |
WIN874 | WIN874, UNICODE |
WIN1250 | LATIN2, WIN1250, UNICODE, MULE_INTERNAL |
WIN | ISO_8859_5, WIN, ALT, KOI8, UNICODE, MULE_INTERNAL |
WIN1256 | WIN1256, UNICODE |
TCVN | TCVN, UNICODE |
Pour activer la conversion automatique de jeux de caractères, vous devez dire à PostgreSQL quel jeu de caractères (encodage) vous voulez utiliser côté client. Il y'a plusieurs façons de faire cela:
En utilisant la commande \encoding dans psql. \encoding vous permet de changer de jeu de caractères client à la volée. Par exemple, pour changer l'encodage en SJIS, tapez:
\encoding SJIS
En utilisant les fonctions libpq.
\encoding appelle en fait
PQsetClientEncoding()
pour faire son travail.
int PQsetClientEncoding(PGconn *conn, const char *encoding);
ou conn est une connexion au serveur, et encoding est l'encodage que vous voulez utiliser. Si la fonction fixe l'encodage, elle renvoie 0, sinon -1. L'encodage actuel pour cette connexion peut être déterminé en utilisant:
int PQclientEncoding(const PGconn *conn);
Notez que ceci renvoie l'ID d'encodage, pas une chaîne symbolique tel que EUC_JP. Pour convertir un ID d'encodage en NOM, vous pouvez utiliser:
char *pg_encoding_to_char(int encoding_id);
En utilisant SET client_encoding TO. Fixer l'encodage client peut être fait avec cette commande SQL:
SET CLIENT_ENCODING TO 'valeur';
Vous pouvez aussi utiliser la syntaxe SQL plus standard SET NAMES pour ceci:
SET NAMES 'valeur';
Pour demander l'actuel encodage client:
SHOW client_encoding;
Pour revenir à l'encodage par défaut:
RESET client_encoding;
En utilisant PGCLIENTENCODING. Si la variable d'environnement PGCLIENTENCODING est définie dans l'environnement client, cet encodage client est automatiquement sélectionné lorsqu'une connexion au serveur est établie. (Ceci peut être surchargé avec n'importe quelle autre des méthodes ci-dessus.)
En utilisant la variable de configuration client_encoding. Si la variable client_encoding est définie, cet encodage client est automatiquement sélectionné lorsqu'une connexion au serveur est établie. (Ceci peut être surchargé avec n'importe quelle autre des méthodes ci-dessus.)
Si la conversion d'un caractère particulier n'est pas possible — supposons que vous avez choisi EUC_JP pour le serveur et LATIN1 pour le client, alors certains caractères japonais ne pourront pas être convertis en LATIN1 — ils seront transformés en leur valeur hexadécimale entre parenthèses, i.e., (826C).
Voici de bonnes sources pour commencer à maîtriser les différents jeux de caractères.
Des explications détaillées de EUC_JP, EUC_CN, EUC_KR, EUC_TW apparaissent dans la section 3.2.
Le site web du Unicode Consortium
UTF-8 est défini ici.
Précédent | Sommaire | Suivant |
Localisation | Niveau supérieur | Planifier les tâches de maintenance |