Ich bin nicht sehr versiert in Unicode-Konvertierungsproblemen, aber ich habe das schon einmal bei mir selbst gemacht, und ich werde demonstrieren, was meiner Meinung nach passiert.
Ich glaube, was Sie hier sehen, ist kein Problem beim Laden von Sonderzeichen mit nzload, sondern ein Problem damit, wie Ihre Anzeige-/Terminalsoftware die Daten anzeigt und/oder wie Netezza die Zeichendaten speichert. Ich vermute eine doppelte Konvertierung nach/von UTF-8 (die von Netezza unterstützte Unicode-Codierung). Mal sehen, ob wir herausfinden können, was es ist.
Hier verwende ich PuTTY mit dem Standard-Remote-Zeichensatz (für mich) 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 können wir von od sehen dass die Datei nur die Daten enthält, die wir erwarten, aber wenn wir cat die Datei sehen wir das zusätzliche Zeichen. Wenn es nicht in der Datei enthalten ist, stammt das Zeichen wahrscheinlich aus der Anzeigeübersetzung.
Wenn ich die PuTTY-Einstellungen so ändere, dass UTF-8 der entfernte Zeichensatz ist, sehen wir es so:
$ 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¿
Also dieselben Quelldaten, aber zwei unterschiedliche Bildschirmdarstellungen, die nicht zufällig mit Ihren beiden unterschiedlichen Ausgaben identisch sind. Dieselben Daten können auf mindestens zwei Arten angezeigt werden.
Sehen wir uns nun an, wie es in Netezza geladen wird, einmal in eine VARCHAR-Spalte und wieder in eine NVARCHAR-Spalte.
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
Die Daten wurden ohne Fehler geladen. Beachten Sie, während ich die Option escapechar für nzload spezifiziere , keines der Zeichen in diesem speziellen Beispiel von Eingabedaten muss mit Escapezeichen versehen werden, noch werden sie mit Escapezeichen versehen.
Ich werde jetzt die rawtohex-Funktion aus dem SQL Extension Toolkit als datenbankinternes Tool verwenden, so wie wir od verwendet haben von der Kommandozeile.
select rawtohex(col1) from test_enc_vchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
select rawtohex(col1) from test_enc_nvchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
An diesem Punkt scheinen beide Spalten genau die gleichen Daten wie die Eingabedatei zu haben. So weit, so gut.
Was ist, wenn wir die Spalte auswählen? Fürs Protokoll:Ich mache das in einer PuTTY-Sitzung mit dem Remote-Zeichensatz UTF-8.
select col1 from test_enc_vchar;
COL1
----------------
PROFESSIONAL¿
(1 row)
select col1 from test_enc_nvchar;
COL1
---------------
PROFESSIONAL¿
(1 row)
Gleiche Binärdaten, aber unterschiedliche Anzeige. Wenn ich dann die Ausgabe jeder dieser Auswahlen in echo kopiere an od geleitet ,
$ 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
Basierend auf dieser Ausgabe würde ich wetten, dass Sie Ihre Beispieldaten, von denen ich auch wetten würde, dass sie UTF-8 sind, in eine VARCHAR-Spalte und nicht in eine NVARCHAR-Spalte laden. Dies ist an sich kein Problem, kann aber später zu Anzeige-/Konvertierungsproblemen führen.
Im Allgemeinen möchten Sie UTF-8-Daten in NVARCHAR-Spalten laden.
