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)

Eindeutigkeit

   Eine Verwechslung ist somit nicht möglich.

Leider ist eine Verwechslung von UTF-8 und z.B. ISO 8859-1 sehr wohl möglich. Es ist zwar unwahrscheinlich, dass ein Text — als ISO 8859-1 kodiert — nur UTF-8-gültige Byte-Sequenzen enthält, es ist aber nicht unmöglich. Daher ist die Aussage, dass eine Verwechslung sei nicht möglich sei, absolut nicht haltbar. Ich spiele mit dem Gedanken, den Absatz „Eindeutigkeit“ in „Mehrdeutigkeit“ umzubenennen und neu zu schreiben (u.a. mit einem Verweise auf die eben ergänzte Möglichkeit, die Kodierung als "charset" im HTTP-Header "Content-Type" anzugeben). SvenHerzberg 17:35, 24. Aug. 2011 (CEST)

Dieser Fehler fiel mir beim Lesen auch gleich auf. Ich habe es hoffentlich etwas klarer geschrieben. Statt den Abschnitt neu zu schreiben, kann man auch erwägen, ihn einfach zu entfernen. Er ist unvollständig (beispielsweise kann man manche URLs eindeutig als "nicht UTF-8" oder "nicht ASCII" erkennen), nicht unbedingt hilfreich und auch nicht Themen-spezifisch. Vielleicht wäre so eine "UTF-8 vs. ASCII Eindeutigkeitsdiskussion" in UTF-8 besser aufgehoben. --Steffen (Diskussion) 13:50, 11. Apr. 2013 (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)

Natürlich kann man Set-Cookie: foobar=Lorem%20ipsum schreiben, aber meines Verständnisses nach hat das %20 hier für HTTP keine spezielle Bedeutung. Es ist kein Leerzeichen. Meines Verständnisses nach wäre beispielsweise Set%2DCookie%3A ein anderes Headerfeld. RFC 2616 (HTTP/1.1) schreibt TEXT = <any OCTET except CTLs, but including LWS>, mit CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)>, die anderen Zeichen müssen aus ISO 8859-1 oder nach RFC 2047 kodiert werden. Ein Leerzeichen (octet 32) ist damit ohne spezielle Kodierung erlaubt. RFC 2047 hat übrigens als ein Beispiel (=?ISO-8859-1?Q?a_b?=) als encoded form für (a b), was so in URIs nicht verwendet wird; das ist also ein anderes Thema. Wenn eine Webanwendung zusätzliche Kodierungen verwendet, beispielsweise nach RFC 3986, ist das meiner Meinung nach anwendungsspezifisch und nicht allgemeingültig. --Steffen (Diskussion) 14:44, 11. Apr. 2013 (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)

Ja, finde ich auch, die hier beschriebene Kodierung könnte man korrekter "URI-Kodierung" nennen, da sie nicht nur für URLs gilt. Das passt dann auch besser zum Titel von RFC 3986 (Uniform Resource Identifier (URI): Generic Syntax). --Steffen (Diskussion) 14:44, 11. Apr. 2013 (CEST)

• Du hast formal recht: Weil URI der abstrakte Obertyp ist und das Verfahren (auch) auf URI-Ebene für alle abgeleiteten Bezeichner definiert ist, kann man das so nennen.
• Nur ist es unter dem altehrwürdigen Namen vielfach bekannter; Google findet 342.000 gegen 33.000 Vorkommen.
• Eine WL als URI-Encoding würde ich deshalb jederzeit begrüßen; eine Lemma-Verschiebung dagegen nicht.
• Die Kollegen der enWP verwenden Prozentkodierung als Lemma und erwähnen ausschließlich URL-Encoding als Synonym.
• Der Ausdruck URI-Encoding ist schlicht ungebräuchlich; bekannt wurde es nun einmal mit der RFC 1738 im Jahr 1994. Die Verallgemeinerung zur URI war auch schon 1994 mit der RFC 1630 (Encoding dort auf Seite 8) aufgebracht worden.
  • 1994 wurde allerdings noch die alte Verschlüsselung der ISO 8859-1 thematisiert.
• Der Artikel könnte in seiner Einleitung deutlich herausstellen, dass dies auch für URI gilt und die Methodik auch in anderen Bereichen (Cookie) zum Escaping benutzt wird.
• URI sind ein abstrakter Obertyp und haben selbst keine konkreten Anwendungen.
  • Nicht-URL-Anwendungen von URI sind, grob gesprochen, URN. Praktisch alle vorkommenden Anwendungen von URN sind aber so aufgebaut, dass ausschließlich ASCII-Zeichen zur Identifizierung vorkommen (DOI usw.) und Encoding nie erforderlich wird. Ich wüsste jetzt spontan erstmal keine URN, die eines Encoding bedürften; insbesondere wenn man klassischerweise die E-Mail-Adressen den URL zuschlägt. Hier ist data: auch wieder so ein Sonderfall.
• Heißt in der Konsequenz: So gut wie alle praktisch vorkommenden Anwendungen sind URL-Encoding; hinzu kommt die Nutzung des identischen und wohlbekannten Verfahrens für Cookies usw. (was allerdings nicht von den RFC erfasst wurde).

Liebe Grüße --PerfektesChaos 21:06, 11. Apr. 2013 (CEST)

Ich halte PerfektesChaos' Argumentation für logisch und valide, weshalb ich von einer Lemmaverschiebung ebenfalls absehen würde. --Lagunenfisch (Diskussion) 14:08, 13. Apr. 2013 (CEST)

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)

ACHTUNG: Eine Zusatzangabe zu einem lokalen Netzwerknamen kann in einer URI möglich sein. Diese Angabe wird in zwei Schrägstriche // eingeschlossen.

http://de.selfhtml.org/html/allgemein/referenzieren.htm (nicht signierter Beitrag von 94.222.190.160 (Diskussion) 17:12, 8. Mai 2011 (CEST))

Prozentzeichen

Der Englische Artikel zur URL Kodierung erwähnt das Prozentzeichen nicht als reserviertes Zeichen. Wenn man RFC 3986 liest dann sieht man dass das Prozentzeichen wirklich nicht reserviert ist.

-- Janburse 17:39, 24. Jul. 2011 (CEST)

'Because the percent ("%") character serves as the indicator for percent-encoded octets, it must be percent-encoded as "%25"' [| RFC 3986, Page 14]. Der Englische Artikel sollte korrigiert werden.

-- Beste Grüße, kwt (nicht signierter Beitrag von 212.21.166.254 (Diskussion) 13:47, 8. Okt. 2012 (CEST))

en:Percent-encoding#Percent-encoding the percent character – habe nicht erforscht, seit wann das da steht. Das Prozentzeichen ist nicht reserviert, man kann es aber nicht „verbatim” im Link unterbringen, weil es so als Einleitung einer Prozentkodierung fehlinterpretiert werden könnte. Man muss es also irgendwie maskieren, und dazu bietet sich seine Prozentkodierung an (andere Maskierung halte ich für möglich, „must“ insofern falsch). --Lückenlos^wecken! 16:38, 27. Dez. 2014 (CET)

An diesem philosophischen Problem hätten die ollen Griechen ihre Freude gehabt.

Aus der Perspektive einer URI ist das Prozentzeichen auch nicht „reserviert“. Es trennt in der URI keine logischen Bestandteile voneinander; hat keine syntaktische Bedeutung. Deswegen wird es nicht bei den reservierten Zeichen gelistet.

In dem Moment jedoch, in dem ich mich entscheide, ~ oder § oder halt % zum Encoding zu benutzen, ist dieses Zeichen der Liste der reservierten Zeichen hinzuzufügen; das angetroffene Markierungszeichen selbst muss immer kodiert werden.

Eine andere Maskierungsmöglichkeit als die Anwendung derselben Encoding-Prozedut, die auch auf die reservierten Zeichen angewendet wird, ist nicht definiert und würde die Sache auch nur unnötig verkomplizieren. So kann der Server jedes Zeichen, das bei ihm ankommt, auf das Markierungszeichen prüfen und wertet dann stumpf das nachfolgende Oktett aus. Was immer dabei rauskommen möge; wegen ANSI/UTF-8 ist das immer noch zweideutig genug. Die andere gebräuchliche Maskierungsmöglichkeit ist die Verdoppelung (da \ keine Sonderbedeutung hat); also würde %% für ein einzelnes Prozent stehen. Dazu muss ich aber beim Entschlüsseln wieder denken und verzweigen. Also einfach stumpf entschlüsseln, und beim Verschlüsseln das Markierungszeichen ganz simpel wie ein reserviertes Zeichen behandeln.

LG --PerfektesChaos 17:32, 27. Dez. 2014 (CET)

Oder: für die Definition einer validen URL ist das Prozentzeichen nicht reserviert – mir fällt eben auf, dass das momentan im Artikel und auch in URL falsch steht. In deren Rahmen kann man mit dem Prozentzeichen alles mögliche anstellen, z. B. eine Domain www.100%ig.de anlegen (oder? Chromium spinnt, aber Midori und Firefox melden brav, dass es die Domain nicht gibt). – Nun kann man die Methode der Prozentkodierung als spezielles Feature hinzufügen, dadurch wird das Prozentzeichen dann reserviertes Zeichen. – Allerdings führt RFC 3986 das %-Zeichen auch nicht als „nicht reserviert“ auf, das finde ich nicht ganz durchdacht. In RFC 1738 wird es immerhin als unsafe geführt, gerade mit Hinweis auf mögliche Prozentkodierung … --Lückenlos^wecken! 20:19, 29. Dez. 2014 (CET)

Felder

Ad. "URLs können maximal folgende Felder beinhalten:"

Wieso Felder? Es geht an dieser Stelle doch um Zeichen! Ausserdem gibt es keine maximalen Felder - was sollte bei einer URL damit genmeint sein? (nicht signierter Beitrag von 178.191.185.68 (Diskussion) 16:00, 12. Aug. 2011 (CEST))

Mir kommt es auch so vor, als könne man das erst verstehen, wenn man es schon anderswoher weiß. Ich verstehe ungefähr, was gemeint ist, finde es aber nicht einfach, es flüssig zu erklären. – Zu Felder vs. Zeichen: Die erste eingerückte Zeile ist ein Beispiel, gebildet aus den „speziellen“ Zeichen, die die Felder voneinander trennen, und Beispielen für die einzelnen Felder, „z. B.“ ist info eine Beispielzeichenkette für das letzte mögliche Feld, das hier als „Dokumentenanker“ bezeichnet wird. Die „Felder” werden auch bei weitem nicht einzeln genannt, nur eine „beispielhafte” Auswahl von ihnen wird angedeutet. Der „formale“ Rahmen für eine „exakte“ Darstellung des Sachverhalts wäre die Theorie formaler Sprachen. Ein „Feld“ würde ich als Variable interpretieren, die Zeichenketten als Werte annehmen kann. „Zeichenkette“ bezieht sich auf ein bestimmtes formales Alphabet (vgl. Code, worauf die Einleitung ja auch verlinkt – Alphabet (Informatik)), den „Zeichenvorrat“, den man exakterweise irgendwo nennen müsste. Hier entspricht er wohl (für die gesamte Zeichenkette) den US-ASCII-Zeichen (vg. Einleitung: „nur bestimmte Zeichen des ASCII-Zeichensatzes“), im Falle der Felder ohne die genannten „reservierten“ oder sonstwie „speziellen“ Zeichen. Die exakte Darstellung wäre sehr viel aufwändiger als die vorhandene Andeutung … „Es geht an dieser Stelle doch um Zeichen!“ Ich finde es allerdings schon frech, zu behaupten, es gehe „doch um Zeichen“, bevor man verstanden hat, worum es geht. – Zu „maximal“ etwas einfacher: Im vorhandenen Text ist nicht von „maximalen Feldern“ die Rede, sondern von „maximal vorhandenen“. In der Beispielzeile kommen alle möglichen Felder vor. Ein Beispiel für Felder, die „minimal“ vorhanden sein müssen, wäre vielleicht example.net – alles habe ich auch noch nicht verstanden. --Lückenlos^wecken! 17:53, 26. Dez. 2014 (CET) – Hm, es geht hier schon eher um Zeichen! als um Felder, die „Felder“ werden hier ins Spiel gebracht, um die „speziellen Zeichen“ zu erklären. Vielleicht würde der Abschnitt verständlicher, wenn man die „Felder“ nicht als allererstes bringt, sondern die „speziellen Zeichen“, und dann die „Felder“ zur Erläuterung. --Lückenlos^wecken! 18:36, 26. Dez. 2014 (CET)

Wie wäre es, im umseitigen Artikel statt dessen die Vokabel „Elemente“ einzubauen?

• Der Begriff fields kommt meiner Erinnerung nach häufiger in den RFC vor, ohne dass ich jetzt eine Strichliste gemacht hätte. Aber wir müssen sowas ja nicht buchstäblich übersetzen.
• Die „Elemente“ sind die menscheninterpretierten anschaulichen Konzepte wie Fragmentbezeichner, Parametername, Pfad usw., auf die sich etwa ein Browser verlässt.
• Die Vokabel „Element“ kommt allerdings momentan für die Zuweisung n=v vor, aber diese Gruppe könnte man ja in „Zuweisung“ umbenennen.

Der Satz „URLs können maximal folgende Felder enthalten:“ ist sowieso verbesserungfähig.

• Plural von URL in Germanisch ist nicht URLs.
• Nur links vom Schrägstrich nach der Domain hat jemand Vorschriften zu machen, nur das ist technisch interessant.
• Alles ab dem einzelnen / ist Privatangelegenheit des Servers und nur eine Empfehlung, um anschaulich interpretierbare und mit Standardsoftware ver- und entschlüsselbare URL zu konstruieren.

LG --PerfektesChaos 23:43, 26. Dez. 2014 (CET)

Ich wusste nicht, dass da auch von „Elementen“ gesprochen wird, das finde ich jetzt auch wegen „HTML-Element“ verwirrend. „Feld“ finde ich ganz intuitiv, kann man wie in einem Formular i. A. leerlassen. Habe keinen Verbesserungsvorschlag. Halt, „Eine URL kann“ könnte besser sein als „URLs können“. --Lückenlos^wecken! 16:51, 27. Dez. 2014 (CET)

Als menschlicher Thesaurus, ohne eine Software oder diese alten raschelnden Papierdinger bemüht zu haben, kann ich noch spontan „Bestandteile“ oder „Komponenten“ in den Ring werfen. In der RFC 3986 werden components dafür gebraucht. „Felder“ erinnert mich an die Felder im HTTP, deren GET gerade die gewünschte URL (bzw. der Pfad-Anteil) ist.

LG --PerfektesChaos 17:37, 27. Dez. 2014 (CET)

Nun erscheint mir Verweis auf URL#Aufbau sehr hilfreich, wo dummerweise auch wieder „Elemente“ steht. RFC 3986 spricht selbst von „Elementen“ eines URI, dann aber mehr von Protokoll-„Elementen“. „Bestandteile” ist ganz gut – RFC 3986 verwendet sogar „components“! „Bestandteile“ wäre vielleicht als Übersetzung angemessen. – Es wäre schön, die „reservierten“ Zeichen farblich abzusetzen, in Hilfe:Syntaxhighlight sehe ich dazu aber so schnell nichts. --Lückenlos^wecken! 21:46, 29. Dez. 2014 (CET)

– „Bestandteile“ steht ja sogar unter in URL#Geschichte! --Lückenlos^wecken! 11:43, 30. Dez. 2014 (CET)

vgl. http://wiki.selfhtml.org/wiki/Glossar:URL-Codierung --Lückenlos^wecken! 11:43, 30. Dez. 2014 (CET)

Hilfe:Syntaxhighlight befasst sch mit formalen Sprachen; der serverseitige Anteil einer URL nach dem ersten Schrägstrich ist aber nur ein pragmatisches Gewurstel.

Das%20l%C3%A4sst+sich_machen.

Guten Rutsch schon mal. --PerfektesChaos 12:27, 30. Dez. 2014 (CET)

212.21.166.254, Edit vom 2012-10-08, 09:52:46

[Worum geht es? Vielleicht diese drei IP-Edits, so revertiert? --Lückenlos^wecken! 16:55, 29. Dez. 2014 (CET)]

Bedaure, diese Textänderung geht mir zu weit. Ich habe erstmal reverted; dein Edit ist ja rekonstruierbar und wäre erstmal hier auf der Disku zu klären.

• Gegenüber der vorherigen Variante wird weniger deutlich, was „müssen“, „sollen“, „kann“, „manchmal“, „besser nicht“ ist.

-- Zugegeben, hast recht.

• Die Ausflüge in die Zeichenkodierungen sind mindestens an dieser Stelle zu weitgehend; wenn überhaupt, dann an anderer Stelle.
• Grundsätzlich gibt der Server und der Publizierer einer Ressource vor, wie die Adresse auszusehen hat und sonst niemand. Der Betreiber des Servers entscheidet innerhalb der übertragungstechnisch erlaubten Zeichen, welche URL für eine bestimmte Aktion gilt.

-- Ich muss mich korrigieren, nur-ASCII ist nicht korrekt, habe das Fehlinterpretiert. URIs erlauben dem Publizierer einer Ressource das Verwenden von beliebigen Zeichensätzen für bestimmte Teile (z.B. Daten) der URI.

• Nett ist es, wenn es dabei die hübsche Encoding-Formel gibt, mit der man sich über Prozentzeichen eine menschenlesbare Anzeige kyrillischer Buchstaben zurückrechnen kann. Das muss aber nicht so sein. Nichts anderes ist die Bedeutung der RFC 3166 RFC 3986.

-- RFC 3166 ist ein 'Request to Move RFC 1403 to Historic Status'. Ich nehme mal an das ist'n typo?

Nee, das war der Versuch, mir ohne C&P die vier Ziffern RFC 3986 von der Vorderseite zu merken. Bloß war ich grad auf dem andern Ohr in der ISO 3166 und hatte meine Hirnhälften miteinander vertauscht. P.C.

• Kein Server-Betreiber ist dazu verpflichtet, irgendwelches Prozent-Encoding zu unterstützen und irgendwelche Zeichenketten umzuformatieren. Jeder Server kann das Prozentzeichen nach eigenem Belieben interpretieren; ob das bei Neueinführungen schlau wäre, ist eine andere Frage.

-- 'Once produced, a URI is always in its percent-encoded form' (RFC 3986, Page 14) und 'URIs that differ in the replacement of an unreserved character with its corresponding percent-encoded US-ASCII octet are equivalent: they identify the same resource.' (RFC 3986, Page 14). D.h. Wenn sich ein Serverbetreiber an den Standard halten will, so muss er es unterstützen. Aber ein Standard ist kein Gesetz, weshalb du recht hast: Verpflichtet ist er nicht.

• Der momentane Text ist hinsichtlich Verständlichkeit suboptimal; der Änderungsversuch jedoch noch nicht zielführend und noch verwirrender.

-- Zugegeben, suboptimal.

• IRIs sind URIs?

-- Nein, IRIs sind ein neuer Standard, der den URI Standard ablösen soll. IRI sieht alle Zeichen des UCS vor definiert aber kein binäres Encoding dieser Zeichen). URIs hingegen erlauben vom Anbieter definierte Zeichensätze für bestimmte Teile (und definieren auch kein binäres Encoding). (nicht signierter Beitrag von 212.21.166.254 (Diskussion) 13:47, 8. Okt. 2012 (CEST))

Beste Grüße --PerfektesChaos 10:20, 8. Okt. 2012 (CEST)

-- Danke für deine Kommentare -- kwt (nicht signierter Beitrag von 212.21.166.254 (Diskussion) 13:47, 8. Okt. 2012 (CEST))

Mir gefällt der Artikel auch nicht so recht; aber ich habe grad keinen Nerv, ihn grundlegend neu zu schreiben. Es wird der Gesamt-Zusammenhang nicht so richtig deutlich.

• Alle diese RFC sind nur Angebote. Sie bieten eine Standard-Lösung an für Standard-Probleme, die alle Programmierer eines Webservers haben. Damit nicht jeder das Rad neu erfinden muss und man untereinander versteht, was die anderen machen, übernimmt man intelligenterweise bei Neuentwicklungen die von den RFC vorgeschlagene Lösung. Diese sind aber keine Standards, und niemand muss sich dran halten.
• Ausgangspunkt ist das HTTP-GET.
  • Alles, was sich übertragungstechnisch in das GET aus RFC 1945 #section-5.1 zwischen die beiden Leerzeichen SP hineinquetschen lässt und keine CR LF enthält, kann die Ressource identifizieren.
  • Das sind völlig beliebige 7-Bit-Zeichen von 33 bis 127. Andere (8-bit, Tabulator, FormFeed) wären im Prinzip auch noch zur Identifizierung der Ressource möglich; es kann aber sein, dass unterwegs ein Netzknoten oder Proxy das ausliest und Whitespace konvertiert oder Identifizierer mit 8-Bit-Zeichen als beschädigt ansieht, verwirft und die Anfrage nicht weiterleitet.
  • Insbesondere kann man ein # in den Identifizierer einbauen. Weil Browser die Adresse vor der Anfrage am # abschneiden und üblicherweise nur den Teil davor für die Anfrage benutzen, das Fragment hinter dem # sich jedoch lokal merken und nach Eintrudeln der Ressource zum Ankersprung benutzen, könnten diese Ressourcen nur mit sockets oder wget usw. abgerufen werden.
  • Die URI sehen deshalb per RFC 1630 vor, dass der Identifizierer kein # enthalten sollte.
  • Die URI für neu eingerichtete Server-Identifizierer-Strukturen sollen das Prozentzeichen nach den Encoding-Decoding-Regeln dieses Artikels benutzen.
  • Wenn man hierarchische Datenstrukturen verwendet, sollen Schrägstriche zur Gliederung der Segmente benutzt werden. Ob man diese so interpretiert und ob da etwas hierarchisch ist, steht dem Betreiber frei.
  • Wenn man Queries benutzt, soll man sie mit dem Fragezeichen einleiten und danach = für die Wertzuweisung und danach & oder ; (HTML) für die Trennung von Tupeln benutzen. Hat man aber keine Query, kann man die ? = & als ganz normale Textzeichen benutzen.
  • Diese Empfehlungen sind in der ersten Hälfte der 1990er (zunächst noch ohne UTF-8 und in plain ISO-8859-1) entstanden. Wer etwas Neues aufbaut, sollte sich möglichst daran halten, darf aber auch eine komplette Eigenentwicklung zur Konstruktion seiner Identifizierer verwenden. Man kann seinen Identifizierer dann halt nicht mehr URI nennen, weil er nicht mehr uniform gemäß RFC 1630 ist.
  • Hält man sich nicht daran, funktioniert es auch, bloß halt nicht unbedingt mit Browsern oder HTML-Formularen.
• Man hat als Publisher ein Dokument mit einem menschenlesbaren Namen, etwa „Rödel“ oder „Русский“; passt halt nicht in 7 Bit.
  • RFC 1630 bietet jetzt die Möglichkeit, sich einen 7-Bit-Identifizierer dazu auszudenken, der dieses Dokument mit einem Namen versieht, der hinterher wieder in eine menschenlesbare Form konvertiert werden kann und den ursprünglichen Dokument-Namen wiedergibt.
  • Man kann aber als Identifizierer auch wählen: „Hurradudodeldu“, „A79B21F52E310C“ oder „gliggelblumpf“.
• Der Betreiber des Servers gibt vor, wie die URI→URL lautet, unter der er eine Ressource zur Verfügung stellt.
  • Eigentlich dürfte man nur solche Ressourcen abrufen, von denen zuvor der Server die URL bekanntgegeben hatte.
  • Tückisch wird es, wenn die Benutzer sich selbst die URL ausdenken, unter der sie eine Ressource erwarten. Das ist aber bei Such-Abfragen zwangsläufig der Fall.
• Zeitliche Entwicklung:
  • RFC 1630 (1994): ISO 8859-1 (Westliche Welt) – genau analog der Praxis im NCSA, heute Apache.
  • RFC 2396 #section2.1 (1998) erwähnte UTF-8 – „source of confusion“
  • RFC 3986 (2005) – Nichts Neues in dieser Angelegenheit
  • RFC 3987 (2005) = Internationalized Resource Identifier (IRI) – fordert UTF-8 und gibt präzise Regeln dazu vor.
• Ein schlauer Server kann auf verschiedene Identifizierer-Anfragen mit derselben Ressource korrekt antworten.
  1. Er kann R%C3%B6del als „Rödel“ verstehen und dekodieren.
  2. Er kann gleichzeitig R%f6del als „Rödel“ verstehen und dekodieren.
  3. Er kann auch noch Rödel als „Rödel“ verstehen und dekodieren.
  4. „Русский“ kann auch als @Rcy;@ucy;@scy;@scy;@kcy;@icy;@jcy; verstanden und kodiert werden.
  • Wohl nur im ersten Fall würde ein Browser das in der Adresszeile hübsch menschenlesbar darstellen können.
  • Die ersten beiden Fälle sind uniform gemäß RFC nach 2005 / vor 1996. Die weiteren sind proprietär und keine URI gemäß RFC.

Soviel dazu; beste Grüße --PerfektesChaos 17:18, 8. Okt. 2012 (CEST)

Tabellen mit reservierten Zeichen ergänzen

In der englischsprachigen Version dieses Artikels sind zwei Zeichentabellen zu finden: „Reserved Characters“ und „Unreserved Characters“. Ich halte diese Tabellen für hilfreich und insbesondere Neulingen würden sie einen schnellen Überblick geben. Da diese Tabellen eine größere Änderung des Artikels darstellen, möchte ich mich vor dem Einfügen aber zunächst bei euch erkundigen, ob dies in Ordnung ist? --Lagunenfisch (Diskussion) 18:19, 20. Apr. 2013 (CEST)

Beide Informationen sind in unserer derzeitigen Version bereits enthalten.

Insbesondere ist es wichtig, die reservierten Zeichen zu kennen.

Einen besonderen Sinngehalt sehe ich nicht darin, nach Nennung des Wortes „Buchstaben“ und danach nochmals der Aufzählung [A-Z, a-z] eine Tabelle einzufügen, in der aufgezählt und verlinkt wird, was ein „A“ ist, was ein „B“ ist, was ein „a“ ist, was ein „b“ ist.

Schönes Wochenende --PerfektesChaos 18:36, 20. Apr. 2013 (CEST)

Genus URL

Die URL hat gemäß Rechtschreibduden (25. Auflage, vorige meiner Erinnerung nach auch):

die, selten der

• Grund ist, dass dies geistig für „Internet-Adresse“ oder „Seiten-Adresse“ steht.
• Dass das „L“ für locator steht, weiß von zehn befragten Internetnutzern kaum einer.
• Wir verwenden durchgängig die allgemein übliche Form.

Dementsprechend habe ich die heutige Änderung revertiert.

VG --PerfektesChaos 23:00, 25. Nov. 2013 (CET)

application/x-www-form-urlencoded unterstützt KEIN "charset"

Im Abschnitt "MIME-Typ" wird geschrieben:

 Mit dem MIME-Typ „application/x-www-form-urlencoded“ können URL-kodierte Daten gekennzeichnet werden. Bei der Übermittlung von Web-Formularangaben mittels der POST-Methode wird dieser MIME-Typ als Inhaltstyp (Content-Type) angegeben; gelegentlich auch mit expliziter Kodierung: „application/x-www-form-urlencoded; charset: UTF-8“.

Wie in der Diskussion hier http://forums2.atozed.com/viewtopic.php?f=7&t=26622 und hier https://bugzilla.mozilla.org/show_bug.cgi?id=241540 zu lesen ist, ist "charset" nicht zulässig für den Medientyp "application/x-www-form-urlencoded". Viele Server werden Fehler erzeugen, wenn "charset" trotzdem gesendet wird. Die HTML5 Spezifikation schreibt eine UTF-8-Koderung vor, sofern nicht anders angegeben innerhalb der Web-Seite. Weitere Informationen hier: http://www.w3.org/TR/html5/forms.html . --217.229.10.174 22:07, 4. Apr. 2014 (CEST)

Danke für den Hinweis, sieht plausibel aus.

Müsste man nochmal genauer durchgucken und mit den RFC abgleichen und dann einpflegen.

Liebe Grüße --PerfektesChaos 22:14, 4. Apr. 2014 (CEST)

Außerdem ist der entsprechende Absatz hier ohnehin falsch platziert. application/x-www-form-urlencoded ist nicht das gleiche wie URL-Encoding. Die Zeichenkette „My First Blog Post“ als Titel ergibt URL-encoded "title=My%20First%20Blog%20Post", aber Form-encoded "title=My+First+Blog+Post". --Highbrow (Diskussion) 21:02, 12. Jun. 2018 (CEST)

URL-Kodierung in der Wikipedia

Man vergleiche die Ergebnisse von http://de.wikipedia.org/wiki/Almagest#%C3%9Cberlieferung und von http://de.wikipedia.org/wiki/Almagest#.C3.9Cberlieferung miteinander! Gibt es was dazu zu sagen? Wie heißt das, wenn Punkt statt Prozentzeichen verwendet wird? --Lückenlos^wecken! 12:53, 25. Dez. 2014 (CET)

Wir sind hier in der Diskussion zu einem Artikel, nicht in der zur Programmierung hinter einem Wiki.

Die von dir angesprochene Formatierung wurde vor über 10 Jahren einmal festgelegt.

• Sie hatte damals technische Gründe in der zwei Jahre alten Wiki-Software, die aber seitdem längst weggefallen sind.
• Früher gab es auch keine reinen Fragmente; man musste schreiben: Almagest#Anker:Überlieferung
• Die Umstellung der Wikis von ISO 8859-1 auf UTF-8 erfolgte erst im April 2004.

Im Prinzip könnte man das heute anders lösen, muss aber sowieso alle alten Links weiter verstehen. Im HTML-Dokument werden Fragmentbezeichner mit Punkten generiert, basierend auf der Browser-Technologie und Wikisyntax anfangs des Jahrtausends, und werden auch so bleiben.

Allerdings könnte der Server sich irgendwann mal dazu bequemen, auch das rein Prozent-kodierte Format gleichrangig zu verstehen. Das ginge auch; muss dann halt die Prozentzeichen in Punkte umbauen, so dass auch dein zweiter Link zum Erfolg führt.

• Unkodiertes http://de.wikipedia.org/wiki/Almagest#Überlieferung geht ebenfalls nicht.

Unsere Parserfunktionen kennen den Trick; {{fullurl:Almagest#Überlieferung}} ergibt //de.wikipedia.org/wiki/Almagest#Überlieferung.

VG --PerfektesChaos 13:26, 25. Dez. 2014 (CET)

Danke für die interessante Antwort. Heißt das nicht, dass URL-Kodierung keineswegs dasselbe ist wie Prozentkodierung? Noch schlimmer wäre das bei en:Percent-encoding/en:URL encoding (zeigt auf weitere interessante Sachen, in Lemmata funktionieren auch &...;) … Und sowieso: Wäre ich der erste, der auch URL-Kodierung sagen würde, wenn Leerzeichen durch Pluszeichen (Google-Suchseiten) oder Bindestriche (Blogs, andere Wikis, Onlinezeitungen) ersetzt werden, und dann noch Satz- und Sonderzeichen weglässt etc.? --Lückenlos^wecken! 16:57, 25. Dez. 2014 (CET)

• „URL-Kodierung“ und „Prozentkodierung“ sind in der Tat nicht das Gleiche.
  • Der Begriff „Prozentkodierung“ ist allerdings anschaulich und laienverständlich, und deshalb sehr weit verbreitet.
• Schließlich muss jede allgemeine Kodierungsvorschrift mit dem Problem der Unicode-Zeichen (insbesondere >255) irgendwie klarkommen.
  • Auf diesem Planeten gibt es dafür keine andere Übereinkunft als Prozentkodierung; und deshalb ist die Prozentkodierung irgendwie in jeder „URL-Kodierung“ mit enthalten.
  • In einer anderen Galaxie hätte man genauso eine Dollar-Kodierung erfinden können; die würde gleichermaßen funktionieren.
• Der Oberbegriff „URL-Kodierung“ umfasst einen Problemlösungsweg für unterschiedliche Teilaspekte:
  1. Wie gehe ich mit (echten) Unicode-Zeichen >255 um?
  2. Was mache ich mit ANSI-Zeichen; also (128…159) … 160 … 255?
  3. Was mache ich mit reservierten ASCII-Zeichen 33…127, und welche Zeichen betrachte ich als „reserviert“ und welche nicht?
  4. Wie hältst du es mit dem Leerzeichen 32₁₀?
• Die Aspekte 1.–3. werden über Prozentkodierung realisiert; für 4. gibt es Prozentkodierung %20 genauso wie + oder den Trick der Wiki-Software, sich dieser Fragestellung geschickt zu entziehen, indem sie vorher im Seitennamen die Leerzeichen in Unterstreichungsstriche wandelt.
  • Die erhebliche Akzentuierung auf der Prozentkodierung bei der Lösung macht die quasi-synonyme Verwendung des Begriffs nachvollziehbar.
• Es ist letztlich immer die Entscheidung des Servers (bzw. seiner Programmierer und des Betreibers), wie er die an ihn gerichtete Anfrage zu interpretieren und zu beantworten geruht.
  • Alle diese RFC sind nur Empfehlungen.
  • Nicht einmal die Vorgaben im Artikel URL muss ein Server einhalten. Es ist nicht verboten, das anders zu handhaben, und funktioniert trotzdem.
  • Alle diese RFC sind freiwillige Übereinkommen, um die entstehenden Zeichenketten menschenfreundlich interpretierbar zu halten und ihnen einen Sinn wie Pfade, Verzeichnisse, Parameterzuweisungen oder Fragmente zu unterlegen.
  • Die URL-Spielregeln schränken damit die Vielfalt technisch möglicher GET-Strings dahingehend ein, dass sie von Menschen und Standard-Software syntaktisch interpretiert werden kann.
  • Ausschlaggebend ist die beim HTTP-GET übermittelte Zeichenkette; und deren Format gibt der Server vor. Alle Zeichen sind dort erlaubt (zumindest ASCII außer Leerzeichen). Man kann sogar ganz fies sein und # als bedeutungstragendes Zeichen in der Ressourcen-ID benutzen, woraufhin kein normaler Browser bei Standard-Abfragen (außer bestimmten fragmentierten Medienformaten) das # und alle anderen danach kommenden Zeichen zum Server übermitteln würde.
• Die Wiki-interne Seite Wikipedia:Technik/Skin/JS/Encoding #encode schlüsselt noch weiter auf, was es alles an Varianten für geforderte „URL-Kodierung“ gibt.

LG --PerfektesChaos 18:23, 25. Dez. 2014 (CET)

Prozent vs. Praxis

Dies gegen #Titeländerung und als Fortsetzung von #URL-Kodierung in der Wikipedia – wo ich Wikipedia:Technik/Skin/JS/Encoding sehr aufschlussreich finde – unter besser passender Überschrift. Ich störe mich sehr an der einleitenden Behauptung, das URL-Encoding werde auch Prozentkodierung genannt. {{Belege fehlen!}} – sind die Menschen belegbar so dumm? URL-Kodierung gibt es in der Praxis. Was auf der WP-Technik-Seite steht, sollte auch im Artikel stehen: verschiedene Beispiele für URL-Kodierung. Einige bekannte, die wirklich angewendet werden (Google, Wikipedia, Wikis zu speziellen Themen, Blogs/Online-Zeitschriften). Außerdem die fiktive URL-Kodierung gemäß RFC 3986, deren Prozentkodierung ich in der Praxis einzig im Fall der Anführungszeichen bei Google-Suchen kenne (https://www.google.de/search?q=%22Prozentzeichen+beim+URL-Encoding%22&gws_rd=ssl). Als Beispiel für die Darstellung von Leerzeichen#Leerzeichen in URIs würde ich auch Binnenmajuskel#Wiki-Links nennen, Beispiel https://wiki.ubuntu.com/Lubuntu/ReportingBugs. Die Darstellung von Interpunktionszeichen und Ultra-ASCII-Zeichen ist in den Wikimedia-Projekten relevant (welche die Prozentenkodierung nicht verwenden), anderswo? – Gibt es nun Belege dafür, dass die Umwandlung von Leerzeichen in Unterstriche, Bindestriche, Pluszeichen, Binnenmajuskel, … sowie die Punkt-Kodierung für Wikimedia-Abschnittstitel auch Prozentkodierung genannt werden? (PerfektesChaos schreibt „nur Empfehlung“, es ist ein Request for Comments, an dessen Vorschläge sich offenbar niemand hält.) --Lückenlos^wecken! 09:30, 30. Dez. 2014 (CET)

• Zur Begrifflichkeit:
  • „URL-Kodierung“ ist der Fachausdruck.
  • „Prozentkodierung“ ist eine umgangssprachliche und durchaus anschauliche Prägung. Sie will das gleiche meinen, obwohl sie nur einen Aspekt ausdrückt.
  • An Google-Treffern für deutschsprachige Komponenten kommen 2350 für „URL-Kodierung“, 950 für „Prozentkodierung“. Damit ist das auch relevanter Sprachgebrauch und muss im Artikel erwähnt werden.
  • „Prozentkodierung“ ist eine unscharfe aber synonym gebrauchte Bezeichnung. Über Leerzeichen machen sich die Verwender keinen Kopf.
• Zu den Fragmentbezeichnern im Wiki:
  • An der oben auftretenden Abschnittsüberschrift #Titeländerung steht im HTML-Dokument:
    • <span id="Titel.C3.A4nderung">Titeländerung</span>
  • Das bedeutet: Das Fragment heißt in Wirklichkeit schon Titel.C3.A4nderung.
  • Es wird nicht wie ein „ä“ für den Transport encoded, sondern es wird seit über zehn Jahren schon in reinem ASCII von der Wiki-Software generiert. Das geschah seinerzeit, um Probleme mit den damaligen Browser-Verionen (vor allem IE) zu vermeiden.
• Es gibt unendlich viele Interpretationen, was als reserviertes Zeichen aufgefasst wird und was nicht.
  • Vor allem die Aufnahme der Praxis einzelner Server würde den Artikel fluten und ihn unlesbar und unverständlich und auch unpflegbar machen; die Programmierer bei Google oder Bing könnten von einem Tag auf den anderen die Software ändern, wovon wir nichts mitbekommen und was auch enzyklopädisch irrelevant ist.
  • Wir können nur das wiedergeben, was in den RFC oder in Standardsoftware steht.
• Es gibt keine Domain und wird keine erlaubt werden, die ein % enthielte; die ICANN liest auch unsere Wikipedia-Artikel.
  • Es gibt zwar internationalisierte Domans; diese arbeiten aber vorab mit einem eigenen Kodierungssystem (Punycode) und sind für das encoding reines ASCII ohne ein irgendwie reserviertes Zeichen.
  • Encoding ist erst mit dem Pfad relevant.
• Es ist nicht zwingend erforderlich, alle reservierten Zeichen zu encoden, und welche sind unbedingt reserviert und welche nur manchmal?
  • Die gängigen encoding-Standardfunktionen der verschiedensten Programmiersprachen machen das zwar aus Bequemlichkeit einheitlich für sämtliche Vorkommen; oft reicht eines.
    • Von den Fragezeichen wäre nur eines wichtig, das im Pfad zwischen der Domain und der Query stünde. Die Pfade stellen sowas wie Dateinamen dar; wenn es jemand tatsächlich fertigbekäme und so ungeschickt wäre, in seinem Dateipfad ein Fragezeichen unterzubringen, dann müste das encoded werden. Nach dem ersten Auftreten ist es egal; innerhalb der Query stört es keine Interpretation mehr.
    • Das # muss encoded werden, solange es keinen Fragmentbezeichner abtrennen soll. Ein bekannter Fehler ist es, dass jemand eine URL mitsamt Fragmentbezeichner encoded und damit einen Pfad generiert, der beim Empfänger nicht vorhanden ist. Nach Abtrennung des Fragmentbezeichners durch # wären weitere egal, obwohl sie dort nicht erwünscht sind.
    • Ein Gleichheitszeichen müsste dann encoded werden, wenn der Server erwarten würde, dass beim Name=Wert in seinen Parameternamen Name ein Gleichheitszeichen auftreten kann. Das wäre aber mittelprächtg bescheuert und ist vom encoding-Algorithmus ohnehin nicht zu unterscheiden; höchstens beim Einpacken einer Formulareingabe in eine Query.
    • Die & (oder gelegentlich ;) müssen dann escaped werden, wenn eine Formulareingabe sie innerhalb eines Wertes findet; in der Gesamt-URL dürfen sie aber nicht escaped werden. Im Pfad-Anteil vor dem ersten ? sind sie dagegen belanglos.
  • Es gibt jede Menge willkürlicher Annahmen, was den Empfänger vermutlich stören würde und was man ihm deshalb besser kodiert schickt. Sicherheitshalber wird meist zuviel kodiert, was die URL schwer lesbar macht.
  • Im Wiki-Quelltext wird sogar mehr kodiert als den Server stören würde; die [ ] encoden wir aus eigennützigen Gründen in der Hoffnung, dass der Server am anderen Ende das schon wieder aufdröseln würde; genauso verfährt die Wiki-Software mit | innerhalb von fremden URL.
• Binnenmajuskel (CamelCasing) sind eine seit 40 Jahren unabhängig vom Internet in den Programmierspachen gebräuchliche Praxis, um mit dem Problem der menschenfreundlichen Segmentierung von Symbolen klarzukommen, die keine Leerzeichen enthalten können und wo womöglich auch _ unerwünscht sind (die meist zulässige und auch von den Wikis zur besseren Lesbarkeit als _ statt %20 genutzte Form).
  • Bei der Gelegenheit nochmal zur Klarstellung: Das _ in einer Wiki-URL ist kein Encoding. Die Ressource heißt so. In der Wiki-Datenbank in der Liste aller Seitentitel gibt es kein einziges Leerzeichen; die wirklichen Seitennamen im Wiki haben in ihrer kanonischen Form keine Leerzeichen. Nur für die optische Darstellung für Menschen werden die _ in Leerzeichen umgewandelt (und bilden eine zweite kanonische Form).
• Die Vorschläge oben bewegen sich weg vom Gegenstand des Artikels, dem URL-Encoding, und gehen zu einem philosophisch-syntaktischen Grundproblem: Wenn einzelne Zeichen in einer formalen Notation eine Sonderbedeuutung haben, aber auch als Zeichen selbst innerhalb von Zeichenketten vorkommen können – was mache ich dann? Es gibt drei Wege, die in einer Konvention gewählt werden können:
  1. Fluchtsymbol; \ oder Esc
  2. Verdoppelung; etwa "" in einer durch " begrenzten Zeichenkette
  3. Kodierung des Zeichenwertes; hilft auch aus einer 8-Bit-Begrenzung des Zeichenvorrates heraus.

Guten Rutsch schonmal --PerfektesChaos 12:15, 30. Dez. 2014 (CET)

URL encoding Tabellen (00 bis FF)

ASCII Steuerzeichen gehören nicht in eine URL

ASCII Character	Description	URL-encoding
NUL	null character	%00
SOH	start of header	%01
STX	start of text	%02
ETX	end of text	%03
EOT	end of transmission	%04
ENQ	enquiry	%05
ACK	acknowledge	%06
BEL	bell (ring)	%07
BS	backspace	%08
HT	horizontal tab	%09
LF	line feed	%0A
VT	vertical tab	%0B
FF	form feed	%0C
CR	carriage return	%0D
SO	shift out	%0E
SI	shift in	%0F
DLE	data link escape	%10
DC1	device control 1	%11
DC2	device control 2	%12
DC3	device control 3	%13
DC4	device control 4	%14
NAK	negative acknowledge	%15
SYN	synchronize	%16
ETB	end transmission block	%17
CAN	cancel	%18
EM	end of medium	%19
SUB	substitute	%1A
ESC	escape	%1B
FS	file separator	%1C
GS	group separator	%1D
RS	record separator	%1E
US	unit separator	%1F

Character	Windows-1252	UTF-8
␢	%20	%20
!	%21	%21
"	%22	%22
#	%23	%23
$	%24	%24
%	%25	%25
&	%26	%26
'	%27	%27
(	%28	%28
)	%29	%29
*	%2A	%2A
+	%2B	%2B
,	%2C	%2C
-	%2D	%2D
.	%2E	%2E
/	%2F	%2F
0	%30	%30
1	%31	%31
2	%32	%32
3	%33	%33
4	%34	%34
5	%35	%35
6	%36	%36
7	%37	%37
8	%38	%38
9	%39	%39
:	%3A	%3A
;	%3B	%3B
<	%3C	%3C
=	%3D	%3D
>	%3E	%3E
?	%3F	%3F
@	%40	%40
A	%41	%41
B	%42	%42
C	%43	%43
D	%44	%44
E	%45	%45
F	%46	%46
G	%47	%47
H	%48	%48
I	%49	%49
J	%4A	%4A
K	%4B	%4B
L	%4C	%4C
M	%4D	%4D
N	%4E	%4E
O	%4F	%4F
P	%50	%50
Q	%51	%51
R	%52	%52
S	%53	%53
T	%54	%54
U	%55	%55
V	%56	%56
W	%57	%57
X	%58	%58
Y	%59	%59
Z	%5A	%5A
[	%5B	%5B
\	%5C	%5C
]	%5D	%5D
^	%5E	%5E
_	%5F	%5F
`	%60	%60
a	%61	%61
b	%62	%62
c	%63	%63
d	%64	%64
e	%65	%65
f	%66	%66
g	%67	%67
h	%68	%68
i	%69	%69
j	%6A	%6A
k	%6B	%6B
l	%6C	%6C
m	%6D	%6D
n	%6E	%6E
o	%6F	%6F
p	%70	%70
q	%71	%71
r	%72	%72
s	%73	%73
t	%74	%74
u	%75	%75
v	%76	%76
w	%77	%77
x	%78	%78
y	%79	%79
z	%7A	%7A
{	%7B	%7B
	%7C	%7C
}	%7D	%7D
~	%7E	%7E
	%7F	%7F
`	%80	%E2%82%AC
	%81	%81
‚	%82	%E2%80%9A
ƒ	%83	%C6%92
„	%84	%E2%80%9E
…	%85	%E2%80%A6
†	%86	%E2%80%A0
‡	%87	%E2%80%A1
ˆ	%88	%CB%86
‰	%89	%E2%80%B0
Š	%8A	%C5%A0
‹	%8B	%E2%80%B9
Œ	%8C	%C5%92
	%8D	%C5%8D
Ž	%8E	%C5%BD
	%8F	%8F
	%90	%C2%90
‘	%91	%E2%80%98
’	%92	%E2%80%99
“	%93	%E2%80%9C
”	%94	%E2%80%9D
•	%95	%E2%80%A2
–	%96	%E2%80%93
—	%97	%E2%80%94
˜	%98	%CB%9C
™	%99	%E2%84
š	%9A	%C5%A1
›	%9B	%E2%80
œ	%9C	%C5%93
	%9D	%9D
ž	%9E	%C5%BE
Ÿ	%9F	%C5%B8
	%A0	%C2%A0
¡	%A1	%C2%A1
¢	%A2	%C2%A2
£	%A3	%C2%A3
¤	%A4	%C2%A4
¥	%A5	%C2%A5
¦	%A6	%C2%A6
§	%A7	%C2%A7
¨	%A8	%C2%A8
©	%A9	%C2%A9
ª	%AA	%C2%AA
«	%AB	%C2%AB
¬	%AC	%C2%AC
­	%AD	%C2%AD
®	%AE	%C2%AE
¯	%AF	%C2%AF
°	%B0	%C2%B0
±	%B1	%C2%B1
²	%B2	%C2%B2
³	%B3	%C2%B3
´	%B4	%C2%B4
µ	%B5	%C2%B5
¶	%B6	%C2%B6
·	%B7	%C2%B7
¸	%B8	%C2%B8
¹	%B9	%C2%B9
º	%BA	%C2%BA
»	%BB	%C2%BB
¼	%BC	%C2%BC
½	%BD	%C2%BD
¾	%BE	%C2%BE
¿	%BF	%C2%BF
À	%C0	%C3%80
Á	%C1	%C3%81
Â	%C2	%C3%82
Ã	%C3	%C3%83
Ä	%C4	%C3%84
Å	%C5	%C3%85
Æ	%C6	%C3%86
Ç	%C7	%C3%87
È	%C8	%C3%88
É	%C9	%C3%89
Ê	%CA	%C3%8A
Ë	%CB	%C3%8B
Ì	%CC	%C3%8C
Í	%CD	%C3%8D
Î	%CE	%C3%8E
Ï	%CF	%C3%8F
Ð	%D0	%C3%90
Ñ	%D1	%C3%91
Ò	%D2	%C3%92
Ó	%D3	%C3%93
Ô	%D4	%C3%94
Õ	%D5	%C3%95
Ö	%D6	%C3%96
×	%D7	%C3%97
Ø	%D8	%C3%98
Ù	%D9	%C3%99
Ú	%DA	%C3%9A
Û	%DB	%C3%9B
Ü	%DC	%C3%9C
Ý	%DD	%C3%9D
Þ	%DE	%C3%9E
ß	%DF	%C3%9F
à	%E0	%C3%A0
á	%E1	%C3%A1
â	%E2	%C3%A2
ã	%E3	%C3%A3
ä	%E4	%C3%A4
å	%E5	%C3%A5
æ	%E6	%C3%A6
ç	%E7	%C3%A7
è	%E8	%C3%A8
é	%E9	%C3%A9
ê	%EA	%C3%AA
ë	%EB	%C3%AB
ì	%EC	%C3%AC
í	%ED	%C3%AD
î	%EE	%C3%AE
ï	%EF	%C3%AF
ð	%F0	%C3%B0
ñ	%F1	%C3%B1
ò	%F2	%C3%B2
ó	%F3	%C3%B3
ô	%F4	%C3%B4
õ	%F5	%C3%B5
ö	%F6	%C3%B6
÷	%F7	%C3%B7
ø	%F8	%C3%B8
ù	%F9	%C3%B9
ú	%FA	%C3%BA
û	%FB	%C3%BB
ü	%FC	%C3%BC
ý	%FD	%C3%BD
þ	%FE	%C3%BE
ÿ	%FF	%C3%BF

ASCII-Kürzel für Leerzeichen

Es wäre wohl nicht "(LZ)" sondern "SP". Aus gewisser GEwohnheit packe ich solche Kürzel ggf. in spitze Klammern, also "<SP>". --Alexander.stohr (Diskussion) 01:27, 11. Feb. 2015 (CET)

Naja, das ist hier nur als deutschsprachger Kommentar für „Leerzeichen“ gemeint und dieses darunter verlinkt; weil von wegen damit man irgendwas sieht und irgendwas verlinkt werden kann.

Eine komplette ASCII-Steuerzeichentabelle wie im dortigen Artikel wird ja hier nicht abgebildet. Da würde man im englischsprachigen Zusammenhang bleiben, aber hier ist es nur ein einzelnes Element.

Da wir versuchen, laienverständlich zu bleiben, und <SP> für die Laien unenträtselbar bliebe, die Experten aber sowieso wissen, was %20 ist und sich die Erklärung für LZ denken können, ist allen geholfen.

LG --PerfektesChaos 09:29, 11. Feb. 2015 (CET)

Über dem Abschnitt steht ASCII - wobei das "S" darin für "Standard" steht. Wenn also jemand eines der bemühten Kürzel nicht kennt müsste er (ziemlich naheliegend?) da nach schlagen. Einen "Laien-Standard" gibt es nicht. Es dürfte für das Leerzeichen (engl. Space) wohl auch einen Artikel geben, den man genau dort dann auch verlinken könnte. --Alexander.stohr (Diskussion) 01:06, 14. Feb. 2015 (CET)

An dem Link selbst erscheint als Tooltip das Wort „Leerzeichen“, wodurch das „LZ“ hinreichend erklärt ist.

Genauso kann man buchstabenfrei schreiben [_] oder was immer.

Hier ist aber nicht wie in einer ASCII-Steuerzeichentabelle von „VT“ und „LF“ die Rede, sondern ohne Nachschlagen von kryptischen Codes wollen wir einfach nur für schlichte Gemüter sichtbare Zeichen haben, die wir mit Leerzeichen verlinken können.

--PerfektesChaos 01:00, 15. Feb. 2015 (CET)

Tabelle umbrechen

Hallo, könnte bitte jemand die sehr lange, d. h. breite Tabelle im Abschnitt Relevante ASCII-Zeichen in Prozentdarstellung in der Hälfte umbrechen? Das Hin- und Her-Geschiebe könnte so vermieden werden. Danke, --Wi-luc-ky (Diskussion) 23:03, 19. Jan. 2018 (CET)

Eindeutig zweideutig!

„In der empfohlenen Kodierung UTF-8 wäre beispielsweise der Buchstabe „ö“ (mit dem dezimalen Unicode-Zeichenwert“ … %6F%CC%88! Hier, direkt reingebaut, zwei völlig unterschiedliche Zeichen. „ö“ vs. „ö“ Obwohl, völlig?

Und: %6F%CC%88? „Es besteht jedoch prinzipiell der Bedarf, in URLs beliebige Byte-Folgen … darstellen zu können“