Punycode / IDN कन्वर्टर

एन्कोडिंग

अंतरराष्ट्रीयकृत डोमेन नामों को Unicode (中文.com) और ASCII Punycode (xn--) के बीच बदलें। ईमेल पते और प्रति-लेबल विवरण का समर्थन करता है। RFC 3492।

100% क्लाइंट-साइड कोई बैकएंड नहीं

दूरस्थ URL लाए नहीं जाते; अपना JSON सीधे पेस्ट करें।

मोड

इनपुट

आउटपुट

RFC 3492 Punycode एन्कोडिंग; पूर्ण IDNA2008 मैपिंग नहीं है (कोई CheckBidi / CheckNFC नहीं)। IDNA2008 के तहत तकनीकी रूप से अमान्य ACE लेबल अभी भी डिकोड हो सकता है।

बदलने के लिए डोमेन या ईमेल दर्ज करें।

इस पृष्ठ पर

Punycode क्या है?#

डोमेन नेम सिस्टम ASCII पर बनाया गया था — अक्षर A-Z, अंक, और हाइफ़न। तो कोई ब्राउज़र 中文.com या münchen.de जैसे डोमेन को कैसे हल करता है, जिनके कैरेक्टर उस वर्णमाला में नहीं हैं? जवाब है Punycode (और इसके इर्द-गिर्द का IDN ढाँचा): एक उलटा हो सकने वाला एन्कोडिंग जो हर नॉन-ASCII लेबल को xn-- प्रीफ़िक्स से शुरू होने वाले ASCII-सेफ़ रूप में बदल देता है। DNS केवल xn--fiq228c.com देखता कभी; ब्राउज़र आपको 中文.com दिखाता है।

यह औज़ार दोनों दिशाओं में कन्वर्ट करता है:

ASCII में एक Unicode डोमेन या ईमेल लेता है और वह xn-- रूप बनाता है जिसे DNS और प्रमाणपत्र वास्तव में ढोते हैं। प्रत्येक लेबल स्वतंत्र रूप से कन्वर्ट होता है — münchen.中文.com xn--mnchen-3ya.xn--fiq228c.com बन जाता है, जिसमें अनुगामी .com वैसे ही छोड़ दिया जाता है क्योंकि वह पहले से ही ASCII है।
Unicode में उल्टा करता है: यह xn-- लेबलों को वापस मानव-पठनीय लिपि में पढ़ता है।

ईमेल भी संभाला जाता है। औज़ार @ का पता लगाता है, केवल डोमेन हिस्से को कन्वर्ट करता है, और स्थानीय हिस्से (मेलबॉक्स नाम) को वैसे ही रखता है — इसलिए Büchner@中文.com Bü[email protected] बन जाता है, कभी किसी विकृत पूरी-स्ट्रिंग कन्वर्सन में नहीं।

इसका उपयोग कैसे करें#

ऊपर-बाईं ओर टॉगल से ASCII में या Unicode में चुनें। औज़ार तब भी एक दिशा सुझाता है जब वह आपके इनपुट में कोई xn-- लेबल नोटिस करता है।
कोई डोमेन या ईमेल इनपुट पैनल में चिपकाएँ। हेडर बताता है कि इसे डोमेन या ईमेल के रूप में पहचाना गया।
कन्वर्ट किया गया परिणाम आउटपुट पैनल भरता है; उसे लेने के लिए कॉपी पर क्लिक करें।
पैनलों के नीचे, प्रति-लेबल विभाजन तालिका हर लेबल और जो वह बना दिखाती है — काम की जब किसी लंबे डोमेन में कई नॉन-ASCII लेबल हों और केवल कुछ बदले हों।
आउटपुट को वापस इनपुट में ले जाने और दिशा पलटने के लिए स्वैप (एक त्वरित राउंड-ट्रिप जाँच), münchen.中文.com लोड करने के लिए नमूना, और रीसेट करने के लिए साफ़ करें का उपयोग करें।

प्रमुख विशेषताएँ#

दोनों दिशाएँ, प्रत्येक लेबल अपने आप। हर लेबल स्वतंत्र रूप से कन्वर्ट होता है और विभाजन तालिका ठीक दिखाती है कि कौन बदले और कौन ASCII रहा।
ईमेल-जागरूक। एकल @ का पता लगाया जाता है और मेलबॉक्स नाम सुरक्षित रखा जाता है; केवल डोमेन पक्ष एन्कोड होता है। कई @ कैरेक्टरों वाला इनपुट स्पष्ट संदेश के साथ अस्वीकार किया जाता है बजाय चुपचाप परिणाम बिगाड़ने के।
सेपरेटर नॉर्मलाइज़ेशन। फुल-विड्थ डॉट ．, इडियोग्राफ़िक फुल स्टॉप 。, और हाफ़विड्थ ｡ सब उसी ASCII . के रूप में माने जाते हैं जैसे IDN में वास्तव में होते हैं, इसलिए चिपकाया गया टेक्स्ट नहीं टूटता।
विकृत इनपुट पर सख्त। एक खराब xn-- लेबल (जैसे xn--!!) दोषपूर्ण लेबल की ओर इशारा करती एक साफ़ त्रुटि उठाता है, बजाय गलत डोमेन निकालने के।
दायरे के बारे में ईमानदार। औज़ार के नीचे का अनुपालन नोट स्पष्ट रूप से कहता है कि यह Punycode एन्कोडिंग और मैपिंग चरण लागू करता है — यह कोई पूर्ण IDNA2008 वैधता जाँचक नहीं है, इसलिए कोई तकनीकी रूप से-अमान्य ACE लेबल यहाँ फिर भी डिकोड हो सकता है।

कार्य उदाहरण#

ASCII में कन्वर्ट करने पर, प्लेसहोल्डर münchen.中文.com बन जाता है:

xn--mnchen-3ya.xn--fiq228c.com

विभाजन तीन लेबल दिखाता है, जिनमें से दो कन्वर्ट हुए: münchen → xn--mnchen-3ya, 中文 → xn--fiq228c, और .com वैसे ही क्योंकि वह पहले से ASCII था। Unicode में पलटें और परिणाम को वापस चिपकाएँ münchen.中文.com बिलकुल वैसे ही बहाल करने के लिए।

कुछ और वास्तविक कन्वर्सन देखने लायक:

中文.com           → xn--fiq228c.com
münchen.de        → xn--mnchen-3ya.de
😂.com             → xn--g28h.com
café.fr           → xn--caf-dma.fr
日本語.jp          → xn--wgv71a119e.jp
Büchner@中文.com   → Bü[email protected]   (email: mailbox preserved)

आख़िरी वह मामला है जो लोगों को पकड़ लेता है: साधारण औज़ार पूरी स्ट्रिंग एन्कोड करते हैं और पता तोड़ देते हैं। यहाँ केवल @ के बाद का डोमेन हिस्सा बदलता है।

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

मेरा इमोज़ी डोमेन इतने छोटे `xn--` लेबल में क्यों कन्वर्ट होता है?#

😂.com जैसा एकल-कैरेक्टर इमोज़ी डोमेन xn--g28h.com बन जाता है क्योंकि Punycode एक नॉन-ASCII कैरेक्टर वाले लेबल के लिए जिसके बाद ASCII हो, असाधारण रूप से कॉम्पैक्ट है — यह नॉन-ASCII कैरेक्टरों की स्थिति और कोड पॉइंट्स को ASCII वालों के सापेक्ष एन्कोड करता है, इसलिए एक-कैरेक्टर लेबल को बहुत कम बाइट्स चाहिए। लंबे या अधिक विविध नॉन-ASCII लेबल लंबे ACE स्ट्रिंग्स बनाते हैं।

आउटपुट इनपुट जैसा ही दिखता है — क्या कुछ हुआ?#

यदि आपके इनपुट का हर लेबल पहले से शुद्ध ASCII है (जैसे example.com), तो एन्कोड करने के लिए कुछ नहीं, और आउटपुट इनपुट के बराबर है। विभाजन तालिका भरोसेमंद सूचक है: वह लेबल जिसका output अपने input से मेल खाता है वह कन्वर्ट नहीं हुआ, क्योंकि उसे ज़रूरत नहीं थी।

मैंने एक ईमेल चिपकाया और स्थानीय हिस्सा कन्वर्ट नहीं हुआ। क्या वह सही है?#

हाँ, और यह जानबूझकर है। अंतर्राष्ट्रीयकृत ईमेल (SMTPUTF8) मेलबॉक्स नाम में UTF-8 की अनुमति देता है, पर आम मामले के लिए उसे xn-- में कन्वर्ट करना गलत है — स्थानीय हिस्सा कोई DNS नाम नहीं है और Punycode द्वारा हल नहीं होता। यह औज़ार केवल डोमेन पक्ष कन्वर्ट करता है, जो वह हिस्सा है जिसे DNS-सुरक्षित होना ज़रूरी है। यही कारण है कि कई @ कैरेक्टर अस्वीकार किए जाते हैं: वे “डोमेन पक्ष” को अस्पष्ट बनाते हैं।

क्या मैं किसी भी डोमेन को रजिस्टर या हल करने के लिए ASCII रूप का उपयोग कर सकता हूँ?#

किसी भी आधुनिक ब्राउज़र या रिज़ॉल्वर द्वारा हल करने के लिए, हाँ। रजिस्ट्रेशन के लिए, नियम सख्त हैं: IDNA2008 कुछ कैरेक्टरों और नॉर्मलाइज़ेशन को अस्वीकार करता है जिन्हें पुराने मैपिंग (IDNA2003) अनुमति देते थे। यह औज़ार एन्कोडिंग भरोसेमंद ढंग से करता है पर पूर्ण IDNA2008 वैधता जाँच नहीं चलाता, इसलिए ऐसी स्ट्रिंग जो यहाँ साफ़-सुथरी एन्कोड हो, किसी रजिस्ट्रार द्वारा फिर भी अस्वीकार की जा सकती है। संदेह हो तो अपने रजिस्ट्रार के लुकअप औज़ार से पुष्टि करें।