टेक्स्ट की केसिंग कैसे कनवर्ट करें

नामकरण परंपराएँ मायने रखती हैं। चाहे आप कोड लिख रहे हों, फ़ाइल नाम बना रहे हों, या शीर्षक स्वरूपित कर रहे हों, सही पाठ केस का उपयोग करने से चीज़ें सुसंगत और पेशेवर रहती हैं। मैन्युअल रूप से केस के बीच परिवर्तित करना थकाऊ और त्रुटि-प्रवण है, विशेष रूप से लंबे पाठ या चर नामों के साथ। एक ब्राउज़र-आधारित कनवर्टर हर सामान्य केस प्रारूप को तुरंत संभालता है।

सामान्य पाठ केस और उनका उपयोग कहाँ होता है

पाठ केस कैसे बदलें

1. अपना पाठ चिपकाएँ: कनवर्टर में कोई भी पाठ दर्ज करें। यह एकल शब्दों, चर नामों, वाक्यों या पूरे पैराग्राफ़ के साथ काम करता है।
2. एक केस चुनें: उस प्रारूप पर क्लिक करें जो आप चाहते हैं। रूपांतरण तुरंत लागू होता है।
3. परिणाम कॉपी करें: अपने कोड, दस्तावेज़, या फ़ाइल नाम के लिए परिवर्तित पाठ प्राप्त करने के लिए कॉपी पर क्लिक करें।

कोड में नामकरण परंपराओं का संक्षिप्त इतिहास

प्रारंभिक प्रोग्रामिंग भाषाओं में पहचानकर्ता लंबाई पर कठोर सीमाएँ थीं: FORTRAN (1957) ने 6 वर्णों की अनुमति दी; ALGOL (1958) ने सीमित वर्णों की अनुमति दी। प्रोग्रामर्स को आक्रामक रूप से संक्षिप्त करना पड़ता था। केस परंपराओं की कोई आवश्यकता नहीं थी क्योंकि पहचानकर्ता कई शब्दों के लिए बहुत छोटे थे।

जब भाषाओं ने लंबे पहचानकर्ताओं की अनुमति दी (C 1972, Pascal 1970), तो शब्दों को अलग करना एक प्रश्न बन गया। Pascal ने शब्दों को अलग करने के लिए बड़े अक्षरों के उपयोग को लोकप्रिय बनाया: MyVariable। C ने ऐतिहासिक रूप से अंडरस्कोर के साथ छोटे अक्षरों का उपयोग किया: my_variable। विभाजन बना रहा है: अधिकांश C-परिवार और Unix भाषाएँ snake_case पसंद करती हैं (Python, Ruby, Rust डिफ़ॉल्ट रूप से, PostgreSQL कॉलम), जबकि Java-परिवार और Microsoft भाषाएँ camelCase पसंद करती हैं (JavaScript, Java, C#, Swift, Kotlin)।

PascalCase Smalltalk (1980 के दशक) से वर्ग नामों के लिए उभरा, फिर C++ (1985), Java (1995), और C# (2000) द्वारा अपनाया गया। आज अधिकांश भाषाएँ शब्द विभाजक वरीयता की परवाह किए बिना प्रकार/वर्गों के लिए PascalCase और उदाहरणों/फ़ंक्शनों के लिए camelCase का उपयोग करती हैं।

kebab-case वेब के साथ दिखाई दिया: CSS ने हाइफ़न चुना (background-color) और URL भी उन्हें पसंद करते हैं। अधिकांश आधुनिक वेब भाषाएँ (HTML, CSS, URL पथ, JSON स्कीमा) उपयोगकर्ता-दृश्य पहचानकर्ताओं के लिए kebab-case का उपयोग करती हैं।

सबसे नई परंपरा स्थिरांकों और पर्यावरण चरों के लिए SCREAMING_SNAKE_CASE है: एक Unix शेल विरासत जो 2000 के दशक तक अधिकांश प्रोग्रामिंग भाषाओं में चली गई।

प्रत्येक परंपरा का उपयोग कब करें

एक व्यावहारिक गाइड:

• UPPERCASE गद्य में: संक्षिप्ताक्षर (NASA, HTML, CSS), जोर (शायद ही कभी; बोल्ड आमतौर पर बेहतर है), डिज़ाइन सिस्टम में शीर्षक जो इसे निर्दिष्ट करते हैं।
• lowercase गद्य में: URL, ईमेल पते, हैशटैग, आकस्मिक चैट। कोड में: शायद ही कभी, कुछ Lisp वेरिएंट को छोड़कर।
• शीर्षक केस: पुस्तक शीर्षक, लेख शीर्षक, उचित संज्ञाएँ। विभिन्न शैली गाइडों के पास किन शब्दों को बड़े अक्षर में लिखना है के बारे में अलग-अलग नियम हैं।
• वाक्य केस: आधुनिक डिज़ाइन सिस्टम में शरीर पाठ, विवरण, UI लेबल के लिए मानक (Material Design, Apple HIG दोनों बटनों के लिए वाक्य केस पसंद करते हैं)।
• camelCase: JavaScript/TypeScript चर, Java/Swift विधि नाम, अधिकांश OO भाषाओं में उदाहरण चर।
• PascalCase: वर्ग नाम, प्रकार नाम, React/Vue घटक नाम, एनम प्रकार।
• snake_case: Python और Ruby चर/फ़ंक्शन, डेटाबेस कॉलम नाम, GraphQL फ़ील्ड नाम (कभी-कभी), शेल चर।
• SCREAMING_SNAKE_CASE: अधिकांश भाषाओं में स्थिरांक, पर्यावरण चर (DATABASE_URL, NODE_ENV), YAML/JSON में कॉन्फ़िग कुंजियाँ।
• kebab-case: URL slug, CSS वर्ग नाम, HTML data-* विशेषताएँ, npm पैकेज नाम, स्थैतिक-साइट जनरेटरों में फ़ाइल नाम।
• dot.case: कोड में ऑब्जेक्ट संपत्ति पथ, कॉन्फ़िग फ़ाइलें (Nginx, Spring Boot गुण), नेमस्पेस्ड इवेंट।

शीर्षक केस नियम

«शीर्षक केस» सरल लगता है लेकिन इसमें शैली-गाइड जटिलताएँ हैं:

• APA शैली: 4+ अक्षरों के शब्दों को बड़े अक्षर में लिखें; लंबाई की परवाह किए बिना सभी संज्ञाओं, क्रियाओं, विशेषणों, क्रियाविशेषणों को बड़े अक्षर में लिखें।
• Chicago Manual of Style: पहले/अंतिम शब्दों को बड़े अक्षर में लिखें; सभी संज्ञाओं, क्रियाओं, विशेषणों, क्रियाविशेषणों, सर्वनामों को बड़े अक्षर में लिखें; अनुच्छेद (a, an, the), छोटे पूर्वसर्ग, समन्वय संयोजन (and, but, or) को छोटे अक्षरों में।
• AP शैली: 4+ अक्षरों के सभी शब्दों को बड़े अक्षर में लिखें; पूर्वसर्गों के लिए विशिष्ट अपवाद।
• MLA शैली: Chicago के समान लेकिन पूर्वसर्ग हैंडलिंग में मामूली अंतर के साथ।

एक «सरल शीर्षक केस» कनवर्टर हर शब्द को बड़े अक्षर में लिखता है (जो तकनीकी रूप से किसी प्रमुख शैली गाइड से मेल नहीं खाता)। अधिकांश कनवर्टर «Title Case» को त्वरित अनुमान के रूप में पेश करते हैं लेकिन परिणाम को निम्न के लिए मैन्युअल समीक्षा हेतु ध्वजांकित करते हैं:

• अनुच्छेद (a, an, the)
• संयोजन (and, but, or, for, nor)
• छोटे पूर्वसर्ग (in, on, at, by, to, of)
• संक्षिप्ताक्षर (API, HTTP, CSS)

सामान्य कठिनाइयाँ

• camelCase में संक्षिप्ताक्षर: xmlHTTPRequest अजीब है। Google की JavaScript शैली गाइड संक्षिप्ताक्षरों को शब्दों के रूप में मानने की सिफारिश करती है: xmlHttpRequest या XmlHttpRequest। Microsoft और Java शैली गाइड उन्हें सभी-बड़े अक्षरों में रखते हैं: XMLHttpRequest। एक परंपरा चुनें।
• पहचानकर्ताओं में संख्याएँ: version2Point0 vs version2_0 vs version20। कोई सार्वभौमिक नियम नहीं; भाषा परंपरा पर निर्भर करता है।
• प्रारंभिक अक्षर-बड़े अक्षर वाले संक्षिप्ताक्षर: «i18n» camelCase है, «I18n» PascalCase है, «I18N» screaming है। अपने संदर्भ से मेल करें।
• पूर्वसर्गों पर शीर्षक केस: «Off The Record» अधिकांश संपादकों को गलत लगता है; «Off the Record» अधिकांश शैली गाइडों का पालन करता है। प्रकाशन से पहले सत्यापित करें।
• डेटाबेस केस परंपराएँ भिन्न होती हैं: PostgreSQL और अधिकांश SQL कार्यान्वयन गैर-उद्धृत पहचानकर्ताओं के लिए केस-असंवेदनशील हैं लेकिन उद्धृत पहचानकर्ताओं के लिए केस-संवेदनशील हैं। यदि वास्तविक कॉलम नाम mycolumn है तो SELECT myColumn FROM table विफल हो सकता है।
• OS द्वारा फ़ाइल नाम केस संवेदनशीलता: macOS HFS+ डिफ़ॉल्ट रूप से केस-असंवेदनशील है; APFS केस-असंवेदनशील है लेकिन केस-संरक्षण है; Linux ext4 केस-संवेदनशील है; Windows NTFS केस-असंवेदनशील है (लेकिन Windows पर Linux उपप्रणालियाँ केस-संवेदनशील हैं)। MyFile.txt और myfile.txt एक ही फ़ाइल हो सकती हैं या नहीं।
• Unicode केस स्थानीय-निर्भर है: बड़ा İ (तुर्की बिंदुयुक्त I) vs I (अंग्रेज़ी)। कुछ toUpperCase() कार्यान्वयन स्पष्ट स्थानीय के बिना यह गलत कर देते हैं।

सुझाव

• अपनी भाषा की परंपरा से मेल करें: Python snake_case का उपयोग करता है, JavaScript camelCase का उपयोग करता है, और CSS kebab-case का उपयोग करता है। एक कोडबेस के भीतर संगति व्यक्तिगत वरीयता से अधिक महत्वपूर्ण है।
• Unicode समर्थित है: कनवर्टर उच्चारण वर्णों, इमोजी, और CJK वर्णों को संभालता है, इसलिए यह किसी भी भाषा में पाठ के साथ काम करता है।
• शीर्षक केस में संक्षिप्ताक्षरों की जाँच करें: अधिकांश शीर्षक केस कनवर्टर हर शब्द को बड़े अक्षर में लिखते हैं, जो «API» को «Api» में बदल सकता है। परिवर्तित करने के बाद संक्षिप्ताक्षरों की समीक्षा करें।
• पठनीयता के लिए वाक्य केस का उपयोग करें: बटन लेबल और विवरण जैसे उपयोगकर्ता-सामना वाले पाठ के लिए, वाक्य केस अक्सर शीर्षक केस की तुलना में पढ़ने में आसान होता है।
• अपने linter को कॉन्फ़िगर करें: ESLint, Prettier, Pylint, RuboCop सभी स्वचालित रूप से नामकरण परंपराओं को लागू कर सकते हैं। उन्हें एक बार सेट करें और linter को save पर केस उल्लंघनों को पकड़ने दें।
• कोड-स्टाइल गाइड का उपयोग करें: Google, Airbnb, Microsoft, GitHub सभी प्रमुख भाषाओं के लिए शैली गाइड प्रकाशित करते हैं। अपनी परियोजना के लिए एक चुनें और उससे चिपके रहें।

गोपनीयता और गोपनीय पाठ

केस कनवर्टर पूरी तरह से आपके ब्राउज़र में चलता है। आप जो पाठ चिपकाते हैं, मध्यवर्ती रूपांतरण, और आउटपुट सभी आपके डिवाइस पर रहते हैं। कुछ भी सर्वर पर अपलोड, लॉग, या किसी के साथ साझा नहीं किया जाता है।

यह मायने रखता है क्योंकि आप जो स्ट्रिंग्स परिवर्तित करते हैं वे अक्सर गोपनीय होती हैं: मालिकाना कोडबेस से चर नाम, आंतरिक API एंडपॉइंट्स, मसौदा लेख शीर्षक, प्रतिबंध के तहत ग्राहक-सामना वाली प्रति, उत्पाद संरचना प्रकट करने वाले डेटाबेस कॉलम नाम। क्लाउड केस कनवर्टर अपने अनुरोध लॉग में प्रत्येक रूपांतरण को लॉग करते हैं और उन्हें «सुधार» या एनालिटिक्स के लिए उपयोग कर सकते हैं। केवल-ब्राउज़र कनवर्टर में शून्य एक्सपोज़र है, और पृष्ठ लोड होने के बाद ऑफ़लाइन काम करता है।