Excel आपकी CSV क्यों बिगाड़ता है
पिनकोड का शुरुआती ज़ीरो ग़ायब हो जाता है, प्रोडक्ट कोड तारीख़ बन जाते हैं, और लंबे आइडेंटिफ़ायर चुपचाप राउंड हो जाते हैं। यह फ़ाइल खोलते समय होता है, सेव करते समय नहीं — इसीलिए इतने लोग कभी समझ ही नहीं पाते कि गड़बड़ कहां हुई।
आख़िरी समीक्षा
नुक़सान फ़ाइल खोलते ही हो जाता है
यही हिस्सा इस समस्या को पकड़ना इतना मुश्किल बनाता है। CSV एक टेक्स्ट फ़ाइल है: उसकी हर वैल्यू बस कैरेक्टर है, और फ़ाइल में कहीं नहीं लिखा कि उनमें से किसी का मतलब क्या है। Excel जब इसे खोलता है तो हर कॉलम का टाइप अंदाज़े से तय करता है, वैल्यू को उसी हिसाब से बदल देता है, और उसी पल से बदला हुआ वर्शन रखता है। फ़ाइल सेव करते ही वे बदलाव वापस लिख दिए जाते हैं।
यानी फ़ाइल ठीक थी, आपकी सेव की हुई फ़ाइल ठीक नहीं है, और किसी भी मोड़ पर आपको चेतावनी नहीं मिली। लोग मान लेते हैं कि एक्सपोर्ट ख़राब था, दोबारा एक्सपोर्ट करते हैं, और वही नतीजा पाते हैं — क्योंकि गड़बड़ी डाउनलोड के बाद उनकी अपनी मशीन पर हो रही है।
वे चार बदलाव जिनसे नुक़सान होता है
शुरुआती ज़ीरो हटा दिए जाते हैं। 01234 जैसा पोस्टकोड, फ़्रांस का डिपार्टमेंट कोड, अकाउंट नंबर, ज़ीरो से शुरू होने वाला फ़ोन नंबर — सब नंबर जैसे दिखते हैं, इसलिए ज़ीरो को बेमतलब मानकर हटा दिया जाता है। वह बेमतलब नहीं है; वह आइडेंटिफ़ायर का हिस्सा है।
लंबे नंबर राउंड हो जाते हैं। स्प्रेडशीट नंबरों को फ़्लोटिंग पॉइंट में लगभग पंद्रह सार्थक अंकों तक रखती है, इसलिए ऑर्डर रेफ़रेंस, क्रेडिट कार्ड नंबर, IMEI या 64-बिट आइडेंटिफ़ायर चुपचाप राउंड हो जाता है — आख़िरी अंक ज़ीरो बन जाते हैं। सेल नंबर जैसी दिखती है, पर नंबर ग़लत होता है।
जो कुछ भी तारीख़ जैसा दिखे, उसका फ़ॉर्मैट बदल दिया जाता है, स्थानीय तरीक़े के हिसाब से। 03/05 एक देश में मार्च है और दूसरे में मई, इसलिए एक ही फ़ाइल दो दफ़्तरों में खोलने पर दो अलग डेटासेट बनते हैं। इससे भी बुरा, जो वैल्यू कभी तारीख़ थीं ही नहीं वे भी बदल जाती हैं: SEPT1 जैसा जीन का नाम तारीख़ बन जाता है — यह समस्या इतनी ज़िद्दी रही कि आख़िरकार जेनेटिसिस्ट ने इससे लड़ते रहने की बजाय जीन के नाम ही बदल दिए।
ऐक्सेंट वाले अक्षर अजीब चिह्नों (mojibake) में बदल जाते हैं। CSV में उसकी कैरेक्टर एन्कोडिंग का कोई रिकॉर्ड नहीं होता, इसलिए UTF-8 में सेव की गई फ़ाइल अगर पुराने कोड पेज के रूप में पढ़ी जाए — या उल्टा — तो ठीक वही पंक्तियां बिगड़ती हैं जिनमें ऐक्सेंट वाले नाम हैं।
हल: खोलें नहीं, इम्पोर्ट करें
जिस CSV की आपको परवाह है, उस पर कभी डबल-क्लिक न करें। डबल-क्लिक करना Excel को अंदाज़ा लगाने की इजाज़त देना है, और वह पूरे भरोसे से अंदाज़ा लगाता है।
इसकी जगह Data → From Text/CSV इस्तेमाल करें। इम्पोर्ट डायलॉग में आप कुछ भी पार्स होने से पहले हर कॉलम का टाइप तय कर सकते हैं — पोस्टकोड वाले और आइडेंटिफ़ायर वाले कॉलम को Text चुनें, और वे बिल्कुल वैसे ही आएंगे जैसे फ़ाइल में हैं। इसमें आप एन्कोडिंग और डिलिमिटर भी ख़ुद बता सकते हैं, अंदाज़े पर छोड़ने की बजाय। इसमें बीस सेकंड लगते हैं और पूरा हल यही है।
Google Sheets में भी यही लागू होता है: File → Import, और “Convert text to numbers, dates and formulas” बंद कर दें। LibreOffice Calc डिफ़ॉल्ट रूप से कॉलम-टाइप डायलॉग दिखाता है — यह उन गिने-चुने मामलों में से है जहां उसका बर्ताव सीधे-सीधे बेहतर है।
इम्पोर्ट से पहले जांचें
जब कुछ पहले ही बिगड़ चुका हो, तो सबसे काम का पहला क़दम है फ़ाइल को किसी स्प्रेडशीट के छुए बिना देखना। CSV देखने पर वैल्यू ठीक वैसी दिखती हैं जैसी बाइट्स में हैं — शुरुआती ज़ीरो मौजूद, लंबे नंबर पूरे, तारीख़ें उसी टेक्स्ट के रूप में जैसे लिखी गई थीं। इससे तुरंत पता चल जाता है कि एक्सपोर्ट ग़लत था या इम्पोर्ट।
इससे वे दो बातें भी दिखती हैं जो CSV अपने बारे में कभी नहीं बताती: डिलिमिटर — कॉमा, सेमीकॉलन या टैब; यूरोपीय लोकेल सेमीकॉलन से एक्सपोर्ट करते हैं क्योंकि वहां कॉमा दशमलव का चिह्न है — और एन्कोडिंग। इम्पोर्ट से पहले दोनों पता हों तो बाक़ी ज़्यादातर अंदाज़ेबाज़ी ख़त्म हो जाती है।
अगर CSV आप बना रहे हैं
एक्सपोर्ट करते समय लिए गए कुछ फ़ैसले आगे की ये सारी दिक़्क़तें रोक देते हैं।
बाइट ऑर्डर मार्क (BOM) के साथ UTF-8 लिखें, अगर फ़ाइल Windows पर Excel में खुलनी है। Excel UTF-8 पहचानने के लिए इसी मार्क का इस्तेमाल करता है और इसके बिना ऐक्सेंट वाले अक्षर बिगाड़ देता है — यह उन कम मामलों में से है जहां BOM जोड़ना सिरदर्द नहीं, सही फ़ैसला है।
हर वह फ़ील्ड कोट करें जो ग़लत पढ़ा जा सकता है, और आइडेंटिफ़ायर वाले कॉलम हमेशा। कोट करने से Excel खोलते समय बदलाव करना बंद नहीं करता, पर हर दूसरे प्रोग्राम के लिए इरादा बिल्कुल साफ़ हो जाता है।
CSV इस्तेमाल न करने पर भी सोचें। अगर पाने वाला JSON या असली स्प्रेडशीट ले सकता है, तो दोनों में टाइप साफ़-साफ़ दर्ज होते हैं और इनमें से कोई भी गड़बड़ी नहीं होती। CSV की ख़ूबी यह है कि उसे हर प्रोग्राम पढ़ लेता है; कमज़ोरी यह कि कोई इस पर सहमत नहीं कि उसमें लिखा क्या है।
अक्सर पूछे जाने वाले सवाल
क्या सेव करने के बाद नुक़सान वापस ठीक हो सकता है?
भरोसे के साथ नहीं। हटाया गया शुरुआती ज़ीरो और राउंड हुआ अंक चले गए — फ़ाइल में ऐसा कुछ नहीं बचा जिससे उन्हें वापस लाया जा सके। ओरिजिनल सोर्स से दोबारा एक्सपोर्ट करें; इसीलिए सोर्स एक्सपोर्ट को बिना छुए रखना डिस्क की जगह के लायक है।
मेरी CSV एक ही लंबे कॉलम में क्यों खुलती है?
डिलिमिटर वह नहीं है जिसकी स्प्रेडशीट उम्मीद कर रही है — आम तौर पर सेमीकॉलन वाली फ़ाइल कॉमा वाले लोकेल में खोली गई होती है, या उल्टा। इम्पोर्ट डायलॉग में आप इसे ख़ुद बता सकते हैं, जो सिस्टम की रीजनल सेटिंग्स बदलने से ज़्यादा तेज़ है।
मेरे पहले कॉलम के नाम की शुरुआत में यह अजीब-सा कैरेक्टर क्या है?
बाइट ऑर्डर मार्क, जिसे एन्कोडिंग के संकेत की बजाय टेक्स्ट के रूप में पढ़ लिया गया। यह वही मार्क है जो Excel में ऐक्सेंट वाले अक्षर ठीक करता है, इसीलिए यह काम का भी है और खीझ दिलाने वाला भी — ज़्यादातर सही CSV पार्सर इसे अपने-आप हटा देते हैं।
क्या CSV का कोई स्टैंडर्ड है?
बस 2005 का एक सलाहकारी स्पेसिफ़िकेशन, जो बताता है कि ज़्यादातर टूल क्या करते हैं — और ढेरों सॉफ़्टवेयर कुछ और करते हैं। इसीलिए डिलिमिटर, कोटिंग, लाइन एंडिंग और एन्कोडिंग सब अलग-अलग होते हैं — और इसीलिए असली फ़ाइलों पर सिर्फ़ वही तरीक़ा काम करता है जो इन्हें मान लेने की बजाय पहचानता है।
मेरे टेक्स्ट एडिटर में एक पंक्ति कई लाइनों में क्यों टूट जाती है?
क्योंकि कोट किए गए फ़ील्ड में नियम के मुताबिक़ लाइन ब्रेक हो सकते हैं — आम तौर पर पते वाले फ़ील्ड में। रिकॉर्ड फिर भी एक ही पंक्ति है; जो भी चीज़ फ़ाइल को नई लाइन पर बांटेगी, वह ठीक इन्हीं पंक्तियों को बिगाड़ देगी — इसीलिए कॉमा या नई लाइन पर बांटना CSV पढ़ने का ग़लत तरीक़ा है।