Използване на nzload за зареждане на специални символи

Не съм много запознат с проблемите с конвертирането на Unicode, но съм си правил това преди и ще демонстрирам какво мисля, че се случва.

Вярвам, че това, което виждате тук, не е проблем със зареждането на специални знаци с nzload, а по-скоро е проблем с това как вашият дисплей/терминален софтуер показва данните и/или Netezza как съхранява данните за знаците. Подозирам двойно преобразуване към/от UTF-8 (кодирането Unicode, което Netezza поддържа). Да видим дали можем да познаем кое е.

Тук използвам PuTTY със стандартния (за мен) Remote Character Set като 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Â¿

Тук виждаме отод че файлът съдържа само данните, които очакваме, но когато кат файла виждаме допълнителния знак. Ако не е във файла, знакът вероятно идва от превода на дисплея.

Ако променя настройките на PuTTY, така че UTF-8 да бъде отдалеченият набор от знаци, ще го видим по следния начин:

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

И така, едни и същи изходни данни, но две различни представяния на екрана, които неслучайно са същите като вашите два различни изхода. Едни и същи данни могат да бъдат показани поне по два начина.

Сега нека видим как се зарежда в Netezza, веднъж в колона VARCHAR и отново в колона 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

Данните са заредени без грешки. Забележете, докато посочвам опцията за escapechar за nzload , нито един от символите в тази конкретна извадка от входни данни не изисква екраниране, нито се екранира.

Сега ще използвам функцията rawtohex от SQL Extension Toolkit като инструмент в базата данни, както използвахме od от командния ред.

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

В този момент и двете колони изглежда имат точно същите данни като входния файл. Дотук добре.

Ами ако изберем колоната? За протокола, правя това в PuTTY сесия с отдалечен набор от символи UTF-8.

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

Същите двоични данни, но различен дисплей. Ако след това копирам изхода на всеки от тези селекции в echo тръбопровод доот ,

$ 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

Въз основа на този резултат бих се обзаложил, че зареждате примерните си данни, които също бих се обзаложил, че са UTF-8, в колона VARCHAR, а не в колона NVARCHAR. Това само по себе си не е проблем, но може да има проблеми с показването/преобразуването надолу по линията.

Най-общо казано, бихте искали да заредите UTF-8 данни в NVARCHAR колони.