JSON से CSV: हेडर कहाँ से आता है और वैल्यू क्यों बदलती हैं

जब JSON से CSV रूपांतरण डेटा खोता है, तो लगभग कभी भी वह "कन्वर्ज़न" चरण में नहीं होता। क्षति दो ऐसे सवालों में होती है जो किसी ने नहीं पूछे: हेडर किसने तय किया, और क्या हर सेल उस वैल्यू के रूप में पहचाना जाता है जो वह था?

तीस सेकंड में एक फील्ड गायब

बहुत से कन्वर्टर — मानक jq पाइपलाइन समेत — हेडर सिर्फ पहले रिकॉर्ड से लेते हैं। Python में परिणाम दोहराएँ:

复制data = [{"id": 1, "name": "A"}, {"id": 2, "email": "b@x.com"}]
first_keys = list(data[0].keys())          # ['id', 'name']
rows = [[r.get(k, "") for k in first_keys] for r in data]
# दूसरे रिकॉर्ड का email बिना एरर या चेतावनी गायब हो जाता है

email की हेडर में नहीं है: उसे खाली सेल बनने का हक भी नहीं — कॉलम कभी बना ही नहीं, और वैल्यू चुपचाप फेंक दी जाती है। समाधान है की यूनियन: सभी रिकॉर्ड पर जाएँ और जहाँ भी दिखने वाली हर की के लिए कॉलम बनाएँ। वही डेटा यूनियन से गुज़रने पर हेडर देता है id,name,email, जहाँ name अनुपस्थित है वहाँ खाली सेल — और कुछ भी नहीं खोता।

हमारे /convert/csv पेज का डायरेक्ट कन्वर्टर ठीक यही रणनीति लागू करता है। इनपुट [{"id":1,"name":"A"},{"id":2,"email":"b@x.com"}] पर वह देता है:

复制id,name,email
1,A,
2,,b@x.com

कीज़ पहली उपस्थिति के क्रम में लगाई जाती हैं और अनुपस्थित फील्ड खाली सेल बन जाते हैं। jsonoperations और jsonbeam दोनों इसे "क्लासिक बग का सुधार" कहती हैं — लेकिन "यूनियन इस्तेमाल करता है" कहानी का आधा हिस्सा ही है। यूनियन की अपनी कीमत है; वह अगला सेक्शन है।

हेडर बनाने के तीन तरीके — और किसके लिए कौन-सा

चुनाव का मापदंड "कौन ज़्यादा परिष्कृत है" नहीं, बल्कि ग्राहक इस CSV से क्या करेगा:

• झाँकने वाला सहकर्मी: पहले रिकॉर्ड की कीज़ काफी हैं, रिकॉर्ड के शेप आमतौर पर एकसार होते हैं।
• रिपोर्ट या डेटा पाइपलाइन: की यूनियन न्यूनतम शर्त है — खाली सेल खुद जानकारी है।
• आवर्ती ऑटो एक्सपोर्ट: स्पष्ट कॉलम सूची। शेप ड्रिफ्ट (ऊपर से नया फील्ड, की का नाम बदला) ज़ोर से विफल होगा, चुपचाप वैसी टेबल नहीं बनेगी जिसका गलत होना कोई नोटिस नहीं करता।

तीसरा विकल्प सबसे अनदेखा है। ऑटोमेशन में "कन्वर्ज़न सफल रहा" और "कन्वर्ज़न सही है" दो अलग बयान हैं — और स्पष्ट कॉलम सूची अकेली तंत्र है जो दोनों को अलग करती है।

जब की में डॉट हो, फ्लैटनिंग के पाथ टकराते हैं

डॉट नोटेशन में फ्लैटनिंग {"a": {"b": 2}} को a.b कॉलम बना देती है। लेकिन अगर की खुद में डॉट हो? pandas से परखा:

复制import pandas as pd
d = [{"a.b": 1, "a": {"b": 2}}]
pd.json_normalize(d, sep=".")
# सिर्फ एक कॉलम बचता है: ['a.b'] — दो पूरी तरह अलग कीज़ एक ही पाथ पर टकराती हैं

शाब्दिक की a.b और नेस्टेड पाथ a → b एक ही कॉलम नाम देते हैं, एक दूसरे को मिटा देता है, और डेटा चुपचाप बिगड़ जाता है। उदाहरण बनाया गया है, पर असली डेटा में भी होता है: मॉनिटरिंग मेट्रिक के नाम (cpu.usage) और लॉग फील्ड (error.type) डॉट से प्यार करते हैं।

दो उपाय:

1. सेपरेटर बदलें। sep="_" या अपना सेपरेटर — यह जाँचने के बाद कि मूल कीज़ कभी उसे नहीं रखतीं।
2. पाथ नोटेशन बदलें। JSON Pointer सेपरेटर के रूप में / इस्तेमाल करता है (/a/b); toolvore का Excel कन्वर्टर यही रास्ता लेता है। उसकी भी वही अस्पष्टता श्रेणी है — / वाली की ~1 लिखी जाती है — पर एस्केप नियम RFC 6901 में मानकीकृत हैं, हर टूल के अपने आविष्कार नहीं।

जो भी चुनें, नियम एक्सपोर्ट के दस्तावेज़ में लिखें। CSV हेडर ही वह अकेला "स्कीमा" है जो यह डेटा साथ रखता है; पाठक आपके फ्लैटनिंग नियम कहीं और नहीं मिलेंगे।

ऐरे: तीन रणनीतियाँ, हर एक अलग चीज़ खोती है

JSON से CSV के रास्ते में ऐरे ही असली बाधा हैं: एक सेल कई वैल्यू नहीं रख सकता। तीन रणनीतियाँ, व्यवहार में जाँचे गए नुकसान के साथ:

हमारे /convert/csv और /convert/table कन्वर्टर सेल में JSON इस्तेमाल करते हैं। इनपुट [{"orderId":"A001","items":[{"sku":"X1","qty":2},{"sku":"Y9","qty":1}]}] देता है:

复制orderId,items
A001,"[{""sku"":""X1"",""qty"":2},{""sku"":""Y9"",""qty"":1}]"

विस्फोटित रो चाहिए तो pandas record_path सीधे कर देता है:

复制orders = [{"orderId": "A001", "total": 99,
           "items": [{"sku": "X1", "qty": 2}, {"sku": "Y9", "qty": 1}]}]
items = pd.json_normalize(orders, record_path=["items"],
                          meta=["orderId", "total"], sep=".")
# दो डिटेल रो; हर एक में orderId और total डुप्लिकेट

विस्फोट में तीन जाल हैं जिन पर पहले फैसला चाहिए: कई ऐरे एक साथ फोड़ना कार्टेशियन प्रोडक्ट बनाता है; खाली ऐरे डिफ़ॉल्ट में कोई रो नहीं देते (आपकी ग्राहक सूची लोग खो देती है); और डुप्लिकेट पैरेंट फील्ड में डाउनस्ट्रीम पर orderId से एग्रीगेट करते समय डिडुप्लिकेशन चाहिए। convertcsvonline गाइड "पहले ग्रैन्युलैरिटी तय करें" इसी वजह से पहला कदम रखता है — ग्रैन्युलैरिटी तय होते ही तीनों सवालों का एक-एक जवाब होता है।

परखा गया: वैल्यू जो रूपांतरण से बदलकर निकलती हैं

हमारे असली कन्वर्टर पर फिडेलिटी टेस्ट (Node v22.13.1 + papaparse, /convert/csv वाली वही इम्प्लीमेंटेशन):

1. null, अनुपस्थिति और खाली स्ट्रिंग सभी खाली सेल बनते हैं। इनपुट [{"a":null},{"b":""},{"c":1}] — तीनों सेल खाली निकलते हैं। CSV के पास तीन अवस्थाएँ नहीं, सिर्फ "अक्षर हैं" और "अक्षर नहीं"। राउंड-ट्रिप के बाद तीनों "" पढ़े जाते हैं; मूल सिमेंटिक्स वापस नहीं आती।

2. नेस्टेड ऑब्जेक्ट और ऐरे JSON स्ट्रिंग बन जाते हैं। कोट्स RFC 4180 अनुसार दुगुने होते हैं ({""name"":""张三""}), और सेल को किसी भी JSON पार्सर में डालते ही वैल्यू लौटती है — इसीलिए सेल में JSON फिडेलिटी रखता है।

3. 20 अंकों का पूर्णांक पार्सिंग पर ही सटीकता खोता है — दोष CSV का नहीं। इनपुट "id": 9007199254740993; CSV में पहले से 9007199254740992। JavaScript का JSON.parse IEEE 754 double इस्तेमाल करता है: नुकसान पार्सिंग पर होता है, किसी भी CSV कन्वर्टर से पहले। Python json.load पूरा सुरक्षित रखता है। आईडी-जैसे फील्ड (snowflake ID, ऑर्डर नंबर) उत्पादक से ही स्ट्रिंग बनकर आने चाहिए। संख्या सटीकता पर और देखें बड़ी संख्याएँ सटीकता क्यों खोती हैं।

4. स्ट्रिंग के अग्र-शून्य CSV की टेक्स्ट परत पर सुरक्षित हैं। "phone": "00123" CSV में 00123 ही रहता है, क्योंकि शुरू से अंत तक वह स्ट्रिंग है और कुछ उसे खरोंच नहीं सकता। शून्य खरोंचते हैं बाद के चरण में, जब Excel सेल को संख्या मान लेता है — देखें JSON को Excel में बदलने के चार तरीके।

5. कॉमा, कोट या न्यूलाइन वाले फील्ड। papaparse RFC 4180 मानता है: फील्ड कोट करो, भीतरी कोट दुगुने करो। "He said \"hi\", ok" निकलता है "He said ""hi"", ok" बनकर और राउंड-ट्रिप अक्षत निकलता है। लाइब्रेरी टालकर हाथ से लिखे सीरियलाइज़र लगभग हमेशा ठीक वहीं टूटते हैं।

राउंड-ट्रिप: इनफ़रेंस स्विच क्या बदलता है

CSV → JSON को हर सेल का टाइप अनुमानित करना होता है। हमारा कन्वर्टर टाइप इनफ़रेंस डिफ़ॉल्ट रूप से बंद रखता है और सब स्ट्रिंग लौटाता है:

复制[{ "id": "9007199254740992", "phone": "00123" }]

typeInference चालू होने पर id संख्या बन जाता है (सटीकता तब खोई जा चुकी है), जबकि phone स्ट्रिंग रहता है — इनफ़रेंस नियम अग्र-शून्य रूपों जैसे 010 को बाहर करते हैं, जो वैध संख्या लिटरल नहीं, तो स्ट्रिंग किस्मत से बच जाता है।

यह असममिति याद रखें: इनफ़रेंस बंद सबसे बुरे में टाइप लेता है; इनफ़रेंस चालू डेटा ले सकता है। संख्या चाहने वाले कॉलम स्पष्ट कॉलम परिभाषाओं से बदलें, ग्लोबल इनफ़रेंस के भरोसे नहीं। हमारे पिछले लेख JSON, CSV और टैबुलर डेटा की rowsToRecords इम्प्लीमेंटेशन यही सिद्धांत कोड में है।

ग्राहक के अनुसार रणनीति: निर्णय तालिका

साझा नियम: इंसान जितना पास, उतनी ढील देने की गुंजाइश; मशीन जितना पास, उतना सब स्पष्ट होना चाहिए।

कॉपी करने योग्य चेकलिस्ट

• [ ] हेडर पूरी की यूनियन से आता है या स्पष्ट सूची से? नहीं तो, साबित कर सकते हैं कि किसी रिकॉर्ड ने फील्ड नहीं खोया?
• [ ] कीज़ में डॉट या स्लैश हो सकते हैं? फ्लैटनिंग सेपरेटर से टकराव जाँचा गया?
• [ ] ऐरे रणनीति डॉक्यूमेंटेड है? खाली ऐरे का व्यवहार तय है?
• [ ] null, अनुपस्थिति और खाली स्ट्रिंग के लिए ग्राहक क्या पढ़ेगा? एक नियम चुनकर स्थिर करें।
• [ ] आईडी-जैसे कॉलम (ID, ऑर्डर नंबर, फोन) शुरू से अंत तक स्ट्रिंग बनकर यात्रा करते हैं?
• [ ] विस्फोट के बाद रो संख्या ऐरे लंबाइयों के योग के बराबर? नमूने पर जाँचा?
• [ ] कॉमा, कोट और न्यूलाइन वाले नमूना फील्ड राउंड-ट्रिप अक्षत निकलते हैं?
• [ ] रीइम्पोर्ट पर ग्लोबल टाइप इनफ़रेंस बंद, संख्या कॉलम के लिए स्पष्ट परिभाषाएँ?

आठों के स्पष्ट उत्तर होने पर ही यह CSV "सही" है — केवल "सफलतापूर्वक बदला गया" नहीं।

FAQ

कन्वर्टर डिफ़ॉल्ट रूप से नेस्टेड ऑब्जेक्ट कॉलम में फ्लैट क्यों नहीं करता?

फ्लैटनिंग कॉलम संख्या को नियंत्रण से बाहर कर देती है: गहरा नेस्टिंग user.address.geo.lat जैसे नाम बनाता है, और की यूनियन के साथ मिलकर भिन्न शेप का एक ही रिकॉर्ड कॉलम का ढेर जोड़ देता है। सेल में JSON स्ट्रिंग फिडेलिटी और स्थिर कॉलम संख्या रखते हैं; ज़रूरत होने पर स्पष्ट रूप से फ्लैट करें।

हेडर में डुप्लिकेट कॉलम नाम हों तो क्या करें?

फ्लैटनिंग के बाद दो अलग कीज़ का टकराव (जैसे a.b बनाम नेस्टेड a→b) ऊपरी छोर पर ही हल करें: सेपरेटर बदलें या JSON Pointer पर जाएँ। एक ही ऑब्जेक्ट के भीतर डुप्लिकेट पर कन्वर्टर आमतौर पर आखिरी वैल्यू रखते हैं; हेडर के डुप्लिकेट इम्प्लीमेंटेशन पर निर्भर — papaparse का unparse डिडुप्लिकेट नहीं करता, Excel खोलते समय चुपचाप मर्ज या फेंक देता है। इसीलिए यह चेकलिस्ट में है।

विस्फोट के बाद डुप्लिकेट पैरेंट फील्ड बग है?

नहीं — यह डिज़ाइन है। विस्फोटित रो यानी डिटेल रो, और डिटेल रो की से पैरेंट रिकॉर्ड से दोबारा जुड़ सकना चाहिए। डाउनस्ट्रीम पर पैरेंट की से एग्रीगेट करें; आकार चिंता दे तो डिटेल फ़ाइल और अलग master टेबल एक्सपोर्ट करें।

कैसे जाँचूँ कि मेरे रूपांतरण में कोई फील्ड नहीं खोया?

की ऑडिट करें: मूल JSON की सभी कीज़ का यूनियन निकालें, फिर CSV के कॉलम हेडर का सेट, और अंतर निकालें। गैर-रिक्त अंतर का अर्थ खोए फील्ड। बैच पाइपलाइन में इसे टेस्ट में assert के रूप में कोड करें: फील्ड खोने लगने वाला कोई भी कन्वर्टर बदलाव स्वतः विफल होगा।