स्प्रेडशीट के CSV एक्सपोर्ट कन्वर्ट करने पर क्यों टूट जाते हैं

कोई CSV फ़ाइल देखने में उतनी ही सादी लगती है जितना कोई डेटा फ़ॉर्मेट हो सकता है — हर लाइन को कॉमा पर बाँटो, पहली लाइन को कॉलम हेडर मानो, बस हो गया — और यही दिखने वाली सादगी असल वजह है कि असली दुनिया का डेटा सामने आते ही इस फ़ॉर्मेट को ग़लत तरीक़े से संभालना कितना आसान हो जाता है। कॉमा पर सीधे बाँटने वाला सीधा-सादा तरीक़ा किसी नमूना उदाहरण पर बिल्कुल सही काम करता है और उसी पहली रो पर टूट जाता है जहाँ किसी असली डेटा वैल्यू में अपना ही एक कॉमा हो — जो कोई अपवाद नहीं, बल्कि एक आम बात है: "Main Street 123, फ़्लैट 4" जैसा कोई पता, या "शर्मा, गुप्ता एंड कंपनी" जैसा कोई कंपनी का नाम, या कोई प्रोडक्ट डिस्क्रिप्शन जिसमें इत्तेफ़ाक़ से कोई लिस्ट शामिल हो — ये सब बिल्कुल सामान्य वैल्यू हैं जिनमें जायज़ तौर पर ठीक वही कैरेक्टर मौजूद होता है जिसे कोई सीधा-सादा पार्सर फ़ील्ड सेपरेटर के तौर पर इस्तेमाल कर रहा है।

CSV की स्पेसिफ़िकेशन एम्बेडेड-कॉमा की समस्या को इस तरह हल करती है कि किसी फ़ील्ड को डबल कोट्स में लपेटने की इजाज़त देती है, जिसके अंदर कॉमा, यहाँ तक कि लाइन-ब्रेक भी, बस शाब्दिक डेटा होते हैं, कोई बनावट नहीं — `"शर्मा, गुप्ता एंड कंपनी"` जैसी कोई सही तरीक़े से कोटेड फ़ील्ड एक अकेली वैल्यू के तौर पर समझी जाती है जिसमें एक कॉमा शामिल है, न कि उस कॉमा पर बँटे दो अलग-अलग वैल्यू। कोई पार्सर जो यह ट्रैक किए बिना कि वह इस वक़्त किसी कोटेड फ़ील्ड के अंदर है या नहीं, हर कॉमा पर सीधे बाँट देता है, इस फ़र्क़ को समझ ही नहीं सकता, और चुपचाप उस एक कंपनी के नाम को दो झूठे कॉलम में बाँट देता है — आमतौर पर बिना किसी एरर के, और यही बात इस तरह की गड़बड़ी को ख़तरनाक बनाती है: कन्वर्ज़न सफल दिखती है, और यह गड़बड़ी बाद में ही पता चलती है, अक्सर तब जब वह बिगड़ा हुआ डेटा पहले से ही किसी काम में इस्तेमाल हो चुका होता है।

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

किसी कच्ची CSV फ़ाइल में हर अकेली वैल्यू प्लेन टेक्स्ट के रूप में स्टोर होती है, और यह बताने का कोई बिल्ट-इन तरीक़ा नहीं होता कि कोई दी गई वैल्यू "असल में" कोई नंबर है, कोई बूलियन है, या बस एक स्ट्रिंग है जो इत्तेफ़ाक़ से नंबर जैसी दिखती है — यह उसी पल एक असली समस्या बन जाती है जब कोई कन्वर्टर टाइप का अपने-आप अनुमान लगाकर मददगार बनने की कोशिश करता है। "007" जैसे किसी पिन कोड या "042" जैसी किसी ID में शुरुआती ज़ीरो का अर्थपूर्ण मतलब होता है — यह एक तय-चौड़ाई वाला पहचान-नंबर है, और "7" व "007" एक ही संख्या दिखाने के बावजूद अलग-अलग पहचान-नंबर हैं — लेकिन कोई कन्वर्टर जो नंबर जैसी दिखने वाली स्ट्रिंग को उत्साह से असली नंबर में बदल देता है, वह चुपचाप उस शुरुआती ज़ीरो को गिरा देता है, क्योंकि संख्या 7 को इस बात का कोई अंदाज़ा ही नहीं होता कि पहले उसके आगे कितने ज़ीरो लगे थे। "+91 98765 43210" जैसा कोई फ़ोन नंबर आंशिक रूप से नंबर जैसा दिखता है लेकिन है बिल्कुल भी अंकगणितीय डेटा नहीं, और इसे किसी नंबर में बदलने से कुछ ऐसा बनता है जिसका वाक़ई कोई मतलब नहीं रहता। सुरक्षित, सही डिफ़ॉल्ट यह है कि अस्पष्ट वैल्यू को टेक्स्ट ही रहने दिया जाए जब तक कि कोई वैल्यू बेशक़ और सुरक्षित रूप से नंबर न हो, क्योंकि यहाँ ग़लत अंदाज़ा लगाना डेटा को चुपचाप बिगाड़ देता है, न कि कोई दिखने वाला, पकड़ में आने वाला एरर देता है।

CSV फ़ॉर्मेट के अपने असली एज-केस से आगे, Microsoft Excel एक अतिरिक्त घर्षण जोड़ देता है जिसका CSV स्पेसिफ़िकेशन से कोई लेना-देना नहीं है: कई क्षेत्रीय Excel कॉन्फ़िगरेशन डिफ़ॉल्ट रूप से फ़ील्ड डिलिमिटर के तौर पर कॉमा की बजाय सेमीकोलन इस्तेमाल करते हैं, क्योंकि उन लोकेल में कॉमा पहले से ही दशमलव सेपरेटर के तौर पर इस्तेमाल हो रहा होता है, जिसका मतलब है कि उन Excel कॉन्फ़िगरेशन में से किसी एक से एक्सपोर्ट की गई CSV फ़ाइल किसी कॉमा-डिलिमिटेड पार्सर से बिल्कुल सही पार्स नहीं होगी। Excel की एक और जानी-पहचानी आदत है कि जब कोई CSV फ़ाइल देखने के लिए खोली जाती है तो यह उन वैल्यू को अपने-आप दोबारा फ़ॉर्मेट कर देता है जिन्हें वह पहचानता समझता है — जैसे किसी लंबे न्यूमेरिक ID को साइंटिफ़िक नोटेशन में बदल देना — जो असल में Excel की तरफ़ से देखने के वक़्त की ग़लतफ़हमी है, न कि अंतर्निहित CSV फ़ाइल की कोई ख़ामी, लेकिन इसे अक्सर एक्सपोर्ट में ही हुई असली डेटा करप्शन समझ लिया जाता है।