इंपोर्ट से पहले CSV से Windows-1251 और BOM की गड़बड़ी कैसे हटाएं

फाइल पूरी तरह ठीक दिख सकती है, फिर भी उसकी एनकोडिंग गलत हो सकती है

पुराने अकाउंटिंग या डेटाबेस सॉफ्टवेयर से एक्सपोर्ट की गई CSV फाइल अक्सर UTF-8 होती ही नहीं। सिरिलिक टेक्स्ट के लिए Windows-1251 और पश्चिमी यूरोप के एक्सेंट वाले अक्षरों के लिए Windows-1252, दोनों आज भी बरसों पहले बने सिस्टम से आमतौर पर निकलते हैं। स्प्रेडशीट प्रोग्राम ऐसी फाइल को अक्सर बिना शिकायत दिखा देता है, क्योंकि वह एनकोडिंग का अपना अंदाजा अपने आप लगा लेता है। इसलिए फाइल तब तक सामान्य दिखती है, जब तक उसे कोई कम लचीला प्रोग्राम न पढ़े, जैसे स्क्रिप्ट, इंपोर्ट पाइपलाइन या डेटाबेस लोडर। ऐसा प्रोग्राम UTF-8 मानकर चलता है, और उसे फाइल के असली टेक्स्ट की जगह बिगड़े अक्षरों की पूरी दीवार मिलती है।

फाइल की शुरुआत में तीन बाइट का निशान सख्त पार्सर को तोड़ सकता है

UTF-8 का बाइट ऑर्डर मार्क (BOM) एक अदृश्य निशान है, बस तीन बाइट का, जो फाइल की बिल्कुल शुरुआत में बैठकर बताता है कि आगे का टेक्स्ट Unicode है। Excel जैसे प्रोग्राम के लिए, जो इसे जांचता है, यह मददगार है। मुश्किल तब शुरू होती है, जब फाइल को किसी सख्त JSON इंपोर्टर या ऐसी स्क्रिप्ट में जाना हो, जो इसकी उम्मीद नहीं करती। ये फालतू बाइट पहले कॉलम के हेडर के पहले अक्षर से चिपक जाते हैं, इसलिए जिस कॉलम को “id” के नाम से पढ़ा जाना था, वह बाकी कोड में कहीं भी इस नाम से मेल नहीं खाता। कन्वर्जन से पहले इस निशान को पहचानकर हटा देना, न कि परिणाम वाली फाइल में छोड़ देना, ऐसी गड़बड़ी से बचाता है, जिसे बाद में ढूंढना उलझन भरा हो सकता है।

विकल्पों के मेन्यू के बिना, अपने आप सही एनकोडिंग

भरोसेमंद एनकोडिंग पहचान, जैसी CSV से JSON एक भी पंक्ति पढ़ने से पहले चलाता है, सबसे पहले बाइट ऑर्डर मार्क देखती है। फिर वह बाकी बाइट को सख्ती से UTF-8 के रूप में जांचने की कोशिश करती है, और यह सख्त जांच फेल होने पर ही Windows-1251 या Windows-1252 पर जाती है; दोनों में से कौन, यह इस पर तय होता है कि ऊंचे मान वाले बाइट फाइल में कैसे बंटे हैं। यह क्रम मायने रखता है। जो फाइल पहले से UTF-8 है, उस पर कभी शक करके उसे कुछ और समझकर गलत नहीं पढ़ा जाता। वहीं जो फाइल UTF-8 नहीं है, वह सही पहचानी जाती है, न कि जबरदस्ती UTF-8 मानकर रास्ते में बिगड़े अक्षरों में बदल दी जाती है। यही पहचान CSV से Excel में भी पहले चलती है, उन मामलों के लिए, जब फाइल को स्क्रिप्ट की जगह स्प्रेडशीट में जाना हो।

डेटा टाइप उतने ही जरूरी हैं, जितनी कैरेक्टर एनकोडिंग

सही कैरेक्टर एनकोडिंग CSV से JSON कन्वर्जन में टूटने वाली चीजों का सिर्फ आधा हिस्सा सुलझाती है। बाकी आधा यह तय करना है कि कौन-सी वैल्यू JSON नंबर या बूलियन बनें और कौन-सी सादा टेक्स्ट रहें। 00123 जैसी वैल्यू नंबर 123 बनते ही अपना शुरुआती शून्य हमेशा के लिए खो देती है, और लगभग पंद्रह अंकों से लंबा पहचान नंबर टेक्स्ट रहने की जगह सामान्य फ्लोटिंग-पॉइंट नंबर बनते ही राउंड ऑफ हो जाता है। दोनों को स्ट्रिंग ही रहने देना चाहिए, क्योंकि इन्हें कन्वर्ट करने से डेटा खुद बदल जाता है, सिर्फ उसकी फॉर्मेटिंग या रूप नहीं।

दोहराया गया हेडर इंपोर्ट को गलत एनकोडिंग से अलग तरीके से तोड़ सकता है

JSON ऑब्जेक्ट में एक ही नाम वाली दो प्रॉपर्टी नहीं हो सकतीं। इसलिए अगर मूल फाइल के दो कॉलम का हेडर एक जैसा है, जो एक से ज्यादा सिस्टम से जोड़े गए एक्सपोर्ट में कोई अनोखी बात नहीं, तो कन्वर्जन के दौरान इन डुप्लिकेट को अलग-अलग नाम देने पड़ते हैं। वरना हर बनने वाले ऑब्जेक्ट में दूसरे कॉलम का डेटा पहले कॉलम के डेटा पर लिख दिया जाता है, बिना किसी चेतावनी के। यह एनकोडिंग या टाइप से अलग तरह की गड़बड़ी है, पर यह भी इंपोर्ट को उतनी ही चुपचाप बिगाड़ सकती है। यह जांच लेना ठीक रहता है कि कन्वर्जन टूल ऐसा होने पर बताता है, न कि टकराव को चुपचाप सुलझा देता है, और परिणाम को JSON फॉर्मेटर में खोलने पर बदले गए नाम एक नजर में दिख जाते हैं।

चरण-दर-चरण: इंपोर्ट से पहले फाइल की जांच

एक्सपोर्ट को एक बार CSV से JSON में कन्वर्ट करें, डिलिमिटर (कॉलम अलग करने वाला चिह्न) और एनकोडिंग को ऑटोमैटिक पर छोड़कर। फिर दोनों अंदाजे जांचें: परिणाम को JSON फॉर्मेटर में भेजें, जो पेज के सुझाए अगले चरणों में से एक है, और पहले कुछ रिकॉर्ड पढ़ें। बिगड़े सिरिलिक अक्षर या टूटे एक्सेंट का मतलब है कि एनकोडिंग का अंदाजा गलत था; अगर रिकॉर्ड में एक ही लंबा नाम है, जिसके अंदर डिलिमिटर अब भी मौजूद हैं, तो गलती डिलिमिटर के अंदाजे में है। जो गलत है, उसे हाथ से सेट करें और फिर से कन्वर्ट करें: एनकोडिंग मेन्यू में Windows-1251, Windows-1252, BOM के साथ या उसके बिना UTF-8 और UTF-16 LE हैं, और डिलिमिटर मेन्यू में कॉमा, सेमीकोलन, टैब, पाइप या आपका अपना कोई कैरेक्टर। जिस फाइल का डिलिमिटर या एनकोडिंग बिल्कुल समझ में न आए, उसे बेतुके परिणाम में बदलने की जगह एक संदेश के साथ लौटा दिया जाता है।

इसके बाद तय करें कि वैल्यू किस टाइप में बदलें: डिफॉल्ट सेटिंग शुरुआती शून्य वाली वैल्यू और लंबे पहचान नंबर को पहले से ही टेक्स्ट रहने देती है, और अगर फाइल कोड, फोन नंबर या अकाउंट नंबर से बनी है, तो वैल्यू टाइप में सब कुछ टेक्स्ट रखने का विकल्प चुनने पर कुछ भी कन्वर्ट नहीं होता। जब परिणाम JSON फॉर्मेटर में खुला हो, तो गड़बड़ मूल फाइल के दो निशान खोजें: id हेडर वाले दो कॉलम id और id_2 बनकर निकलते हैं, और हेडर से ज्यादा फील्ड वाली पंक्ति अतिरिक्त फील्ड __extra नाम के तहत रखती है। दोनों को मूल फाइल में ठीक करना उस सिस्टम में ठीक करने से सस्ता है, जो बाद में इन पर अटक जाता। एक बैच में बीस फाइलें तक, कुल 300 MB तक, ब्राउजर टैब छोड़े बिना कन्वर्ट हो जाती हैं।