ตัวแปลง IDN Punycode

ตัวแปลง IDN Punycode เป็นเครื่องมือฟรีสำหรับแปลงชื่อโดเมนสากลเป็น Punycode ในรูปแบบ ASCII และแปลง Punycode กลับเป็นข้อความ Unicode ที่อ่านได้

Punycode คืออะไร และมีไว้ทำไม?

Punycode เป็นส่วนหนึ่งของกระบวนการ IDNA ที่ใช้แปลง U-label แบบ Unicode เป็น A-label แบบ ASCII ทำให้ชื่อที่มีตัวอักษรอย่าง ü, é หรือ 漢 ใช้งานผ่านระบบที่เดิมรองรับเฉพาะอักษรละตินพื้นฐาน ตัวเลข และขีดกลางได้

A-label ตามมาตรฐาน IDNA จะขึ้นต้นด้วย xn-- คำนำหน้านี้บอกแอปพลิเคชันที่รองรับ IDNA ว่าอักขระที่เหลือเป็นรูปแบบ Punycode ของ U-label ส่วนจุดยังคงทำหน้าที่แบ่งป้ายชื่อ แต่ละส่วนของโดเมนจึงถูกแปลงแยกกัน

Punycode ใช้ในระบบ Internationalised Domain Names in Applications หรือที่เรียกสั้น ๆ ว่า IDNA โดย IDNA ยังครอบคลุมการตรวจสอบความถูกต้องและการจัดการอักขระ ขณะที่ Punycode มีหน้าที่สร้างรูปแบบ ASCII ของป้ายชื่อ Unicode ที่เข้าเกณฑ์

Punycode คือการเข้ารหัส ไม่ใช่การเข้ารหัสลับ ทุกคนสามารถแปลงรูปแบบ ASCII กลับเป็น Unicode ได้ จึงไม่ได้ช่วยปกปิดข้อมูลและไม่ควรใช้เพื่อซ่อนข้อมูลโดยเด็ดขาด

จะแปลงชื่อโดเมนสากลได้อย่างไร?

ป้อนข้อความ Unicode ในช่อง แปลงเป็น Punycode/ASCII หรือป้อน A-label แบบ ASCII ในช่อง แปลงเป็น IDN/ข้อความ ผลลัพธ์ที่ตรงกันจะปรากฏในช่อง Punycode/ASCII หรือ IDN/ข้อความ

1. คัดลอกเฉพาะชื่อโดเมนหรือป้ายชื่อที่ต้องการแปลง โดยไม่รวมเครื่องหมายคำพูดที่ครอบอยู่
2. ใช้ แปลงเป็น Punycode/ASCII สำหรับข้อความ Unicode ที่มีอักษรใส่เครื่องหมายกำกับเสียงหรืออักขระที่ไม่ใช่อักษรละติน
3. ใช้ แปลงเป็น IDN/ข้อความ สำหรับ A-label แบบ ASCII
4. ตรวจสอบป้ายชื่อทุกส่วนหลังแปลง ก่อนนำไปใส่ใน DNS การตั้งค่าอีเมล หรือการกำหนดค่าแอปพลิเคชัน

ตัวแปลงนี้ใช้ฟังก์ชัน idn_to_ascii และ idn_to_utf8 ของ PHP การประมวลผลเกิดขึ้นบนเซิร์ฟเวอร์ ข้อมูลที่ป้อนจะส่งไปยังเซิร์ฟเวอร์ผ่าน HTTPS และไม่มีการจัดเก็บไว้

ตัวอย่างการแปลงโดเมน

ตัวอย่างสั้น ๆ นี้แสดงความสัมพันธ์ระหว่างชื่อที่มองเห็นกับรูปแบบที่ใช้กับ DNS ได้

ข้อมูลเข้า münchen.de

ผลลัพธ์ xn--mnchen-3ya.de

เมื่อนำผลลัพธ์ไปแปลงย้อนกลับ จะได้ münchen.de ป้ายชื่อ de มีเฉพาะอักขระ ASCII จึงไม่ต้องแปลง ส่วนป้ายชื่อที่มี ü จะกลายเป็นป้ายชื่อ xn--

ข้อมูลที่ป้อนต้องเป็นข้อความชื่อโดเมนที่ถูกต้อง รูปแบบเบื้องหลังจะจัดการกรณีทั่วไปดังนี้:

• อักษรที่มีเครื่องหมายกำกับเสียงและอักษรที่ไม่ใช่ละติน: ป้ายชื่อ Unicode ที่เข้าเกณฑ์จะแสดงในรูปแบบ ASCII ผ่าน IDNA และ Punycode
• จุด: จุดแต่ละจุดใช้แบ่งป้ายชื่อ ดังนั้นโดเมนเดียวจึงมีได้ทั้งป้ายชื่อ ASCII ทั่วไปและป้ายชื่อที่ผ่านการเข้ารหัส
• ตัวเลขและขีดกลางทั่วไป: อักขระเหล่านี้เป็น ASCII อยู่แล้วและโดยทั่วไปยังคงอ่านได้ ทั้งนี้ต้องเป็นไปตามกฎไวยากรณ์ของชื่อโดเมน
• ช่องว่าง: ป้ายชื่อโฮสต์ DNS ทั่วไปไม่อนุญาตให้มีช่องว่าง หากมีช่องว่างติดมาโดยไม่ตั้งใจ ให้ลบออกแทนที่จะคาดหวังว่า Punycode จะเก็บไว้เป็นส่วนหนึ่งของโดเมน
• เครื่องหมายวรรคตอน: จุดใช้แบ่งป้ายชื่อ แต่อักขระที่เป็นส่วนหนึ่งของพาธ URL พอร์ต หรือสตริงคำค้นหา ไม่ถือเป็นส่วนหนึ่งของชื่อโฮสต์
• ข้อมูลว่างหรือยาวมาก: ค่าว่างไม่มีโดเมนให้แปลง นอกจากนี้ DNS ยังจำกัดป้ายชื่อที่เข้ารหัสแล้วแต่ละส่วนไว้ที่ 63 ออกเทต ป้ายชื่อ Unicode ที่ดูสั้นจึงอาจยาวเกินกำหนดหลังแปลง

ทำไมแปลง Punycode ไม่สำเร็จหรือได้ข้อความที่ไม่คาดคิด?

โดยทั่วไป การแปลงไม่สำเร็จเพราะข้อมูลที่ป้อนไม่ใช่ข้อความ IDN ที่ถูกต้อง มี A-label ที่มีรูปแบบผิด หรือผ่านการเข้ารหัสแบบอื่นมาก่อน เมื่อแปลงเป็น IDN/ข้อความ ข้อมูล ASCII ทั่วไปที่ไม่ใช่ A-label อาจคงเดิมโดยไม่มีการเปลี่ยนแปลง ก่อนแก้ไขอักขระด้วยตนเอง ให้ตรวจสอบว่าต้นทางเป็น U-label แบบ Unicode, A-label แบบ ASCII หรือชื่อโฮสต์ที่เข้ารหัสแบบ URL

• A-label มีรูปแบบผิดหรือใช้การเข้ารหัสไม่ถูกต้อง: ป้ายชื่อ xn-- ที่มีรูปแบบผิดอาจแปลงไม่สำเร็จ ข้อความ Base64 ข้อความเลขฐานสิบหก และ URL ที่เข้ารหัสแบบเปอร์เซ็นต์ไม่ใช่ Punycode
• อักขระที่ไม่รองรับ: Punycode สามารถแทนค่า Unicode ได้ แต่กฎของ IDNA และผู้ให้บริการจดทะเบียนโดเมนอาจไม่ยอมรับอักขระ ชุดอักขระ หรือระบบการเขียนบางแบบ
• ป้ายชื่อยาวเกินกำหนด: DNS จำกัดป้ายชื่อที่เข้ารหัสแล้วแต่ละส่วนไว้ที่ 63 ออกเทต ป้ายชื่อ Unicode จึงอาจยาวเกินไปหลังแปลง
• ข้อมูลเข้าไม่ครบหรือมีส่วนเกิน: การคัดลอกวงเล็บ หมายเลขพอร์ต หรือบางส่วนของแอตทริบิวต์ HTML ติดมากับชื่อโฮสต์ อาจทำให้ค่าไม่ถูกต้อง
• ข้อมูลถูกเข้ารหัสซ้ำ: หากอักขระในโดเมน Punycode ถูกเข้ารหัสแบบเปอร์เซ็นต์ไว้อย่างชัดเจนหรือเข้ารหัสในรูปแบบที่ไม่เป็นมาตรฐาน อักขระเหล่านั้นอาจปรากฏเป็นลำดับเปอร์เซ็นต์ ให้ถอดรหัสชั้น URL ก่อนด้วยตัวถอดรหัส URL แล้วจึงแปลงโดเมนที่ได้
• ข้อมูลไบนารีแทนข้อความ: การแปลง IDN ใช้กับข้อความชื่อโดเมนแบบ Unicode ไบต์จากไฟล์ทั่วไปอาจไม่ผ่านการตรวจสอบ หรือกลายเป็นอักขระที่ไม่มีความหมายเมื่อนำมาตีความเป็นข้อความ

จะพบ Punycode ได้ที่ไหนบ้าง?

โดยหลักแล้วจะพบ Punycode ในชื่อโดเมน ระเบียน DNS การจัดการแถบที่อยู่ของเบราว์เซอร์ และระบบที่จัดเก็บชื่อโฮสต์เป็น ASCII เบราว์เซอร์อาจแสดงชื่อสากลที่อ่านได้หรือคงรูปแบบ xn-- ไว้ ขึ้นอยู่กับกฎด้านความปลอดภัยและอักขระที่ใช้

ที่อยู่อีเมลสามารถใช้ Punycode ในส่วนโดเมนหลังเครื่องหมาย @ ได้ แต่ Punycode ไม่ได้เข้ารหัสชื่อกล่องจดหมายที่อยู่ก่อนเครื่องหมาย @ เพย์โหลด JSON และสตริงคำค้นหาอาจมี Punycode เมื่อใช้ส่งชื่อโฮสต์ แต่ไวยากรณ์ของ JSON และสตริงคำค้นหาไม่ได้กำหนดให้ข้อความทั่วไปต้องใช้ Punycode

โดยปกติ Data URI จะใช้การเข้ารหัสแบบเปอร์เซ็นต์หรือ Base64 กับเนื้อหา Punycode จะปรากฏใน Data URI ก็ต่อเมื่อข้อความภายในมีชื่อโฮสต์สากล เช่นเดียวกัน ให้ใช้ตัวเข้ารหัส URL กับค่าในพาธหรือสตริงคำค้นหา และใช้ Punycode กับชื่อโฮสต์โดยตรง

คำถามที่พบบ่อย

วาง URL ทั้งหมดลงในตัวแปลง IDN ได้ไหม?

แยกชื่อโฮสต์ออกมาแล้วแปลงเฉพาะส่วนนั้นจะปลอดภัยกว่า เนื่องจากรูปแบบโปรโตคอล พอร์ต พาธ ส่วนย่อย และสตริงคำค้นหามีกฎไวยากรณ์ของตัวเอง อักขระในส่วนเหล่านั้นอาจต้องเข้ารหัสแบบ URL แทน Punycode

ถ้าชื่อโดเมนมีป้ายชื่อ xn-- แปลว่าเว็บไซต์ไม่ปลอดภัยหรือไม่?

ไม่ใช่ โดเมนสากลที่ถูกต้องจำนวนมากใช้ป้ายชื่อ xn-- อย่างไรก็ตาม อักขระจากระบบการเขียนต่างกันที่ดูคล้ายกันอาจถูกนำไปใช้สร้างชื่อให้ชวนเข้าใจผิด จึงควรตรวจสอบการสะกดหลังถอดรหัสและยืนยันว่าเป็นองค์กรที่คาดไว้ ก่อนกรอกรหัสผ่านหรือข้อมูลการชำระเงิน

ใช้ emoji ในโดเมน Punycode ได้ไหม?

ไม่อนุญาตให้ใช้ emoji ในป้ายชื่อโดเมนตาม IDNA แม้อัลกอริทึม Punycode จะเข้ารหัสจุดรหัสของ emoji ได้ก็ตาม นโยบายของผู้ให้บริการจดทะเบียนโดเมนอาจจำกัดระบบการเขียนและสัญลักษณ์ที่อนุญาตเพิ่มเติม

ทำไมเบราว์เซอร์แสดง Punycode แทน Unicode?

เบราว์เซอร์อาจคงรูปแบบ ASCII ไว้เมื่อป้ายชื่อผสมหลายระบบการเขียน มีอักขระที่เกี่ยวข้องกับการปลอมแปลง หรือไม่เป็นไปตามนโยบายการแสดงผลของเบราว์เซอร์ นี่เป็นมาตรการป้องกันในการแสดงผล ไม่ใช่หลักฐานว่าการแปลงไม่ถูกต้อง

ชื่อที่แปลงแล้วจะใช้กับ DNS ได้แน่นอนหรือไม่?

ไม่แน่นอน การแปลงสำเร็จไม่ได้ยืนยันว่าโดเมนนั้นจดทะเบียนแล้ว ยังว่างอยู่ หรือได้รับอนุญาตจากผู้ให้บริการจดทะเบียนที่เกี่ยวข้อง ก่อนนำผลลัพธ์ไปใช้ ให้ตรวจสอบความยาวของป้ายชื่อ ตรวจสอบการสะกดในรูปแบบที่อ่านได้ และยืนยันว่าผู้ให้บริการจดทะเบียนยอมรับอักขระเหล่านั้น