Punycode / IDN কনভার্টার
এনকোডিংআন্তর্জাতিক ডোমেইন নামগুলোকে Unicode (中文.com) এবং ASCII Punycode (xn--) এর মধ্যে রূপান্তর করুন। ইমেল ঠিকানা এবং লেবেল অনুযায়ী বিবরণ সমর্থন করে। RFC 3492।
দূরবর্তী URL আনা হয় না; আপনার JSON সরাসরি পেস্ট করুন।
RFC 3492 Punycode এনকোডিং; সম্পূর্ণ IDNA2008 ম্যাপিং নয় (কোনো CheckBidi / CheckNFC নেই)। IDNA2008 অনুযায়ী কারিগরিভাবে অবৈধ ACE লেবেল এখনও ডিকোড হতে পারে।
এই পৃষ্ঠায়
Punycode কী?#
Domain Name System ASCII-এর উপর নির্মিত ছিল — A-Z অক্ষর, সংখ্যা, এবং হাইফেন। তাহলে একটি ব্রাউজার কীভাবে 中文.com বা münchen.de-এর মতো একটি ডোমেইন সমাধান করে, যাদের অক্ষরগুলো সেই অক্ষরমালায় নেই? উত্তর হলো Punycode (এবং এর চারপাশের IDN ফ্রেমওয়ার্ক): একটি উল্টোদিকে ফেরানো যায় এমন এনকোডিং যা প্রতিটি নন-ASCII লেবেলকে xn-- প্রিফিক্স দিয়ে শুরু একটি ASCII-নিরাপদ রূপে পরিণত করে। DNS শুধুমাত্র xn--fiq228c.com দেখে; ব্রাউজার আপনাকে 中文.com দেখায়।
এই টুলটি উভয় দিকে কনভার্ট করে:
- Unicode → Punycode একটি Unicode ডোমেইন বা ইমেল নেয় এবং
xn--রূপ তৈরি করে যা DNS এবং সার্টিফিকেট আসলে বহন করে। প্রতিটি লেবেল স্বাধীনভাবে কনভার্ট করা হয় —münchen.中文.comহয়ে যায়xn--mnchen-3ya.xn--fiq228c.com, শেষের.comএকা রাখা হয় কারণ এটি ইতিমধ্যে ASCII। - Punycode → Unicode উল্টোটা করে: এটি
xn--লেবেলগুলোকে মানব-পঠনযোগ্য লিপিতে ফিরিয়ে পড়ে।
ইমেলও সামলানো হয়। টুলটি @ সনাক্ত করে, শুধুমাত্র ডোমেইন অংশ কনভার্ট করে, এবং লোকাল অংশ (মেইলবক্স নাম) অস্পর্শিত রাখে — তাই Büchner@中文.com হয়ে যায় Bü[email protected], কখনো একটি বিকৃত সম্পূর্ণ-স্ট্রিং কনভার্সন নয়।
ব্যবহারবিধি#
- উপরের বাম দিকের টগল থেকে Unicode → Punycode বা Punycode → Unicode বেছে নিন। টুলটি একটি দিকও পরামর্শ দেয় যখন এটি আপনার ইনপুটে একটি
xn--লেবেল খেয়াল করে। - ইনপুট পেইনে একটি ডোমেইন বা একটি ইমেল পেস্ট করুন। হেডারটি দেখায় এটিকে একটি ডোমেইন নাকি ইমেল হিসেবে চেনা হয়েছে।
- কনভার্ট করা ফলাফল আউটপুট পেইন পূরণ করে; নেওয়ার জন্য কপি ক্লিক করুন।
- পেইনগুলোর নিচে, প্রতি-লেবেল বিবরণ টেবিল প্রতিটি লেবেল এবং কী হয়েছে তা দেখায় — কার্যকর যখন একটি লম্বা ডোমেইনে বেশ কয়েকটি নন-ASCII লেবেল থাকে এবং শুধু কয়েকটি পরিবর্তিত হয়।
- আউটপুটকে আবার ইনপুটে নিতে এবং দিক উল্টে দিতে আউটপুট → ইনপুট ব্যবহার করুন (একটি দ্রুত রাউন্ড-ট্রিপ যাচাই),
münchen.中文.comলোড করতে নমুনা, এবং রিসেট করতে মুছুন।
মূল বৈশিষ্ট্য#
- উভয় দিক, প্রতিটি লেবেল নিজে নিজে। প্রতিটি লেবেল স্বাধীনভাবে কনভার্ট করা হয় এবং বিবরণ টেবিল ঠিক দেখায় কোনগুলো পরিবর্তিত হয়েছে এবং কোনগুলো ASCII হয়ে গেছে।
- ইমেল-সচেতন। একটি একক
@সনাক্ত করা হয় এবং মেইলবক্স নাম সংরক্ষিত হয়; শুধুমাত্র ডোমেইন পাশ এনকোড করা হয়। একাধিক@অক্ষর সহ ইনপুট একটি স্পষ্ট বার্তা সহ প্রত্যাখ্যান করা হয়, নীরবে ফলাফল দূষিত করার বদলে। - বিভাজক নরমালাইজেশন। ফুল-উইডথ ডট
., আইডিওগ্রাফিক ফুল স্টপ।, এবং হাফউইডথ。সবই IDN-এ যেমন আসলে ASCII.তা হিসেবে গণ্য হয়, তাই পেস্ট করা টেক্সট ভাঙে না। - ত্রুটিপূর্ণ ইনপুটে কঠোর। একটি খারাপ
xn--লেবেল (যেমনxn--!!) একটি পরিষ্কার ত্রুটি উত্থাপন করে যা ত্রুটিপূর্ণ লেবেলটিকে নির্দেশ করে, একটি ভুল ডোমেইন তৈরি করার বদলে। - সুযোগ সম্পর্কে সৎ। টুলের নিচের সম্মতি নোটটি স্পষ্টভাবে বলে যে এটি Punycode এনকোডিং এবং ম্যাপিং ধাপ বাস্তবায়ন করে — এটি একটি সম্পূর্ণ IDNA2008 বৈধতা যাচাইকারী নয়, তাই একটি কারিগরিভাবে-অবৈধ ACE লেবেল এখানে এখনও ডিকোড হতে পারে।
ব্যবহারিক উদাহরণ#
Unicode → Punycode-এ কনভার্ট করলে, প্লেসহোল্ডার münchen.中文.com হয়ে যায়:
xn--mnchen-3ya.xn--fiq228c.com
বিবরণটি তিনটি লেবেল দেখায়, যাদের মধ্যে দুটি কনভার্ট করা হয়েছে: münchen → xn--mnchen-3ya, 中文 → xn--fiq228c, এবং .com অস্পর্শিত কারণ এটি ইতিমধ্যে ASCII ছিল। Punycode → 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), এনকোড করার মতো কিছু নেই, এবং আউটপুট ইনপুটের সমান। বিবরণ টেবিলটি হলো নির্ভরযোগ্য নির্দেশক: এমন একটি লেবেল যার আউটপুট তার ইনপুট-এর সাথে মেলে তা কনভার্ট করা হয়নি, কারণ তা প্রয়োজন ছিল না।
আমি একটি ইমেল পেস্ট করেছি এবং লোকাল অংশটি কনভার্ট হয়নি। এটি কি সঠিক?#
হ্যাঁ, এবং এটি ইচ্ছাকৃত। আন্তর্জাতিককৃত ইমেল (SMTPUTF8) মেইলবক্স নামে UTF-8 অনুমোদন করে, কিন্তু তা xn---এ কনভার্ট করা সাধারণ ক্ষেত্রের জন্য ভুল — লোকাল অংশটি একটি DNS নাম নয় এবং Punycode দ্বারা সমাধান করা হয় না। এই টুলটি শুধুমাত্র ডোমেইন পাশ কনভার্ট করে, যা সেই অংশ যা অবশ্যই DNS-নিরাপদ হতে হবে। এটিও কেন একাধিক @ অক্ষর প্রত্যাখ্যান করা হয়: সেগুলো “ডোমেইন পাশ” অস্পষ্ট করে তোলে।
আমি কি ASCII ফর্ম ব্যবহার করে যেকোনো ডোমেইন নিবন্ধন বা সমাধান করতে পারি?#
যেকোনো আধুনিক ব্রাউজার বা সমাধানকারী দ্বারা সমাধানের জন্য, হ্যাঁ। নিবন্ধনের জন্য, নিয়মগুলো কঠোর: IDNA2008 নির্দিষ্ট অক্ষর এবং নরমালাইজেশন অনুমোদন করে না যা পুরোনো ম্যাপিং (IDNA2003) অনুমোদন করত। এই টুলটি এনকোডিং বিশ্বস্তভাবে করে কিন্তু সম্পূর্ণ IDNA2008 বৈধতা যাচাই চালায় না, তাই এমন একটি স্ট্রিং যা এখানে পরিষ্কারভাবে এনকোড হয় তবুও একজন রেজিস্ট্রার দ্বারা প্রত্যাখ্যান করা হতে পারে। সন্দেহ হলে, আপনার রেজিস্ট্রারের লুকআপ টুল দিয়ে নিশ্চিত করুন।