केस कन्वर्टर

केस शैलियाँ समझें

टेक्स्ट केस की एक फ़ील्ड गाइड

"केस" दरअसल एक साथ दो अलग-अलग चुनावों का वर्णन करता है: कौन-से अक्षर बड़े किए जाएँ, और शब्दों के बीच की सीमाएँ कैसे चिह्नित हों। मानव गद्य शब्द-सीमाओं को स्पेस से चिह्नित करता है और बड़े-अक्षर तय करने के लिए व्याकरण पर निर्भर करता है। प्रोग्रामिंग पहचानकर्ता (identifiers) में स्पेस नहीं आ सकते, इसलिए वे एक विकल्प गढ़ते हैं — एक कूबड़ (camelCase), एक अंडरस्कोर (snake_case), एक हाइफ़न (kebab-case) या एक बिंदु (dot.case) — और केसिंग का नियम शैली में ही समेट लेते हैं। लगभग हर नामित केस उन्हीं दो सवालों का एक ख़ास जवाब है।

रोज़मर्रा की शैलियाँ वही हैं जो आप लेखन में पहले से मिलते हैं। UPPERCASE हर अक्षर को बड़ा कर देता है और संक्षिप्ताक्षरों, छोटे शीर्षकों और ज़ोर के लिए सुरक्षित है; इसकी लंबी कतारें धीरे पढ़ी जाती हैं क्योंकि एक-समान अक्षर-आकार उन शब्द-आकार संकेतों को हटा देते हैं जिन पर पाठक निर्भर रहते हैं। lowercase इसका उल्टा चरम है। वाक्य केस (Sentence case) केवल पहले शब्द का पहला अक्षर बड़ा करता है (साथ ही व्यक्तिवाचक संज्ञाएँ) और मुख्य पाठ, UI लेबल तथा अधिकांश आधुनिक हेडलाइनों के लिए स्वाभाविक शैली है। टाइटल केस (Title Case) हर महत्वपूर्ण शब्द का पहला अक्षर बड़ा करता है और पुस्तकों, लेखों तथा गीतों के शीर्षकों में इस्तेमाल होता है — और, जैसा अगला भाग दिखाता है, यह दिखने में जितना सरल लगता है उतना तय नहीं है।

प्रोग्रामिंग शैलियाँ अपने विभाजकों के आधार पर बँटती हैं। camelCase शब्दों को बिना किसी विभाजक के जोड़ता है और पहले शब्द को छोटे अक्षरों में रखता है: helloWorld, getUserName। PascalCase (औपचारिक रूप से UpperCamelCase) वही है पर पहला अक्षर भी बड़ा करता है: HelloWorld, HttpRequest। snake_case छोटे अक्षरों के शब्दों को अंडरस्कोर से जोड़ता है; जब हर अक्षर भी बड़ा हो तो यह SCREAMING_SNAKE_CASE बन जाता है (जिसे CONSTANT_CASE या UPPER_SNAKE_CASE भी कहते हैं)। kebab-case अंडरस्कोर की जगह हाइफ़न रखता है और असामान्य रूप से कई उपनामों से जाना जाता है — dash-case, spinal-case, lisp-case और caterpillar-case सभी एक ही चीज़ बताते हैं। Train-Case इसका बड़े-अक्षर वाला चचेरा भाई है (Hello-World), और dot.case बस पूर्ण-विरामों से अलग करता है। अंत में नवीनता वाली शैलियाँ हैं: aLtErNaTiNg CaSe (उर्फ़ "studly caps" या "mocking/SpongeBob case") हर वर्ण पर छोटे और बड़े के बीच पलटती है, और iNVERSE case हर अक्षर के मौजूदा केस को उलट देती है।

हर केस शैली कहाँ इस्तेमाल होती है

प्रोग्रामिंग भाषाएँ किसी एक परंपरा पर सहमत नहीं हैं, और "सही" केस चुनना ज़्यादातर उस समुदाय से मेल खाने की बात है जिसमें आपका कोड रहता है — लिंटर और कोड-समीक्षक इसे आपके लिए लागू करते हैं। Python की आधिकारिक स्टाइल गाइड, PEP 8, फ़ंक्शन और वैरिएबल के लिए snake_case, क्लास नामों के लिए PascalCase और मॉड्यूल-स्तर के कॉन्स्टेंट के लिए SCREAMING_SNAKE_CASE निर्धारित करती है। Ruby और Rust वही "मानों के लिए snake, टाइप के लिए Pascal" वाला विभाजन अपनाते हैं। C-परिवार और JavaScript की दुनिया कैमल केस पर टिकी है: Java और JavaScript वैरिएबल तथा मेथड के लिए camelCase और क्लास के लिए PascalCase इस्तेमाल करते हैं; C# मेथड नामों को भी बड़ा करता है। Go की अपनी एक ख़ासियत है — यह कैमल और पास्कल केस इस्तेमाल करता है पर बड़े-अक्षर को एक अर्थ देता है, क्योंकि जो पहचानकर्ता बड़े अक्षर से शुरू होता है वह अपने पैकेज से एक्सपोर्ट (सार्वजनिक) होता है जबकि छोटे अक्षर वाला निजी रहता है।

पहचानकर्ताओं के बाहर, परंपराएँ उल्लेखनीय रूप से एक-सी हैं। कॉन्स्टेंट और एनवायरनमेंट वैरिएबल लगभग सार्वभौमिक रूप से SCREAMING_SNAKE_CASE होते हैं (DATABASE_URL, MAX_RETRIES)। CSS क्लास नाम, HTML एट्रिब्यूट और URL स्लग kebab-case इस्तेमाल करते हैं क्योंकि हाइफ़न इन संदर्भों में हर जगह सुरक्षित है और शब्द-विराम की तरह पढ़ा जाता है। SQL टेबल और कॉलम परंपरागत रूप से snake_case इस्तेमाल करते हैं। और मानव के सामने आने वाले पाठ के लिए — हेडलाइन, नेविगेशन लेबल, बटन टेक्स्ट — चुनाव वाक्य केस (जिसे पठनीयता के लिए अब अधिकांश प्रोडक्ट और संपादकीय स्टाइल गाइड पसंद करते हैं) और टाइटल केस (जो प्रकाशित रचनाओं के शीर्षकों के लिए अब भी मानक है) के बीच होता है।

टाइटल केस दिखने से ज़्यादा मुश्किल है

"टाइटल केस" सुनने में एक ही नियम लगता है, पर इसका कोई एकल प्राधिकरण नहीं है — और प्रमुख स्टाइल गाइड सचमुच आपस में असहमत हैं। वे आसान हिस्सों पर सहमत हैं: हर गाइड पहले शब्द, मुख्य शब्दों (संज्ञा, सर्वनाम, क्रिया, विशेषण, क्रियाविशेषण) को बड़ा करती है, और बीच में आने पर आर्टिकल a, an और the को छोटा रखती है। वे छोटे जोड़ने वाले शब्दों — पूर्वसर्ग और संयोजक — पर मतभेद रखती हैं, और ठीक यहीं एक भोला कन्वर्टर शीर्षकों को ग़लत कर देता है।

सबसे साफ़ विभाजन पूर्वसर्गों पर है। AP (एसोसिएटेड प्रेस) और APA एक लंबाई-नियम इस्तेमाल करते हैं: तीन या कम अक्षरों वाले पूर्वसर्गों और संयोजकों को छोटा रखें, पर चार या अधिक अक्षरों वाले किसी भी शब्द को बड़ा करें — इसलिए AP लिखता है Gone With the Wind, चार-अक्षर वाले With को बड़ा करते हुए। Chicago (CMOS) और MLA उल्टा रुख़ अपनाते हैं और लंबाई की परवाह किए बिना सभी पूर्वसर्गों को छोटा रखते हैं, जिससे Gone with the Wind छोटे with के साथ बनता है। गाइड अंतिम शब्द पर भी भिन्न हैं: AP, Chicago और MLA शीर्षक के अंतिम शब्द को हमेशा बड़ा करते हैं, इसलिए अंत में आया पूर्वसर्ग भी बड़ा हो जाता है (What to Look For)। APA का कोई अंतिम-शब्द नियम नहीं है, इसलिए इसके लंबाई-नियम के तहत वही शीर्षक What to Look for पर ख़त्म होता है। समन्वयकारी संयोजक (and, but, or, nor, for, so, yet) अधिकांश गाइडों में छोटे रखे जाते हैं, हालाँकि Chicago so और yet को तब बड़ा मानता है जब वे क्रियाविशेषण की तरह काम करते हैं। व्यावहारिक सार: एक सामान्य "टाइटल केस" बटन — इस टूल वाले की तरह — एक उचित परंपरा लागू करता है, पर अगर आप किसी विशिष्ट स्टाइल गाइड के लिए लिख रहे हैं तो छोटे शब्दों को हमेशा हाथ से जाँच लें।

camelCase, snake_case और साथी: एक छोटा इतिहास

नाम इन प्रथाओं से कहीं नए हैं। शब्दों को भीतरी बड़े-अक्षरों से जोड़ना — जिसे टाइपोग्राफ़र और ऑक्सफ़ोर्ड इंग्लिश डिक्शनरी मीडियल कैपिटल्स कहते हैं — सदियों पुराना है, जो कंप्यूटर से बहुत पहले रासायनिक नामकरण और लिपिक संक्षेपण में दिखता है। यह 1970 के दशक में कई प्रोग्रामिंग भाषाओं में एक मानक पहचानकर्ता शैली बन गया, पर आकर्षक नाम बाद में आया: इस शैली के लिए सबसे पहले दर्ज शब्द "InterCaps" अप्रैल 1990 में Usenet पर दिखा, और "CamelCase" शब्द ख़ुद 1995 में Newton Love ने गढ़ा, जिन्होंने कहा कि "शैली के कूबड़पन" ने पहले उन्हें इसे HumpyCase कहने को प्रेरित किया। फिर डॉट-कॉम उछाल ने मीडियल कैपिटल्स को आम ब्रांड नामों में फैला दिया — iMac, PowerPoint, YouTube।

अंडरस्कोर परंपरा भी उतनी ही पुरानी है और इसका नाम उतना ही नया। अंडरस्कोर वाले पहचानकर्ता 1960 के दशक के उत्तरार्ध तक जाते हैं और C ने इन्हें पक्का कर दिया — ये The C Programming Language (1978) में भरे पड़े हैं — पर snake_case शब्द 2004 के आसपास ही Ruby समुदाय में लोकप्रिय हुआ, Gavin Kistner की एक Usenet पोस्ट में। kebab-case को इसका अनौपचारिक नाम इस बात से मिलता है कि हाइफ़न शब्दों को कबाब की सींक पर लगे माँस की तरह "छेदते" हैं; हाइफ़न-को-विभाजक बनाने की आदत ख़ुद Lisp से आती है, जिसके पहचानकर्ताओं में हमेशा हाइफ़न की अनुमति रही है, इसीलिए इस शैली को lisp-case भी कहते हैं। एक क़रीबी रिश्तेदार है हंगेरियन नोटेशन, जिसे Charles Simonyi ने Microsoft में गढ़ा (वे पहले Xerox PARC में काम कर चुके थे), जो एक वैरिएबल नाम के आगे उसके टाइप या भूमिका के लिए एक छोटा छोटे-अक्षर वाला टैग लगाता है (strName, iCount)। इसे "हंगेरियन" दोनों कारणों से कहते हैं — Simonyi के मूल की ओर इशारा, और इसलिए भी कि, हंगेरियन नामों की तरह, यह "दिए गए नाम" से पहले "टाइप" रखता है।

यूनिकोड जाल: बड़े-अक्षर करना सरल क्यों नहीं है

सादे अंग्रेज़ी के लिए केस बदलना मामूली है: दो समानांतर 26-अक्षरों वाली वर्णमालाओं के बीच खिसकना। बाक़ी दुनिया के लिए यह सचमुच कठिन है, क्योंकि केस मैपिंग भाषा-निर्भर है और हमेशा एक-से-एक नहीं होती। कुछ प्रलेखित जाल भोले कन्वर्टरों को फँसाते हैं:

• जर्मन ß की लंबाई बदल जाती है। शार्प s का ऐतिहासिक रूप से कोई एकल बड़ा रूप नहीं रहा, इसलिए ß का डिफ़ॉल्ट यूनिकोड बड़ा रूप दो-अक्षर वाला अनुक्रम SS है — यानी straße बड़ा होकर STRASSE बनता है और पाठ लंबा हो जाता है। एक बड़ा एस्ज़ेट ẞ (U+1E9E) 2008 में यूनिकोड में जोड़ा गया और 2017 में आधिकारिक जर्मन वर्तनी में स्वीकारा गया, पर चूँकि यह अब भी वैकल्पिक है, मानक मैपिंग SS ही बनी हुई है।
• तुर्की का बिंदुदार/बिंदुरहित i। तुर्की में दो अलग i हैं: बिंदुदार i/İ और बिंदुरहित ı/I। तुर्की i को बड़ा करने पर बिंदुदार बड़ा İ मिलना चाहिए, और I को छोटा करने पर बिंदुरहित ı — जो अंग्रेज़ी के बिल्कुल उल्टा है। तुर्की पाठ पर अंग्रेज़ी-लोकेल बड़ा-अक्षर लगाना उसे बिगाड़ देता है, जो असली बग़ों का एक मशहूर स्रोत है।
• यूनानी अंतिम सिग्मा। छोटा सिग्मा किसी शब्द के अंत में ς और अन्यत्र σ लिखा जाता है, इसलिए यूनानी शब्द को सही ढंग से छोटा करने के लिए यह जानना ज़रूरी है कि शब्द कहाँ ख़त्म होता है — यह संदर्भ एक एकल-वर्ण लुकअप नहीं दे सकता।
• लिगेचर और डाइग्राफ़। लिगेचर fl बड़ा होकर दो अक्षर FL बनता है। डाइग्राफ़ अक्षरों के दो नहीं, तीन रूप होते हैं: lj (छोटा), LJ (बड़ा) और एक अलग टाइटल-केस रूप Lj जो तब इस्तेमाल होता है जब किसी शब्द का केवल पहला अक्षर बड़ा किया जाता है।

व्यावहारिक सबक यह है कि केस रूपांतरण हमेशा वापस राउंड-ट्रिप नहीं करता — ß को SS बड़ा करके फिर छोटा करने पर ss मिलता है, मूल नहीं — और यह कि अंग्रेज़ी-लक्षित कन्वर्टर (इस जैसा) प्लेटफ़ॉर्म की डिफ़ॉल्ट, लोकेल-निरपेक्ष मैपिंग इस्तेमाल करता है। यह अंग्रेज़ी, पश्चिमी यूरोपीय पाठ और अधिकांश उच्चारण-चिह्न वाली लैटिन लिपि के लिए सही है, पर अगर आप तुर्की, अज़रबैजानी या सावधानी से टाइपसेट यूनानी पर केस लगा रहे हैं तो आपको एक लोकेल-सजग टूल चाहिए।

स्लग, पहचानकर्ता और SEO

जब आप किसी मानव शीर्षक को URL स्लग में बदलते हैं, तो पारंपरिक लक्ष्य छोटे अक्षरों वाला kebab-case होता है, और विभाजक का चुनाव सजावटी नहीं है। Google का पुराना मार्गदर्शन है कि URL में शब्दों को अलग करने के लिए हाइफ़न, अंडरस्कोर नहीं इस्तेमाल करें: एक सर्च इंजन red-running-shoes को तीन शब्दों की तरह पढ़ता है पर red_running_shoes को एकल टोकन redrunningshoes मानता है, जिससे मिलान कमज़ोर होता है। छोटे अक्षर भी मायने रखते हैं, क्योंकि कई सर्वरों पर URL पथ केस-संवेदी होते हैं, इसलिए केस मिलाना डुप्लिकेट URL या टूटे लिंक का जोखिम पैदा करता है। इसलिए एक अच्छा स्लग छोटे अक्षर करता है, स्पेस और विराम-चिह्नों को एकल हाइफ़न से बदलता है, उच्चारण-चिह्नों को सादे ASCII में लाता है, और छोटे भराव शब्दों को हटा देता है।

कोड पहचानकर्ताओं के लिए, समान सलाह बस यही है कि जिस भाषा और कोडबेस में आप हैं उसकी परंपरा से मेल खाएँ, क्योंकि एकरूपता ही नामों को पढ़ने-योग्य बनाती है और लिंटरों को शांत रखती है। केस शैलियाँ अर्थ में विनिमेय हैं — वही शब्द, बस अलग तरह से विरामित — और ठीक इसीलिए एक कन्वर्टर उपयोगी है: snake_case में एक कॉलम नाम पेस्ट करें और उसे सीधे camelCase प्रॉपर्टी के रूप में उठा लें जो आपके फ़्रंट-एंड को चाहिए, या किसी पेज शीर्षक को उस kebab-case स्लग में बदल दें जिसकी उसे ज़रूरत है।

आम केस-रूपांतरण ग़लतियाँ

• संक्षिप्ताक्षरों और व्यक्तिवाचक संज्ञाओं को बिगाड़ना। आँख मूँदकर टाइटल-केस लगाना हर शब्द की पूँछ को छोटा कर देता है, NASA को Nasa, iPhone को Iphone और McDonald को Mcdonald बना देता है। जानबूझकर किया गया बड़ा-अक्षर हमेशा मानवीय जाँच माँगता है।
• ग़लत नियम-पुस्तिका लगाना। AP के लंबाई-नियम से बना शीर्षक Chicago-शैली वाले दस्तावेज़ में ग़लत दिखता है और इसका उल्टा भी; बैच-रूपांतरण से पहले वह गाइड चुनें जो आपका प्रकाशन इस्तेमाल करता है।
• गद्य में प्रोग्रामर केस इस्तेमाल करना (या इसका उल्टा)। snake_case कोड में जँचता है, वाक्य में नहीं; टाइटल केस हेडिंग में जँचता है, वैरिएबल नाम में नहीं।
• URL में अंडरस्कोर। ये साफ़-सुथरे दिखते हैं पर SEO को कमज़ोर करते हैं — हाइफ़न की ओर हाथ बढ़ाएँ।
• ग़ैर-अंग्रेज़ी पाठ को भोलेपन से बड़ा करना, जो तुर्की, जर्मन और यूनानी को चुपचाप बिगाड़ देता है (ऊपर यूनिकोड जाल देखें)।
• राउंड-ट्रिप में डेटा खोना। पाठ को "सामान्यीकृत" करने के लिए छोटा करना और फिर दोबारा बड़ा करना शायद ही मूल को लौटाता है — एक बार अंतर मिट जाए तो मिट जाता है, इसलिए केस-संवेदी किसी भी चीज़ की एक अछूती प्रति रखें।

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

टाइटल केस (Title Case) क्या है?

टाइटल केस हर मुख्य शब्द के पहले अक्षर को बड़ा करता है। यह टूल आम परंपरा का पालन करता है: छोटे पूर्वसर्गों (of, in, on, at, to, for, from, with, by, up, as, a, an, the, and, but, or, nor) को छोड़कर बाकी सभी शब्दों का पहला अक्षर बड़ा किया जाता है — जब तक कि वे शीर्षक का पहला या अंतिम शब्द न हों।

camelCase और PascalCase में क्या अंतर है?

camelCase छोटे अक्षर से शुरू होता है (helloWorld), जबकि PascalCase (जिसे UpperCamelCase भी कहते हैं) बड़े अक्षर से शुरू होता है (HelloWorld)। camelCase आमतौर पर JavaScript के वैरिएबल नामों में इस्तेमाल होता है; PascalCase क्लास और कंपोनेंट नामों के लिए आम है।

snake_case बनाम kebab-case का उपयोग कब करूँ?

snake_case (अंडरस्कोर) Python के वैरिएबल और कॉन्स्टेंट में, और SQL कॉलम नामों में मानक है। kebab-case (हाइफ़न) CSS क्लास नामों, HTML एट्रिब्यूट और URL स्लग में मानक है। JavaScript आमतौर पर वैरिएबल के लिए camelCase पसंद करता है।

क्या यह यूनिकोड और उच्चारण-चिह्न वाले अक्षरों को संभालता है?

हाँ। बड़े/छोटे अक्षर में बदलने के लिए JavaScript के अंतर्निहित toUpperCase()/toLowerCase() का उपयोग होता है, जो उच्चारण-चिह्न वाले अक्षर, जर्मन ß → SS और अधिकांश यूनिकोड लिपियों को सही ढंग से संभालता है। camelCase और snake_case गैर-ASCII वर्ण और विराम-चिह्न हटा देते हैं, केवल अक्षर, अंक और स्पेस रखते हैं।

क्या कुछ भी सर्वर पर अपलोड होता है?

नहीं। सारा रूपांतरण आपके ब्राउज़र में होता है। आपका टेक्स्ट कभी आपके डिवाइस से बाहर नहीं जाता।

संबंधित टूल

• वर्ड काउंटर
• टेक्स्ट डिफ़ चेकर
• टेक्स्ट से हेक्स
• URL एन्कोड / डिकोड