dot.case कन्वर्टर: पैकेज और डोमेन नेम जनरेटर
किसी भी टेक्स्ट को तुरंत साफ़ dot.case फ़ॉर्मैट में बदलें। चाहे आप Java पैकेज का नाम रख रहे हों, डोमेन नाम बना रहे हों, या हायरार्किकल नेमस्पेस को व्यवस्थित कर रहे हों, हमारा टूल प्रोग्रामिंग और वेब के नियमों का पालन करते हुए आपके टेक्स्ट को अपने-आप सही dot.case फ़ॉर्मैटिंग में बदल देता है।
किसी भी टेक्स्ट को तुरंत सही dot.case में बदलें — पैकेज पाथ, कॉन्फ़िग की (config key) या कोई साधारण फ़्रेज़ पेस्ट करें और Java, Kotlin या कॉन्फ़िगरेशन फ़ाइलों के लिए डॉट से अलग किया हुआ, लोअरकेस आइडेंटिफ़ायर पाएँ।
पदानुक्रमित संरचना को बनाए रखता है: हर शब्द या खंड डॉट से अलग होने वाला एक घटक बन जाता है, जिससे आउटपुट में नेमस्पेस की गहराई तुरंत दिखाई देती है।
यह Java पैकेज नामों और डोमेन आइडेंटिफ़ायर्स में अमान्य कैरेक्टर्स — जैसे स्लैश, हाइफ़न और अंडरस्कोर — को हटा देता है, जिससे बिना किसी अतिरिक्त प्रोसेसिंग के एक साफ़ नेमस्पेस पाथ मिलता है।
यह कई तरह के फ़ॉर्मैट से इनपुट लेता है: स्पेस से अलग किए गए फ़्रेज़, camelCase, snake_case और kebab-case, सभी से एक जैसा dot.case आउटपुट मिलता है।
यह सिर्फ़ लोअरकेस (छोटे अक्षरों) में आउटपुट देता है, जो जावा पैकेज के नाम रखने के उस नियम से मेल खाता है जिसमें क्लास के नामों के साथ भ्रम से बचने के लिए अपरकेस (बड़े अक्षरों) का इस्तेमाल साफ़ तौर पर मना है।
यह रिवर्स-डोमेन नोटेशन (com.company.project), प्रॉपर्टी की हायरार्की (app.server.port) और लॉग कैटेगरी के नामों के लिए काम करता है — तीनों ही मामलों में कन्वर्ज़न का एक ही लॉजिक लागू होता है।
कैसे इस्तेमाल करें
अपना टेक्स्ट या पैकेज का नाम डालें
नेमस्पेस-रेडी टेक्स्ट कॉपी करें
जावा डेवलपमेंट
- पैकेज के नाम
- नेमस्पेस का संगठन
- मॉड्यूल आइडेंटिफ़ायर
- लाइब्रेरी पाथ
वेब डेवलपमेंट
- डोमेन नाम
- रिवर्स डोमेन
- ईमेल पते
- कॉन्फ़िगरेशन कीज़
सिस्टम का संगठन
- फ़ाइल पाथ
- कॉन्फ़िगरेशन कीज़
- रजिस्ट्री एंट्रीज़
- ऑब्जेक्ट नोटेशन
| मूल पाठ | परिणाम |
|---|---|
com user profile | com.user.profile |
org-project-main | org.project.main |
web_app_config | web.app.config |
domain name system | domain.name.system |
प्रोग्रामिंग
- जावा
- एंड्रॉयड
- कोटलिन
- स्काला
वेब सिस्टम
- DNS
- ईमेल
- कॉन्फ़िग फ़ाइलें
- पैकेज के नाम
जब आप कोई नया Java या Kotlin प्रोजेक्ट बना रहे हों, तो कोई भी कोड लिखने से पहले इस कन्वर्टर का इस्तेमाल करके रूट पैकेज का नाम (com.yourcompany.projectname) तय कर लें — क्योंकि क्लास बन जाने के बाद पैकेज का नाम बदलने पर हर फ़ाइल में मौजूद हर इंपोर्ट स्टेटमेंट को रिफ़ैक्टर करना पड़ता है।
Spring Boot की application.properties या application.yml फ़ाइलों के लिए, कॉन्फ़िगरेशन कीज़ डॉट-सेपरेटेड हायरार्की (जैसे spring.datasource.url, server.port) को फ़ॉलो करती हैं — सही फ़ॉर्मैट वाले प्रॉपर्टी नाम पाने के लिए अपनी कस्टम कॉन्फ़िग की-डिस्क्रिप्शन को यहाँ कन्वर्ट करें।
Log4j और SLF4J लॉगर के नाम आम तौर पर dot.case में पूरी तरह से बताए गए क्लास के नाम होते हैं; जब आप अपनी लॉगिंग कॉन्फ़िगरेशन में हर पैकेज के लिए लॉग लेवल सेट कर रहे हों, तो पैकेज पाथ को सही ढंग से फ़ॉर्मेट करने के लिए इस टूल का इस्तेमाल करें।
Android पैकेज के नाम Java की तरह ही 'रिवर्स-डोमेन डॉट-केस' कन्वेंशन को फॉलो करते हैं। build.gradle में सेट करने से पहले अपने ऐप आइडेंटिफ़ायर (com.yourname.appname) को यहाँ कन्वर्ट करके पक्का कर लें कि वह सही है, क्योंकि Play Store पर पब्लिश करने के बाद पैकेज के नाम बदले नहीं जा सकते।
JavaScript और Node.js में, dotenv-expand, nconf और convict जैसी लाइब्रेरीज़ में नेस्टेड कॉन्फ़िग कीज़ (nested config keys) के लिए डॉट-नोटेशन का इस्तेमाल किया जाता है — अपना कॉन्फ़िग स्कीमा लिखने से पहले नेस्टेड कॉन्फ़िगरेशन की पाथ्स (paths) को फ़ॉर्मेट करने के लिए इस टूल का इस्तेमाल करें।
Java पैकेज के नाम हमेशा अपनी ऑर्गनाइज़ेशन के रिवर्स डोमेन (जैसे com.yourcompany) से शुरू करें, न कि 'app' या 'util' जैसे जेनेरिक प्रीफ़िक्स से — क्योंकि जेनेरिक नाम अलग-अलग प्रोजेक्ट्स में आपस में टकरा सकते हैं और मल्टी-मॉड्यूल बिल्ड में डिपेंडेंसी रिज़ॉल्यूशन को उलझा सकते हैं।
डॉट से अलग किए गए हर हिस्से को छोटे अक्षरों (lowercase) वाले एक शब्द के तौर पर रखें और शुरुआत में कोई नंबर न लगाएं — जावा कंपाइलर हिस्सों के अंदर नंबर स्वीकार करते हैं, लेकिन कई बिल्ड टूल और IDE रीफैक्टरिंग फ़ीचर नंबर से शुरू होने वाले पैकेज नामों के साथ अजीब तरह से काम करते हैं।
सेगमेंट के नामों के तौर पर Java के रिज़र्व्ड वर्ड्स (जैसे class, interface, package, import) का इस्तेमाल करने से बचें — JVM इनमें से कुछ को पैकेज आइडेंटिफ़ायर में इस्तेमाल करने की इजाज़त देता है, लेकिन IDE और लिनटर इन्हें कन्फ़्यूजिंग मानते हैं और कुछ बिल्ड टूल्स तो इन्हें पूरी तरह से रिजेक्ट कर देते हैं।
कॉन्फ़िगरेशन की-हायरार्की (keys की बनावट) के लिए एक जैसी गहराई (depth) का इस्तेमाल करें — एक ही कॉन्फ़िग फ़ाइल में फ़्लैट कीज़ (जैसे database) और डीप कीज़ (जैसे app.server.database.pool.maxSize) को मिलाने से एक उलझन भरी समझ बनती है, जिससे कॉन्फ़िगरेशन ऑडिट करना मुश्किल हो जाता है।
Android ऐप पब्लिश करते समय, Play Store पर पहली बार रिलीज़ करने से पहले ही पैकेज का नाम तय कर लें — प्रोजेक्ट में मौजूद ज़्यादातर दूसरे आइडेंटिफ़ायर के उलट, Android पैकेज का नाम आपके ऐप की लिस्टिंग से हमेशा के लिए जुड़ जाता है और स्टोर पर पूरी तरह से नई एंट्री बनाए बिना इसे बदला नहीं जा सकता।
अक्सर पूछे जाने वाले सवाल
हमारे टूल्स और सेवाओं के बारे में आम सवालों के जवाब पाएँ।
डॉट.केस को समझना
dot.case प्रोग्रामिंग में नाम रखने के उन आम तरीकों में सबसे पुराना है जो आज भी रोज़ाना इस्तेमाल होते हैं। 1996 में Java 1.0 में इसे पैकेज का नाम रखने का ज़रूरी तरीका बनाने से पहले, यह शुरुआती Lisp सिस्टम और Unix कॉन्फ़िगरेशन फ़ाइलों में दिखाई दिया था। Java लैंग्वेज स्पेसिफ़िकेशन के अनुसार, पूरे इकोसिस्टम में ग्लोबल यूनिकनेस (हर जगह अलग पहचान) पक्का करने के लिए पैकेज के नाम लोअरकेस में और डॉट से अलग किए गए आइडेंटिफ़ायर होने चाहिए, जो रिवर्स डोमेन ऑर्डर (जैसे com.company.product) में हों। इस ज़रूरत ने dot.case को डेवलपर्स के बीच मुख्यधारा के कल्चर में उस तरह से पहुँचाया जैसा कोई और तरीका नहीं कर पाया था, क्योंकि हर Java फ़ाइल पैकेज डिक्लेरेशन से शुरू होती है।
इस कन्वर्टर का मुख्य रोज़ाना इस्तेमाल Java और Kotlin डेवलपमेंट में होता है। जब आप कोई नया मॉड्यूल, लाइब्रेरी या Android ऐप शुरू करते हैं, तो पहली क्लास बनाने से पहले आपको एक पैकेज आइडेंटिफ़ायर की ज़रूरत होती है। प्रोडक्ट मैनेजर और डिज़ाइनर प्रोजेक्ट के नाम आम अंग्रेज़ी में देते हैं (जैसे 'User Authentication Service', 'Payment Gateway Client'); यह टूल उन्हें सही पैकेज पाथ सेगमेंट में बदल देता है, जिनके आगे आप अपनी ऑर्गनाइज़ेशन का रिवर्स डोमेन लगा सकते हैं। यह कन्वर्ज़न इतना आसान है कि डेवलपर्स अक्सर इसे मन में ही कर लेते हैं, लेकिन कई शब्दों वाले नामों को मैन्युअल रूप से बदलने पर एकरूपता की कमी हो सकती है — जैसे 'auth service' को टाइप करने वाले के हिसाब से com.company.authservice, com.company.auth_service या com.company.authService लिखा जा सकता है।
दूसरा इस्तेमाल Spring Boot और सामान्य JVM कॉन्फ़िगरेशन का है। Spring का एक्सटर्नलाइज़्ड कॉन्फ़िगरेशन सिस्टम डॉट से अलग की गई की-हायरार्की (key hierarchies) का बड़े पैमाने पर इस्तेमाल करता है: जैसे spring.datasource.url, spring.jpa.hibernate.ddl-auto, management.endpoints.web.exposure.include। जब आप अपने एप्लीकेशन के लिए खास कॉन्फ़िगरेशन प्रॉपर्टीज़ तय करते हैं, तो Spring के कन्वेंशन (तरीके) को अपनाने से आपकी कीज़ (keys) फ्रेमवर्क का ही हिस्सा लगती हैं और Spring Boot के कॉन्फ़िगरेशन बाइंडिंग और रिलैक्स्ड बाइंडिंग नियमों के साथ कम्पैटिबिलिटी पक्की होती है।
JVM की दुनिया के बाहर, dot.case इन जगहों पर दिखता है: कॉन्फ़िगरेशन की के (keys) के तौर पर इस्तेमाल होने वाली JavaScript ऑब्जेक्ट प्रॉपर्टी चेन (जैसे webpack resolve.alias, eslint rules.no-unused-vars), Python लॉगिंग कॉन्फ़िगरेशन (जैसे logging.getLogger('myapp.services.auth')), YAML कॉन्फ़िगरेशन हायरार्की जिन्हें कॉन्फ़िगरेशन लाइब्रेरीज़ डॉट को सेपरेटर के तौर पर इस्तेमाल करके फ़्लैट (flatten) करती हैं, और DNS होस्टनेम जहाँ हर लेबल डॉट से अलग किया गया एक कंपोनेंट होता है। यह कन्वर्टर इन सभी संदर्भों में उपयोगी है, भले ही इसमें Java पैकेज शामिल न हों।
छोटे नामों के लिए मैन्युअल तरीका आसान है, लेकिन बड़े पैमाने पर इसमें गलतियाँ हो सकती हैं: सभी अक्षरों को छोटे (lowercase) में बदलना, नॉन-अल्फ़ान्यूमेरिक कैरेक्टर हटाना और डॉट्स से जोड़ना। डेवलपर्स अक्सर जिन मुश्किल मामलों में फंस जाते हैं, वे हैं: लगातार सेपरेटर (जैसे कई स्पेस या अंडरस्कोर और हाइफ़न के मेल से बनने वाले डबल डॉट्स), किसी सेगमेंट की शुरुआत में अंक होना (जो Java पैकेज में अमान्य है), और गलती से पूरे रिवर्स डोमेन के बजाय प्रोजेक्ट के TLD को एक सेगमेंट के तौर पर शामिल कर लेना। यह टूल इन सभी मामलों को सही फ़ॉर्मेट में बदल देता है।