Diskussion:URL-Encoding

Überarbeiten

Vergleiche Wikipedia:Löschkandidaten/21._Dezember_2006#URL-Kodierung_.28erledigt.2C_LA_zur.C3.BCckgezogen.29. --Grüße, Auke Creutz um 23:49, 21. Dez. 2006 (CET)

Also der Artikel sollte noch ein wenig ausgearbeitet werden. Man könnte zum Beispiel auf Umlaute eingehen (die im deutschen Sprachzusammen hang ja wichtig sind.

Beispiel: le%20r.txt funktioniert, aber t%f6st.txt nicht überall oder garnicht obwohl töst.txt existiert.

Das Thema sollte man zumindest kurz anschneiden. Vielleicht auch irgendwie verlinken mit einem Thema zu de-Domains wo Umlaute "sinnvollerweise" für Webaddressen erlaubt sind (aber mit nichtdeutschen Tastaturen nur schwer einzugeben sind) Ich werde mich bemühen ob ich dazu ne gute Quelle finde. Kommentare dazu sind erwünscht und ich bin auch froh, wenn da jemand sehr genau Ahnung hat wie das nun ist und die Erweiterungen schreibt. -- JonnyJD 19:03, 24. Mai 2007 (CEST)

Da hab ich mich selber mal durch die RFC gewälzt und ein wenig nachgeforscht. So sollte das jetzt stimmen bzw. t%c3%b6st.txt funktionieren ;-) Ich muss zugeben das war lehrreich.

Des Weiteren habe ich den Artikel nochmal ein wenig überarbeitet und mit den vorangegangenen Bearbeitungen sehe ich keinen Grund mehr für den Überarbeiten-Baustein und habe ihn entfernt. Besser werden kann der Artikel natürlich trotzdem noch. -- JonnyJD 21:21, 24. Mai 2007 (CEST)

UTF-8

(nachstehende Diskussion wurde von Diskussion:UTF-8 herübergeschoben -- JonnyJD 01:40, 29. Mai 2007 (CEST)) Wieso ist das hier falsch? Die Begründung Revert, da falsch. Jedes nicht erlaubte "Oktett" wird bei der URL-Kodierung als %XX kodiert, unabhängig davon, ob es Teil einer UTF-8-Sequenz war oder nicht. macht für mich keinen Sinn. Ohne Kenntnis von UTF-8 kommt man nämlich weder von den Oktetts zu den Umlauten als auch andersherum. Wie im Artikel auch erwähnt, wird im RFC 3986 ausdrücklich UTF-8 erwähnt.

Kann mir dann jemand mal ordentlich erklären warum die Aussage, dass UTF-8 in der URL-Kodierung benutzt wird falsch ist? -- JonnyJD 12:44, 25. Mai 2007 (CEST)

Wenn ich RFC 3986 richtig interpretiere, wird weder Unicode noch UTF-8 vorgeschrieben, wenn es darum geht, nicht-ASCII-Zeichen im Pfad- oder Query-Teil einer URL zu kodieren. Es kann "[...] some other superset of the US-ASCII character encoding" benutzt werden. Also meintewegen ISO 8859-1 oder Codepage 437 oder KOI-8. Auf Seite 16 steht des weiteren:

When a new URI scheme defines a component that represents textual

data consisting of characters from the Universal Character Set [UCS],

the data should first be encoded as octets according to the UTF-8

character encoding [STD63];

Ich lese das so, dass es erstens nur für neue, also nach dem Erscheinen von RFC 3986 definierte URI-Schemata gilt, und außerdem heißt "should" nicht "must". Sprich: Neue URI-Schemen sollten UTF-8 verwenden, müssen es aber nicht, und für die bisher definierten URI-Schemen bleibt alles beim alten: Es kann jeder beliebige Zeichensatz verwendet werden, sofern sich beide Seiten über die Bedeutung der Oktette einig sind. Bei Wikipedia wurden z. B. vor der Umstellung der Wikipedia auf UTF-8 die Artikel-URLs ebenfalls (zumindest in der deutschen und englischen Wikipedia) in Latin-1 kodiert. Also http://de.wikipedia.org/wiki/Ärger wurde zu http://de.wikipedia.org/wiki/%C4rger. Und auch heute noch verstehen die Server derartige Anfragen (alles was keine gültige UTF-8-Sequenz ist, wird als ISO 8859-1 interpretiert) und schicken einen Redirekt zu http://de.wikipedia.org/wiki/%C3%84rger.

In RFC 3986 ist ist UTF-8 nur bei Hostnamen vorgeschrieben, die dem "reg-name" entsprechen, also keine IP-Adresse sind. --RokerHRO 22:32, 25. Mai 2007 (CEST)

Bei der Wikipedia funktioniert es offensichtlich (auch wenn das Linkziel bei mir auf Linux nur mit Kästchen dasteht da ich z.B. nicht Latin-1 verwende). Auf anderen Servern funktioniert das jedoch nicht in Latin-1. Siehe dazu z.B. auch die Testdateien in Diskussion:URL-Kodierung. Es kann sein, dass in Abschnitt 2.4 der Referenz UTF-8 zwar erwähnt, aber nicht vorgeschrieben wird. Eine andere Kodierung wäre aber nicht eindeutig und man muss quasi das Charset des entsprechenden Servers kennen. (du sprachst vom "einig sein" der Seiten) Wenn ich also versuche z.B. das Eurozeichen zu kodieren müsste ich wissen ob Latin-1 oder "Latin-15" verwendet werden soll. Also vielleicht schreibt es das RFC nicht zwingend vor, aber mit UTF-8 kommt man um einiges zielsicherer zum Ziel als auf anderen Wege. Vielleicht müsste man mal schaun ob man das auch anders belegen kann, aber dass dies so läuft stelle ich erstmal fest.

Die englische Wikipedia zieht UTF-8 laut en:Percent-encoding#Current standard direkt aus dem RFC (wo ich mir aber auch nicht sicher wäre). Gibt es denn noch Server die UTF-8 nicht akzeptieren? Das akzeptieren von Nicht-UTF-Kodierungen kann ja genausogut einfach aus Kompatibilitätsgründen sein. Als von fast allen Servern verstandenes Formt wäre UTF imho zu erwähnen.

Gibt es da ansonsten keinen anderen festen Standard? Also so wie es dargestellt wird schickt man mit der URL nur eine Bytefolge und hofft ganz doll, dass der Server dann auch versteht was man ihm sagen wollte? Also schön wenn es meist klappt, aber wenn es nicht klappt fängt man an zu überlegen. -- JonnyJD 00:58, 26. Mai 2007 (CEST)

Nachtrag: netzreport zieht UTF-8 aus dem RFC 3629 hinzu zur URL-Kodierung.

RFC 2718 sagt:

2.2.5 Character encoding

     When describing URL schemes in which (some of) the elements of the
     URL are actually representations of sequences of characters, care
     should be taken not to introduce unnecessary variety in the ways
     in which characters are encoded into octets and then into URL
     characters.  Unless there is some compelling reason for a
     particular scheme to do otherwise, translating character sequences
     into UTF-8 (RFC 2279) [3] and then subsequently using the %HH
     encoding for unsafe octets is recommended.

empfiehlt UTF-8 für neue URL schemes. Das heisst für mich, dass es für die meisten Server wohl eine gute Idee ist UTF-8 zu Unterstützen, aber sie nicht dazu gezwungen sind. Wie kann ich denn in dem Zusammenhang neue URL schemes verstehen?

Kann jemand finden wie die großen Browser Firefox und IE einen in der Addressleiste eingetippten Link kodieren wenn sie ihn zum Server schicken? Ich tippe ja auf UTF-8, kann es aber auch nicht finden sondern nur durch nichtrepräsentante tests raten. -- JonnyJD 01:29, 26. Mai 2007 (CEST)

-- JonnyJD 01:29, 26. Mai 2007 (CEST)

Firefox schickt Latin-1, wenn das Zeichen in Latin-1 darstellbar ist. Beispiel: http://roker.dingens.org/ß/ wird als http://roker.dingens.org/%df/ abgeschickt und vom Webserver auch verstanden. Kannst ja außerdem mal http://roker.dingens.org/¤/ und http://roker.dingens.org/€/ versuchen, letzteres wird fälschlicherweise auch auf ¤ geleitet. Interessanterweise geht http://roker.dingens.org/ÿ/ nicht, obwohl das Verzeichnis existiert. Offenbar mag der Webserver kein %FF. :-/

"URL-Schemata" sind der Teil vor dem ersten :, also http, ftp, news usw. Wenn nun jemand ein neues URL-Schema definieren will, wird ihm empfohlen, UTF-8 für die Kodierung von nicht-ASCII-Zeichen zu verwenden, außer, es sprechen zwingende Gründe ("comelling reason") dagegen.

--RokerHRO 12:04, 26. Mai 2007 (CEST)

Da fängt es schon an: Ausser bei http://roker.dingens.org/%df/ kommt bei mir immer nur ein Object not found. Unabhängig davon ob ich den Konqueror oder Firefox nehme. Mein Tip ist deshalb, dass Firefox etc. Latin-1 genau dann automatisch nehmen, wenn Latin-1 auf der Clientenmaschine eingestellt ist. Es sei angemerkt, dass auf deinem server http://roker.dingens.org/%C3%9F/ (UTF-8) auch nicht funktioniert (was bei mir identisch ist mit dem Abschicken eines unkodierten ß). Ich kann mir das nur so erklären, dass es nur davon abhängt in welchem Encoding die Datei auf dem Server liegt. Ich habe meine Testfiles mit UTF-8 hochgeladen und du deine mit Latin-1. Da beim Hochladen die Dateinamen nur als Bytes hochgeladen werden, macht das wohl den Unterschied. Das heisst aber auch, dass man ohne Klimmzüge nicht von einer Maschine mit einer Kodierung auf eine Maschine mit einer anderen klarkommt. Das ist mir bei Dokumenten etc. klar, aber dort wird die Kodierung ja festgelegt. Bei solchen Metasachen wie URLs wäre ein Standard jedoch von Nöten.

Ja, so ein Standard versucht das von dir erwähnte RFC ja zu sein. Aber bis sich so ein Standard eben in der breiten Masse durchgesetzt hat, vergeht eben eine Weile. :-/ --RokerHRO 12:10, 27. Mai 2007 (CEST)

Ich würde das also zusammenfassen, dass man erstens (immernoch) möglichst keine NON-ASCII Zeichen in URLs haben sollte (es sei denn wirklich "rein binäre" Daten) und zweitens wissen oder ahnen muss in welchem Encoding die Datei auf dem Server liegt und dann die Kodierung entsprechend vornehmen muss. Ich hätte ja gehofft da wären wir schon weiter (eine RFC von 2005 klingt ja aktuell).

Programmierer sind eben träge. Und erst recht im 7-bit-Amerika, wo selbst 8-bit-Zeichensätze langezeit kaum unterstützt worden sind. --RokerHRO 12:10, 27. Mai 2007 (CEST)

Gibt es denn eine sinnvolle Erklärung warum diverse tools die im Netz kursieren fest auf UTF-8 setzen? Haben die das alle von en.wikipedia abgeschrieben? (In dem Fall wäre eine Diskussion auf en.wikipedia fällig um den Mißstand zu beseitigen)

Ich bezweifele, dass so viele Tools fest auf UTF-8 setzen. Ich glaube, die meisten Programmierer (insbesondere von Freier Software) machen sich darüber überhaupt keine Sorgen, solange die Software auf ihrem eigenen Rechner anstandslos läuft. Kommandozeilenprogramme wie wget oder curl haben z.B. keinerlei Möglichkeit, den Zeichensatz von URLs anzugeben, sie benutzen einfach den Bytestrom, den sie über die Kommandozeile vorgesetzt bekommen. --RokerHRO 12:10, 27. Mai 2007 (CEST)

Das mit dem Scheme dachte ich mir auch irgendwie so, aber dann sind die RFCs in dem Punkt ja praktisch irrelevant für fast alle URLs. Es ist zu bezweifeln, dass http etc. so schnell durch Neuentwicklungen abgelöst werden..

Richtig. Leider. --RokerHRO 12:10, 27. Mai 2007 (CEST)

Wenn ich das nun richtig erfasst habe und es keine Beanstandungen gibt werde ich den Stand in URL-Kodierung so einarbeiten. Hier gehört dann wirklich kein Link hinein, die Diskussion wird sinnvollerweise dort hinüberkopiert und es wäre nett wenn jemand mal über meine Ausführungen in URL-Kodierung drüberschaun könnte später. Nebeneffekt ist, dass ich total enttäuscht bin vom ernüchternden Stand der Dinge ;-) -- JonnyJD 15:04, 26. Mai 2007 (CEST)

Ja, ich denke, dort kann man das Thema in epischer Breite diskutieren. In diesem Artikel kann aber durchaus erwähnt werden, dass RFC 3986 in URLs UTF-8 für nicht-ASCII-Zeichen im Hostname vorschreibt und in Pfadangaben immerhin empfielt, mit verweis dann auf das Lemma URL-Kodierung. --RokerHRO 12:10, 27. Mai 2007 (CEST)

Titeländerung

Ich schlage vor den Titel zu Prozent-Kodierung zu ändern. Nicht nur dass diese Bezeichnung auch in der RFC-Spezifikation verwendet wird, sie ist auch – wenn man sich die Verwendung dieser Kodierung anschaut – zutreffender als URL-Kodierung. Denn sie wird nicht nur bei URLs sondern auch im Header von Protokollen wie HTTP oder SMTP verwendet. (Der vorstehende, nicht signierte Beitrag stammt von 212.95.109.95 (Diskussion • Beiträge) 11:40, 9. Sep. 2007)

Also im RFC direkt kann man Percent-Encoding schreiben, weil man ja weiß worum es geht. Als TITEL hier aber vollkommen ungeeignet, da man damit nicht aussagt was mit Prozentzeichen kodiert wird. Gab es das nicht auch irgendwie in Windows Batchdateien oder ähnliches? Was du mit den HTTP/SMTP headern willst verstehe ich nicht. Dort stehen URLs (Methode, URL, Version: in der request line, Bsp. GET /index.html HTML/1.1). Die werden mit URL-Kodierung kodiert. Darum geht es doch gerade oder? Dass die URLs auch so im Browser angezeigt werden, oder halt nicht, ist ja eher ein Seiteneffekt. Wenn auch für den normalen user viel eher einsehbar als ein HTTP header ;-) Dass die englische Wikipedia so einen Begriff aus dem Raum greift, heisst ja noch lange nicht, dass wir das auch so nennen müssen. (ergo: Titel beibehalten)-- JonnyJD 15:11, 9. Sep. 2007 (CEST)

Die Kodierung wird eben nicht nur bei URLs verwendet sondern auch in den Header-Feldwerten des HTTP und SMTP. Ein Beispiel: Angenommen in einem Cookie soll ein Text mit Zeilenumbruch gespeichert werden, könnte das Header-Feld dazu wie folgt aussehen: Set-Cookie: foobar=Lorem%20ipsum%0D%0Adolor%20sit%20amet%20... was eben „Lorem ipsum〈CRLF〉dolor sit amet ...“ entspricht. 89.166.128.39 21:56, 9. Sep. 2007 (CEST)

Es wäre schön wenn sich dazu mal noch jemand drittes (vielleicht auch nicht anonymes und beliebig doppelbares) äußert. So kommen wir nicht weiter. Ich bin (stur) der Meinung, das das trotzdem die selbes Seite der selben Medaille ist. Die Cookies sind ja auch nur erzwungenen query-Variablen (für mich: get,post,cookie). Jedenfalls kein Grund URL-Kodierung als Titel für abwegig zu halten. Der Grund für die Kodierung bleibt ja haargenau der gleiche: Das HTTP-Protokoll ist ASCII-basiert. Alles was darin an Werten hineingeschrieben wird (sei es in der URL mit per get, Post-Variablen oder halt ein Cookie),wird deshalb auf die gleiche Weise kodiert. Oder willst du das HTTP-Kodierung nennen? Dann wäre SMTP aussen vor. Prozent-Kodierung ist jedenfalls nichtssagend für mich. -- JonnyJD 22:12, 10. Sep. 2007 (CEST)

der fachbegriff ist "url-encoding". mit der übersetzung kann ich leben, da erkennbar ist worum es geht. prozent-kodierung kommt nicht in die tüte, da muß man dann ja raten was gemeint sein könnte. -- ∂ 22:15, 10. Sep. 2007 (CEST)

Die Quoted-printable-Kodierung müsste dann ja genau genommen auch eigentlich E-Mail-Kodierung genannt werden, da sie eben zur Kodierung von Nicht-ASCII-Zeichen in E-Mails verwendet wird. Dennoch wird sie wie im RFC Quoted-printable genannt, weil es eben der Fachbegriff ist. 89.166.151.48 15:39, 11. Sep. 2007 (CEST)

Jein, genaugenommen ist der Artikel Quoted-printable sehr schlecht strukturiert und sollte in den Artikel Multipurpose Internet Mail Extensions eingearbeitet werden. Letzterer wäre dann das Pendant zur URL-Kodierung und nur als solcher dann thematisch vergleichbar. MIME ist in dem Fall aber wirklich ein besserer Titel als Email-Kodierung und sagt inhaltlich ja auch genau das aus. Der Titel des RFCs bezieht sich auch auf MIME genau wie sich der RFC hier auf URLs bezieht. Ich würde mich nebenbei sehr freuen wenn jemand die verschiedenen Kodierungsarten in MIME einfügt und damit einen guten Artikel erzeugt. Ich habe aber leider gerade nicht die Muße dazu. Da du dich aber anscheinen schon gut eingearbeitet hast, kannst du das ja vielleicht machen ;-) -- JonnyJD 01:30, 12. Sep. 2007 (CEST)

Der Begriff URL-Encoding ist meiner Erfahrung nach die am häufigsten verwendete Bezeichnung für diese Kodierung. Außerdem heißen entsprechende Funktionen oder Klassen in allen mir bekannten Programmiersprachen und Libraries, die sowas anbieten, urlencode/urldecode oder schlimmstenfalls noch urlify/deurlify. Eine Verwendung dieser Kodierung für SMTP-Header ist mir nicht bekannt und ich kann auch nirgends Hinweise dafür finden. Die "normale" Kodierung für SMTP Header-Values außerhalb von 7-Bit ASCII (MIME-Header bzw. MIME Encoded-Words), die in RFC 2047 beschrieben ist, unterscheidet sich wesentlich vom URL-Encoding und verwendet kein Prozentzeichen als Escape-Zeichen. Die Verwendung für Cookies im HTTP-Protocol ist nicht standardisiert, sondern nur gängige Praxis bei Websiteentwicklern, die damit die durch das HTTP-Protokoll gegebenen Beschränkungen für den erlaubten Cookie-Inhalt umgehen wollen und die in der Regel sowieso Funktionen zum Urlencoden zur Verfügung haben. Da Cookie-Inhalte von der Infrastruktur (Browser/Server/Proxy) nicht ausgewertet sondern nur weitergeleitet werden müssen, ist das auch problemlos möglich. Für HTTP-Header wird generell ISO-8859-1 oder MIME-Encoded-Words verwendet (siehe RFC 2616), außer wenn URIs oder Teile davon enthalten sind, die dann wiederum urlencoded werden. Somit wäre vielleicht URI-Encoding die exakteste Bezeichung, allerdings hatten bei der Entstehung dieses Encodings URLs noch in etwa die Bedeutung der heutigen URIs und da URL im allgemeinen Sprachgebrauch nach wie vor als Synonym für URI verwendet wird, halte ich die Bezeichnung URL-Kodierung auch immernoch für angemessen. (Die älteste auffindbare Erwähnung dieses Encodings findet sich offenbar hier vom 13. April 1992) --x4u•☏ 01:07, 4. Dez. 2007 (CET)

Einleitung

Ich habe mal an der Einleitung gebastelt, da ich gerade auf der Suche nach etwas zum Thema war und mir die wichtigsten Informationen eben dort fehlten - ich hoffe, es war keine Verschlimmbesserung. Und weiter verbessern könnt ihr gerne :-) Grüße, -- Schusch 12:53, 19. Nov. 2007 (CET)