Haben Sie mit dem URL-kodierten Format zu tun? Dann ist diese Website genau das Richtige für Sie! Nutzen Sie unser superpraktisches Online-Tool, um Ihre Daten zu kodieren oder zu dekodieren.

Kodieren in das URL-kodierte Format

Um Binärdateien (wie Bilder, Dokumente usw.) zu kodieren, verwenden Sie das Formular zum Hochladen von Dateien etwas weiter unten auf dieser Seite.

Kodieren von Dateien ins URL-kodierte Format

Klicken (oder tippen) Sie hier, um eine Datei auszuwählen
Die maximale Dateigröße beträgt 192MB.

Über uns

Willkommen bei URL Dekodieren und Kodieren. Es ist ein einfaches Online-Tool, das genau das tut, was es sagt: es dekodiert schnell und einfach aus dem URL-kodierten Format oder zurück. URL kodiert Ihre Daten ohne Probleme oder dekodiert sie in ein für Menschen lesbares Format.

URL-Kodierung, auch als Prozentkodierung bekannt, ist ein Mechanismus, um Informationen in einem Uniform Resource Identifier (URI) zu kodieren. Obwohl es als URL-Kodierung bekannt ist, wird es in der Hauptgruppe der Uniform Resource Identifier (URI) viel allgemeiner verwendet, die sowohl Uniform Resource Locator (URL) als auch Uniform Resource Name (URN) umfasst. Es wird auch bei der Aufbereitung von Daten des Medientyps "application/x-www-form-urlencoded" verwendet, wie sie häufig bei der Übermittlung von HTML-Formulardaten in HTTP-Anfragen eingesetzt werden.

Erweiterte Optionen
  • Zeichensatz: Unsere Website verwendet den Zeichensatz UTF-8, so dass Ihre Eingabedaten in diesem Format übertragen werden. Ändern Sie diese Option, wenn Sie die Daten vor der Kodierung in einen anderen Zeichensatz konvertieren möchten. Beachten Sie, dass im Falle von Textdaten das Kodierungsschema keine Informationen zum Zeichensatz enthält, so dass Sie den entsprechenden Satz während des Dekodierungsprozesses angeben müssen. Bei Dateien ist die Option binär die Standardeinstellung, die jegliche Konvertierung unterlässt; diese Option ist für alles außer einfachen Textdokumenten erforderlich.
  • Trennzeichen für Zeilenumbruch: Unix- und Windows-Systeme verwenden unterschiedliche Zeilenumbruchzeichen, so dass sie in Ihren Daten vor der Kodierung - von der gewählten Option abhängig - durch die ausgewählte Option ersetzt werden. Für den Abschnitt "Dateien" ist dies teilweise irrelevant, weil Dateien bereits die entsprechenden Trennzeichen enthalten, Sie können aber festlegen, welches für die Funktionen "Kodieren von jeder Zeile einzeln" und "Zeilen in Abschnitte aufteilen" verwendet werden soll.
  • Kodieren von jeder Zeile einzeln: Sogar Zeilenumbrüche werden in ihre prozentkodierte Form konvertiert. Verwenden Sie diese Option, wenn Sie mehrere unabhängige, durch Zeilenumbrüche getrennte Dateneinträge kodieren möchten. (*)
  • Zeilen in Abschnitte aufteilen: Die kodierten Daten werden in einen Fließtext ohne Leerzeichen umgewandelt. Aktivieren Sie diese Option, wenn Sie die Daten in mehrere Zeilen aufteilen möchten. Das angewandte Zeichenlimit ist in der MIME-Spezifikation (RFC 2045) festgelegt, die besagt, dass die kodierten Zeilen nicht länger als 76 Zeichen sein dürfen. (*)
  • Live-Modus: Wenn Sie diese Option aktivieren, werden die eingegebenen Daten sofort mit den integrierten JavaScript-Funktionen Ihres Browsers kodiert, ohne dass Informationen an unsere Server gesendet werden. Derzeit unterstützt dieser Modus nur den Zeichensatz UTF-8.
(*) Diese Optionen können nicht gleichzeitig aktiviert werden, weil die resultierende Ausgabe für die meisten Anwendungen ungültig wäre.

Sicher und geschützt

Die gesamte Kommunikation mit unseren Servern erfolgt über sichere SSL-verschlüsselte Verbindungen (https). Wir löschen hochgeladene Dateien sofort nach der Verarbeitung von unseren Servern. Die daraus resultierende herunterladbare Datei wird direkt nach dem ersten Downloadversuch oder nach 15 Minuten Inaktivität (je nachdem, was kürzer ist) gelöscht. Der Inhalt der übermittelten Daten oder hochgeladenen Dateien wird von uns in keiner Weise aufbewahrt oder überprüft. Lesen Sie unsere Datenschutzerklärung unten für weitere Details.

Völlig kostenlos

Die Nutzung unseres Tools ist kostenlos. Von nun an müssen Sie für solche einfachen Aufgaben keine Software mehr herunterladen.

Details der URL-Kodierung

Typen von URI-Zeichen

Die in einem URI zulässigen Zeichen sind entweder reserviert oder nicht reserviert (oder ein Prozentzeichen als Teil einer Prozent-Kodierung). Reservierte Zeichen sind Zeichen, die manchmal eine besondere Bedeutung haben. So werden beispielsweise Schrägstriche verwendet, um verschiedene Teile einer URL (oder allgemeiner eines URI) zu trennen. Nicht reservierte Zeichen haben keine solche besondere Bedeutung. Bei der Prozentkodierung werden reservierte Zeichen durch spezielle Zeichenfolgen dargestellt. Die reservierten und nicht reservierten Zeichensätze und die Umstände, unter denen bestimmte reservierte Zeichen eine besondere Bedeutung haben, haben sich mit jeder neuen Revision der Spezifikationen, die URIs und URI-Schemata regeln, leicht geändert.

RFC 3986 Abschnitt 2.2 Reservierte Zeichen (Januar 2005)
! * ' ( ) ; : @ & = + $ , / ? # [ ]

RFC 3986 Abschnitt 2.3 Nicht reservierte Zeichen (Januar 2005)
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

Andere Zeichen in einem URI müssen in Prozent kodiert werden, um korrekt dargestellt zu werden.

Prozentkodierung reservierter Zeichen

Wenn ein Zeichen aus dem reservierten Satz, auch bekannt als "reserviertes Zeichen", eine besondere Bedeutung, auch "reservierter Zweck", in einem bestimmten Kontext hat und ein URI-Schema besagt, dass es notwendig ist, dieses Zeichen für einen anderen Zweck zu verwenden, muss das Zeichen prozentkodiert werden. Die Prozentkodierung eines reservierten Zeichens bedeutet, dass das Zeichen in seinen entsprechenden Byte-Wert in ASCII konvertiert wird und dieser Wert dann als ein Paar von Hexadezimalziffern dargestellt wird. Die Ziffern, denen ein Prozentzeichen ("%") vorangestellt ist, werden dann im URI anstelle des reservierten Zeichens verwendet. (Ein Nicht-ASCII-Zeichen wird in der Regel in seine Bytefolge in UTF-8 konvertiert, und dann wird jeder Byte-Wert wie oben beschrieben dargestellt.)

Das reservierte Zeichen "/" zum Beispiel hat, wenn es in der "Pfad"-Komponente eines URI verwendet wird, die besondere Bedeutung eines Trennzeichens zwischen Pfadsegmenten. Wenn nach einem bestimmten URI-Schema "/" in einem Pfadsegment enthalten sein muss, dann müssen die drei Zeichen "%2F" (oder "%2f") anstelle eines "/" in diesem Segment verwendet werden.

Reservierte Zeichen nach der Prozentkodierung
! # $ & ' ( ) * + , / : ; = ? @ [ ]
%21 %23 %24 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5D

Reservierte Zeichen, die in einem bestimmten Kontext keinen reservierten Zweck haben, können ebenfalls prozentual kodiert werden, unterscheiden sich aber semantisch nicht von anderen Zeichen.

In der "Abfrage"-Komponente eines URI (der Teil nach einem "?"-Zeichen) wird beispielsweise "/" immer noch als reserviertes Zeichen betrachtet, aber es hat normalerweise keinen reservierten Zweck (es sei denn, ein bestimmtes URI-Schema definiert es anders). Das Zeichen muss nicht prozentkodiert werden, wenn es keinen reservierten Zweck hat.

URIs, die sich nur dadurch unterscheiden, ob ein reserviertes Zeichen prozentual kodiert ist oder nicht, werden normalerweise als nicht äquivalent (dieselbe Ressource bezeichnend) betrachtet, es sei denn, die fraglichen reservierten Zeichen haben keinen reservierten Zweck. Diese Bestimmung hängt von den Regeln ab, die von den einzelnen URI-Schemata für reservierte Zeichen festgelegt wurden.

Prozentkodierung von nicht reservierten Zeichen

Zeichen aus dem nicht reservierten Satz müssen nie prozentual kodiert werden.

URIs, die sich nur darin unterscheiden, ob ein nicht reserviertes Zeichen prozentkodiert ist oder nicht, sind per Definition äquivalent, aber URI-Verarbeiter behandeln sie in der Praxis nicht immer als äquivalent. Beispielsweise sollten URI-Konsumenten "%41" nicht anders behandeln als "A" ("%41" ist die Prozentkodierung von "A") oder "%7E" anders als "~", aber einige tun es doch. Im Interesse größtmöglicher Interoperabilität wird den URI-Herstellern daher von der Prozentkodierung nicht reservierter Zeichen abgeraten.

Prozentkodierung des Prozentzeichens

Da das Prozentzeichen ("%") als Indikator für prozentkodierte Oktette dient, muss es als "%25" prozentkodiert sein, damit dieses Oktett als Data innerhalb eines URI verwendet werden kann.

Prozentkodierung beliebiger Daten

Die meisten URI-Schemata beinhalten die Darstellung beliebiger Daten, wie z. B. einer IP-Adresse oder eines Systempfads, als Komponenten eines URIs. URI-Schema-Spezifikationen sollten eine explizite Zuordnung zwischen URI-Zeichen und allen möglichen Datenwerten, die durch diese Zeichen dargestellt werden, vorsehen, tun dies aber häufig nicht.

Binäre Daten

Seit der Veröffentlichung von RFC 1738 im Jahr 1994 ist festgelegt, dass Schemata, die die Darstellung von Binärdaten in einem URI vorsehen, die Daten in 8-Bit-Bytes unterteilen und jedes Byte auf dieselbe Weise wie oben beschrieben prozentual kodieren müssen. Der Byte-Wert 0F (hexadezimal) sollte zum Beispiel durch "%0F" dargestellt werden, aber der Byte-Wert 41 (hexadezimal) kann durch "A" oder "%41" dargestellt werden. Die Verwendung von nicht kodierten Zeichen für alphanumerische und andere nicht reservierte Zeichen wird in der Regel bevorzugt, da dies zu kürzeren URLs führt.

Zeichendaten

Das Verfahren für die Prozentkodierung von Binärdaten wurde oft - manchmal unangemessen oder unvollständig spezifiziert - auf zeichenbasierte Daten extrapoliert. In den Anfangsjahren des World Wide Web, als man mit Datenzeichen aus dem ASCII-Repertoire arbeitete und die entsprechenden Bytes in ASCII als Grundlage für die Bestimmung prozentkodierter Sequenzen verwendete, war diese Praxis relativ harmlos; viele Leute gingen davon aus, dass Zeichen und Bytes eins-zu-eins abgebildet werden und austauschbar sind. Die Notwendigkeit, Zeichen außerhalb des ASCII-Bereichs darzustellen, wuchs jedoch schnell, und URI-Schemata und -Protokolle boten oft keine Standardregeln für die Aufbereitung von Zeichendaten zur Aufnahme in einen URI. Webanwendungen begannen daher, verschiedene Multi-Byte-, zustandsabhängige und andere nicht-ASCII-kompatible Kodierungen als Grundlage für die Prozentkodierung zu verwenden, was zu Mehrdeutigkeiten und Schwierigkeiten bei der zuverlässigen Interpretation von URIs führte.

Viele URI-Schemata und Protokolle, die auf den RFCs 1738 und 2396 basieren, gehen beispielsweise davon aus, dass die Datenzeichen gemäß einer nicht spezifizierten Zeichenkodierung in Bytes konvertiert werden, bevor sie in einem URI durch nicht reservierte Zeichen oder prozentkodierte Bytes dargestellt werden. Wenn das Schema keine Kodierungshinweise im URI erlaubt oder die Kodierung mit ASCII-Kodierung in Konflikt gerät, kann der URI nicht zuverlässig interpretiert werden. Einige Schemata berücksichtigen die Kodierung überhaupt nicht und schlagen stattdessen nur vor, dass Datenzeichen direkt auf URI-Zeichen abgebildet werden, was es den einzelnen Benutzern überlässt, zu entscheiden, ob und wie sie Datenzeichen, die weder in den reservierten noch in den nicht reservierten Zeichen enthalten sind, prozentkodieren.

Gebräuchliche Zeichen nach der Prozentkodierung (ASCII oder UTF-8 basierend)
neue Zeile Leerzeichen " % - . < > \ ^ _ ` { | } ~
%0A oder %0D oder %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E

Beliebige Zeichendaten werden manchmal prozentkodiert und in Nicht-URI-Situationen verwendet, z. B. für Programme zur Verschleierung von Passwörtern oder andere systemspezifische Übersetzungsprotokolle.
Zur Desktop-Version wechseln
2012-2024 urlencoder.org
Datenschutzbestimmungen Kontakt
Diese Website verwendet Cookies. Wir verwenden Cookies, um Inhalte/Anzeigen zu personalisieren und unseren Datenverkehr zu analysieren.