NDJSON को CSV में बदलें

इस साइट के किसी भी और स्रोत से यहाँ हिसाब सबसे सीधा है। NDJSON हर लाइन में एक पूरा रिकॉर्ड होने की गारंटी देता है, तो मिलने वाली पंक्तियों की संख्या फ़ाइल की लाइनों की संख्या के बराबर है — कमांड लाइन पर wc -l, या किसी भी एडिटर की लाइन गिनती। किसी भी डेटा में लाइन-ब्रेक नहीं बन सकता, क्योंकि किसी स्ट्रिंग के भीतर मौजूद नई-लाइन JSON में एस्केप की जाती है।

इससे यह बदलाव उस तरह अनुमानित बनता है जो JSON ऐरे नहीं होता। अगर फ़ाइल में 4,12,000 लाइनें हैं तो एक हेडर के साथ 4,12,000 पंक्तियाँ मिलती हैं, और अगर आउटपुट में कम हों तो दिक़्क़त इनपुट में थी, बदलाव में नहीं। ख़ाली लाइनें छोड़ दी जाती हैं, फ़ाइल के अंत की वह आख़िरी लाइन भी जो लगभग हर राइटर पीछे छोड़ जाता है।

NDJSON फ़ाइल की हर लाइन स्वतंत्र है, और कुछ भी दूसरी लाइन को पहली की कुंजियाँ दोहराने पर मजबूर नहीं करता। कई तरह की घटनाएँ भेजने वाली कोई लॉग धारा — एक अनुरोध, एक त्रुटि, किसी काम का पूरा होना — सबको एक ही फ़ाइल में, हर एक की अलग फ़ील्ड के साथ, डाल देती है।

यह बदलाव फ़ाइल में कहीं भी दिखी हर कुंजी इकट्ठा करके उसे एक कॉलम देता है, जहाँ किसी लाइन में कुछ नहीं था वहाँ सेल ख़ाली छोड़ देता है। कुछ खोता नहीं, और नतीजा बहुत विरल हो सकता है — चालीस कॉलम जिनमें से हर पंक्ति सिर्फ़ आठ इस्तेमाल करती है। ऐसे में jq से एक घटना-प्रकार चुनकर पहले फ़ाइल छाँटना बेहतर है, स्प्रेडशीट चौड़ी करने से।

अगर कोई लाइन मान्य JSON नहीं है, तो बदलाव उसके आगे नहीं बढ़ता। संदेश बताता है कौन-सी लाइन: "This file could not be read as NDJSON — line 3 is not valid JSON." यह जानबूझकर है, कमज़ोरी नहीं।

लॉग में टूटी लाइन का मतलब लगभग कभी कोई भटका हुआ अक्षर नहीं होता। इसका मतलब है अधूरा लेखन — बीच में रुकी प्रक्रिया, किसी सीमा पर कटी घूमी हुई फ़ाइल — और उसके बाद की हर चीज़ संदिग्ध है। चुपचाप लाइन छोड़ देना कुछ अनजान संख्या के रिकॉर्ड ग़ायब कर देता, बिना कोई संकेत दिए। लाइन नंबर हाथ में होने से पूँछ ठीक करना एक कमांड का काम है।

संरचित लॉगिंग अक्सर नेस्टेड होती है: एक request ऑब्जेक्ट जिसमें method और path, एक user ऑब्जेक्ट जिसमें id, एक context ब्लॉक जिसमें ट्रेस पहचान। ये पथ के नाम पर कॉलम बनकर चपटी हो जाती हैं — request.method, user.id — हर पत्ती-मान के लिए एक कॉलम।

एक या दो स्तर ऐसी टेबल देते हैं जिस पर कोई भी काम कर सके, और यह अधिकतर लॉगिंग लाइब्रेरी के डिफ़ॉल्ट को कवर करता है। गहरी संरचनाएं जल्दी चौड़ी होती हैं। जब ऐसा हो, तो असल में काम की चीज़ फ़ाइल का एक ही सबट्री होता है — उसे पहले निकालना पूरा चपटा करने से बेहतर टेबल देता है।

कोई सूची ढोने वाला रिकॉर्ड — टैग, त्रुटि फ़्रेम, लागू नियमों का सेट — गिनी हुई कॉलम में चपटा होता है: tags.0, tags.1, tags.2। हर मान बचता है और टेबल को फ़ाइल की सबसे लंबी सूची जितने कॉलम मिलते हैं, ज़्यादातर ख़ाली।

विश्लेषण के लिए यह शायद ही वह हो जो चाहिए था। अगर सूची गौण है, तो बदलने से पहले उसे एक स्ट्रिंग में जोड़ देना एक पढ़ने लायक कॉलम देता है। अगर सूची ही विश्लेषण का विषय है, तो चाहिए एक पंक्ति प्रति तत्व — दोनों एक jq एक्सप्रेशन भर हैं।

टाइप सबसे बड़ा नुक़सान हैं, और यह साफ़ रहना ज़रूरी है कि यह मंज़िल पर खोता है, रास्ते में नहीं। मान ईमानदारी से लिखे जाते हैं — संख्या अंकों में, बूलियन true या false, null ख़ाली सेल — पर CSV का कोई टाइप-सिस्टम नहीं, तो जो भी फ़ाइल खोले वही तय करता है कि हर चीज़ क्या है।

Excel ग़लत और अनुमानित तरीक़े से तय करता है: पहचान संख्याओं से शुरुआती शून्य ग़ायब हो जाते हैं, तारीख़ जैसा दिखने वाला कुछ भी तारीख़ बन जाता है। उपाय है खोलने की बजाय आयात करना — Data, फिर From Text/CSV, पहचान कॉलम को Text सेट करके — या XLSX में बदलना, जहाँ टाइप फ़ाइल में दर्ज होते हैं, अंदाज़ा नहीं लगाया जाता।

कॉमा, उद्धरण चिह्न या लाइन-ब्रेक रखने वाले मान दोहरे उद्धरण चिह्नों में लपेटे जाते हैं, भीतरी उद्धरण दोहराए जाते हैं — यह RFC 4180 का रिवाज़ है और हर भरोसेमंद इंपोर्टर इसे सही पढ़ता है। बाक़ी सब बिना लपेटे लिखा जाता है, तो फ़ाइल पढ़ने लायक बनी रहती है।

लॉग डेटा इस तरीक़े पर सबसे ज़्यादा टिकता है। यूज़र एजेंट, क्वेरी-स्ट्रिंग वाले रिक्वेस्ट पथ, त्रुटि संदेश और स्टैक ट्रेस सब कॉमा और उद्धरण चिह्नों से भरे होते हैं। अगर मंज़िल स्प्रेडशीट नहीं बल्कि शेल पाइपलाइन है — awk, cut — तो टैब-सेपरेटेड में बदलना यह बहस टाल देता है।

पार्स तेज़ है और सीमा मेमोरी है, क्योंकि पहली पंक्ति लिखे जाने से पहले पूरी फ़ाइल रिकॉर्ड में पढ़ी जाती है और सभी कॉलम तय किए जाते हैं। मुफ़्त सीमा 100 MB तक स्वीकारती है; कुछ दसियों मेगाबाइट आराम से बदल जाते हैं और कई सौ पर ब्राउज़र टैब मेहनत करने लगता है।

उससे ऊपर, स्रोत फ़ॉर्मेट आपके पक्ष में है। NDJSON किसी भी लाइन-सीमा पर सुरक्षित रूप से बँटता है — split -l 5,00,000 वैध फ़ाइलें देता है — तो बड़े लॉग को टुकड़ों में बदलना कोई जुगाड़ नहीं, वैध तरीक़ा है। गीगाबाइट भर की फ़ाइल के लिए स्ट्रीमिंग औज़ार सही उपकरण है, यह पेज नहीं।

CSV एक झलक है, बदली नहीं। इसने टाइप खो दिए हैं, संरचना चपटी कर दी है, और ऐसे रिकॉर्ड मिला दिए हैं जिन्हें कभी सहमत होने की ज़रूरत नहीं थी — इनमें से कुछ भी टेबल से वापस नहीं मिल सकता।

मूल फ़ाइल आगे की चीज़ों के लिए भी बेहतर है। यह बिना दोबारा लिखे जुड़ती है, jq से बिना पूरा लोड किए छनती है, और सवाल बदलने पर अलग सबट्री निकालकर दोबारा बदली जा सकती है। CSV को आज के सवाल का जवाब मानिए, NDJSON को डेटा।

यह बदलाव इसी ब्राउज़र टैब में चलने वाला सादा JavaScript है। कोई अनुरोध फ़ाइल कहीं नहीं ले जाता, न कोई खाता है और न दैनिक सीमा, और नेटवर्क टैब खोलकर आप यह ख़ुद देख सकते हैं।

इस जोड़ी के लिए यह कोई सुविधा भर नहीं है। प्रोडक्शन लॉग में IP पते, सेशन पहचान, अनुरोध पथ और अक्सर टोकन वाली क्वेरी-स्ट्रिंग होती है — ठीक वह श्रेणी जिसे किसी वेब सेवा में पेस्ट नहीं करना चाहिए।