Brug af nzload til at indlæse specialtegn

Jeg er ikke særlig kyndig med Unicode-konverteringsproblemer, men jeg har gjort dette mod mig selv før, og jeg vil demonstrere, hvad jeg tror, der sker.

Jeg tror, at det du ser her ikke er et problem med at indlæse specialtegn med nzload, det er snarere et problem med hvordan din skærm/terminalsoftware viser dataene og/eller Netezza hvordan gemmer tegndataene. Jeg har mistanke om en dobbeltkonvertering til/fra UTF-8 (den Unicode-kodning, som Netezza understøtter). Lad os se, om vi kan finde ud af, hvad det er.

Her bruger jeg PuTTY med standard (for mig) Remote Character Set som 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Â¿

Her kan vi se fra od at filen kun har de data, vi forventer, men når vi katter filen ser vi det ekstra tegn. Hvis det ikke er i filen, kommer tegnet sandsynligvis fra visningsoversættelsen.

Hvis jeg ændrer PuTTY-indstillingerne til at have UTF-8 som fjerntegnsættet, ser vi det på denne måde:

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

Så de samme kildedata, men to forskellige repræsentationer på skærmen, som ikke tilfældigt er de samme som dine to forskellige output. De samme data kan vises på mindst to måder.

Lad os nu se, hvordan det indlæses i Netezza, én gang i en VARCHAR-kolonne og igen i en NVARCHAR-kolonne.

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

Dataene er indlæst uden fejl. Bemærk, mens jeg angiver escapechar-indstillingen for nzload , ingen af tegnene i denne specifikke prøve af inputdata kræver escape, og de er heller ikke escaped.

Jeg vil nu bruge rawtohex-funktionen fra SQL Extension Toolkit som et værktøj i databasen, ligesom vi har brugt od fra kommandolinjen.

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

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

På dette tidspunkt ser begge kolonner ud til at have nøjagtig de samme data som inputfilen. Så langt, så godt.

Hvad hvis vi vælger kolonnen? For en ordens skyld gør jeg dette i en PuTTY-session med fjerntegnsæt UTF-8.

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

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

Samme binære data, men forskellig visning. Hvis jeg så kopierer output fra hver af disse markeringer til ekko overført til 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

Baseret på dette output vil jeg satse på, at du indlæser dine eksempeldata, som jeg også vil satse på er UTF-8, i en VARCHAR-kolonne i stedet for en NVARCHAR-kolonne. Dette er ikke i sig selv et problem, men kan have visnings-/konverteringsproblemer.

Generelt vil du gerne indlæse UTF-8-data i NVARCHAR-kolonner.