21.2. Support des jeux de caractères
Le support des jeux de caractères dans PostgreSQL™ permet d'insérer du texte dans
différents jeux de caractères, dont ceux mono-octet tels que la série
ISO 8859 et ceux multi-octets tels que EUC (Extended Unix Code), UTF-8 ou le codage
interne 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 par le serveur (c'est-à-dire comme encodage du
serveur). Le jeu de caractères par défaut est sélectionné pendant
l'initialisation du cluster de base de données avec
initdb
. Ce choix peut être
surchargé à la création de la base. Il est donc possible de disposer
de bases utilisant chacune un jeu de caractères différent.
21.2.1. Jeux de caractères supportés
Le Tableau 21.1,
« Jeux de caractères de PostgreSQL™ » présente les jeux
de caractères utilisables avec 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
|
Oui
|
1
|
|
|
WIN1253
|
Windows CP1253
|
Grec
|
Oui
|
1
|
|
|
WIN1254
|
Windows CP1254
|
Turque
|
Oui
|
1
|
|
|
WIN1255
|
Windows CP1255
|
Hébreux
|
Oui
|
1
|
|
|
WIN1256
|
Windows CP1256
|
Arabe
|
Oui
|
1
|
|
|
WIN1257
|
Windows CP1257
|
Baltique
|
Oui
|
1
|
|
|
WIN1258
|
Windows CP1258
|
Vietnamien
|
Oui
|
1
|
ABC, TCVN, TCVN5712,
VSCII
|
Toutes les API ne supportent pas
tous les jeux de caractères de la liste. Le pilote JDBC de
PostgreSQL™, par exemple, ne
supporte pas MULE_INTERNAL, LATIN6, LATIN8 et
LATIN10.
SQL_ASCII se comporte de façon
considérablement différente des autres valeurs. Quand le jeu 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 n'est
effectuée avec SQL_ASCII. De ce fait,
cette valeur ne déclare pas tant un encodage spécifique que
l'ignorance de l'encodage. Dans la plupart des cas, si des données
non ASCII doivent être traitées, il est déconseillé d'utiliser la
valeur SQL_ASCII car PostgreSQL™ est alors incapable de
convertir ou de valider les caractères non ASCII.
21.2.2. Choisir le jeu de caractères
initdb
définit le jeu
de caractères par défaut pour un cluster. Par exemple,
initdb -E EUC_JP
paramètre le jeu de caractères (encodage) à EUC_JP (Extended Unix Code for Japanese). L'option
--encoding peut aussi être utilisée à la
place de -E (options longues). Si aucune
option -E ou --encoding n'est donnée,
initdb
tente de déterminer
l'encodage approprié en fonction de la locale indiquée ou de celle
par défaut.
Il est possible de créer une base de données avec un jeu de
caractère différent :
createdb -E EUC_KR korean
Cela crée une base de données appelée korean qui utilise le jeu de caractères EUC_KR. Un autre moyen de réaliser cela est
d'utiliser la commande SQL suivante :
CREATE DATABASE korean WITH ENCODING 'EUC_KR';
L'encodage de la base de données est conservé dans le catalogue
système pg_database. Cela est visible à
l'aide de l'option -l ou de 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)
Important
Bien qu'il soit possible de préciser n'importe quel encodage
pour une base de données, il est déconseillé de choisir un
encodage qui n'est pas attendu par la locale sélectionnée. Les
paramètres LC_COLLATE et LC_CTYPE impliquent un encodage particulier, et
les opérations dépendantes de la locale (comme le tri)
interprètent souvent mal les données stockées dans un encodage
incompatible.
Comme ces paramètres de locales sont gelés par
initdb
, la latitude apparente
laissée dans l'utilisation des encodages des bases de données
d'un cluster est plus théorique que réelle. Il est probable que
ces mécanismes soient revus dans les prochaines versions de
PostgreSQL™.
Une possibilité d'utiliser les codages multiples en toute
sûreté est de configurer la locale à C
ou POSIX lors d'
initdb
, ce qui désactive
toute connaissance réelle de la locale.
21.2.3. Conversion automatique d'encodage entre serveur et client
PostgreSQL™ supporte les
conversions automatiques d'encodage 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 ». Une nouvelle conversion peut être créée
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 clients disponibles
|
|
BIG5
|
non supporté comme encodage
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 encodage
serveur
|
|
GBK
|
non supporté comme encodage
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 encodage
serveur
|
|
SQL_ASCII
|
tous (aucune conversion n'est
réalisée)
|
|
UHC
|
non supporté comme encodage
serveur
|
|
UTF8
|
tout encodage
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
|
|
WIN1253
|
WIN1253
,
UTF8
|
|
WIN1254
|
WIN1254
,
UTF8
|
|
WIN1255
|
WIN1255
,
UTF8
|
|
WIN1256
|
WIN1256
,
UTF8
|
|
WIN1257
|
WIN1257
,
UTF8
|
|
WIN1258
|
WIN1258
,
UTF8
|
Pour activer la conversion automatique des jeux de caractères, il
est nécessaire d'indiquer à PostgreSQL™ le jeu de caractères
(encodage) souhaité côté client. Il y a plusieurs façons de le
faire :
-
en utilisant la commande
\encoding
dans psql.
\encoding
permet de changer
l'encodage client à la volée. Par exemple, pour changer le
codage en SJIS, taper :
\encoding SJIS
-
en utilisant les fonctions libpq.
\encoding
appelle en fait
PQsetClientEncoding() pour se
faire.
int PQsetClientEncoding(PGconn *conn, const char *encoding);
avec
conn
une connexion
au serveur et
encoding
l'encodage souhaité. Si la fonction fixe l'encodage, elle
renvoie 0, sinon -1. L'encodage courant d'une connexion peut
être déterminé en utilisant :
int PQclientEncoding(const PGconn *conn);
Cela renvoie l'ID de l'encodage, et non une chaîne symbolique
telle que EUC_JP. Pour convertir un
ID d'encodage en NOM, on utilise :
char *pg_encoding_to_char(int encoding_id);
-
en utilisant
SET
client_encoding TO
. L'encodage client peut
être fixé avec la commande SQL suivante :
SET CLIENT_ENCODING TO 'valeur';
La syntaxe SQL plus standard SET
NAMES peut également être utilisée pour cela :
SET NAMES 'valeur';
Pour connaître l'encodage client courant :
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, l'encodage client est automatiquement
sélectionné lors de l'établissement d'une connexion au
serveur (cette variable peut être surchargée à l'aide de
toute autre méthode décrite ci-dessus).
-
en utilisant la variable de configuration client_encoding.
Si la variable client_encoding est
définie, l'encodage client est automatiquement sélectionné
lors de l'établissement d'une connexion au serveur (cette
variable peut être surchargée à l'aide de toute autre méthode
décrite ci-dessus).
Si la conversion d'un caractère particulier n'est pas possible --
dans le cas d'encodages EUC_JP pour le
serveur et LATIN1 pour le client, par
exemple, certains caractères japonais n'ont pas de représentation
en LATIN1 -- une erreur est remontée.
Si l'encodage client est défini en tant que SQL_ASCII, la conversion de l'encodage est
désactivée quelque soit celui du serveur. Comme pour le serveur,
SQL_ASCII est déconseillé sauf à ne
travailler qu'avec des données ASCII.
21.2.4. Pour aller plus loin
Quelques sources intéressantes pour commencer à maîtriser les
différents jeux de caractères.
|