Geben Sie eine Domain ein und vergleichen Sie beide Schreibweisen. Zeichenhinweise helfen bei der Prüfung, belegen aber nicht die Vertrauenswürdigkeit einer Website.
Läuft lokal in deinem Browser| Label | ASCII / Punycode | Schriften | Risiko |
|---|---|---|---|
| Domain eingeben, um jedes Label zu prüfen. | |||
Für Wiederherstellung, Zertifikate, Allowlists, Redirects und Sicherheit den Host normalisieren und die ASCII-Form mit aktueller IDNA-Implementierung vergleichen.
Geben Sie einen Hostnamen ein oder fügen Sie ihn ein — in Unicode oder bereits kodiert — und drücken Sie Konvertieren und prüfen. Das Werkzeug reduziert die Eingabe auf einen Hostnamen, faltet Groß- und Kleinschreibung sowie Kompatibilitätsformen (NFKC und Kleinschreibung), entfernt die von IDNA ignorierten Zeichen und kodiert jedes nicht-ASCII-Label als Punycode. Die ASCII-Zeile ist damit die Form, die ein Resolver oder eine Allowlist tatsächlich sehen würde.
Punycode-Labels werden zusätzlich dekodiert und neu kodiert: Ein Label, das nicht kanonisch zurückläuft, wird als ungültiges Punycode gemeldet statt als Zeichensalat angezeigt. Alles läuft auf der Seite, ohne DNS-Abfrage und ohne Anfrage an die Website; ein sauberer Bericht heißt, dass kein offensichtliches Risiko auf Zeichenebene gefunden wurde — nicht, dass die Domain vertrauenswürdig ist.
Das Feld wird als Hostname behandelt, nicht als URL: Schema, Pfad, Query und abschließender Port werden entfernt, ein letzter Punkt wird verworfen und ein IP-Literal wie [::1] wird mit einer Meldung abgelehnt statt umgewandelt. Ein leeres Feld wird ebenfalls abgelehnt.
Vor der Kodierung wird der Name in seine kanonische Form gebracht: NFKC faltet Vollbreite- und Kompatibilitätszeichen, Labels werden kleingeschrieben, und die von IDNA ignorierten Codepunkte — Nullbreiten-Leerzeichen, weiche Bindestriche, Byte-Order-Marken, Variantenselektoren, bidirektionale Steuerzeichen — werden entfernt. Das ist dieselbe Behandlung, die Browser vor der Verwendung eines Hostnamens anwenden; münchen.de, MÜNCHEN.DE und eine Schreibweise mit Nullbreiten-Leerzeichen landen deshalb auf derselben ASCII-Ausgabe.
Jedes nicht-ASCII-Label wird anschließend als Punycode kodiert und mit xn-- versehen. Punycode-Labels werden auch dekodiert und neu kodiert: Wenn ein Label nicht zu einem kanonischen Unicode-Label dekodiert — etwa xn--a —, meldet das Werkzeug es als ungültiges Punycode, statt die dekodierten Bytes anzuzeigen.
Ein roter Befund markiert etwas, das ein Browser oder Resolver ablehnen würde, oder etwas, das ein Zeichen versteckt: ein Label, das mit einem Bindestrich beginnt oder endet, ein Zeichen, das in einem Hostname-Label nicht vorkommen darf (Unterstrich, @, Leerzeichen), ein ungültiges Punycode-Label oder ein Label, das nach der Umwandlung 63 Oktette überschreitet. Der vollständige ASCII-Name sollte 253 Zeichen nicht überschreiten.
Gemischte Schriftsysteme in einem Label, unsichtbare oder bidirektionale Zeichen und gängige Doppelgänger — zusammen mit dem vereinfachten Skeleton gemeldet — sind die Muster, auf denen Homograph-Angriffe aufbauen. Die Risikomarke der Tabelle wiederholt dieses Urteil pro Label: Hoch, wenn das Label nicht verwendbar ist oder Schriften mischt, Mittel bei Punycode-Präfix oder Doppelgänger, Niedrig für ein gewöhnliches ASCII-Label.
Die Analyse bleibt auf Zeichenebene. Es wird kein DNS-Eintrag abgefragt, kein Zertifikat geladen und keine Registry- oder Reputationsquelle konsultiert; ein Name kann daher jede Prüfung dieser Seite bestehen und trotzdem eine registrierte Phishing-Domain sein, die auflöst und Inhalte ausliefert.
Vergleichen Sie die ASCII-Form: Für Allowlists, Zertifikatsprüfungen und Redirect-Regeln vergleichen Sie den normalisierten ASCII-Hostnamen — nicht den angezeigten Unicode-Namen — und stellen ihn der ASCII-Form gegenüber, die das andere System erzeugt. Muss eine Entscheidung registry-genau sein, bestätigen Sie das Ergebnis mit einer vollständigen UTS#46/IDNA-Implementierung.