Použití nzload k načtení speciálních znaků

Nejsem moc důvtipný v problémech s převodem Unicode, ale už jsem si to udělal dříve a ukážu, co si myslím, že se děje.

Věřím, že to, co zde vidíte, není problém s načítáním speciálních znaků pomocí nzload, spíše je to problém s tím, jak váš zobrazovací/terminálový software zobrazuje data a/nebo jak Netezza ukládá data znaků. Mám podezření na dvojitou konverzi do/z UTF-8 (kódování Unicode, které Netezza podporuje). Podívejme se, jestli dokážeme zjistit, která to je.

Zde používám PuTTY s výchozí (pro mě) vzdálenou znakovou sadou jako 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Â¿

Zde můžeme vidět z od že soubor obsahuje pouze data, která očekáváme, nicméně když cat souboru vidíme znak navíc. Pokud v souboru není, znak pravděpodobně pochází z překladu zobrazení.

Pokud změním nastavení PuTTY tak, aby vzdálenou znakovou sadou bylo UTF-8, uvidíme to takto:

$ 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¿

Tedy stejná zdrojová data, ale dvě různé reprezentace na obrazovce, které jsou ne náhodou stejné jako vaše dva různé výstupy. Stejná data lze zobrazit alespoň dvěma způsoby.

Nyní se podívejme, jak se načítá do Netezzy, jednou do sloupce VARCHAR a znovu do sloupce 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

Data načtena bez chyb. Všimněte si, že když specifikuji možnost escapechar pro nzload , žádný ze znaků v tomto konkrétním vzorku vstupních dat nevyžaduje escapování, ani nejsou escapovány.

Nyní použiji funkci rawtohex z SQL Extension Toolkit jako nástroj v databázi, jako jsme používali od z příkazového řádku.

select rawtohex(col1) from test_enc_vchar;
           RAWTOHEX
------------------------------
 50524F46455353494F4E414CC2BF
(1 row)

select rawtohex(col1) from test_enc_nvchar;
           RAWTOHEX
------------------------------
 50524F46455353494F4E414CC2BF
(1 row)

V tomto okamžiku se zdá, že oba sloupce obsahují přesně stejná data jako vstupní soubor. Zatím je to dobré.

Co když vybereme sloupec? Pro záznam, dělám to v relaci PuTTY se vzdálenou znakovou sadou UTF-8.

select col1 from test_enc_vchar;
      COL1
----------------
 PROFESSIONALÂ¿
(1 row)

select col1 from test_enc_nvchar;
     COL1
---------------
 PROFESSIONAL¿
(1 row)

Stejná binární data, ale jiné zobrazení. Pokud pak zkopíruji výstup každého z těchto výběrů do echo převedeno do 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

Na základě tohoto výstupu bych se vsadil, že načítáte vaše ukázková data, která bych také vsadil na UTF-8, do sloupce VARCHAR spíše než do sloupce NVARCHAR. To samo o sobě není problém, ale může mít problémy se zobrazením/převodem.

Obecně řečeno, budete chtít načíst data UTF-8 do sloupců NVARCHAR.