XML फ़ॉर्मैट करें
XML की उलझी दीवार को पढ़ने लायक इंडेंट करें, या वापस मिनिफ़ाई करें। कमेंट, CDATA सेक्शन और नेमस्पेस जस के तस रहते हैं। कुछ भी स्टोर नहीं किया जाता।
- कभी स्टोर नहीं होती
- न कतार, न इंतज़ार
- साइनअप नहीं, वॉटरमार्क नहीं
फ़ॉर्मैट किया हुआ XML यहां दिखेगा।
यह कैसे काम करता है
अपना XML पेस्ट करें
या .xml, .svg, .rss या .xsd फ़ाइल छोड़ें। यह कभी स्टोर नहीं होती।
इंडेंट चुनें
दो स्पेस, चार, टैब, या मिनिफ़ाई करके एक लाइन में।
कॉपी या डाउनलोड करें
अगर XML टूटा हुआ है, तो नतीजे की जगह आपको लाइन और कॉलम बताया जाता है।
XML को दोबारा इंडेंट करना जितना दिखता है, उससे ज़्यादा जोखिम भरा क्यों है
XML में व्हाइटस्पेस डिफ़ॉल्ट रूप से मायने रखता है, और यही बात लोगों को चौंकाती है। JSON में फ़ॉर्मैटिंग से कुछ नहीं बिगड़ता, लेकिन XML पार्सर को एलिमेंट के बीच के स्पेस और नई लाइनों को टेक्स्ट कंटेंट के रूप में बताना ही पड़ता है — उन्हें अनदेखा किया जा सकता है या नहीं, यह स्कीमा (अगर हो) तय करता है। इसलिए दोबारा इंडेंट करने से डॉक्यूमेंट सच में बदल जाता है। ज़्यादातर कॉन्फ़िगरेशन और डेटा फ़ाइलों पर इसका कोई असर नहीं पड़ता, लेकिन मिक्स्ड कंटेंट वाले डॉक्यूमेंट में — जहां टेक्स्ट और एलिमेंट साथ-साथ होते हैं, जैसे XHTML या DocBook — इससे डॉक्यूमेंट का कहा हुआ बदल सकता है।
इसलिए यहां की फ़ॉर्मैटिंग उन चीज़ों को नहीं छूती जिन्हें छूना नहीं चाहिए। जिस एलिमेंट पर xml:space="preserve" लगा है, उसका कंटेंट बिल्कुल वैसा ही रहता है जैसा लिखा गया, क्योंकि यह एट्रिब्यूट ठीक यही कहने के लिए बना है। CDATA सेक्शन बिना छेड़े आगे जाते हैं; वे ऐसे टेक्स्ट के लिए होते हैं जिसे इंटरप्रेट नहीं किया जाना चाहिए, और उनके अंदर फ़ॉर्मैटिंग करने से वह ख़राब हो जाएगा। एंटिटी रेफ़रेंस रेफ़रेंस ही रहते हैं, उन्हें उन कैरेक्टर में नहीं बदला जाता जिनके लिए वे हैं।
नेमस्पेस बिल्कुल वैसे ही रखे जाते हैं जैसे लिखे गए हैं — प्रीफ़िक्स, डिक्लेरेशन और वे एलिमेंट जिनसे वे जुड़े हैं। यह ज़ाहिर-सी बात लगती है, पर है नहीं: जो फ़ॉर्मैटर प्रीफ़िक्स को नॉर्मलाइज़ करता है या डिक्लेरेशन को वहां ले जाता है जहां उसे सही लगता है, वह ऐसा डॉक्यूमेंट बनाता है जो तकनीकी रूप से बराबर होता है, पर उन टूल्स में फ़ेल हो जाता है जो प्रीफ़िक्स को अक्षरशः मिलाते हैं। एट्रिब्यूट का क्रम भी वैसा ही रखा जाता है, हालांकि XML के लिए उसका कोई मतलब नहीं — इसी वजह से, क्योंकि पिछले वर्शन से diff करना साफ़-सुथरे क्रम से ज़्यादा काम का है।
फ़ॉर्मैटिंग के दौरान well-formedness की जांच होती है: हर टैग बंद हो, सही तरह नेस्ट हो, एक ही रूट एलिमेंट हो, कैरेक्टर मान्य हों, ऐम्परसैंड और ऐंगल ब्रैकेट ठीक से एस्केप हों। यह XML की दो कसौटियों में से निचली कसौटी है। कोई डॉक्यूमेंट पूरी तरह well-formed होकर भी अपने DTD या स्कीमा के हिसाब से अमान्य हो सकता है, और कितनी भी फ़ॉर्मैटिंग यह नहीं दिखाएगी।
जब आपको कुछ और चाहिए
xmllint --format in.xml यही काम कमांड लाइन पर करता है और ज़्यादातर Unix सिस्टम पर पहले से इंस्टॉल होता है; xmlstarlet fo --indent-tab इंडेंटेशन पर ज़्यादा कंट्रोल देता है। दोनों ही उतनी बड़ी फ़ाइलें संभाल लेते हैं जितनी कोई वेब पेज मेमोरी में रख ही नहीं सकता।
जब डॉक्यूमेंट की तुलना करनी हो, उसे साइन करना हो या कैनॉनिकल रूप में सेव करना हो, तो फ़ॉर्मैटिंग बिल्कुल ग़लत काम है। Canonical XML — xmllint --c14n — वह एक नॉर्मलाइज़्ड रूप बनाता है जिसमें दो बराबर डॉक्यूमेंट एक जैसे हो जाते हैं, और XML पर डिजिटल सिग्नेचर इसी पर टिके होते हैं। साइन किए गए डॉक्यूमेंट को pretty-print करने से उसका सिग्नेचर टूट जाता है, और यह सबक़ सीखने का सबसे महंगा तरीक़ा है।
अक्सर पूछे जाने वाले सवाल
क्या मेरा XML कहीं स्टोर होता है?
नहीं। कोई सर्वर कॉल नहीं, कोई लॉगिंग नहीं, और कुछ भी स्टोर नहीं होता। पेज लोड होने के बाद आप इंटरनेट बंद कर सकते हैं और यह काम करता रहता है। यहां यह जितना दिखता है उससे ज़्यादा मायने रखता है: लोग ऑनलाइन फ़ॉर्मैटर में जो चीज़ें पेस्ट करते हैं वे API रिस्पॉन्स, कॉन्फ़िग फ़ाइलें और एरर पेलोड होती हैं, और उनमें अक्सर टोकन, ग्राहकों के रिकॉर्ड और इंटरनल होस्टनेम होते हैं।
फ़ॉर्मैटिंग के बाद क्या-क्या बचा रहता है?
कमेंट, CDATA सेक्शन, प्रोसेसिंग इंस्ट्रक्शन, XML डिक्लेरेशन और सभी नेमस्पेस प्रीफ़िक्स। एट्रिब्यूट का क्रम वैसा ही रहता है जैसा लिखा गया। जिस एलिमेंट में सिर्फ़ टेक्स्ट है, वह एक ही लाइन पर रहता है, क्योंकि <title>Hello</title> को तीन लाइनों में तोड़ना सुंदर नहीं है — और मिक्स्ड-कंटेंट डॉक्यूमेंट में इससे टेक्स्ट का असली मतलब बदल जाएगा।
क्या इंडेंट करने से मेरे XML का मतलब बदल जाएगा?
जिस एलिमेंट में सिर्फ़ दूसरे एलिमेंट हैं, उसमें नहीं। लेकिन XML में ऐसा कोई आम नियम नहीं है कि व्हाइटस्पेस मायने नहीं रखता — मिक्स्ड कंटेंट में, जहां टेक्स्ट और एलिमेंट साथ-साथ होते हैं, जोड़ा गया व्हाइटस्पेस टेक्स्ट का ही हिस्सा बन जाता है। इसीलिए यहां सिर्फ़-टेक्स्ट वाले एलिमेंट को तोड़ा नहीं जाता, एक लाइन पर रखा जाता है। अगर आपके डॉक्यूमेंट में सचमुच मिक्स्ड कंटेंट है और व्हाइटस्पेस उसके लिए मायने रखता है, तो मिनिफ़ाई करना ज़्यादा सुरक्षित है।
क्या यह HTML के साथ काम करता है?
सिर्फ़ तब, जब HTML well-formed XML हो — और ज़्यादातर असली HTML ऐसा नहीं होता। बिना बंद किए <br>, <img> और <li> टैग, बिना कोट के एट्रिब्यूट और अकेले ऐम्परसैंड — ये सब HTML में मान्य हैं और XML में अमान्य। यहां का पार्सर सख़्त XML पार्सर है, इसलिए वह अंदाज़ा लगाने के बजाय इन्हें एरर के रूप में बताएगा। XHTML और SVG बढ़िया फ़ॉर्मैट होते हैं।
SVG का क्या?
हां — SVG भी XML है, और मिनिफ़ाई की हुई SVG पढ़ने का यह अच्छा तरीक़ा है। पाथ, ग्रेडिएंट और अंदर की स्टाइल सब बिना बदले आती हैं; सिर्फ़ एलिमेंट के बीच का व्हाइटस्पेस बदलता है।
क्या कोई साइज़ लिमिट है?
उपलब्ध मेमोरी, न कि हमारी लगाई कोई सीमा। कुछ मेगाबाइट के डॉक्यूमेंट तुरंत फ़ॉर्मैट हो जाते हैं; बहुत बड़े डॉक्यूमेंट की सीमा यह है कि एक बार में कितना मेमोरी में रखा जा सकता है, हमारी तरफ़ की कोई चीज़ नहीं।
ध्यान दें: सिर्फ़ well-formedness की जांच। डॉक्यूमेंट में टैग का संतुलन, सही नेस्टिंग और मान्य कैरेक्टर जांचे जाते हैं और उसे दोबारा इंडेंट किया जाता है — लेकिन कोई DTD या XSD न लाया जाता है, न लागू किया जाता है, इसलिए कोई फ़ाइल ठीक से फ़ॉर्मैट होकर भी अपने स्कीमा के हिसाब से अमान्य हो सकती है। नेमस्पेस बिल्कुल वैसे ही रखे जाते हैं जैसे लिखे गए हैं।
यह टूल अपनी वेबसाइट पर लगाएं
किसी भी ब्लॉग, क्लास पेज या हेल्प आर्टिकल के लिए मुफ़्त। एक स्निपेट पेस्ट करें और आपके विज़िटर इसे सीधे आपके पेज पर इस्तेमाल कर सकेंगे।