Markdown तालिका जनरेटर

Markdown टेबल के बारे में

Markdown टेबल सादे टेक्स्ट में संरचित सारणीबद्ध डेटा बनाने के लिए पाइप (|) और डैश (-) का उपयोग करते हैं।

हाथ से Markdown टेबल लिखना थकाऊ और त्रुटि-प्रवण हो सकता है। यह दृश्य संपादक आपको स्प्रेडशीट-शैली ग्रिड में डेटा दर्ज करने देता है।

पाइप-टेबल वाक्यविन्यास, यांत्रिक रूप से

एक GFM तालिका तीन भागों से बनती है: एक शीर्षक पंक्ति जिसमें सेल्स पाइप (|) से अलग होते हैं, ठीक नीचे एक परिसीमक पंक्ति जो प्रत्येक कॉलम के लिए डैश (---) का उपयोग करती है, और शून्य या अधिक डेटा पंक्तियाँ जिनकी संरचना समान पाइप-अलग होती है। प्रत्येक पंक्ति पर अग्रणी और अनुगामी पाइप वैकल्पिक हैं पर पठनीयता के लिए परंपरागत रूप से शामिल किए जाते हैं। कॉलम संरेखण परिसीमक पंक्ति में कोलनों द्वारा निर्दिष्ट होता है: :--- बाएँ-संरेखण के लिए (डिफ़ॉल्ट), :---: केंद्र के लिए, ---: दाएँ के लिए। न्यूनतम व्यवहार्य तालिका स्रोत में ऐसी दिखती है: पंक्ति 1 पर | Header | Header |, पंक्ति 2 पर | --- | --- |, पंक्ति 3 से आगे | Cell | Cell |। सेल सामग्री में कोई भी इनलाइन Markdown स्वरूपण (बोल्ड, इटैलिक, लिंक, कोड स्पैन, छवियाँ) शामिल हो सकती है पर ब्लॉक-स्तरीय तत्व (सूचियाँ, कोड ब्लॉक, उद्धरण) शामिल नहीं हो सकते। एक सेल के अंदर लाइन ब्रेक को शाब्दिक न्यूलाइन के बजाय <br> टैग के रूप में एनकोड करना होगा, क्योंकि शाब्दिक न्यूलाइन तालिका संरचना तोड़ देगी। सेल सामग्री के अंदर पाइप वर्णों को \| के रूप में एस्केप करना होगा, अन्यथा पार्सर उन्हें कॉलम विभाजक मानेगा और पंक्ति का कॉलम-गणना ग़लत हो जाएगा। अधिकांश पार्सर असमान कॉलम चौड़ाइयों को सहन करते हैं; स्रोत | a | b | और | aaa | b | समान रूप से रेंडर होते हैं, भले ही बाद वाला स्रोत में अधिक «सही» दिखे। यह उपकरण पठनीयता के लिए हमेशा संरेखित-चौड़ाई वाला स्रोत निकालता है, पर रेंडरिंग कॉम्पैक्ट स्रोत जैसा ही होता है।

तालिकाएँ कहाँ रेंडर होती हैं और कहाँ नहीं

सही ढंग से रेंडर होती हैं: GitHub (issues, pull requests, READMEs, wiki पन्ने, discussions, code reviews, हर जगह टिप्पणियाँ), GitLab (समान सतहें), Bitbucket, Stack Overflow, Reddit (जब subreddit में GFM सक्षम हो, अधिकांश में है), Discord (केवल कोड-ब्लॉक संदर्भ में, चैट संदेशों में पूर्ण GFM तालिकाएँ रेंडर नहीं होतीं पर docs सतह पर markdown-it उन्हें प्रोसेस करता है), Notion (अपने तालिका आयात के साथ), Obsidian, Logseq, Bear, अधिकांश static-site जनरेटर (Hugo, Jekyll, Eleventy, remark-gfm प्लगिन वाला Astro, Next.js MDX), VS Code का पूर्वावलोकन, GitHub Pages, Read the Docs (कॉन्फ़िगरेशन पर निर्भर)। सही ढंग से रेंडर नहीं होतीं: सख़्त CommonMark (बिना एक्सटेंशन के commonmark reader वाला Pandoc, pipe-tables flag के बिना Discount C पार्सर), Slack (Markdown का एक उप-समूह रेंडर करता है पर तालिकाएँ नहीं), अधिकांश ईमेल क्लाइंट (ईमेल में रेंडर किया गया HTML संरचनात्मक रूप से ठीक है पर इनलाइन-स्टाइल है, Markdown नहीं), Markdown प्लगिन के बिना पुराने WordPress इंस्टॉलेशन। सामान्य नियम: यदि आपका गंतव्य डेवलपर-उन्मुख प्लेटफ़ॉर्म (GitHub परिवार, तकनीकी दस्तावेज़) है, GFM तालिकाएँ काम करती हैं। यदि गंतव्य सामान्य-दर्शक प्लेटफ़ॉर्म (Slack, ईमेल, Twitter) है, मान लें कि तालिकाएँ रेंडर नहीं होंगी और या तो छवि के रूप में पूर्व-रेंडर करें या सूची के रूप में पुनः लिखें।

वैकल्पिक Markdown तालिका वाक्यविन्यास

GitHub की पहुँच के कारण pipe-table प्रारूप का प्रभुत्व है, पर यह एकमात्र Markdown तालिका वाक्यविन्यास नहीं है। Pandoc सरल तालिकाएँ रिक्त-पंक्ति-और-डैश परिसीमकों का उपयोग करती हैं और कॉलम को पाइप के बजाय दृश्य स्थिति से संरेखित करती हैं, संकीर्ण तालिकाओं के लिए बहुत अधिक पठनीय पर हाथ से लिखने में अधिक कठिन। Pandoc multi-line तालिकाएँ उन सेल्स का समर्थन करती हैं जो कई पंक्तियों में फैलें, उस लंबी विवरणात्मक सामग्री के लिए महत्वपूर्ण जो एक पंक्ति में नहीं समाती। Pandoc grid तालिकाएँ ASCII-कला सीमाओं (+---+---+) का उपयोग करती हैं जो हाथ से बनाए रखने में दर्दनाक दिखती हैं पर उपकरणों के लिए उत्सर्जित करना आसान। reStructuredText (Sphinx) केवल grid तालिकाओं का उपयोग करता है, हर Python परियोजना का दस्तावेज़ इसी तरह लिखा जाता है। AsciiDoc तकनीकी पुस्तक-लेखन के लिए अनुकूलित एक भिन्न pipe-उपसर्ग वाक्यविन्यास (|===) का उपयोग करता है। Markdown में HTML हमेशा बाहर निकलने के रास्ते के रूप में उपलब्ध है: कोई भी Markdown प्रोसेसर कच्चा HTML पास होने देता है, इसलिए जब pipe तालिकाएँ पर्याप्त नहीं होतीं तो आप पूर्ण row/column स्पैनिंग, अर्थपूर्ण मार्कअप और CSS स्टाइलिंग वाली एक असली <table> डाल सकते हैं। यह उपकरण जो pipe-table वाक्यविन्यास उत्पन्न करता है वह GFM-शैली है, आधुनिक डेवलपर पारिस्थितिकी तंत्र के लिए सबसे अनुकूल विकल्प।

सामान्य उपयोग

• GitHub README फ़ाइलें। तुलना तालिकाएँ («हमारी लाइब्रेरी बनाम विकल्प»), सुविधा मैट्रिक्स, समर्थित-संस्करण सूचियाँ, योगदानकर्ता सूचियाँ, कमांड संदर्भ कार्ड। संभवतः GFM तालिकाओं का सबसे सामान्य एकल उत्पादन उपयोग।
• दस्तावेज़ीकरण और wiki। API संदर्भ तालिकाएँ (पैरामीटर नाम / प्रकार / विवरण / डिफ़ॉल्ट), कॉन्फ़िगरेशन विकल्प तालिकाएँ, त्रुटि कोड संदर्भ, भाषा-अनुवाद मैट्रिक्स। Read the Docs, MkDocs, Docusaurus, GitBook सभी GFM तालिकाएँ समर्थन करते हैं।
• तुलना ब्लॉग पोस्ट। «Framework X बनाम Framework Y» लेख, हार्डवेयर स्पेक तुलना, मूल्य निर्धारण स्तर विश्लेषण। pipe-table प्रारूप तदर्थ अनुच्छेदों की तुलना में बहुत अधिक पठनीय है और Medium, dev.to, Substack और व्यक्तिगत ब्लॉगों पर साफ़ रेंडर होता है।
• मूल्य निर्धारण पन्ने। SaaS स्तर तालिकाएँ (Free / Pro / Enterprise सुविधाओं की पंक्तियों के पार) त्वरित मसौदा-संस्करण मॉकअप के लिए pipe-table रूप में अच्छी तरह काम करती हैं, इससे पहले कि वाणिज्यिक डिज़ाइनर पॉलिश्ड HTML संस्करण बनाएँ।
• GitHub issue टेम्पलेट। बग रिपोर्ट टेम्पलेट अक्सर तालिका रूप में पुनरुत्पादन कदम शामिल करते हैं (कदम / अपेक्षित / वास्तविक / स्क्रीनशॉट)। sprint प्रगति ट्रैक करने के लिए परियोजना बोर्ड स्थिति तालिकाएँ।
• मीटिंग नोट्स और परियोजना योजनाएँ। साझा नोट दस्तावेज़ों में कार्य-वस्तु तालिकाएँ (मालिक / कार्य / देय तिथि / स्थिति)। निर्णय लॉग। जोखिम रजिस्टर।
• CSV आयात। कई तालिका जनरेटर CSV-से-Markdown आयात प्रदान करते हैं, एक CSV चिपकाएँ, एक Markdown तालिका प्राप्त करें। उलटा (Markdown से CSV) भी सामान्य है जब दस्तावेज़ीकरण से संरचित डेटा को वापस स्प्रेडशीट प्रारूप में निकालना हो।

चौड़ाई की समस्या और अन्य बाधाएँ

Pipe तालिकाओं की कई अंतर्निहित सीमाएँ हैं जिन्हें जानना सार्थक है। कॉलम चौड़ाई सबसे लंबी सेल-सामग्री से बंधी होती है, एक लंबा URL या किसी सेल में विवरणात्मक अनुच्छेद पूरे कॉलम को चौड़ा कर देता है, जो ऐसी अव्यवस्थित तालिकाएँ पैदा कर सकती है जो मानक दस्तावेज़ीकरण पृष्ठ चौड़ाइयों में फ़िट नहीं होतीं। समाधान या तो लंबी सामग्री को छोटा करना है (विवरण के लिए कहीं और लिंक करना), या यदि आपको लपेटने योग्य सेलों की आवश्यकता है तो इनलाइन HTML का उपयोग करना। कोई पंक्ति या कॉलम स्पैनिंग नहीं, हर सेल ठीक एक पंक्ति और एक कॉलम लेती है। विलय की गई सेलों वाली जटिल तालिकाओं को rowspan / colspan विशेषताओं के साथ असली HTML <table> की आवश्यकता है। कोई नेस्टेड तालिकाएँ नहीं, आप Markdown में दूसरी तालिका की सेल के अंदर एक तालिका नहीं रख सकते। सेलों में कोई ब्लॉक-स्तरीय सामग्री नहीं, सेल के अंदर कोई सूचियाँ, कोई कोड ब्लॉक, कोई उद्धरण नहीं। इनलाइन सामग्री (बोल्ड, इटैलिक, कोड स्पैन, लिंक, छवियाँ) ठीक है पर कुछ भी बहु-पंक्ति <br> टैगों की आवश्यकता रखता है। शीर्षक पंक्ति अनिवार्य है GFM में, कोई शीर्ष-रहित तालिका वाक्यविन्यास नहीं है। यदि आप दृश्य शीर्षक के बिना तालिका चाहते हैं, शीर्षक सेलों को खाली छोड़ें पर पंक्ति फिर भी मौजूद होनी चाहिए। संरेखण प्रति-कॉलम पूरे कॉलम पर लागू होता है, आप एक ही कॉलम में विभिन्न सेलों के लिए विभिन्न संरेखण नहीं रख सकते। इन बाधाओं से अधिक परिष्कृत तालिका लेआउट के लिए, सही उपकरण आपके Markdown स्रोत में HTML है, स्वयं Markdown नहीं।

CSV ↔ Markdown रूपांतरण

अधिकांश वास्तविक दुनिया का तालिका डेटा CSV फ़ाइलों में रहता है (स्प्रेडशीट निर्यात, API प्रतिक्रियाएँ, लॉग विश्लेषण आउटपुट), Markdown से और तक रूपांतरण एक सामान्य workflow है। CSV → Markdown: CSV पार्स करें (एम्बेडेड कॉमा वाले उद्धृत फ़ील्ड, एस्केप किए गए उद्धरण, फ़ील्ड के भीतर लाइन ब्रेक संभालते हुए), फिर प्रत्येक पंक्ति को उपयुक्त शीर्षक और परिसीमक पंक्तियों के साथ | मान | मान | के रूप में स्वरूपित करें। इस सहित अधिकांश तालिका जनरेटर CSV आयात प्रदान करते हैं; एकमुश्त रूपांतरण के लिए आप csvkit का csvlook कमांड-लाइन उपकरण भी उपयोग कर सकते हैं जो समान pipe-format आउटपुट उत्पन्न करता है। Markdown → CSV: GFM तालिका को पंक्तियों और कॉलमों में वापस पार्स करें, फिर उचित quoting के साथ CSV उत्सर्जित करें। दस्तावेज़ीकरण से संरचित डेटा को विश्लेषण के लिए स्प्रेडशीट रूप में वापस निकालते समय उपयोगी। Markdown-से-CSV दिशा pandoc (सही reader/writer संयोजन के साथ), tableconvert.com और विभिन्न कमांड-लाइन उपयोगिताओं द्वारा प्रदान की जाती है। राउंड-ट्रिप एक दिशा में हानिकारक है, स्वरूपण (बोल्ड, लिंक, छवियाँ) CSV कदम के माध्यम से अक्षुण्ण तभी जीवित रहता है जब आप CSV सेल सामग्री को कच्चे Markdown टेक्स्ट के रूप में लिखते हैं और परिणाम को फिर से Markdown के रूप में मानते हैं।

गोपनीयता: यहाँ भी «केवल-ब्राउज़र» क्यों मायने रखता है

तालिकाएँ संवेदनशील डेटा नहीं लगतीं, पर तालिकाओं की सामग्री अक्सर होती है। परियोजना योजनाओं में कर्मचारी निर्णय और अघोषित सुविधाएँ होती हैं। मूल्य निर्धारण तालिकाओं में वाणिज्यिक जानकारी होती है। अप्रकाशित ब्लॉग पोस्ट में तुलना तालिकाएँ संपादकीय स्थिति प्रकट करती हैं। मीटिंग नोट कार्य-वस्तुओं में असाइनमेंट और जवाबदेही जानकारी होती है। सर्वर-साइड तालिका जनरेटर आपके डेटा को तीसरे पक्ष पर अपलोड करते हैं जहाँ वह लॉग में बैठता है। यह उपकरण JavaScript के माध्यम से पूरी तरह आपके ब्राउज़र में चलता है, सेल संपादित करते समय DevTools के Network टैब में सत्यापित करें, या लोड होने के बाद पृष्ठ को ऑफ़लाइन (एयरप्लेन मोड) करें और संपादक फिर भी काम करता है। अप्रकाशित दस्तावेज़ीकरण मसौदों, आंतरिक परियोजना नियोजन, अभी तक प्रकाशित न हुए ब्लॉग पोस्ट के लिए तुलना तालिकाओं, या किसी भी ऐसी तालिका सामग्री के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी नहीं देखना चाहते।

अक्सर पूछे जाने वाले प्रश्न

कौन सा Markdown टेबल सिंटैक्स जनरेट होता है?

यह मानक GFM (GitHub Flavored Markdown) सिंटैक्स जनरेट करता है, पाइप के साथ, डैश की विभाजक रेखा और वैकल्पिक कोलन।

कॉलम संरेखण कैसे सेट करें?

प्रत्येक कॉलम हेडर के नीचे L (बाएँ), C (केंद्र) या R (दाएँ) बटन पर क्लिक करें। बाएँ संरेखण :--- का उपयोग करता है।

क्या मैं CSV से आयात कर सकता हूँ या स्प्रेडशीट से चिपका सकता हूँ?

CSV आयात रोडमैप पर है। अभी के लिए, Excel/Google Sheets से चिपकाना अक्सर काम करता है क्योंकि अधिकांश स्प्रेडशीट ऐप क्लिपबोर्ड पर टैब-अलग डेटा रखते हैं, जिसे आप व्यक्तिगत सेलों में चिपका सकते हैं। मैन्युअल चिपकाने के बिना बल्क CSV आयात के लिए, csvkit के csvlook जैसे कमांड-लाइन उपकरण समान GFM-तालिका आउटपुट उत्पन्न करते हैं, या pandoc सीधे CSV को Markdown में परिवर्तित कर सकता है pandoc --from csv --to gfm input.csv के साथ।

विलयित सेल, नेस्टेड तालिकाएँ, या सेलों में ब्लॉक सामग्री के बारे में क्या?

GFM pipe तालिकाएँ इनका समर्थन नहीं करतीं। प्रत्येक सेल ठीक एक पंक्ति और एक कॉलम लेती है; कोई rowspan या colspan नहीं। कोई नेस्टेड तालिकाएँ नहीं। सेल के अंदर कोई ब्लॉक-स्तरीय सामग्री (सूचियाँ, कोड ब्लॉक, उद्धरण) नहीं, केवल इनलाइन सामग्री (बोल्ड, इटैलिक, कोड स्पैन, लिंक, छवियाँ, <br> के माध्यम से लाइन ब्रेक)। इन बाधाओं से अधिक परिष्कृत तालिका लेआउट के लिए, अपने Markdown स्रोत में सीधे कच्चा HTML <table> एम्बेड करें, हर Markdown प्रोसेसर HTML को अपरिवर्तित पास होने देता है। समझौता यह है कि स्रोत हाथ से पढ़ने और संपादित करने में बहुत अधिक कठिन हो जाता है।

क्या पंक्तियों या कॉलम की सीमा है?

आप 20 कॉलम और 100 पंक्तियों तक रख सकते हैं। अधिकांश दस्तावेज़ीकरण और README फ़ाइलों के लिए यह पर्याप्त है।

क्या मेरी तालिकाओं की सामग्री कहीं भेजी जाती है?

नहीं। उत्पादन JavaScript के माध्यम से पूरी तरह आपके ब्राउज़र में चलता है। आप जो सेल संपादित करते हैं और Markdown आउटपुट कभी नेटवर्क पार नहीं करते, टाइप करते समय DevTools के Network टैब में सत्यापित करें, या लोड होने के बाद पृष्ठ को ऑफ़लाइन (एयरप्लेन मोड) करें और संपादक फिर भी काम करता है। अप्रकाशित दस्तावेज़ीकरण मसौदों, आंतरिक परियोजना योजनाओं, अभी तक प्रकाशित न हुई मूल्य तुलना तालिकाओं, या किसी भी ऐसी सारणीबद्ध सामग्री के लिए सुरक्षित जिसे आप किसी अजनबी की हार्ड ड्राइव पर कॉपी नहीं देखना चाहते।

संबंधित टूल