JSON और CSV: डेटा का अर्थ बचाकर उसे दूसरे रूप में ले जाएं
सफल रूपांतरण केवल खुलने वाली फाइल नहीं है। उत्पाद की पहचान पहचान ही रहे, कीमत कीमत रहे और अनुपस्थित डेटा अनुपस्थित रहे। प्रकार और संरचना की गलतियां बिना त्रुटि संदेश के गुजर सकती हैं।
साधारण पंक्तियां या नेस्टेड डेटा?
CSV पंक्तियों और फील्ड वाली तालिका के लिए उपयोगी है। JSON प्रकार वाले मान, सूचियां और नेस्टेड ऑब्जेक्ट दिखा सकता है। एक रिकॉर्ड में कई पते या उत्पाद हों तो CSV बनाने से पहले तय करें कि उन्हें कॉलम में कैसे फैलाना है। हर संरचना के लिए एक ही सही तालिका नहीं होती।
संदर्भ: IETF RFC 8259 — JSON Data Interchange Format · IETF RFC 4180 — Common CSV Format
सजाना और सत्यापित करना अलग काम हैं
JSON को फॉर्मेट करने से इंडेंटेशन पढ़ना आसान होता है, लेकिन कीमत या तारीख सही होने का प्रमाण नहीं मिलता। स्कीमा जांच घोषित प्रकार और जरूरी फील्ड देखती है; डेटा का अर्थ फिर भी ऐप के नियम तय करते हैं।
JSON में उद्धरण चिह्नों के बीच का टेक्स्ट, संख्या से अलग है। CSV में कॉमा या नई पंक्ति वाले फील्ड को उचित उद्धरण चिह्नों में रखना पड़ता है; ऐसे फील्ड के अंदर उद्धरण चिह्न को दोहराया जाता है।
संदर्भ: IETF RFC 8259 — JSON Data Interchange Format · IETF RFC 4180 — Common CSV Format
रूपांतरण के बाद क्या जांचें
मूल डेटा रखें। रिकॉर्ड की संख्या और कॉलम नाम मिलाएं। एक सामान्य रिकॉर्ड तथा खाली मान, विराम चिह्न या कई भाषाओं वाला दूसरा रिकॉर्ड देखें। नतीजा उसी ऐप में खोलें जिसमें उसका उपयोग होगा; कन्वर्टर उस ऐप के आयात विकल्पों की गारंटी नहीं देता।
- 0017 जैसे पहचान मान में शून्य जरूरी हों तो उसे टेक्स्ट रखें।
- बिना सोचकर तय किए खाली मान, null और 0 को एक न मानें।
- गुप्त प्रवेश जानकारी या असली लोगों के रिकॉर्ड के बजाय बनाए गए नमूने लें।
- स्प्रेडशीट में अविश्वसनीय CSV सावधानी से खोलें; कुछ सेल टेक्स्ट की जगह फॉर्मूला समझे जा सकते हैं।
संदर्भ: OWASP — CSV Injection
उदाहरण: नाम के भीतर कॉमा
उदाहरण JSON: {"sku":"0017","name":"नोटबुक, नीली","price":12.5}। कॉमा से अलग किए गए CSV में नाम को उद्धरण चिह्नों में रखें: 0017,"नोटबुक, नीली",12.5।
आयात पर जांचें कि sku, 17 बनने के बजाय 0017 ही रहे और उत्पाद का नाम 2 कॉलम में न बंटे। केवल आउटपुट फाइल बनना इन दोनों बातों का प्रमाण नहीं है।