एक ही लाइन में लिखी, न पढ़ी जाने वाली SQL को ठीक से इंडेंट की गई क्वेरी में बदलें — 18 डायलेक्ट, सब कुछ आपके ब्राउज़र में।
SQL शायद ही कभी पढ़ने लायक़ हालत में मिलती है: ORM से निकली एक अंतहीन लाइन, स्लो-क्वेरी लॉग में हर कीवर्ड लोअरकेस, किसी चैट क्लाइंट से बरबाद हुई इंडेंटेशन। पढ़ने से पहले उसे हाथ से दोबारा फ़ॉर्मैट करने में दस मिनट बरबाद होते हैं — और पढ़ना ही वह जगह है जहाँ बग छिपे होते हैं: एक join शर्त जो चुपके से फ़िल्टर बन गई, एक OR जो लेखक की सोच से ज़्यादा चौड़ा बँधता है, तीन स्तर गहरी एक सबक्वेरी। उसे यहाँ पेस्ट करें और वह हर क्लॉज़ अलग लाइन में, नेस्टिंग सही ढंग से पंक्तिबद्ध और कीवर्ड आपकी पसंद के केस में लेकर वापस आती है।
काम एक असली पार्सर करता है, रेगुलर एक्सप्रेशनों का ढेर नहीं। क्वेरी को टोकन में बाँटा जाता है, क्लॉज़ के पेड़ के रूप में समझा जाता है और दोबारा छापा जाता है — यही वजह है कि टिप्पणियाँ उसी लाइन पर रहती हैं जहाँ लिखी गई थीं, स्ट्रिंग लिटरल तब भी अछूते बचते हैं जब उनमें SELECT या FROM जैसे शब्द हों, और कोई विंडो फ़ंक्शन अपना OVER (PARTITION BY … ORDER BY …) ब्लॉक ठीक से नेस्ट किए रखता है। अठारह डायलेक्ट दिए गए हैं — Standard SQL, PostgreSQL, MySQL, MariaDB, SQLite, SQL Server (T-SQL), Oracle PL/SQL, BigQuery, Snowflake, Redshift, Spark, Trino, Hive, Db2, Db2 for i, TiDB, SingleStore और N1QL — और यह चुनाव सजावट नहीं है: PostgreSQL की डॉलर-कोटिंग ($$body$$) और T-SQL के ब्रैकेट ([dbo].[table]) Standard SQL में पार्स एरर हैं और सही डायलेक्ट के साथ बिल्कुल ठीक फ़ॉर्मैट होते हैं। ?, :name, $1 और @name जैसे प्लेसहोल्डर हर डायलेक्ट में पहचाने जाते हैं और ज्यों के त्यों आगे भेज दिए जाते हैं, इसलिए क्वेरी लॉग से सीधे कॉपी की गई SQL बिगड़ती नहीं।
दो ईमानदार सीमाएँ। फ़ॉर्मैटर सिर्फ़ इतना जाँचता है कि टेक्स्ट चुने हुए डायलेक्ट के लिए व्याकरण की दृष्टि से वैध SQL है: उसे आपकी टेबलों के बारे में कुछ नहीं पता, इसलिए वह ऐसी क्वेरी भी फ़ॉर्मैट कर देगा जो किसी ऐसे कॉलम की बात करती हो जो है ही नहीं, और वह कभी कुछ चलाता नहीं। जब टेक्स्ट पार्स नहीं हो पाता तो वह अधूरा-फ़ॉर्मैट किया कचरा लौटाने के बजाय बता देता है कि पार्सर कहाँ हार गया, लाइन और कॉलम के साथ। किसी अनजान साइट के बजाय यहाँ फ़ॉर्मैट करने की वजह निजता है: प्रोडक्शन क्वेरी में टेबल के नाम, बिज़नेस लॉजिक और कभी-कभी निजी डेटा होता है। लाइब्रेरी (sql-formatter, MIT, vai.la से दी जाती है और सिर्फ़ आपके पहले फ़ॉर्मैट पर डाउनलोड होती है) आपके ब्राउज़र के भीतर चलती है।
नहीं। क्वेरी आपके अपने डिवाइस पर JavaScript से पार्स होकर दोबारा छापी जाती है — कुछ भी अपलोड, लॉग या स्टोर नहीं होता। यह मायने रखता है, क्योंकि असली क्वेरी आपका स्कीमा, आपके बिज़नेस नियम और कभी-कभी लिटरल में बैठा निजी डेटा उजागर कर देती हैं। पहली बार फ़ॉर्मैट करने के बाद आप इंटरनेट काट सकते हैं और यह फिर भी काम करेगा।
वही जो आपका डेटाबेस बोलता है। Standard SQL ज़्यादातर सामान्य क्वेरी को कवर कर लेता है, लेकिन डेटाबेस-विशिष्ट सिंटैक्स के लिए मेल खाता डायलेक्ट चाहिए: [ब्रैकेट] के लिए SQL Server (T-SQL), $$डॉलर कोटिंग$$ के लिए PostgreSQL। वैध SQL पर आया पार्स एरर आमतौर पर डायलेक्ट बदलने से ठीक हो जाता है।
नहीं। सिर्फ़ स्पेस, लाइन ब्रेक और कीवर्ड का केस बदलते हैं। पहचानकर्ता, स्ट्रिंग लिटरल, संख्याएँ और टिप्पणियाँ ठीक वैसी ही वापस आती हैं जैसी टाइप की गई थीं, इसलिए फ़ॉर्मैट की गई क्वेरी मूल के बराबर ही रहती है।
क्योंकि पार्सर को दिखाए गए लाइन और कॉलम पर कुछ ऐसा मिला जिसे वह व्याकरण में नहीं बिठा पाया। तीन आम वजहें: कोई टाइपो, जैसे छूटा हुआ कॉमा, कोट या कोष्ठक; कोई ऐसा टुकड़ा जो पूरा स्टेटमेंट नहीं है; या ग़लत डायलेक्ट चुने होने पर डेटाबेस-विशिष्ट सिंटैक्स।
हाँ। स्थान-आधारित (?), क्रमांकित ($1) और नामित (:name, @name) प्लेसहोल्डर हर डायलेक्ट में पहचाने जाते हैं और बिना बदले वापस छापे जाते हैं, इसलिए आप क्वेरी लॉग या किसी फ़्रेमवर्क के डीबग आउटपुट से सीधे पेस्ट कर सकते हैं।
हाँ। सेमीकोलन से अलग किए गए स्टेटमेंट एक के बाद एक फ़ॉर्मैट होते हैं, बीच में एक ख़ाली लाइन के साथ। इनपुट की सीमा 300,000 अक्षर है ताकि पेज कभी जमे नहीं; उससे ज़्यादा हो तो फ़ाइल को बाँट लें।
Vai.la किसी भी URL को क्लिक आंकड़ों, QR Code और आपके अपने बायोलिंक के साथ एक शॉर्ट लिंक में बदल देता है।
टूल्स का इस्तेमाल कैसे होता है या उनके परिणामों के आधार पर लिए गए निर्णयों के लिए Vai.la ज़िम्मेदार नहीं है।