Μετατροπέας Punycode / IDN

Άρα το Punycode δεν είναι γλώσσα, γραμματοσειρά ή κωδικός χώρας — είναι μετάφραση ανάμεσα σε δύο γραφές του ίδιου ονόματος. Η γραφή Unicode λέγεται U-label (中文.com, bücher.de), η γραφή ASCII λέγεται A-label (xn--fiq228c.com, xn--bcher-kva.de), και η ιδέα της εισαγωγής διεθνών ονομάτων στο DNS λέγεται IDN (διεθνοποιημένα ονόματα τομέα) ή IDNA, το σύνολο των κανόνων που χτίζονται από πάνω της.

Υπάρχει επειδή το DNS σχεδιάστηκε στις αρχές της δεκαετίας του 1980 γύρω από ένα σκόπιμα μικροσκοπικό αλφάβητο. Ένα όνομα υπολογιστή που ταξιδεύει μέσω DNS, σε αρχείο ζώνης, σε cache του resolver, σε γραμμή αρχείου καταγραφής ή σε πιστοποιητικό TLS, πρέπει να είναι απλό ASCII — η μορφή μετάδοσης απλώς δεν έχει πεδίο για οτιδήποτε άλλο. Το Punycode είναι διέξοδος: επιτρέπει σε ένα όνομα που δεν είναι ASCII να ταξιδεύει σαν να ήταν, και επιτρέπει στο άκρο λήψης να ανακατασκευάσει ακριβώς τους αρχικούς χαρακτήρες. Γι' αυτό ένας κινεζικός τομέας λειτουργεί καθόλου σε πρόγραμμα περιήγησης, και γι' αυτό το xn-- είναι το μοναδικό αλφαριθμητικό που εμφανίζεται σε κάθε σημείο όπου δεν μπορεί να σταλεί η γραφή Unicode.

Τι πληκτρολογείται (U-label)	Τι λαμβάνει το DNS (A-label)	Τι σημαίνει
中文.com	xn--fiq228c.com	Οι κινεζικές λέξεις για τη «κινεζική γλώσσα»
中国	xn--fiqs8s	“Κίνα” στα κινέζικα
例え.jp	xn--r8jz45g.jp	Ιαπωνικά παραδείγματα
bücher.de	xn--bcher-kva.de	Γερμανικό bücher, “βιβλία”
münchen.de	xn--mnchen-3ya.de	Μόναχο
😂.com	xn--e28h.com	Μια ετικέτα με emoji — νόμιμη στην κωδικοποίηση, όχι στα περισσότερα μητρώα

Μια σύγκριση μήκους που αξίζει να θυμόμαστε: το 中文 είναι 2 χαρακτήρες και 6 byte σε UTF-8, αλλά το xn--fiq228c είναι 11 byte ASCII. Το Punycode συνήθως μακραίνει ένα όνομα, ποτέ δεν το κάνει μικρότερο.

Για το bücher παρακολουθούνται οι τρεις κινήσεις. Η μηχανή λέγεται bootstring, και ολόκληρος ο αλγόριθμος είναι μόνο μερικές δεκάδες γραμμές κώδικα (μπορεί να διαβαστεί στο σενάριο αυτής της σελίδας).

1. Τα απλά γράμματα μπαίνουν μπροστά. Κάθε βασικός χαρακτήρας ASCII αντιγράφεται με την αρχική σειρά του και παραμένει αναγνώσιμος: bücher → bcher. Επειδή κάτι αντιγράφηκε και έμεινε κάτι ακόμη, προστίθεται μία - ως όριο: bcher-.
2. Τα υπόλοιπα γράφονται ως αριθμοί base-36. Τα υπόλοιπα χαρακτήρες διαχειρίζονται με αύξουσα σειρά σημείων κώδικα, και ο καθένας γράφεται ως αριθμός μεταβλητού μήκους σε base 36, όπου a=0 … z=25 και 0=26 … 9=35. Για το bücher το υπολειπόμενο ü γίνεται τα ψηφία kva.
3. Προστίθεται το πρόθεμα. Το κωδικοποιημένο μέρος προστεθειμένο στο αντιγραμμένο μέρος δίνει bcher-kva, και στο πλαίσιο του τομέα γράφεται ως xn--bcher-kva.

Το κόλπο που κάνει αυτή την ιδέα έξυπνη είναι τι περιέχουν εκείνοι οι αριθμοί base-36: όχι τον ίδιο τον χαρακτήρα, αλλά μια διαφορά — πόσο απέχει ο χαρακτήρας από το προηγούμενα κωδικοποιημένο σημείο κώδικα, συν πού ανήκει μέσα στη συμβολοσειρά. Ο κωδικοποιητής διατρέχει τα σημεία κώδικα κατά αύξουσα σειρά και κάθε ακολουθία ψηφίων περιγράφει μια θέση και μια απόσταση. Μετά από κάθε χαρακτήρα ένας κοινός αριθμός που λέγεται bias προσαρμόζεται, ώστε ο επόμενος αριθμός να χρειάζεται όσο το δυνατόν λιγότερα ψηφία.

Δύο συνέπειες που μπορεί να δει κανείς μόνος του παραπάνω:

• Οι όμοιοι χαρακτήρες είναι φθηνοί. Επειδή αποθηκεύονται μόνο αποστάσεις, μια σειρά από τον ίδιο χαρακτήρα κοστίζει σχεδόν τίποτα: 30 αντίγραφα του 中 κωδικοποιούνται σε xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, μόνο 36 byte. Ένα μετρημένο, άσχετο αλλά γειτονικό μείγμα κινεζικών χαρακτήρων χωρά περίπου 41 χαρακτήρες σε μία νόμιμη ετικέτα 63 byte, και ένας μοναδικός επαναλαμβανόμενος χαρακτήρας φτάνει τους 57.
• Οι διάσπαρτοι χαρακτήρες κοστίζουν ακριβά. Ένας χαρακτήρας μακριά από τον προηγούμενο χρειάζεται μεγαλύτερο αριθμό διαφοράς. Κείμενο στα κινεζικά με πολλούς διαφορετικούς χαρακτήρες κοστίζει συνήθως περίπου 2–3 επιπλέον γράμματα ανά χαρακτήρα, γι' αυτό μια ετικέτα CJK εξαντλεί το χώρο της κάπου στους 20–40 χαρακτήρες, παρόλο που το όριο της ετικέτας είναι 63 byte.

Η αποκωδικοποίηση είναι η ίδια συνταγή ανάποδα: αντιγράφεται το πρόθεμα ASCII, διαβάζονται τα ψηφία, οι διαφορές μετατρέπονται πίσω σε σημεία κώδικα, και κάθε νέος χαρακτήρας εισάγεται στη συμβολοσειρά στη θέση που κωδικοποιεί η διαφορά. Στο bootstring υπάρχουν μόνο πεζά ψηφία, γι' αυτό ένα κεφαλαίο γράμμα μέσα σε κωδικοποιημένο μέρος απορρίπτεται αντί να μαντεύεται· το DNS δεν διακρίνει πεζά/κεφαλαία, οπότε η αποδοχή και των δύο θα έκανε δύο διαφορετικές γραφές διφορούμενες.

• Στη γραμμή διευθύνσεων. Τα προγράμματα περιήγησης μπορεί να εμφανίζουν το xn--fiq228c.com αντί για το 中文.com. Είναι ο ίδιος ιστότοπος. Μερικά προγράμματα περιήγησης εμφανίζουν σκόπιμα τη μορφή Punycode όταν ένα όνομα αναμιγνύει γραφές, ακριβώς για να μην μπορεί ένας χαρακτήρας που μοιάζει με άλλον (κυριλλικό а έναντι λατινικού a) να κρυφτεί στη διεύθυνση.
• Στο ίδιο το DNS. Τα αρχεία ζώνης, οι απαντήσεις των dig / nslookup / DNS-over-HTTPS και τα αρχεία καταγραφής του resolver περιέχουν πάντα μόνο τη μορφή xn--· το απλό Unicode απορρίπτεται ή αλλοιώνεται σιωπηλά.
• Στα πιστοποιητικά TLS. Το subject alternative name για διεθνή τομέα αποθηκεύεται ως A-label (DNS:xn--fiq228c.com), οπότε ένα πιστοποιητικό που δεν μοιάζει με το όνομα που πληκτρολογήθηκε είναι φυσιολογικό, όχι ασυμφωνία.
• Στις ρυθμίσεις και στα εργαλεία. Οι καταχωρίσεις server_name / εικονικού διακομιστή, οι τομείς cookies, τα πάνελ φιλοξενίας και CDN, οι τομείς email, τα κλειδιά API που δεσμεύονται σε τομέα και τα κλειδιά βάσεων δεδομένων είναι όλα ασφαλέστερα στη μορφή A-label.
• Στις δοκιμές και στις ροές δεδομένων. Κάποιες βιβλιοθήκες περνούν το Unicode απευθείας στον resolver και αποτυγχάνουν· η μετατροπή σε Punycode πρώτα είναι η τυπική διόρθωση. Επειδή η αντιστοίχιση είναι κανονική — μία ετικέτα Unicode αντιστοιχεί σε ακριβώς μία A-label — η μορφή xn-- είναι επίσης σταθερό αναγνωριστικό για καταγραφές και αναζητήσεις.

Το Punycode είναι αναστρέψιμη γραφή, τίποτα περισσότερο. Δεν είναι κρυπτογράφηση και δεν είναι χαρακτηριστικό ασφαλείας: όποιος μπορεί να το αποκωδικοποιήσει με το εργαλείο παραπάνω, οπότε μια ετικέτα xn-- λέει «αυτό κωδικοποιήθηκε» και τίποτα για το ποιος την κατέχει. Δεν είναι ούτε συμπίεση — συνήθως μακραίνει το κείμενο, όπως δείχνει το παράδειγμα 6 προς 11 byte παραπάνω. Και δεν είναι το ίδιο με τους άλλους τρόπους με τους οποίους ταξιδεύει το Unicode στο διαδίκτυο· αυτοί λύνουν διαφορετικά επίπεδα του προβλήματος.

Σχήμα	Τι μετατρέπει σε τι	Πού χρησιμοποιείται	Το 中文 γίνεται
Punycode (RFC 3492)	Μια ετικέτα ονόματος τομέα Unicode σε γράμματα και ψηφία ASCII	Μόνο ετικέτες διεθνών τομέων	xn--fiq228c
UTF-8 (RFC 3629)	Σημεία κώδικα σε byte	Κάθε αρχείο και κάθε αίτημα ιστού	E4 B8 AD E6 96 87 (6 byte)
Κωδικοποίηση ποσοστού (RFC 3986)	Byte σε διαφυγές %XX	Διαδρομές URL, query strings, σώματα φορμών	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Byte σε 64 χαρακτήρες ASCII	Δυαδικά δεδομένα μέσα σε κείμενο, JSON, email, data URL	5Lit5paH
Οντότητες HTML	Σημεία κώδικα σε ονομασμένες ή αριθμητικές αναφορές	Πηγαίος κώδικας HTML και XML	中文
Διαφυγές Unicode	Σημεία κώδικα σε \uXXXX	Πηγαίος κώδικας και literal συμβολοσειρών JSON	\u4e2d\u6587

Το πρακτικό συμπέρασμα: το Punycode εφαρμόζεται στις ετικέτες τομέα ενός URL, όχι στο σύνολο του URL. Η διαδρομή και το query string είναι διαφορετικό πρόβλημα και χρησιμοποιούν κωδικοποίηση ποσοστού (βλ. Κωδικοποιητές URL).

• Τα όρια μεγέθους προέρχονται από το DNS, όχι από το Punycode. Μία ετικέτα μπορεί να έχει το πολύ 63 byte και ένα πλήρες όνομα το πολύ 255 byte (RFC 1034 / 1035). Επειδή μια A-label είναι καθαρά ASCII, το πλήθος byte ισούται με το πλήθος χαρακτήρων, και κάθε χαρακτήρας εκτός ASCII καταναλώνει μέρος αυτού του προϋπολογισμού — περίπου 1 χαρακτήρας προϋπολογισμού ανά 1–4 γράμματα Punycode.
• Το Punycode μετατρέπει τα πάντα· τα μητρώα επιτρέπουν μόνο ορισμένα. Οι κανόνες IDNA επιβάλλονται από πάνω και περιορίζουν ποια σημεία κώδικα μπορούν να καταχωριστούν καθόλου — κεφαλαία γράμματα, κενά, σημεία στίξης όπως το !, και σημαίες δεν είναι νόμιμα σε πραγματικό τομέα. Αυτή η σελίδα εκτελεί τη μετατροπή RFC 3492, οπότε θα κωδικοποιήσει πρόθυμα κείμενο που θα απέρριπτε ένα μητρώο.
• Μία γραφή ανά ετικέτα. Το IDNA αποθαρρύνει την ανάμειξη γραφών μέσα σε μία ετικέτα ακριβώς εξαιτίας των επιθέσεων με όμοιους χαρακτήρες. Ένα όνομα μπορεί να κωδικοποιηθεί και εξακολουθεί να είναι άχρηστο, ή να είναι χρήσιμο αλλά να μπλοκάρεται από τα προγράμματα περιήγησης.
• Η διπλή κωδικοποίηση δεν είναι επιτρεπτή. Το xn-- ακολουθούμενο από ήδη κωδικοποιημένο κείμενο δεν είναι έγκυρο, και μια ετικέτα μόνο ASCII δεν αλλάζει καθόλου — δεν υπάρχει τίποτα να κωδικοποιηθεί, οπότε δεν προστίθεται πρόθεμα.
• Η τελική τελεία είναι εντάξει. Το 例え.jp. είναι πλήρως προσδιορισμένο όνομα και η κενή ετικέτα στο τέλος διατηρείται· οι κενές ετικέτες στη μέση δεν είναι έγκυρα ονόματα υπολογιστών.

“Γιατί ο κινεζικός τομέας εμφανίζεται ως xn--fiq228c.com στη γραμμή διευθύνσεων;”

Επειδή το πρόγραμμα περιήγησης επέλεξε να αποδώσει την A-label. Ο ιστότοπος είναι ο ίδιος· με χρήση της κατεύθυνσης Αποκωδικοποίησης αυτής της σελίδας για εμφάνιση της μορφής Unicode, ή με κωδικοποίηση της μορφής Unicode για έλεγχο ότι οι δύο γραφές ταιριάζουν.

“Χρειάζεται να αλλαχθούν οι εγγραφές DNS, το πιστοποιητικό ή η φιλοξενία;”

Όχι. Η A-label xn-- παντού όπου το όνομα διαβάζεται από μηχανή (DNS, πιστοποιητικά, ρυθμίσεις) και η μορφή Unicode χρησιμοποιείται μόνο εκεί όπου το διαβάζει άνθρωπος.

“Γιατί το αποτέλεσμα είναι μακρύτερο από όσα πληκτρολογήθηκαν;”

Επειδή η κωδικοποίηση δεν μεταφέρει τους ίδιους τους χαρακτήρες, μεταφέρει αποστάσεις σε base 36, και το αλφάβητο των 36 χαρακτήρων πρέπει να γράψει αριθμούς που μπορεί να είναι μεγάλοι. Η ανάπτυξη είναι αναμενόμενη, όχι σφάλμα.

“Γιατί η αποκωδικοποίηση λέει «κεφαλαίο γράμμα»;”

Επειδή οι ψηφιακοί χαρακτήρες του bootstring ορίζονται μόνο με πεζά (a-z, 0-9). Ένα κεφαλαίο A-Z μετά την τελευταία παύλα είναι διφορούμενο, αφού λαμβάνεται υπόψη η μη διάκριση πεζών/κεφαλαίων του DNS, γι' αυτό αναφέρεται αντί να μαντεύεται σιωπηλά.

“Ισχύει το Punycode για το τμήμα πριν από το @ σε μια διεύθυνση email;”

Μόνο το τμήμα του τομέα είναι όνομα DNS και μπορεί να είναι Punycode. Το τοπικό μέρος το χειρίζεται το σύστημα αλληλογραφίας, όχι το DNS, οπότε αυτή η κωδικοποίηση δεν εφαρμόζεται σε αυτό.

“Μπορούν δύο διαφορετικά ονόματα Unicode να παράγουν την ίδια A-label;”

Όχι. Η κωδικοποίηση είναι ένα-προς-ένα: διαφορετικές ακολουθίες σημείων κώδικα παράγουν πάντα διαφορετικά bootstring, οπότε η αποκωδικοποίηση του xn--fiq228c δίνει ακριβώς το 中文 και τίποτα άλλο. Αυτό που μπορεί να συγκρουστεί είναι η εμφάνιση — διαφορετικοί χαρακτήρες που μοιάζουν μεταξύ τους — και αυτό είναι ιδιότητα του ρεπερτορίου Unicode, όχι της κωδικοποίησης.

• RFC 3492 — Punycode, η κωδικοποίηση bootstring που υλοποιείται σε αυτή τη σελίδα. Τα γνωστά διανύσματα που αναφέρονται παραπάνω ελέγχονται έναντι των δειγματικών συμβολοσειρών αυτού του εγγράφου.
• RFC 5890, RFC 5891, RFC 5892 και Unicode UTS #46 — το IDNA2008 και η ερμηνεία του στην πλευρά του προγράμματος περιήγησης, οι κανόνες που αποφασίζουν ποιοι χαρακτήρες είναι νόμιμοι, πώς κανονικοποιούνται οι ετικέτες και πώς επιτρέπεται ο συνδυασμός γραφών.
• RFC 1034 και RFC 1035 — τα όρια 63 byte ανά ετικέτα και 255 byte ανά όνομα που κληρονομούνται από το DNS.
• RFC 3490 και RFC 3491 — η παλαιότερη γενιά IDNA2003, που αντικαταστάθηκε από το IDNA2008. Αν ένα όνομα συμπεριφέρεται διαφορετικά σε παλαιό λογισμικό, αυτός είναι συνήθως ο λόγος.

Σημείωση εμβέλειας: αυτό το εργαλείο εκτελεί μόνο μετατροπή RFC 3492 και τίποτα άλλο. Δεν είναι επαληθευτής IDN και δεν ελέγχει κανόνες καταχώρισης, τιμολόγηση ή διαθεσιμότητα τομέα — και επειδή δεν επικοινωνεί ποτέ με το δίκτυο, δεν μπορεί να πει αν ένα όνομα υπάρχει.

Δοκιμή παραπάνω: με επικόλληση του 中文 και με πάτημα του Κωδικοποίηση κειμένου → Punycode για εμφάνιση της A-label, ή με επικόλληση του xn--fiq228c και με πάτημα του Αποκωδικοποίηση Punycode → κείμενο για λήψη των χαρακτήρων πίσω.