محول Punycode / IDN
الترميزحوّل أسماء النطاقات الدولية بين Unicode (中文.com) وPunycode بصيغة ASCII (xn--). يدعم عناوين البريد الإلكتروني وتفصيل كل تسمية. وفق معيار RFC 3492.
لا يتم جلب الروابط البعيدة؛ الصق JSON مباشرة.
ترميز Punycode وفق RFC 3492؛ وليس مطابقة IDNA2008 كاملة (بدون CheckBidi / CheckNFC). قد يتم فك ترميز تسمية ACE غير الصالحة تقنيًا وفق IDNA2008 على أي حال.
في هذه الصفحة
ما هو Punycode؟#
بُني نظام أسماء النطاقات (DNS) على ASCII — الأحرف A–Z، والأرقام، والواصلة. فكيف يحلّ المتصفح نطاقًا مثل 中文.com أو münchen.de، التي محارفها ليست من تلك الأبجدية؟ الجواب هو Punycode (وإطار IDN حوله): ترميز عكسي يحوّل كلّ تسمية غير ASCII إلى صيغة آمنة بـ ASCII تبدأ بالبادئة xn--. فلا يرى 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.
- يَعي البريد الإلكتروني. تُكتشَف علامة
@مفردة ويُحفظ اسم الصندوق؛ ولا يُرمَّز سوى جانب النطاق. والمدخل بعدّة علامات@يُرفَض برسالة واضحة بدلًا من إفساد النتيجة بصمت. - تطبيع الفواصل. تُعامَل النقطة كاملة العرض
.، والنقطة الإيديوغرافية。، ونصف العرض。كلّها بوصفها النقطة ASCII.التي تمثّلها فعلًا في IDN، فلا ينكسر النصّ الملصوق. - صارم مع المدخل المُعوَج. تسمية
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)، فلا شيء لترميزه، والمخرج يساوي المدخل. وجدول التفصيل هو المؤشّر الموثوق: التسمية التي يطابق output فيها input لم تُحوَّل، لأنها لم تحتج إلى ذلك.
لصقت بريدًا إلكترونيًّا ولم يُحوَّل الجزء المحلي. هل هذا صحيح؟#
نعم، وهو متعمَّد. فالبريد الإلكتروني المُدوَل (SMTPUTF8) يسمح بـ UTF-8 في اسم الصندوق، لكنّ تحويله إلى xn-- خطأ للحالة الشائعة — الجزء المحلي ليس اسم DNS ولا يحلّه Punycode. تُحوِّل هذه الأداة جانب النطاق فقط، وهو الجزء الذي يجب أن يكون آمنًا لـ DNS. ولهذا أيضًا تُرفَض علامات @ المتعدّدة: فهي تجعل «جانب النطاق» ملتبسًا.
هل أستطيع استخدام الصيغة ASCII لتسجيل أو حلّ أيّ نطاق؟#
للحلّ بأيّ متصفح أو محلِّل حديث، نعم. أمّا للتسجيل، فالقواعد أصرم: يحظر IDNA2008 محارف وتطبيعات معيّنة سمحت بها التخطيطات الأقدم (IDNA2003). ولا تنفّذ هذه الأداة فحوص صحّة IDNA2008 الكاملة، فقد تُرمَّز سلسلة بنظافة هنا لكن يرفضها المسجِّل. عند الشكّ، أكِّد بأداة بحث مسجِّلك.