Je ne suis pas très au fait des problèmes de conversion Unicode, mais je me suis déjà fait ça et je vais vous montrer ce que je pense qu'il se passe.
Je crois que ce que vous voyez ici n'est pas un problème avec le chargement de caractères spéciaux avec nzload, mais plutôt un problème avec la façon dont votre logiciel d'affichage/terminal affiche les données et/ou Netezza comment stocke les données de caractères. Je soupçonne une double conversion vers/depuis UTF-8 (l'encodage Unicode pris en charge par Netezza). Voyons si nous pouvons déterminer de quoi il s'agit.
Ici, j'utilise PuTTY avec le jeu de caractères distant par défaut (pour moi) en tant que Latin-1.
$ od -xa input.txt
0000000 5250 464f 5345 4953 4e4f 4c41 bfc2 000a
P R O F E S S I O N A L B ? nl
0000017
$ cat input.txt
PROFESSIONAL¿
Ici, nous pouvons voir de od que le fichier ne contient que les données que nous attendons, cependant lorsque nous cat le fichier, nous voyons le caractère supplémentaire. S'il ne se trouve pas dans le fichier, le caractère provient probablement de la traduction d'affichage.
Si je modifie les paramètres PuTTY pour que UTF-8 soit le jeu de caractères distant, nous le voyons de cette façon :
$ od -xa input.txt
0000000 5250 464f 5345 4953 4e4f 4c41 bfc2 000a
P R O F E S S I O N A L B ? nl
0000017
$ cat input.txt
PROFESSIONAL¿
Donc, les mêmes données source, mais deux représentations à l'écran différentes, qui sont, pas par hasard, les mêmes que vos deux sorties différentes. Les mêmes données peuvent être affichées au moins de deux façons.
Voyons maintenant comment il se charge dans Netezza, une fois dans une colonne VARCHAR, et de nouveau dans une colonne NVARCHAR.
create table test_enc_vchar (col1 varchar(50));
create table test_enc_nvchar (col1 nvarchar(50));
$ nzload -db testdb -df input.txt -t test_enc_vchar -escapechar '\' -ctrlchars
Load session of table 'TEST_ENC_VCHAR' completed successfully
$ nzload -db testdb -df input.txt -t test_enc_nvchar -escapechar '\' -ctrlchars
Load session of table 'TEST_ENC_NVCHAR' completed successfully
Les données chargées sans erreur. Notez que je spécifie l'option escapechar pour nzload , aucun des caractères de cet échantillon spécifique de données d'entrée ne nécessite d'échappement, et ils ne le sont pas non plus.
Je vais maintenant utiliser la fonction rawtohex du SQL Extension Toolkit comme outil dans la base de données comme nous avons utilisé od depuis la ligne de commande.
select rawtohex(col1) from test_enc_vchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
select rawtohex(col1) from test_enc_nvchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
À ce stade, les deux colonnes semblent avoir exactement les mêmes données que le fichier d'entrée. Jusqu'ici, tout va bien.
Et si nous sélectionnions la colonne ? Pour mémoire, je le fais dans une session PuTTY avec un jeu de caractères distant UTF-8.
select col1 from test_enc_vchar;
COL1
----------------
PROFESSIONAL¿
(1 row)
select col1 from test_enc_nvchar;
COL1
---------------
PROFESSIONAL¿
(1 row)
Mêmes données binaires, mais affichage différent. Si je copie ensuite la sortie de chacune de ces sélections dans echo redirigé vers od ,
$ echo PROFESSIONAL¿ | od -xa
0000000 5250 464f 5345 4953 4e4f 4c41 82c3 bfc2
P R O F E S S I O N A L C stx B ?
0000020 000a
nl
0000021
$ echo PROFESSIONAL¿ | od -xa
0000000 5250 464f 5345 4953 4e4f 4c41 bfc2 000a
P R O F E S S I O N A L B ? nl
0000017
Sur la base de cette sortie, je parierais que vous chargez vos exemples de données, que je parierais également être UTF-8, dans une colonne VARCHAR plutôt qu'une colonne NVARCHAR. Ce n'est pas, en soi, un problème, mais peut avoir des problèmes d'affichage/de conversion sur toute la ligne.
De manière générale, vous souhaitez charger des données UTF-8 dans des colonnes NVARCHAR.
