Punycode / IDN Dönüştürücü

Yani Punycode bir dil, bir yazı tipi ya da bir ülke kodu değildir — aynı adın iki yazımı arasında bir çeviridir. Unicode yazımına U-etiketi denir (中文.com, bücher.de), ASCII yazımına A-etiketi denir (xn--fiq228c.com, xn--bcher-kva.de) ve uluslararası adları DNS'e koyma fikrinin tamamına IDN (uluslararası alan adları) ya da bunun üzerine kurulu kurallar kümesi olan IDNA denir.

Var olmasının nedeni, DNS'in 1980'lerin başında kasıtlı olarak küçük bir alfabe etrafında tasarlanmasıdır. DNS'ten geçen, bir bölge dosyasına, bir çözümleyici önbelleğe, bir günlük satırına ya da bir TLS sertifikasına giren bir ana bilgisayar adı düz ASCII olmalıdır — tel formatında başka herhangi bir şey için alan yoktur. Punycode kaçış kapısıdır: ASCII olmayan bir adın ASCII gibi taşınmasına izin verir ve alıcı ucun özgün karakterleri tam olarak yeniden oluşturmasını sağlar. Çinli bir alan adının bir tarayıcıda hiç çalışmasının nedeni budur ve Unicode yazımının gönderilemediği her yerde gördüğünüz tek dizge xn--'dir.

Yazdığınız (U-etiketi)	DNS'in aldığı (A-etiketi)	Ne anlama geldiği
中文.com	xn--fiq228c.com	“Çince dili” anlamına gelen Çince sözcükler
中国	xn--fiqs8s	Çincede “Çin”
例え.jp	xn--r8jz45g.jp	Japonca örnekler
bücher.de	xn--bcher-kva.de	Almanca bücher, “kitaplar”
münchen.de	xn--mnchen-3ya.de	Münih
😂.com	xn--e28h.com	Bir emoji etiketi — kodlamada yasal, çoğu kayıt kuruluşunda değil

Hatırlanmaya değer bir uzunluk karşılaştırması: 中文 UTF-8'de 2 karakter ve 6 bayttır, ama xn--fiq228c 11 ASCII bayttır. Punycode genellikle bir adı daha uzun yapar, asla daha kısa değil.

bücher'i alın ve üç hamleyi izleyin. Motora bootstring denir ve tüm algoritma yalnızca birkaç düzine satır koddur (bu sayfanın betiğinde okuyabilirsiniz).

1. Düz karakterleri başa kopyalayın. Her temel ASCII karakter özgün sırasıyla kopyalanır ve okunabilir tutulur: bücher → bcher. Bir şey kopyalandığı ve bir şey arta kaldığı için, sınır olarak tek bir - eklenir: bcher-.
2. Geri kalanı taban-36 sayılar olarak yazın. Kalan karakterler artan kod noktası sırasıyla işlenir ve her biri, a=0 … z=25 ve 0=26 … 9=35 olacak şekilde değişken uzunluklu bir taban-36 sayı olarak yazılır. bücher için artan ü karakteri kva rakamlarına dönüşür.
3. Öneki yapıştırın. Kodlanmış kısım kopyalanan kısma eklenince bcher-kva elde edilir ve alan adı bağlamında xn--bcher-kva olarak yazılır.

Bunu akıllı kılan numara, o taban-36 sayılarının içerdiği şeydir: karakterin kendisi değil, bir delta — karakterin daha önce kodlanmış kod noktasından ne kadar uzak olduğu, artı dizgide nereye ait olduğu. Kodlayıcı kod noktalarını artan sırayla gezer ve her rakam dizisi bir konumu ve bir mesafeyi tanımlar. Her karakterden sonra yanlılık adı verilen paylaşılan bir sayı ayarlanır, böylece sonraki sayı mümkün olan en az rakamla yazılır.

Yukarıda kendiniz görebileceğiniz iki sonuç:

• Benzer karakterler ucuzdur. Yalnızca mesafeler saklandığı için, aynı karakterin bir dizisi neredeyse hiçbir şey maliyetlendirmez: 中 karakterinin 30 kopyası xn--fiqaaaaaaaaaaaaaaaaaaaaaaaaaaaaa olarak kodlanır, yalnızca 36 bayt. Ölçülmüş, ilgisiz ama yakın bir Çince karakter karışımı tek bir yasal 63 baytlık etikete yaklaşık 41 karakter sığdırır ve tek bir tekrarlanan karakter 57'ye ulaşır.
• Dağınık karakterler pahalıdır. Önceki karakterden uzak bir karakter daha uzun bir delta sayısı gerektirir. Birçok farklı karakter içeren Çince metin genellikle karakter başına yaklaşık 2–3 ekstra harf maliyetlidir; bu yüzden bir CJK etiketi, etiket sınırı 63 bayt olmasına rağmen yaklaşık 20–40 karakter civarında yer kalmadan biter.

Çözme, tersine aynı tariftir: ASCII önekini kopyalayın, rakamları okuyun, deltaları yeniden kod noktalarına çevirin ve her yeni karakteri, deltanın kodladığı konuma dizgiye ekleyin. Bootstring'de yalnızca küçük harfli rakamlar vardır; bu yüzden kodlanmış kısmın içindeki büyük harf tahmin edilmek yerine reddedilir — DNS büyük/küçük harf duyarsızdır, iki durumu da kabul etmek iki farklı yazımı belirsiz kılardı.

• Adres çubuğunda. Tarayıcılar 中文.com yerine xn--fiq228c.com gösterebilir. Aynı sitedir. Bazı tarayıcılar bir ad birden fazla yazı sistemini karıştırdığında, tam olarak bir benzer karakterin (Kiril а ile Latin a) URL'nin içine saklanamaması için kasıtlı olarak Punycode biçimini gösterir.
• DNS'in kendisinde. Bölge dosyaları, dig / nslookup / DNS-üzerinden-HTTPS yanıtları ve çözümleyici günlükleri yalnızca xn-- biçimini içerir; düz Unicode reddedilir ya da sessizce bozulur.
• TLS sertifikalarında. Uluslararası bir alan adının konu alternatif adı bir A-etiketi olarak saklanır (DNS:xn--fiq228c.com), bu yüzden yazdığınız adla eşleşmeyen bir sertifika bir uyumsuzluk değil, normaldir.
• Yapılandırmada ve araçlarda. Web sunucusu server_name / sanal ana bilgisayar girdileri, çerez alan adları, barındırma ve CDN panelleri, posta alan adları, bir alan adına bağlı API anahtarları ve veritabanı anahtarları, A-etiketi biçiminde daha güvenlidir.
• Testlerde ve veri hatlarında. Bazı kütüphaneler Unicode'u doğrudan çözümleyiciye geçirir ve başarısız olur; önce Punycode'a dönüştürmek standart çözümdür. Eşleme kanonik olduğu için — bir Unicode etiketi tam olarak bir A-etiketine eşlenir — xn-- biçimi günlükler ve arama için de kararlı bir tanımlayıcıdır.

Punycode tersine çevrilebilir bir yazımdır, başka hiçbir şey değil. Şifreleme değildir ve bir güvenlik özelliği değildir: yukarıdaki araçla herkes çözebilir, bu yüzden bir xn-- etiketi “bu kodlandı” der ve kimin sahip olduğu hakkında hiçbir şey söylemez. Sıkıştırma da değildir — genellikle metni uzatır, yukarıdaki 6 bayttan 11 bayta örneğin gösterdiği gibi. Ve internette Unicode'un dolaşmasının diğer yollarıyla aynı şey de değildir; onlar sorunun farklı katmanlarını çözer.

Şema	Neyi neye çevirir	Nerede kullanılır	中文 olur
Punycode (RFC 3492)	Bir Unicode alan etiketi ASCII harf ve rakamlara	Yalnızca uluslararası alan etiketleri	xn--fiq228c
UTF-8 (RFC 3629)	Kod noktaları baytlara	Her dosya ve web isteği	E4 B8 AD E6 96 87 (6 bayt)
Yüzde kodlaması (RFC 3986)	Baytlar %XX kaçışlarına	URL yolları, sorgu dizgileri, form gövdeleri	%E4%B8%AD%E6%96%87
Base64 (RFC 4648)	Baytlar 64 ASCII karaktere	Metin, JSON, e-posta, veri URL'leri içinde ikili veri	5Lit5paH
HTML varlıkları	Kod noktaları adlandırılmış ya da sayısal referanslara	HTML ve XML kaynağı	中文
Unicode kaçışları	Kod noktaları \uXXXX'e	Kaynak kodu ve JSON dize değişmezleri	\u4e2d\u6587

Pratik sonuç: Punycode bir URL'nin tamamına değil, alan etiketlerine uygulanır. Yol ve sorgu dizgisi farklı bir sorundur ve yüzde kodlaması kullanır (bkz. URL Kodlayıcılar).

• Boyut sınırları Punycode'dan değil, DNS'ten gelir. Tek bir etiket en fazla 63 bayt ve tam bir ad en fazla 255 bayt olabilir (RFC 1034 / 1035). Bir A-etiketi tamamen ASCII olduğu için bayt sayısı karakter sayısına eşittir ve ASCII olmayan her karakter bu bütçenin bir kısmını harcar — kabaca her 1–4 Punycode harfi için 1 karakter bütçesi.
• Punycode her şeyi dönüştürür; kayıt kuruluşları yalnızca bazı şeylere izin verir. IDNA kuralları bunların üstünde durur ve hangi kod noktalarının hiç kaydedilebileceğini kısıtlar — büyük harfler, boşluklar, ! gibi noktalama işaretleri ve bayraklar gerçek bir alan adında yasal değildir. Bu sayfa RFC 3492 dönüşümünü yapar, bu yüzden bir kayıt kuruluşunun reddedeceği metni de memnuniyetle kodlar.
• Tek bir yazı sisteminde kalın. IDNA, tam da benzer-görünüm saldırıları nedeniyle tek bir etiket içinde yazı sistemlerinin karıştırılmasını önerir. Bir ad kodlanabilir ve yine de kullanılamaz olabilir ya da kullanılabilir ama tarayıcılar tarafından kara listeye alınmış olabilir.
• Çift kodlamayın. Zaten kodlanmış metnin önündeki xn-- geçersizdir ve tamamen ASCII olan bir etiket asla değişmez — kodlanacak bir şey yoktur, bu yüzden önek eklenmez.
• Sondaki nokta sorun değildir. 例え.jp. tam nitelikli bir addır ve sondaki boş etiket korunur; ortadaki boş etiketler geçerli ana bilgisayar adları değildir.

“Çince alan adım adres çubuğunda neden xn--fiq228c.com olarak görünüyor?”

Çünkü tarayıcı A-etiketini göstermeyi seçti. Site aynıdır; Unicode biçimini görmek için bu sayfanın Çözme yönünü kullanın ya da iki yazımın eşleştiğini denetlemek için Unicode biçimini kodlayın.

“DNS kayıtlarımı, sertifikamı ya da barındırmamı değiştirmem gerekir mi?”

Hayır. Makinelerin adı okuduğu her yerde (DNS, sertifikalar, yapılandırmalar) xn-- A-etiketini tutun ve Unicode biçimini yalnızca bir insanın okuduğu yerde kullanın.

“Sonuç neden yazdığımdan daha uzun?”

Çünkü kodlama karakterlerin kendisini değil, taban-36 mesafelerini taşır ve 36 karakterlik alfabe büyük olabilecek sayıları yazmak zorundadır. Büyüme beklenir, bir hata değildir.

“Çözme neden ‘büyük harf’ diyor?”

Çünkü bootstring rakamları yalnızca küçük harf olarak tanımlanmıştır (a-z, 0-9). Son tireden sonraki büyük harf A-Z, DNS'in büyük/küçük harf duyarsızlığı hesaba katıldığında belirsiz olur, bu yüzden sessizce tahmin edilmek yerine bildirilir.

“Punycode bir e-posta adresinde @ işaretinden önceki kısma uygulanır mı?”

Yalnızca alan adı kısmı bir DNS adıdır ve Punycode olabilir. Yerel kısım posta sistemi tarafından işlenir, DNS tarafından değil, bu yüzden bu kodlama ona uygulanmaz.

“İki farklı Unicode adı aynı A-etiketini üretebilir mi?”

Hayır. Kodlama birebirdir: farklı kod noktası dizileri her zaman farklı bootstring'ler üretir, bu yüzden xn--fiq228c'nin çözülmesi tam olarak 中文'u verir, başka bir şey değil. Çakışabilen şey görünüştür — benzer görünen farklı karakterler — bu kodlamanın değil, Unicode repertuvarının bir özelliğidir.

• RFC 3492 — Punycode, bu sayfada uygulanan bootstring kodlaması. Yukarıda alıntılanan bilinen vektörler, o belgedeki örnek dizgilere karşı denetlenir.
• RFC 5890, RFC 5891, RFC 5892 ve Unicode UTS #46 — IDNA2008 ve tarayıcı tarafındaki yorumu; hangi karakterlerin yasal olduğunu, etiketlerin nasıl normalleştirildiğini ve yazı sistemlerinin nasıl karıştırılabileceğini belirleyen kurallar.
• RFC 1034 ve RFC 1035 — DNS'ten devralınan 63 baytlık etiket ve 255 baytlık ad sınırları.
• RFC 3490 ve RFC 3491 — IDNA2008 tarafından yerine geçirilen eski IDNA2003 kuşağı. Bir ad eski yazılımda farklı davranıyorsa, genellikle nedeni budur.

Kapsam notu: bu araç yalnızca RFC 3492 dönüşümünü yapar ve başka bir şey yapmaz. Bir IDN doğrulayıcı değildir ve bir alan adının kayıt kurallarını, fiyatını ya da kullanılabilirliğini denetlemez — ve hiçbir zaman ağla iletişim kurmadığı için bir adın var olup olmadığını size söyleyemez.

Yukarıda deneyin: A-etiketini görmek için 中文 yapıştırın ve Metni Punycode'a Kodla → düğmesine basın, ya da karakterleri geri almak için xn--fiq228c yapıştırın ve Punycode'u Metne Çöz → düğmesine basın.