Code

URL kodieren und dekodieren: Prozentkodierung, Leerzeichen und UTF-8

ToolMellow ·

URL-Kodierung stellt ausgewählte Bytes durch Prozentsequenzen dar, damit Text in den vorgesehenen Teil einer URL oder in einen Formularwert passt. ToolMellow bietet drei Arten: URL-Komponente, Formularwert und Ganze URL. Fügen Sie Text ein, wählen Sie die Art und drücken Sie Kodieren oder Dekodieren. Die Umwandlung läuft lokal und öffnet die Adresse nicht, ruft sie nicht über das Netzwerk ab und validiert sie nicht.

Das richtige Ergebnis hängt davon ab, wo Sie den Text verwenden. Ein einzelner Abfragewert, eine vollständige Abfragezeichenfolge und eine bereits zusammengesetzte URL sind unterschiedliche Eingaben. Dieser Leitfaden zeigt genaue Beispiele, erklärt UTF-8 und häufige Fehler und hilft dabei, Trennzeichen oder zu viele Kodierungsschichten nicht versehentlich zu verändern. Die Beispieladressen und Ausgaben dienen zur Erklärung; sie sind keine abgerufenen Ressourcen.

URL-Encoder und -Decoder

URL-Text kodieren oder dekodieren

Öffnen Sie den URL-Encoder und -Decoder und fügen Sie den gesamten zu verändernden Wert ein. Wählen Sie unter Kodierungsart URL-Komponente (%20 für Leerzeichen), Formularwert (+ für Leerzeichen) oder Ganze URL (Trennzeichen beibehalten). Kodieren und Dekodieren verarbeiten die vollständige Editoreingabe; allein das Tippen wandelt sie nicht um.

Lesen Sie die Ausgabe, bevor Sie Ergebnis kopieren oder Herunterladen verwenden. Ergebnis als Eingabe verwenden erlaubt eine weitere Operation, wenn das Ergebnis innerhalb des Eingabelimits liegt. Eine Änderung der Eingabe oder Kodierungsart löscht das alte Ergebnis. Zeilen umbrechen ändert nur den visuellen Umbruch; es fügt keine Zeilenumbrüche ein und verändert keine Prozentsequenzen.

  • Wählen Sie für einen einzelnen Abfragewert oder ein Pfadsegment den Komponentenmodus, statt eine gesamte zusammengesetzte Abfrage zu kodieren.
  • Verwenden Sie den Formularwertmodus nur, wenn das empfangende Format die Wertregeln von application/x-www-form-urlencoded erwartet.
  • Erwägen Sie für eine zusammengesetzte Adresse mit weiterhin bedeutungsvollen Trennzeichen den Modus für ganze URLs; er ist weiterhin weder URL-Parser noch Validator.

Eine Komponente, einen Formularwert oder eine ganze URL wählen

Das Kodieren einer Komponente verhindert, dass reservierte Satzzeichen innerhalb eines Werts als URL-Struktur wirken. Der Formularwertmodus verwendet die Formularkodierungsregeln für einen einzelnen Wert und gibt keinen Parameternamen zurück. Der Modus für die ganze URL behält Trennzeichen wie Doppelpunkt, Schrägstrich, Fragezeichen, kaufmännisches Und, Gleichheitszeichen und Fragmentmarkierung im Text bei.

Wählen Sie die Art anhand der empfangenden Anwendung und nicht danach, welche Ausgabe am kürzesten aussieht. Eine gesamte Abfrage als einen Wert zu kodieren oder Trennzeichen innerhalb eines Werts unverändert zu lassen kann die Bedeutung verändern. Dieses Werkzeug zerlegt eine eingefügte Abfrage nicht in Name/Wert-Paare und bestimmt nicht, welcher Teil zu Host, Pfad, Abfrage oder Fragment gehört.

Eine Komponente, einen Formularwert oder eine ganze URL wählen
ArtGeeignete EingabeGrenze der Implementierung
URL-KomponenteEin Abfragewert oder PfadsegmentKodiert reservierte Satzzeichen und fügt strenge Prozentkodierung für fünf Zeichen hinzu
FormularwertEin einzelner formularkodierter WertURLSearchParams-Kodierung; Dekodieren ersetzt wörtliches + vor strengem Prozentdekodieren
Ganze URLEine bereits zusammengesetzte AdresseencodeURI/decodeURI; eigener reservierter Satz, keine vollständige URL-Validierung

RFC 3986: URI-Syntax, nicht reservierte Zeichen und ProzentkodierungWHATWG URL: Parsen und Serialisieren URL-kodierter FormulardatenECMAScript: encodeURI und decodeURI

Was Prozentkodierung mit Bytes macht

Eine Prozentsequenz besteht aus einem Prozentzeichen und zwei hexadezimalen Ziffern, die ein Byte darstellen. Unicode-Zeichen können mehrere UTF-8-Bytes benötigen; ein sichtbares Zeichen kann deshalb mehrere Sequenzen erfordern. Das ASCII-Leerzeichen ist hexadezimal 20 und wird beim Kodieren von Komponenten und ganzen URLs zu %20; die Formularkodierung stellt es als + dar.

Diese festen Beispiele zeigen, warum die Kodierungsart wichtig ist. Ein wörtliches Plus und ein kodiertes Leerzeichen sind unterschiedliche Werte. Der Schrägstrich und die Abfragesatzzeichen in der dritten Zeile gehören in einem Fall zu Komponentendaten und bleiben im Modus für ganze URLs strukturelle Zeichen. Keine der beiden Aktionen ruft eine Adresse auf.

Was Prozentkodierung mit Bytes macht
EingabetextKomponentenausgabeFormularwertausgabeAusgabe der ganzen URL
a b+ca%20b%2Bca+b%2Bca%20b+c
cafécaf%C3%A9caf%C3%A9caf%C3%A9
a/b?x=1#parta%2Fb%3Fx%3D1%23parta%2Fb%3Fx%3D1%23parta/b?x=1#part
~*~%2A%7E*~*
😀%F0%9F%98%80%F0%9F%98%80%F0%9F%98%80

RFC 3986: URI-Syntax, nicht reservierte Zeichen und ProzentkodierungWHATWG Encoding: UTF-8 und TextdekodierungWHATWG URL: Parsen und Serialisieren URL-kodierter FormulardatenECMAScript: encodeURI und decodeURI

Komponentenmodus und strenges Kodieren von Sonderzeichen

Die Komponentenkodierung von ToolMellow verwendet encodeURIComponent und kodiert zusätzlich !, Apostroph, (, ) und * als Prozentsequenzen. Nur ASCII-Buchstaben, Ziffern und -._~ bleiben wörtlich erhalten. Das entspricht dem nicht reservierten Zeichensatz aus RFC 3986 genauer als unverändertes encodeURIComponent, das diese fünf zusätzlichen Zeichen unverändert lässt.

Zum Beispiel wird der Wert red&blue=1 zu red%26blue%3D1. Er kann als Parameterwert übergeben werden, ohne dass sein kaufmännisches Und zu einem weiteren Abfragetrennzeichen wird. Das Dekodieren von Komponenten verwendet decodeURIComponent: Prozentkodierte reservierte Zeichen werden dekodiert, während ein wörtliches + ein Plus bleibt. Es analysiert keine Abfragepaare und normalisiert keine vollständige URL.

RFC 3986: URI-Syntax, nicht reservierte Zeichen und ProzentkodierungECMAScript: encodeURIComponent und decodeURIComponent

Formularwerte: Plus, Leerzeichen, Tilde und Sternchen

Das Kodieren von Formularwerten folgt der URLSearchParams-Serialisierung für einen einzelnen Wert. Ein Leerzeichen wird zu +, ein wörtliches Plus zu %2B und ein wörtliches Sternchen bleibt erhalten. Tilde wird zu %7E. Diese Unterschiede sind vorgesehen: Formularkodierung besitzt einen eigenen erlaubten Zeichensatz, der nicht genau dem Komponentenmodus entspricht.

Das Dekodieren ersetzt zunächst wörtliche Pluszeichen durch Leerzeichen und ruft danach das strenge decodeURIComponent auf. So wird a+b%2Bc zu a b+c: %2B wird nach der anfänglichen Ersetzung zum Plus und nicht in ein zweites Leerzeichen umgewandelt. Das ist ein Wertdecoder und kein toleranter URLSearchParams-Abfrageparser. Fehlerhafte Sequenzen und ungültiges prozentkodiertes UTF-8 erzeugen Fehler, statt repariert zu werden.

WHATWG URL: Parsen und Serialisieren URL-kodierter FormulardatenECMAScript: encodeURIComponent und decodeURIComponent

Der Modus für ganze URLs erhält seinen eigenen Trennzeichensatz

Das Kodieren ganzer URLs verwendet encodeURI. Es behält Trennzeichen in einer zusammengesetzten Adresse bei und kodiert Leerzeichen sowie andere erforderliche Zeichen. Zum Beispiel wird https://example.com/a b?q=a+b#part zu https://example.com/a%20b?q=a+b#part. Das Plus bleibt in diesem Schritt ein Plus; wie eine Anwendung später die Abfrage analysiert, ist ein gesonderter Schritt.

Das Dekodieren ganzer URLs verwendet decodeURI und behält Prozentsequenzen für seinen eigenen reservierten Zeichensatz ;/?:@&=+$,# bei. Zum Beispiel bleiben %2F, %26 und %23 kodiert, während %20 zu einem Leerzeichen wird. Dieser ältere Satz umfasst nicht alle reservierten Zeichen aus RFC 3986: %5B und %5D werden zu eckigen Klammern, und das Kodieren ganzer URLs kodiert wörtliche eckige Klammern als Prozentsequenzen. Dieser Modus parst keine URL, validiert weder einen Host noch ein Schema, normalisiert keinen IPv6-Host, führt keine IDNA-Domainumwandlung durch und ruft die Adresse nicht ab.

ECMAScript: encodeURI und decodeURIWHATWG URL: URL-Parsen, Hosts und URLSearchParamsRFC 3986: URI-Syntax, nicht reservierte Zeichen und Prozentkodierung

UTF-8, Unicode und der Unterschied bei roher Eingabe

Das Kodieren stellt UTF-8-Bytes der Zeichen, die kodiert werden müssen, als Prozentsequenzen dar. Bei café benötigt der letzte Buchstabe zwei UTF-8-Bytes, dargestellt durch %C3%A9; das Emoji 😀 benötigt vier Bytes. Das Editorlimit zählt JavaScript-UTF-16-Codeeinheiten. Bytelänge, Länge in Codeeinheiten und sichtbare Zeichenanzahl müssen deshalb nicht übereinstimmen. Diese Umwandlung normalisiert Unicode-Text nicht.

Jede Kodierungsart weist ungepaarte Unicode-Surrogate zurück. Das Dekodieren ganzer URLs prüft außerdem zuerst, ob die rohe Eingabe wohlgeformter Unicode ist. Das Dekodieren von Komponenten und Formularwerten führt diese gesonderte Prüfung der rohen Zeichenfolge nicht durch: Nicht kodierte wörtliche Codeeinheiten können unverändert passieren, während prozentkodierte Bytefolgen gültiges UTF-8 ergeben müssen. Verstehen Sie erfolgreiches Dekodieren nicht als allgemeine Prüfung jedes wörtlichen Zeichens oder als Nachweis einer sicheren URL.

ECMAScript: encodeURIComponent und decodeURIComponentECMAScript: encodeURI und decodeURIECMAScript: String-isWellFormedWHATWG Encoding: UTF-8 und Textdekodierung

Fehlerhafte Prozentsequenzen, ungültiges UTF-8 und unerwartete Ausgaben

Eine Prozentsequenz benötigt genau zwei hexadezimale Ziffern nach jedem Prozentzeichen, und kodierte Bytefolgen müssen den UTF-8-Regeln des Decoders entsprechen. Ein wörtliches Prozentzeichen, das Sie kodieren wollen, wird zu %25; ein einzelnes Prozentzeichen in einer Dekodiereingabe ist ein Fehler. Das Werkzeug entfernt Leerraum nicht stillschweigend und dekodiert nicht wiederholt, bis der Text lesbar aussieht.

Prüfen Sie die Art und den vollständigen Originalwert, bevor Sie Zeichen ändern. Rohe Leerzeichen oder Zeilenenden bleiben Eingabedaten und können die Kodierung verändern. Wenn Sie ein HTML-Attribut, eine JSON-Zeichenfolge in Anführungszeichen oder einen gesamten Anfragekörper kopiert haben, parsen Sie dieses äußere Format getrennt. Dessen Trennzeichen und Regeln werden nicht automatisch zu Regeln der Prozentkodierung.

Fehlerhafte Prozentsequenzen, ungültiges UTF-8 und unerwartete Ausgaben
Eingabe oder SymptomGrundHilfreicher nächster Schritt
% oder %2Unvollständige ProzentsequenzPrüfen Sie den vollständig kopierten Wert
%GGSequenzziffern sind nicht hexadezimalPrüfen Sie die ursprüngliche Quelle
%FFKodiertes Byte ist kein gültiges UTF-8Bestimmen Sie die erwartete Zeichenkodierung oder den Binärumfang
a+b behält im Komponentenmodus das PlusWörtliches Plus ist in diesem Modus kein LeerzeichenVerwenden Sie Formularwert nur, wenn der Empfänger ihn erwartet
Ganzes Dekodieren behält %2FdecodeURI erhält das reservierte TrennzeichenVerwenden Sie Komponentendekodieren für den passenden einzelnen Wert

ECMAScript: encodeURIComponent und decodeURIComponentECMAScript: encodeURI und decodeURIRFC 3986: URI-Syntax, nicht reservierte Zeichen und Prozentkodierung

Warum %25 erscheint und wann ein zweites Dekodieren falsch ist

Das Kodieren eines bereits kodierten Prozentzeichens erzeugt eine weitere Schicht: Komponentenkodierung von %2F ergibt %252F. Ein einmaliges Komponentendekodieren von %252F liefert %2F; ein zweites liefert /. Jeder Schritt verändert eine Kodierungsschicht. %25 allein beweist keinen Fehler, weil eine Anwendung absichtlich kodierten Text innerhalb eines anderen Werts transportieren kann.

Bestimmen Sie die von Ihrer Anwendung erwartete Schicht, statt wiederholt zu dekodieren, bis Satzzeichen erscheinen. Ein zweites Komponentendekodieren kann Daten zu einem strukturellen Schrägstrich oder Trennzeichen machen. Das Dekodieren ganzer URLs kann solche kodierten Trennzeichen absichtlich behalten; das Komponentenbeispiel bedeutet daher nicht, dass jeder Modus durch Wiederholung jede Sequenz entfernt. Das Werkzeug kennt die Routing- oder Berechtigungsregeln einer Anwendung nicht.

RFC 3986: URI-Syntax, nicht reservierte Zeichen und ProzentkodierungECMAScript: encodeURIComponent und decodeURIComponentECMAScript: encodeURI und decodeURI

Abfragezeichenfolgen, Pfadsegmente und sichere Verwendung in Anwendungen

Bei einem Abfrageparameter halten Sie den Namen und die Abfragestruktur von seinem Wert getrennt. Eine API zum Erstellen von URLs wie URL und URLSearchParams kann beim Zusammensetzen und Serialisieren einer tatsächlichen Adresse helfen. Dieses Werkzeug verändert nur den eingegebenen Text; es validiert keinen Hostnamen, verkürzt keinen Link, folgt keiner Weiterleitung und entscheidet nicht, welche Schemata Ihre Anwendung erlauben soll.

Prozentkodierung ist eine umkehrbare Darstellung und keine Verschlüsselung, kein Hashing, kein HTML-Escaping und keine Berechtigung. Ein gefährliches Schema zu kodieren macht einen Link nicht vertrauenswürdig; einen Wert zu dekodieren macht ihn nicht sicher für das Einfügen als HTML oder ausführbarer Code. Wenden Sie die Prüf- und Kodierungsregeln des Zielkontexts an und halten Sie tatsächliche Geheimnisse aus geteilten Beispiel-URLs heraus.

WHATWG URL: URL-Parsen, Hosts und URLSearchParamsWHATWG URL: Parsen und Serialisieren URL-kodierter FormulardatenRFC 3986: URI-Syntax, nicht reservierte Zeichen und Prozentkodierung

Eingabelimits, wachsende Ausgabe und lokale Textdateien

Das Eingabelimit beträgt 1,000,000 UTF-16-Codeeinheiten, keine Million UTF-8-Bytes oder sichtbare Grapheme. Prozentsequenzen können die Ausgabe verlängern: Eine Million ASCII-Leerzeichen erzeugen im Komponentenmodus drei Millionen Zeichen. Kopieren und Herunterladen bleiben für Ausgaben über dem Eingabelimit verfügbar, aber Ergebnis als Eingabe verwenden kann ein solches zu großes Ergebnis nicht laden. Verfügbarer Browserspeicher bleibt eine praktische Grenze.

Beim Öffnen einer lokalen Datei liest File.text() UTF-8-Text. Dateien ab 4,000,000 Bytes werden zurückgewiesen; gelesener Text über 1,000,000 UTF-16-Einheiten wird ebenfalls zurückgewiesen. Gewöhnliches Textlesen entfernt eine anfängliche UTF-8-BOM und ersetzt fehlerhafte UTF-8-Sequenzen. Es ist daher weder bytegenaue Binärkodierung noch Dekodierung in einem beliebigen Zeichensatz. Eine Dateiendung beweist die Zeichenkodierung nicht.

W3C File API: Blob als Text lesenWHATWG Encoding: UTF-8 und TextdekodierungECMAScript: String-isWellFormed

Kopieren, Text herunterladen, leeren und Datenschutz

Herunterladen speichert das Ergebnis als UTF-8-Text in toolmellow-result.txt, nicht als Anfrage, Bericht oder geöffnete Webseite. Auch eine erfolgreiche leere Umwandlung aktiviert Ergebnis kopieren und Herunterladen. Ist die Zwischenablage nicht verfügbar, markieren und kopieren Sie die Ausgabe manuell. Für eine einfache Prüfung kodieren Sie bekannten Text, verwenden das Ergebnis bei passender Größe erneut und dekodieren mit derselben Art.

Leeren setzt Eingabe, Ergebnis, Fehler, Such- und Ersetzungsinhalte sowie den Editorverlauf zurück und behält Kodierungsart und Zeilen umbrechen bei. Arbeitsinhalte bleiben im Seitenspeicher statt in einem Kontoverlauf. Aktualisieren oder Schließen verwirft diesen Arbeitszustand; heruntergeladene Dateien bleiben auf Ihrem Gerät. Leeren garantiert keine forensische Löschung aus dem Speicher des Browsers oder Betriebssystems.

Die Umwandlung läuft in einem lokalen Browser-Worker und sendet eingegebenen URL-Text, ausgewählte Dateiinhalte oder Ergebnisse nicht an einen Umwandlungsserver. Das Laden der Website sendet weiterhin gewöhnliche Anfragemetadaten an das Hosting und nutzt Google Analytics für Seitenbesuche, einschließlich Cookies sowie Browser- und Geräteinformationen. Lokale Umwandlung bedeutet weder Anonymität noch null Netzwerkverkehr noch fehlende Infrastrukturprotokolle; lesen Sie die Datenschutzseite.

URL-Encoder und -Decoder mit Rückverweis einbetten

Wählen Sie die Seitensprache und öffnen Sie den Integrationsbereich unter dem Arbeitsbereich. Kopieren oder laden Sie den bereitgestellten HTML-Code in einen Websitebereich, der externe Iframes und Skripte erlaubt. Er enthält das ToolMellow-Iframe, das Skript zur Größenanpassung und einen sichtbaren Rückverweis zur passenden Werkzeugseite in derselben Sprache. Behalten Sie diesen Hinweis mit Link bei.

Prüfen Sie die Einbettung auf einem schmalen Bildschirm und bestätigen Sie Zwischenablageberechtigungen sowie die Unterstützung externer Ressourcen auf Ihrer Plattform. Die Einbettung hat dieselben drei Arten, denselben Textumfang und dieselben Limits; sie ist weder eine serverseitige Umwandlungs-API noch ein Dienst zum Abrufen von URLs. Der bereitgestellte Link verwendet nofollow und noopener; seine Anwesenheit garantiert keine höheren Suchplatzierungen.

Häufige Fragen

Wie kodiere ich Text für eine URL?

Wählen Sie die Art für das Ziel: URL-Komponente für einen einzelnen Wert oder ein Pfadsegment, Formularwert für Formularserialisierung oder Ganze URL für eine zusammengesetzte Adresse mit beizubehaltenden Trennzeichen. Fügen Sie Text ein und drücken Sie Kodieren. Das Werkzeug öffnet die Adresse nicht.

Wie dekodiere ich einen URL-kodierten Wert?

Wählen Sie die passende Art und drücken Sie Dekodieren. Komponenten- und Formularmodi dekodieren prozentkodiertes UTF-8 streng; der Formularmodus ersetzt außerdem zuerst wörtliche Pluszeichen durch Leerzeichen. Der Modus für ganze URLs behält Sequenzen seines eigenen reservierten Satzes bei. Er zerlegt keine Abfrage in Paare.

Wann bedeutet ein Pluszeichen in einer URL ein Leerzeichen?

In diesem Werkzeug ersetzt nur das Dekodieren von Formularwert wörtliches Plus durch Leerzeichen. URL-Komponente und Ganze URL bewahren beim Dekodieren wörtliches Plus. Das Parsen von application/x-www-form-urlencoded hat eine eigene Plusregel; sie gilt nicht allgemein für jede URL-Komponente.

Was unterscheidet %20 und +?

%20 ist die Prozentsequenz für das ASCII-Leerzeichenbyte. Formularserialisierung verwendet Plus für ein Leerzeichen und %2B für ein wörtliches Plus. Das empfangende Format bestimmt, ob Plus als Leerzeichen interpretiert werden soll.

Warum lässt das Dekodieren ganzer URLs %2F unverändert?

Dieser Modus verwendet decodeURI und behält Sequenzen für seinen eigenen Satz ;/?:@&=+$,# bei, einschließlich Schrägstrich, kaufmännischem Und und Fragmentmarkierung. Das sind nicht alle reservierten Zeichen aus RFC 3986: Kodierte eckige Klammern werden zu eckigen Klammern. Komponentenmodus dekodiert auch die Sequenzen dieser Trennzeichen. Wählen Sie nach dem vorgesehenen Adressteil und verwenden Sie den Modus für ganze URLs nicht zur Normalisierung eines IPv6-Hosts.

Wie unterscheidet sich das von encodeURIComponent?

Der Komponentenmodus von ToolMellow kodiert zusätzlich Ausrufezeichen, Apostroph, Klammern und Sternchen. Nur Buchstaben, Ziffern und -._~ bleiben wörtlich erhalten. Der Formularmodus und der Modus für ganze URLs verwenden andere Serialisierungsregeln und sind keine austauschbaren Bezeichnungen.

Warum schlägt URL-Dekodierung fehl?

Unvollständige oder nicht hexadezimale Sequenzen und ungültiges prozentkodiertes UTF-8 verursachen Fehler. Prüfen Sie Originalwert, erwartete Art und äußeres Format. Das Werkzeug repariert keine fehlerhaften Sequenzen und wählt nicht stillschweigend eine andere Zeichenkodierung.

Prüft das Werkzeug Unicode beim Dekodieren immer?

Nein. Das Dekodieren ganzer URLs prüft die rohe Eingabe auf wohlgeformten Unicode; Komponenten- und Formulardekodieren prüfen nicht separat unkodierte wörtliche Codeeinheiten. Prozentkodierte Bytefolgen werden streng als UTF-8 dekodiert. Erfolgreiches Dekodieren ist keine vollständige URL-Validierung.

Warum enthält meine URL %25?

%25 stellt ein Prozentzeichen dar. Es kann entstehen, wenn kodierter Text erneut kodiert wird, zum Beispiel beim Umwandeln von %2F in %252F im Komponentenmodus. Bestimmen Sie die erwartete Schicht; wiederholtes Dekodieren kann Daten zu strukturellen Satzzeichen machen.

Kann ich eine ganze Abfrage in Formularwert einfügen?

Das Werkzeug behandelt sie als einen Wert und nicht als eine Folge von Parameterpaaren. Das Kodieren maskiert Trennzeichen innerhalb dieses Werts; das Dekodieren extrahiert keine Namen und Werte. Verwenden Sie einen passenden URL- oder Abfrageparser für die gesamte Struktur.

Kann ich eine lokale Datei kodieren oder eine große Ausgabe wiederverwenden?

Die Dateiauswahl liest UTF-8-Text aus einer Datei unter 4,000,000 Bytes und erlaubt bis zu 1,000,000 UTF-16-Eingabeeinheiten. Das ist keine Kodierung roher Binärdateien. Größere Ausgaben können weiterhin kopiert oder heruntergeladen werden, aber Ausgaben über dem Limit können nicht erneut als Eingabe dienen.

Ist URL-Kodierung eine Verschlüsselung?

Nein. Prozentkodierung ist eine umkehrbare Darstellung und schafft keine Geheimhaltung oder Berechtigung. Sie ist auch kein Hashing, HTML-Escaping oder Nachweis einer sicheren URL. Wenden Sie die Prüf- und Kodierungsregeln des Zielkontexts an.

Kann ich den URL-Encoder und -Decoder auf meiner Website einbetten?

Verwenden Sie den lokalisierten HTML-Code unter dem Arbeitsbereich, behalten Sie den sichtbaren ToolMellow-Rückverweis bei und prüfen Sie Iframe- und Skriptunterstützung. Die Einbettung hat dieselben drei Arten und lokalen Textlimits; sie ist weder serverseitige Umwandlungs-API noch URL-Abrufdienst.

Quellen und weiterführende Informationen

Setzen Sie es in die Praxis um.