CSV से Excel और वापस: डेटा बिगाड़े बिना कैसे कन्वर्ट करें

सेपरेटर की गड़बड़ी फाइल खुलने से पहले ही शुरू हो जाती है

CSV को कॉलम में कैसे बांटना है, यह Excel फाइल को देखकर तय नहीं करता। वह आपके ऑपरेटिंग सिस्टम की रीजनल सेटिंग में तय लिस्ट सेपरेटर इस्तेमाल करता है। यूरोप की किसी रीजनल सेटिंग वाले कंप्यूटर में यह सेपरेटर डिफॉल्ट रूप से सेमीकोलन होता है, इसलिए कॉमा से अलग किया गया आम एक्सपोर्ट बिना बंटे टेक्स्ट के एक ही कॉलम में आ जाता है। अमेरिका की सेटिंग वाले कंप्यूटर पर सेमीकोलन वाली फाइल के साथ उल्टा होता है। दोनों ही मामलों में फाइल खराब नहीं है। बस Excel ने ऐसी सेटिंग से अंदाजा लगाया, जिनका इससे कोई लेना-देना नहीं कि फाइल कैसे लिखी गई थी। “CSV से Excel” जैसा कन्वर्टर फाइल को कई संभावित सेपरेटर से पढ़कर देखता है और जांचता है कि किस सेपरेटर से सैंपल की सभी लाइनों में फील्ड की संख्या एक जैसी आती है। इस तरह वह अंदाजे से पूरी तरह बच जाता है और न फाइल के एक्सटेंशन पर भरोसा करता है, न सिस्टम की सेटिंग पर।

आगे के जीरो और लंबे नंबर चुपचाप बिगड़ते हैं

CSV को Excel में कन्वर्ट करते समय सबसे ज्यादा नुकसान तब होता है, जब टेक्स्ट को नंबर में बदलने की जल्दबाजी की जाती है। 00123 लिखा प्रोडक्ट कोड उसी पल नंबर 123 बन जाता है, जब स्प्रेडशीट तय करती है कि यह नंबर जैसा दिखता है, और आगे का वह जीरो बाद में वापस नहीं मिलता। वह बस गायब हो जाता है। लंबे पहचान नंबर अलग तरह से बिगड़ते हैं। 16 अंकों वाले कार्ड या बारकोड नंबर के आखिरी कुछ अंक बिना किसी चेतावनी के खो जाते हैं, क्योंकि स्प्रेडशीट के आम नंबर राउंडिंग के बिना लगभग 15 सार्थक अंकों से ज्यादा नहीं रख सकते। इन दोनों को कन्वर्ट करने के बजाय टेक्स्ट ही रहना चाहिए। यही नियम तब भी लागू होता है, जब फाइल Excel में नहीं, किसी प्रोग्राम में जानी हो: “CSV से JSON” इन्हें स्ट्रिंग के रूप में रखता है। जो वैल्यू सच में नंबर हैं, जैसे मात्रा, कीमत और कुल योग, उन्हें फिर भी आम तरीके से कन्वर्ट होना चाहिए, ताकि उन्हें जोड़ा जा सके और उन पर हिसाब लगाया जा सके।

दूसरी भाषाओं का डेटा एनकोडिंग की वजह से बिगड़ता है

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

बाइट ऑर्डर मार्क खुद भी चुपचाप नुकसान कर सकता है

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

वापस CSV में बदलते समय अलग फैसले लेने पड़ते हैं

“Excel से CSV” से स्प्रेडशीट को वापस CSV में बदलते समय एक ऐसा सवाल उठता है, जो उल्टी दिशा में कभी नहीं उठता। फॉर्मूले वाली सेल की दो वैल्यू होती हैं: खुद फॉर्मूले का टेक्स्ट और वह नंबर, जो पिछली बार हिसाब लगाने पर निकला था। CSV फाइल एक बार में इनमें से सिर्फ एक ही रख सकती है। ज्यादातर सिस्टम इंपोर्ट के लिए हिसाब से निकली वैल्यू की उम्मीद करते हैं। फाइल की जांच करने वाला इंसान फॉर्मूले का टेक्स्ट पढ़ना चाहता है। तारीखों पर भी इतना ही साफ ध्यान देना चाहिए। उन्हें एक तय, चुने हुए फॉर्मेट में लिखें, न कि उस रूप में जो स्प्रेडशीट उस समय दिखा रही थी। तब एक ही फाइल की तारीखें इस बात पर निर्भर नहीं करेंगी कि फॉर्मेटिंग किस कंप्यूटर की रीजनल सेटिंग ने की, और हर जगह एक जैसी दिखेंगी।

आम गलतियां और हर एक से बचाने वाली सेटिंग

पहली गलती: डेसिमल सेपरेटर को डॉट पर छोड़ देना। जिस देश में डेढ़ को 1,50 लिखा जाता है, वहां के सेमीकोलन वाले एक्सपोर्ट के लिए “CSV से Excel” में “डेसिमल सेपरेटर” को “कॉमा” पर सेट करना होगा, वरना हर कीमत स्ट्रिंग ही रहती है और जोड़ी नहीं जा सकती। दूसरी गलती: पहचान नंबरों के लिए अपने आप टाइप पहचानने पर भरोसा करना। यह आगे के जीरो और 15 अंकों से लंबे नंबरों को बचा लेता है, लेकिन बिना आगे के जीरो वाला ऑर्डर नंबर या पिन कोड फिर भी नंबर बन जाता है। जब किसी कॉलम में हिसाब की जरूरत न हो, तो “सेल टाइप” को “सब कुछ टेक्स्ट के रूप में” पर रखने से हर वैल्यू ठीक वैसी रहती है, जैसी लिखी गई थी। तीसरी गलती: दसियों लाख पंक्तियों वाले एक्सपोर्ट को एक ही वर्कबुक में ठूंसना। XLSX 10,48,576 पंक्तियों पर रुक जाता है, इसलिए इससे लंबी CSV फाइल बिना बताए काटी नहीं जाती, बल्कि “CSV स्प्लिट करें” के लिंक के साथ लौटा दी जाती है।

वापस CSV बनाते समय “Excel से CSV” की तीन डिफॉल्ट सेटिंग को उस प्रोग्राम से मिलाकर देखें, जो फाइल को आगे पढ़ेगा। “आउटपुट एनकोडिंग” में BOM के साथ UTF-8 है, यानी वह रूप जो Excel को चाहिए; स्क्रिप्ट या डेटाबेस लोडर को आमतौर पर सादा UTF-8 चाहिए। “तारीख का फॉर्मेट” ISO 8601 है, इसलिए 14 मार्च 2026 हर कंप्यूटर पर 2026-03-14 बनती है; दूसरे विकल्प हैं 14.03.2026, 03/14/2026 और Excel का सीरियल नंबर। “लाइन एंडिंग” में Windows के लिए CRLF है, और Unix टूल के लिए LF चुन सकते हैं। चौथी सेटिंग अक्सर नजर से छूट जाती है: डिफॉल्ट रूप से सिर्फ पहली शीट एक्सपोर्ट होती है, इसलिए जिस वर्कबुक में दूसरी शीट भी है, उसके लिए “सभी शीट” चुनें। तब हर शीट की एक CSV फाइल वाला ZIP मिलता है।