मैं यूनिकोड रूपांतरण के मुद्दों के बारे में बहुत जानकार नहीं हूं, लेकिन मैंने इसे पहले खुद से किया है, और जो मुझे लगता है कि हो रहा है, मैं उसे प्रदर्शित करूंगा।
मेरा मानना है कि आप यहां जो देख रहे हैं वह nzload के साथ विशेष वर्ण लोड करने में कोई समस्या नहीं है, बल्कि यह एक मुद्दा है कि आपका डिस्प्ले/टर्मिनल सॉफ़्टवेयर डेटा कैसे प्रदर्शित करता है और/या Netezza वर्ण डेटा को कैसे संग्रहीत कर रहा है। मुझे UTF-8 (यूनिकोड एन्कोडिंग जो Netezza का समर्थन करता है) से/से दोहरे रूपांतरण पर संदेह है। आइए देखें कि क्या हम यह पता लगा सकते हैं कि यह कौन सा है।
यहां मैं डिफ़ॉल्ट (मेरे लिए) रिमोट कैरेक्टर सेट लैटिन -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¿
यहां हम od . से देख सकते हैं फ़ाइल में केवल वही डेटा है जिसकी हम अपेक्षा करते हैं, हालांकि जब हम बिल्ली फ़ाइल में हम अतिरिक्त वर्ण देखते हैं। यदि यह फ़ाइल में नहीं है, तो वर्ण प्रदर्शन अनुवाद से आने की संभावना है।
अगर मैं यूटीएफ -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
डेटा बिना किसी त्रुटि के लोड किया गया। ध्यान दें जब मैं nzload . के लिए एस्केपचर विकल्प निर्दिष्ट करता हूं , इनपुट डेटा के इस विशिष्ट नमूने के किसी भी वर्ण से बचने की आवश्यकता नहीं है, न ही वे बच निकले हैं।
अब मैं SQL एक्सटेंशन टूलकिट से रॉटोहेक्स फ़ंक्शन का उपयोग इन-डेटाबेस टूल के रूप में करूंगा जैसे हमने od का उपयोग किया है कमांड लाइन से।
select rawtohex(col1) from test_enc_vchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
select rawtohex(col1) from test_enc_nvchar;
RAWTOHEX
------------------------------
50524F46455353494F4E414CC2BF
(1 row)
इस बिंदु पर दोनों स्तंभों में इनपुट फ़ाइल के समान ही डेटा प्रतीत होता है। अब तक, बहुत अच्छा।
क्या होगा अगर हम कॉलम का चयन करें? रिकॉर्ड के लिए, मैं इसे यूटीएफ -8 के रिमोट कैरेक्टर सेट के साथ पुटी सत्र में कर रहा हूं।
select col1 from test_enc_vchar;
COL1
----------------
PROFESSIONAL¿
(1 row)
select col1 from test_enc_nvchar;
COL1
---------------
PROFESSIONAL¿
(1 row)
वही बाइनरी डेटा, लेकिन अलग डिस्प्ले। अगर मैं उनमें से प्रत्येक के आउटपुट को echo . में कॉपी करता हूं 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
इस आउटपुट के आधार पर, मैं शर्त लगाता हूं कि आप अपना नमूना डेटा लोड कर रहे हैं, जिसे मैं यूटीएफ -8 भी दांव पर लगाऊंगा, एक NVARCHAR कॉलम के बजाय एक VARCHAR कॉलम में। यह अपने आप में कोई समस्या नहीं है, लेकिन लाइन के नीचे प्रदर्शन/रूपांतरण समस्याएं हो सकती हैं।
सामान्यतया, आप UTF-8 डेटा को NVARCHAR कॉलम में लोड करना चाहेंगे।
