Ik ben niet erg handig met Unicode-conversieproblemen, maar ik heb mezelf dit eerder aangedaan en ik zal laten zien wat ik denk dat er gebeurt.
Ik geloof dat wat je hier ziet geen probleem is met het laden van speciale tekens met nzload, maar eerder een probleem met hoe je display/terminalsoftware de gegevens weergeeft en/of Netezza hoe de tekengegevens worden opgeslagen. Ik vermoed een dubbele conversie van/naar UTF-8 (de Unicode-codering die Netezza ondersteunt). Laten we eens kijken of we kunnen achterhalen welke het is.
Hier gebruik ik PuTTY met de standaard (voor mij) Remote Character Set als 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¿
Hier kunnen we zien vanaf od dat het bestand alleen de gegevens bevat die we verwachten, maar wanneer we katten het bestand zien we het extra karakter. Als het niet in het bestand staat, komt het teken waarschijnlijk uit de weergavevertaling.
Als ik de PuTTY-instellingen wijzig zodat UTF-8 de externe tekenset is, zien we het als volgt:
$ 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¿
Dus dezelfde brongegevens, maar twee verschillende weergaven op het scherm, die niet toevallig hetzelfde zijn als uw twee verschillende uitgangen. Dezelfde gegevens kunnen op ten minste twee manieren worden weergegeven.
Laten we nu eens kijken hoe het in Netezza laadt, eenmaal in een VARCHAR-kolom en opnieuw in een NVARCHAR-kolom.
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
De gegevens zijn zonder fouten geladen. Let op terwijl ik de escapechar-optie specificeer voor nzload , geen van de tekens in dit specifieke voorbeeld van invoergegevens vereist escape-tekens, en ook niet.
Ik zal nu de rawtohex-functie van de SQL Extension Toolkit gebruiken als een in-databasetool zoals we od hebben gebruikt vanaf de opdrachtregel.
select rawtohex(col1) from test_enc_vchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
select rawtohex(col1) from test_enc_nvchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
Op dit punt lijken beide kolommen exact dezelfde gegevens te hebben als het invoerbestand. Tot nu toe, zo goed.
Wat als we de kolom selecteren? Voor de goede orde, ik doe dit in een PuTTY-sessie met een externe tekenset van UTF-8.
select col1 from test_enc_vchar;
COL1
----------------
PROFESSIONAL¿
(1 row)
select col1 from test_enc_nvchar;
COL1
---------------
PROFESSIONAL¿
(1 row)
Zelfde binaire gegevens, maar andere weergave. Als ik dan de uitvoer van elk van die selecties kopieer naar echo doorgesluisd naar 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
Op basis van deze uitvoer durf ik te wedden dat u uw voorbeeldgegevens laadt, waarvan ik ook zou wedden dat het UTF-8 is, in een VARCHAR-kolom in plaats van een NVARCHAR-kolom. Dit is op zich geen probleem, maar kan in de loop van de tijd weergave-/conversieproblemen veroorzaken.
Over het algemeen zou u UTF-8-gegevens in NVARCHAR-kolommen willen laden.