Non sono molto esperto di problemi di conversione Unicode, ma l'ho già fatto a me stesso e dimostrerò cosa penso stia succedendo.
Credo che quello che stai vedendo qui non sia un problema con il caricamento di caratteri speciali con nzload, piuttosto è un problema con il modo in cui il tuo software di visualizzazione/terminale visualizza i dati e/o Netezza come memorizza i dati dei caratteri. Sospetto una doppia conversione da/verso UTF-8 (la codifica Unicode supportata da Netezza). Vediamo se riusciamo a capire quale sia.
Qui sto usando PuTTY con il set di caratteri remoto predefinito (per me) come 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¿
Qui possiamo vedere da od che il file ha solo i dati che ci aspettiamo, tuttavia quando cat il file vediamo il carattere extra. Se non è nel file, è probabile che il carattere provenga dalla traduzione del display.
Se cambio le impostazioni di PuTTY in modo che UTF-8 sia il set di caratteri remoto, lo vediamo in questo modo:
$ 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¿
Quindi, gli stessi dati di origine, ma due diverse rappresentazioni sullo schermo, che, non a caso, sono le stesse dei due diversi output. Gli stessi dati possono essere visualizzati in almeno due modi.
Ora vediamo come viene caricato in Netezza, una volta in una colonna VARCHAR e di nuovo in una colonna 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
I dati caricati senza errori. Nota mentre specifico l'opzione escapechar per nzload , nessuno dei caratteri in questo campione specifico di dati di input richiede l'escape, né viene eseguito l'escape.
Ora userò la funzione rawtohex di SQL Extension Toolkit come strumento nel database come abbiamo usato od dalla riga di comando.
select rawtohex(col1) from test_enc_vchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
select rawtohex(col1) from test_enc_nvchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
A questo punto entrambe le colonne sembrano avere esattamente gli stessi dati del file di input. Fin qui tutto bene.
E se selezioniamo la colonna? Per la cronaca, lo sto facendo in una sessione PuTTY con set di caratteri remoto di UTF-8.
select col1 from test_enc_vchar;
COL1
----------------
PROFESSIONAL¿
(1 row)
select col1 from test_enc_nvchar;
COL1
---------------
PROFESSIONAL¿
(1 row)
Stessi dati binari, ma visualizzazione diversa. Se poi copio l'output di ciascuna di queste selezioni in echo reindirizzato a 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
Sulla base di questo output, scommetterei che stai caricando i tuoi dati di esempio, che scommetterei anche essere UTF-8, in una colonna VARCHAR anziché in una colonna NVARCHAR. Questo non è, di per sé, un problema, ma può avere problemi di visualizzazione/conversione su tutta la linea.
In generale, vorresti caricare i dati UTF-8 nelle colonne NVARCHAR.
