No soy muy hábil con los problemas de conversión de Unicode, pero me he hecho esto a mí mismo antes y demostraré lo que creo que está sucediendo.
Creo que lo que está viendo aquí no es un problema con la carga de caracteres especiales con nzload, sino un problema con la forma en que su software de pantalla/terminal muestra los datos y/o Netezza cómo almacena los datos de caracteres. Sospecho que hay una doble conversión a/desde UTF-8 (la codificación Unicode que admite Netezza). Veamos si podemos averiguar cuál es.
Aquí estoy usando PuTTY con el conjunto de caracteres remoto predeterminado (para mí) como 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¿
Aquí podemos ver desde od que el archivo tiene solo los datos que esperamos, sin embargo, cuando cat el archivo vemos el carácter extra. Si no está en el archivo, es probable que el carácter provenga de la traducción de la pantalla.
Si cambio la configuración de PuTTY para que UTF-8 sea el conjunto de caracteres remoto, lo vemos de esta manera:
$ 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¿
Por lo tanto, los mismos datos de origen, pero dos representaciones en pantalla diferentes, que son, no por casualidad, las mismas que sus dos salidas diferentes. Los mismos datos se pueden mostrar al menos de dos maneras.
Ahora veamos cómo se carga en Netezza, una vez en una columna VARCHAR y nuevamente en una columna 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
Los datos cargados sin errores. Tenga en cuenta mientras especifico la opción escapechar para nzload , ninguno de los caracteres en esta muestra específica de datos de entrada requiere escape, ni se escapan.
Ahora usaré la función rawtohex del SQL Extension Toolkit como una herramienta en la base de datos como hemos usado od desde la línea de comandos.
select rawtohex(col1) from test_enc_vchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
select rawtohex(col1) from test_enc_nvchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
En este punto, ambas columnas parecen tener exactamente los mismos datos que el archivo de entrada. Hasta ahora todo bien.
¿Y si seleccionamos la columna? Para que conste, estoy haciendo esto en una sesión de PuTTY con un juego de caracteres remoto de UTF-8.
select col1 from test_enc_vchar;
COL1
----------------
PROFESSIONAL¿
(1 row)
select col1 from test_enc_nvchar;
COL1
---------------
PROFESSIONAL¿
(1 row)
Los mismos datos binarios, pero diferente visualización. Si luego copio la salida de cada una de esas selecciones en echo conectado a 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
Según este resultado, apostaría a que está cargando sus datos de muestra, que también apostaría que son UTF-8, en una columna VARCHAR en lugar de una columna NVARCHAR. Esto no es, en sí mismo, un problema, pero puede tener problemas de visualización/conversión en el futuro.
En términos generales, le gustaría cargar datos UTF-8 en columnas NVARCHAR.
