Documentation PostgreSQL 8.1.23 > Administration du serveur > Localisation > Support des jeux de caractères | |
Localisation | Planifier les tâches de maintenance |
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), UTF-8 et le code interne de Mule. Tous les jeux de caractères supportés peuvent être utilisés de façon transparente par les clients mais certains ne sont pas supportés au sein du serveur (c'est-à-dire comme jeu de caractères du serveur). 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é lors de la création de la base, vous pouvez donc avoir des bases avec des jeux de caractères différents.
Le Tableau 21.1, « Jeux de caractères de PostgreSQL » montre les jeux de caractères disponibles à l'utilisation dans PostgreSQL™.
Tableau 21.1. Jeux de caractères de PostgreSQL™
Nom | Description | Langue | Serveur | Octets/Caractère | Alias |
---|---|---|---|---|---|
BIG5 | Big Five | Chinois traditionnel | Non | 1-2 | WIN950, Windows950 |
EUC_CN | Code-CN Unix étendu | Chinois simplifié | Oui | 1-3 | |
EUC_JP | Code-JP Unix étendu | Japonais | Oui | 1-3 | |
EUC_KR | Code-KR Unix étendu | Coréen | Oui | 1-3 | |
EUC_TW | Code-TW Unix étendu | Chinois traditionnel, taïwanais | Oui | 1-3 | |
GB18030 | Standard national | Chinois | Non | 1-2 | |
GBK | Standard national étendu | Chinois simplifié | Non | 1-2 | WIN936, Windows936 |
ISO_8859_5 | ISO 8859-5, ECMA 113 | Latin/Cyrillique | Oui | 1 | |
ISO_8859_6 | ISO 8859-6, ECMA 114 | Latin/Arabe | Oui | 1 | |
ISO_8859_7 | ISO 8859-7, ECMA 118 | Latin/Grec | Oui | 1 | |
ISO_8859_8 | ISO 8859-8, ECMA 121 | Latin/Hébreu | Oui | 1 | |
JOHAB | JOHAB | Koréen (Hangul) | Oui | 1-3 | |
KOI8 | KOI8-R(U) | Cyrillique | Oui | 1 | KOI8R |
LATIN1 | ISO 8859-1, ECMA 94 | Europe de l'ouest | Oui | 1 | ISO88591 |
LATIN2 | ISO 8859-2, ECMA 94 | Europe centrale | Oui | 1 | ISO88592 |
LATIN3 | ISO 8859-3, ECMA 94 | Europe du sud | Oui | 1 | ISO88593 |
LATIN4 | ISO 8859-4, ECMA 94 | Europe du nord | Oui | 1 | ISO88594 |
LATIN5 | ISO 8859-9, ECMA 128 | Turque | Oui | 1 | ISO88599 |
LATIN6 | ISO 8859-10, ECMA 144 | Nordique | Oui | 1 | ISO885910 |
LATIN7 | ISO 8859-13 | Baltique | Oui | 1 | ISO885913 |
LATIN8 | ISO 8859-14 | Celtique | Oui | 1 | ISO885914 |
LATIN9 | ISO 8859-15 | LATIN1 avec l'Euro et les accents | Oui | 1 | ISO885915 |
LATIN10 | ISO 8859-16, ASRO SR 14111 | Roumain | Oui | 1 | ISO885916 |
MULE_INTERNAL | Code interne Mule | Emacs multi-langues | Oui | 1-4 | |
SJIS | Shift JIS | Japonais | Non | 1-2 | Mskanji, ShiftJIS, WIN932, Windows932 |
SQL_ASCII | non spécifié (voir le texte) | tout | Oui | 1 | |
UHC | Code unifié Hangul | Koréen | Non | 1-2 | WIN949, Windows949 |
UTF8 | Unicode, 8-bit | tous | Oui | 1-4 | Unicode |
WIN866 | Windows CP866 | Cyrillique | Oui | 1 | ALT |
WIN874 | Windows CP874 | Thai | Oui | 1 | |
WIN1250 | Windows CP1250 | Europe centrale | Oui | 1 | |
WIN1251 | Windows CP1251 | Cyrillique | Oui | 1 | WIN |
WIN1252 | Windows CP1252 | Europe de l'ouest | 1 | ||
WIN1256 | Windows CP1256 | Arabe | Oui | 1 | |
WIN1258 | Windows CP1258 | Vietnamien | Oui | 1 | ABC, TCVN, TCVN5712, VSCII |
Toutes les API ne supportent pas les jeux de caractères de la liste. Par exemple, le pilote JDBC de PostgreSQL™ ne supporte pas MULE_INTERNAL, LATIN6, LATIN8 et LATIN10.
La valeur SQL_ASCII se comporte de façon considérablement différente des autres valeurs. Quand l'ensemble de caractères du serveur est SQL_ASCII, le serveur interprète les valeurs des octets 0-127 suivant le standard ASCII alors que les valeurs d'octets 128-255 sont considérées comme des caractères non interprétés. Aucune conversion de codage ne sera effectuée avec SQL_ASCII. Du coup, cette valeur n'est pas tellement la déclaration qu'un codage spécifique est utilisé, mais plutôt de l'ignorance du codage. Dans la plupart des cas, si vous travaillez avec des données non ASCII, il est déconseillé d'utiliser la valeur SQL_ASCII car PostgreSQL™ sera incapable de vous aider dans la conversion ou la validation des caractères non ASCII.
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, initdb tente de déterminer le codage approprié à utiliser suivant la locale spécifiée ou par défaut.
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';
Le codage 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 postgres | t-ishii | EUC_JP regression | t-ishii | SQL_ASCII template1 | t-ishii | EUC_JP test | t-ishii | EUC_JP utf8 | t-ishii | UTF8 (9 rows)
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ées dans le catalogue système pg_conversion. PostgreSQL™ est livré avec certaines conversions prédéfinies, conversions listées dans le Tableau 21.2, « Conversion de jeux de caractères client/serveur ». Vous pouvez créer une nouvelle conversion en utilisant la commande SQL CREATE CONVERSION.
Tableau 21.2. Conversion de jeux de caractères client/serveur
Jeu de caractères serveur | Jeux de caractères client disponibles |
---|---|
BIG5 | non supporté comme codage serveur |
EUC_CN | EUC_CN, MULE_INTERNAL, UTF8 |
EUC_JP | EUC_JP, MULE_INTERNAL, SJIS, UTF8 |
EUC_KR | EUC_KR, MULE_INTERNAL, UTF8 |
EUC_TW | EUC_TW, BIG5, MULE_INTERNAL, UTF8 |
GB18030 | non supporté comme codage serveur |
GBK | non supporté comme codage serveur |
ISO_8859_5 | ISO_8859_5, KOI8, MULE_INTERNAL, UTF8, WIN866, WIN1251 |
ISO_8859_6 | ISO_8859_6, UTF8 |
ISO_8859_7 | ISO_8859_7, UTF8 |
ISO_8859_8 | ISO_8859_8, UTF8 |
JOHAB | JOHAB, UTF8 |
KOI8 | KOI8, ISO_8859_5, MULE_INTERNAL, UTF8, WIN866, WIN1251 |
LATIN1 | LATIN1, MULE_INTERNAL, UTF8 |
LATIN2 | LATIN2, MULE_INTERNAL, UTF8, WIN1250 |
LATIN3 | LATIN3, MULE_INTERNAL, UTF8 |
LATIN4 | LATIN4, MULE_INTERNAL, UTF8 |
LATIN5 | LATIN5, UTF8 |
LATIN6 | LATIN6, UTF8 |
LATIN7 | LATIN7, UTF8 |
LATIN8 | LATIN8, UTF8 |
LATIN9 | LATIN9, UTF8 |
LATIN10 | LATIN10, UTF8 |
MULE_INTERNAL | MULE_INTERNAL, BIG5, EUC_CN, EUC_JP, EUC_KR, EUC_TW, ISO_8859_5, KOI8, LATIN1 vers LATIN4, SJIS, WIN866, WIN1250, WIN1251 |
SJIS | non supporté comme codage serveur |
SQL_ASCII | tous (aucune conversion ne sera réalisée) |
UHC | non supporté comme codage serveur |
UTF8 | tout codage supporté |
WIN866 | WIN866, ISO_8859_5, KOI8, MULE_INTERNAL, UTF8, WIN1251 |
WIN874 | WIN874, UTF8 |
WIN1250 | WIN1250, LATIN2, MULE_INTERNAL, UTF8 |
WIN1251 | WIN1251, ISO_8859_5, KOI8, MULE_INTERNAL, UTF8, WIN866 |
WIN1252 | WIN1252, UTF8 |
WIN1256 | WIN1256, UTF8 |
WIN1258 | WIN1258, UTF8 |
Pour activer la conversion automatique de jeux de caractères, vous devez dire à PostgreSQL™ quel jeu de caractères (codage) 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 le codage 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 le codage que vous voulez utiliser. Si la fonction fixe le codage, elle renvoie 0, sinon -1. Le codage actuel pour cette connexion peut être déterminé en utilisant :
int PQclientEncoding(const PGconn *conn);
Notez que ceci renvoie l'ID du codage, pas une chaîne symbolique telle que EUC_JP. Pour convertir un ID du codage en NOM, vous pouvez utiliser :
char *pg_encoding_to_char(int encoding_id);
En utilisant SET client_encoding TO. Fixer le codage 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 codage client :
SHOW client_encoding;
Pour revenir au codage par défaut :
RESET client_encoding;
En utilisant PGCLIENTENCODING. Si la variable d'environnement PGCLIENTENCODING est définie dans l'environnement client, ce codage 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, ce codage 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 n'ont pas de représentation en LATIN1 -- une erreur est alors rapportée.
Si l'ensemble de caractères du client est défini en tant que SQL_ASCII, la conversion du codage est désactivée quelque soit l'ensemble de caractères du serveur. Comme pour le serveur, utiliser SQL_ASCII est déconseillé sauf si vous ne travaillez qu'avec des données ASCII.
Ceux-ci sont de bonnes sources pour commencer à maîtriser les différents jeux de caractères.
Une collection complète de documents sur les ensembles de caractères, les codages et les pages code.
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.