Använder nzload för att ladda specialtecken

Jag är inte så insatt i Unicode-konverteringsproblem, men jag har gjort det här mot mig själv förut, och jag ska visa vad jag tror som händer.

Jag tror att det du ser här inte är ett problem med att ladda specialtecken med nzload, snarare är det ett problem med hur din skärm/terminalprogramvara visar data och/eller Netezza hur teckendata lagras. Jag misstänker en dubbelkonvertering till/från UTF-8 (Unicode-kodningen som Netezza stöder). Låt oss se om vi kan ta reda på vad det är.

Här använder jag PuTTY med standard (för mig) fjärrteckenuppsättning 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Â¿

Här kan vi se från od att filen bara har den data vi förväntar oss, men när vi katter filen ser vi det extra tecknet. Om det inte finns i filen kommer tecknet troligen från visningsöversättningen.

Om jag ändrar PuTTY-inställningarna så att UTF-8 är fjärrteckenuppsättningen ser vi det så här:

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

Alltså samma källdata, men två olika representationer på skärmen, som inte av en slump är samma som dina två olika utdata. Samma data kan visas på minst två sätt.

Låt oss nu se hur det laddas in i Netezza, en gång i en VARCHAR-kolumn och igen i en NVARCHAR-kolumn.

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 laddade utan fel. Notera medan jag anger escapechar-alternativet för nzload , inget av tecknen i det här specifika exemplet av indata kräver escape, och de escapes inte heller.

Jag kommer nu att använda rawtohex-funktionen från SQL Extension Toolkit som ett databasverktyg som vi har använt od från kommandoraden.

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

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

Vid denna tidpunkt verkar båda kolumnerna ha exakt samma data som indatafilen. Så långt har det gått bra.

Vad händer om vi väljer kolumnen? För ordens skull gör jag detta i en PuTTY-session med fjärrteckenuppsättning UTF-8.

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

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

Samma binära data, men annan visning. Om jag sedan kopierar utdata från var och en av dessa markeringar till eko leds till 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

Baserat på denna utdata skulle jag satsa på att du laddar din exempeldata, som jag också skulle satsa på är UTF-8, i en VARCHAR-kolumn snarare än en NVARCHAR-kolumn. Detta är i sig inte ett problem, men kan ha visnings-/konverteringsproblem längre fram.

Generellt sett skulle du vilja ladda UTF-8-data till NVARCHAR-kolumner.