Używanie nzload do ładowania znaków specjalnych

Nie jestem zbyt obeznany z problemami z konwersją Unicode, ale robiłem to już wcześniej i pokażę, co moim zdaniem się dzieje.

Uważam, że to, co tu widzisz, nie jest problemem z ładowaniem znaków specjalnych za pomocą nzload, ale jest to problem z tym, jak oprogramowanie wyświetlające/terminala wyświetla dane i/lub Netezza, jak przechowuje dane o znakach. Podejrzewam podwójną konwersję do/z UTF-8 (kodowanie Unicode obsługiwane przez Netezza). Zobaczmy, czy możemy odgadnąć, który to jest.

Tutaj używam PuTTY z domyślnym (dla mnie) zdalnym zestawem znaków 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Â¿

Tutaj widzimy od od że plik zawiera tylko te dane, których oczekujemy, jednak gdy kocimy w pliku widzimy dodatkowy znak. Jeśli nie ma go w pliku, prawdopodobnie znak pochodzi z tłumaczenia wyświetlacza.

Jeśli zmienię ustawienia PuTTY, aby UTF-8 był zdalnym zestawem znaków, widzimy to w ten sposób:

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

A więc te same dane źródłowe, ale dwie różne reprezentacje na ekranie, które nieprzypadkowo są takie same jak dwa różne dane wyjściowe. Te same dane mogą być wyświetlane na co najmniej dwa sposoby.

Zobaczmy teraz, jak ładuje się do Netezza, raz do kolumny VARCHAR i ponownie do kolumny 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

Dane załadowane bez błędów. Zwróć uwagę, kiedy określam opcję znaku ewakuacyjnego dla nzload , żaden ze znaków w tej konkretnej próbce danych wejściowych nie wymaga zmiany znaczenia ani nie są one zmieniane.

Będę teraz używał funkcji rawtohex z zestawu narzędzi SQL Extension Toolkit jako narzędzia w bazie danych, tak jak użyliśmy od z wiersza poleceń.

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

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

W tym momencie obie kolumny wydają się mieć dokładnie te same dane, co plik wejściowy. Jak dotąd tak dobrze.

Co jeśli wybierzemy kolumnę? Dla przypomnienia, robię to w sesji PuTTY ze zdalnym zestawem znaków UTF-8.

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

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

Te same dane binarne, ale inny wyświetlacz. Jeśli następnie skopiuję dane wyjściowe każdego z tych zaznaczeń do echa przesyłane 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 podstawie tych wyników założę się, że ładujesz swoje przykładowe dane, które również założę, że to UTF-8, do kolumny VARCHAR, a nie kolumny NVARCHAR. Samo w sobie nie jest to problem, ale może powodować problemy z wyświetlaniem/konwersją.

Ogólnie rzecz biorąc, chciałbyś załadować dane UTF-8 do kolumn NVARCHAR.