Não sou muito experiente com problemas de conversão de Unicode, mas já fiz isso comigo antes e vou demonstrar o que acho que está acontecendo.
Acredito que o que você está vendo aqui não é um problema com o carregamento de caracteres especiais com o nzload, mas sim um problema com a forma como o software de exibição/terminal exibe os dados e/ou Netezza como está armazenando os dados de caracteres. Suspeito de uma dupla conversão de/para UTF-8 (a codificação Unicode que o Netezza suporta). Vamos ver se conseguimos descobrir qual é.
Aqui estou usando o PuTTY com o conjunto de caracteres remoto padrão (para mim) 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¿
Aqui podemos ver de od que o arquivo tem apenas os dados que esperamos, no entanto, quando cat o arquivo, vemos o caractere extra. Se não estiver no arquivo, o caractere provavelmente vem da tradução de exibição.
Se eu alterar as configurações do PuTTY para que o UTF-8 seja o conjunto de caracteres remoto, veremos desta forma:
$ 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¿
Portanto, os mesmos dados de origem, mas duas representações diferentes na tela, que são, não coincidentemente, iguais às suas duas saídas diferentes. Os mesmos dados podem ser exibidos pelo menos de duas maneiras.
Agora vamos ver como ele é carregado no Netezza, uma vez em uma coluna VARCHAR e novamente em uma coluna 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
Os dados carregados sem erros. Observe enquanto eu especifico a opção escapechar para nzload , nenhum dos caracteres nesta amostra específica de dados de entrada requer escape, nem são escapados.
Agora vou usar a função rawtohex do SQL Extension Toolkit como uma ferramenta no banco de dados, como usamos od da linha de comando.
select rawtohex(col1) from test_enc_vchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
select rawtohex(col1) from test_enc_nvchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
Neste ponto, ambas as colunas parecem ter exatamente os mesmos dados que o arquivo de entrada. Até agora tudo bem.
E se selecionarmos a coluna? Para constar, estou fazendo isso em uma sessão PuTTY com o conjunto de caracteres remoto UTF-8.
select col1 from test_enc_vchar;
COL1
----------------
PROFESSIONAL¿
(1 row)
select col1 from test_enc_nvchar;
COL1
---------------
PROFESSIONAL¿
(1 row)
Mesmos dados binários, mas exibição diferente. Se eu copiar a saída de cada uma dessas seleções em echo canalizado para 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
Com base nessa saída, aposto que você está carregando seus dados de amostra, que também aposto que são UTF-8, em uma coluna VARCHAR em vez de uma coluna NVARCHAR. Isso não é, por si só, um problema, mas pode ter problemas de exibição/conversão no futuro.
De um modo geral, você deseja carregar dados UTF-8 em colunas NVARCHAR.
