IDN-homografiecontrole

Namen waren de eerste twintig jaar van DNS alleen ASCII, daarom wordt alles over hen gemeten in bytes en letters: labels van letters, cijfers en koppeltekens, elk hooguit 63 bytes, in totaal hooguit 255 bytes. Een internationale domeinnaam (IDN) ontstaat wanneer de regels worden opengesteld voor de rest van Unicode, en punycode (RFC 3492) is de spellingregel die het oude mechanisme laat werken: een label dat iets buiten ASCII bevat wordt geschreven als een xn---label, een ASCII-string die dezelfde tekens in gevouwen vorm draagt. 中文.com reist als xn--fiq228c.com, en beide spellingen noemen dezelfde host.

Het deel dat hier ertoe doet is wat punycode niet doet. Het zet spelling om en niets anders. Het heeft geen mening over of аpple.com naast apple.com mag staan, en het kon er niet naar gevraagd worden, want die vraag gaat over ogen en lettertypen en niet over bytes. Het register beslist welke tekens het verkoopt, de browser beslist hoe hij een naam toont die hij veilig acht, en de lezer beslist of hij klikt. Deze pagina beantwoordt de vraag onder alle drie: uit welke tekens bestaat deze naam werkelijk, en wat spelt hij daardoor?

Elke rij hieronder wordt door deze pagina uitgevoerd wanneer ze laadt, en opnieuw door de knop Zelftest, en de pagina moet precies melden wat de rij zegt dat ze meldt — dezelfde bevindingen, hetzelfde niveau, dezelfde DNS-vorm, hetzelfde aantal bytes, niet meer en niet minder. Dat is wat een schoon antwoord hier waard maakt: het codepad dat een gewone naam doorlaat is hetzelfde als het codepad dat de trucs hieronder vangt.

1. Haal de naam uit wat u geplakt heeft. Een kale naam wordt gebruikt zoals hij is; een URL wordt ontdaan van zijn host, en schema, poort, pad en query vallen weg. De pagina zegt welk van de twee het deed, in plaats van stilzwijgend een schuine streep te analyseren alsof die deel van een naam was.
2. Maak het schoon zoals een client dat zou doen. Besturingstekens, de tekens zonder breedte en de byte-ordermarkering worden verwijderd, een volledige breedte- of ideografische punt telt als een punt, en een afsluitende punt is de root en geen fout. Elk teken dat op deze manier wordt verwijderd of opnieuw geïnterpreteerd wordt gemeld, want een stilzwijgend verwijderde spatie zonder breedte is precies het ding waarvan u op de hoogte moet worden gesteld.
3. Splits de naam in labels en meet elk ervan. Een label mag niet leeg zijn, niet beginnen of eindigen met een koppelteken, en geen twee koppeltekens op posities drie en vier hebben, tenzij het een xn---label is. Elk label wordt gemeten in UTF-8-bytes tegen de grens van 63 bytes, en de hele naam tegen 255.
4. Decodeer elk xn---label terug naar zijn tekens. Het gedecodeerde label wordt daarna nog eens gecodeerd en vergeleken met wat u typte. Een label dat die heen-en-terugweg niet overleeft is niet het label waarvoor het zich uitgeeft, en een label dat decodeert naar een besturingsteken of naar niets wordt zo gemeld in plaats van stilletjes weggelaten.
5. Vraag wat elk teken is. Het codepunt, de UTF-8-bytes, het schrift waartoe het behoort, of het in een groep tekens valt die er hetzelfde uitzien, en wat de andere leden van die groep zijn. Hier houdt een Cyrillische a op "een letter" te zijn en wordt het "een letter die eruitziet als een Latijnse".
6. Vouw de naam terug naar de vorm die hij nabootst. Elk look-alike-teken wordt vervangen door het teken waarop het lijkt, wat аpple.com in apple.com verandert. Die gevouwen lezing is de nuttigste regel op de pagina, omdat apple.com iets is waar u op kunt handelen, terwijl "een Cyrillische a" dat niet is.
7. Verzamel de bevindingen en meld de ergste. Bevindingen worden één keer gemeld, met de labels waarin ze voorkomen. Een naam die alleen ongewoon oogt levert opmerkingen op in plaats van bevindingen: Han en Kana mengen, of eindigen op de root-punt, is gewoon schrijfwijze en geen reden tot zorg.

geen hier was niets de vermelding waard — laag dezelfde naam, een tweede keer anders geschreven — medium een teken dat DNS niet draagt, of een teken dat naar een gewone letter vouwt — hoog een naam die gemaakt is om als een andere naam gelezen te worden, of een naam die helemaal niet verzonden kan worden.

Een niveau is het ergste wat de bevindingen kunnen betekenen, geen kans en geen oordeel over de site. Een volkomen eerlijke naam kan een medium zijn omdat hij één teken buiten het alfabet van hostnamen bevat, en een kwaadaardige naam kan een hoog zijn met niets geavanceerder dan een Cyrillische letter erin. De lijst onder het niveau zegt waarom, één regel per bevinding, en die lijst is het deel dat het lezen waard is.

De tabel hieronder is opgebouwd uit dezelfde lijst waaruit de pagina rapporteert, zodat een rij hier en een bevinding in een resultaat elkaar niet kunnen tegenspreken. Een controle die niets vond staat als nee vermeld: het punt van de tabel is dat u kunt zien dat de vraag gesteld en beantwoord is, in plaats van u af te vragen of ze überhaupt gesteld is.

Dezelfde lijst drijft de opmerkingen aan, die helemaal geen niveau dragen: één label zonder punt, een afsluitende root-punt, een topleveldomein dat niet ASCII is, een scheidingsteken dat geen punt is, een naam in hoofdletters, tekens die tijdens het schoonmaken zijn verwijderd, en een URL die tot zijn host is teruggebracht.

Een naam is een lijst van labels, en elk ervan wordt in bytes geteld, niet in tekens. Dat onderscheid is de hele reden dat punycode bestaat: 中文 is twee tekens en zes bytes, en de xn---vorm ervan is vijftien tekens, dus de gecodeerde spelling is wat moet passen. De pagina past beide grenzen toe en meldt welke ze bereikt.

U heeft misschien gemerkt dat een naam in het Chinees, of in het Cyrillisch, soms in uw adresbalk verschijnt als xn---kletskoek in plaats van de tekens die u verwacht. Dat is de browser die weigert de mooie vorm te tonen, niet de site die er niet in slaagt zich te registreren. Een browser past een eigen regel toe op een naam die hij nog nooit heeft gezien, en die regel bestaat om dezelfde reden als deze hele pagina: аpple.com weergeven als аpple.com is precies wat een aanvaller wil, dus een onbekende naam in gemengd schrift wordt in zijn gecodeerde spelling getoond totdat hij vaak genoeg is gezien om te worden vertrouwd.

Punycode is RFC 3492, en de zelftest op deze pagina draait als eerste controle de elf voorbeeldlabels die in dat document zijn afgedrukt, zodat de encoder hier wordt gehouden aan de voorbeelden in de standaard en niet aan zichzelf. De verwerkingsregels waar een IDN doorheen gaat zijn RFC 5891 met de tekentabellen van RFC 5892, en de compatibiliteitslaag die browsers werkelijk toepassen is UTS #46 met de niet-overgangsvlag; deze pagina vertelt u wat die regels doen in plaats van te doen alsof ze worden geïmplementeerd, en het vouwen dat ze wel toepast — NFC, daarna kleine letters, daarna RFC 3492 — is dezelfde korte reeks die een client uitvoert voordat een naam wordt verzonden. De vormgroepen, de schriftbereiken en de tabellen met onzichtbare tekens in deze familie van pagina's zijn met de hand voor de familie geschreven: de standaarden worden genoemd zodat u ze zelf kunt lezen, en er wordt hier geen tekst uit overgenomen.

Is een gemengd-schrift naam altijd een aanval?

Nee, en die behandeling zou op een manier die ertoe doet verkeerd zijn. Japans schrijft Han-tekens en Kana in hetzelfde woord, en Koreaans schrijft Han-tekens binnen Hangul. Wat geen gewone verklaring heeft is Latijn gemengd met Cyrillisch of Grieks in één label, omdat die schriften in geen enkele taal samen worden gebruikt, en de pagina trekt die grens in plaats van elke mengvorm te markeren. Daarom komen de Japanse en Koreaanse rijen in de gevalstabel hierboven schoon terug.

Waarom komt mijn eigen naam als medium terug?

Waarschijnlijk omdat hij één teken bevat dat het alfabet van hostnamen niet bevat — een underscore, een spatie, een accent geschreven als compatibiliteitsteken — en dat is een medium omdat de naam zo niet kan worden verzonden. Medium betekent "hier moet naar gekeken worden", niet "dit is een vervalsing". De bevinding onder het niveau noemt het exacte teken en zijn positie.

Vertelt de pagina mij of een naam gevaarlijk, geregistreerd of bereikbaar is?

Nee, op alle drie. Ze raakt het netwerk nooit aan en lost nooit iets op, dus ze kan niet weten of een naam bestaat of wie hem bezit, en ze zegt bewust niets over wat een site doet. Ze beantwoordt een smallere vraag die u zelf kunt nagaan: uit welke tekens bestaat deze naam, en als ik de look-alikes vouw naar de letters die ze nabootsen, wat spelt hij dan?

Mijn naam staat in het Chinees en de pagina zegt dat het topleveldomein niet ASCII is. Is er iets mis?

Er is niets mis. Een Chinees topleveldomein reist als een eigen xn---label, dus het laatste label van de naam wordt in zijn gecodeerde vorm geschreven, en de pagina vermeldt dat. Opmerkingen krijgen geen niveau omdat ze een feit beschrijven en geen probleem.

Waarom toont de regel "leest als" soms dezelfde naam die ik typte?

Omdat de pagina alleen een gevouwen lezing toont wanneer het vouwen werkelijk iets verandert. Als elk teken in de naam al de vorm heeft die het nabootst, zijn de gevouwen lezing en de naam dezelfde string, en is er niets dat de pagina u kan vertellen.

Wat is een A-label en een U-label?

Een A-label is de ASCII-spelling die reist: xn--fiq228c. Een U-label is hetzelfde label geschreven in het schrift waartoe het behoort: 中文. Het zijn twee spellingen van één label, en de pagina toont voor elk gedecodeerd label beide, zodat u kunt zien wat een gecodeerd label verbergt.