Problématique encoding : Traiter les données en provenance de tables SGBD, via un module SAS/Access
Commençons par expliquer le principe :
Nous avons une base de données ( Oracle, Netezza, Mysql... ) installée sur une serveur et, en "face" un client.
Le client de cette base de donnée se charge de convertir les données (transcoder le cas échéant) en provenance du serveur.
La page de code est un standard informatique qui vise à donner un numéro à chaque caractère d'une langue. La page de code permet d’identifier 256 caractères différents. Compte tenu de la diversité des caractères utilisés d’une langue à l’autre, il existe des nombreuses pages de code.
Il est important que, l'encoding de la Session SAS soit le même que l'encoding du client de la bas de données.
Le client convertit toutes les données dans le jeux de codes du terminal pour les afficher. Si les caractères sélectionnés n'existent pas dans le jeu de codes du terminal, le système affiche un point d'interrogation. Le transcodage des données entre l'encoding du serveur de base de données et l'encoding du client est souvent déterminé par la configuration local du serveur où le client est installé. Toutefois, certains client utilisent leurs propres variables d'environnements qui doivent être configuré. Il est donc important que le serveur connaisse l'encoding du client.
Aussi, chaque client propose sa variable d'environnement qui doit être configuré coté client. Cet variable assure le transcoding depuis l'encoding de la base vers l''encoding de client.
Source : https://support.sas.com/resources/papers/Multilingual_Computing_with_SAS_94.pdf
La norme ISO 8859-1, dont le nom complet est ISO/CEI 8859-1, définit ce qu'elle appelle l'alphabet latin numéro 1, qui consiste en 191 caractères de l'alphabet latin, chacun d'entre eux étant codé par un octet (soit 8 bits). ISO 8859-1 reprend le codage des caractères imprimables d'US-ASCII.
Vérifions dans nzsql :
Nous pouvons afficher le contenu d’une table avec des caractères accentués :
L’affichage est correct :
Il faut maintenant positionner l’option LANG dans le fichier sasenv_local de SAS :
Dans SAS, nous vérifions maintenant les options NLS (National Language Support abrégé par i18n )
Sas est bien configuré en LATIN9
Nous pouvons également exécuter la requête suivant pour vérifier l’encoding du client :
Le code suivant permet de vérifier le bon affichage de caractères :
| Base de données | Variable d’environnement à positionner côté client | Exemple |
| DB2 | DB2CODEPAGE | DB2CODEPAGE=1208 |
| Informix | CLIENT_LOCALE | CLIENT_LOCALE=zh_en.UTF8 |
| Microsoft SQl Server | IANAAppCodePage | IANAAppCodePage=106 |
| Mysql | character_set_client | Set character_set_client=utf-8 |
| Netezza | LANG | Set LANG=fr_FR.iso885915 |
| Oracle | NLS_LANG | NLS_LANG=American_America.UTF8 |
| PostgreSQL | PGCLIENTENCODING | PGCLIENTENCODING=UTF8 |
| Sybase | Locale | Locale=default, us_english, utf8 |
| Teradata | charset_idcharset_type | charset_id=UTF8charset_type=N |
| Vertica | Pas d'optionSAS/ACCESS va transcoder de façon automatique |
Prenons un exemple avec le module SAS/Access to Netezza :
Vérification de l’encoding de la base de données
|
1 2 |
./nzsql -host <serveur base de donnée> -u <utilisateur> -pw <mot de passe> -d <nom de la base> -s <nom du schéma> show nz_encoding |
|
1 |
NOTICE: ISO8859-1 |
Vérification de l’encoding du client :
Lorsque vous démarrez une session SQL Netezza, le système vérifie l'environnement. Il vérifie la valeur définie pour le jeu des codes des paramètres régionaux de la fenêtre de terminal dans laquelle la commande nzsql est appelée. Pour afficher la valeur du jeu de codes des paramètres régionaux, utilisez la commande Linux locale charmap.|
1 |
locale charmap |
|
1 |
ISO8859-1 |
|
1 |
show client_encoding; |
|
1 |
NOTICE: Current client encoding is LATIN9 |
|
1 |
select * from nfilms; |
Il faut maintenant positionner l’option LANG dans le fichier sasenv_local de SAS :
|
1 |
LANG=fr_FR.iso885915 |
|
1 |
export LANG |
|
1 2 |
PROC Options group = LanguageControl; run; |
|
1 2 |
ENCODING=LATIN9 LOCALE=FR_FR |
Vérifions la bonne prise en compte de la variable LANG :
|
1 |
%put %quote(%sysget(LANG)); |
|
1 |
LATIN9 |
|
1 2 3 4 5 |
proc sql; connect to netezza (DATABASE=xxx SERVER=xxx USER=xxx PASSWORD=xxxx); execute(show client_encoding;) by netezza; disconnect from netezza; quit; |
|
1 |
WARNING: During execute: NOTICE: Current client encoding is LATIN9 |
|
1 2 3 4 5 |
options sastrace='d' sastraceloc=saslog nostsuffix; data _null_; set NTZ.films; put title = title $HEX40.; run; |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
NETEZZA: EXIT SQLExecute with return code 0 (SQL_SUCCESS) 0x00000000132018b0 NETEZZA: ENTER SQLFetchScroll 0x00000000132018b0 1 <SQL_FETCH_NEXT> NETEZZA: EXIT SQLFetchScroll with return code 0 (SQL_SUCCESS) 0x00000000132018b0 1 <SQL_FETCH_NEXT> <strong>TITLE=Titanic 546974616E696320202020202020202020202020 TITLE=il était une fois dans l ouest 696C20E97461697420756E6520666F6973206461 TITLE=Bananas 42616E616E617320202020202020202020202020 TITLE=Rocky 526F636B79202020202020202020202020202020 NETEZZA: ENTER SQLFetchScroll 0x00000000132018b0</strong> <SQL_FETCH_NEXT> |
Puis vérification :
|
1 2 |
proc print data=NTZ.films; run; |
Bonjour nicolas, j’ai vu qu’il existait la variable NZ_ENCODING qu’il est possible de d’exporter ou en la définissant pour la session SQL. Tu n’en parles pas ici. Un oubli ?
Bonjour Charles, Merci pour ton commentaire. Je ne suis pas DBA Netezza mais il me semble que la variable NZ_ENCODING est utilisé pour les jeux de caractères non-ASCII. Par exemple pour le codage SJIS (japonais).
SQL Netezza convertit toutes les données des colonnes char, varchar, nchar et nvarchar dans le jeux de codes du terminal pour les afficher. Si les caractères sélectionnés n’existent pas dans le jeu de codes du terminal, le système affiche un point d’interrogation.