it-swarm.com.de

Sollte die URL die Groß- und Kleinschreibung berücksichtigen?

Ich bemerkte, dass 

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

und 

http://stackoverflow.com/questions/ask

beide funktionieren gut - eigentlich wird das vorherige in Kleinbuchstaben umgewandelt.

Ich denke, das macht für den Benutzer Sinn.

Wenn ich Google anschaue, funktioniert diese URL gut:

http://www.google.com/intl/en/about/corporate/index.html  

aber dieser mit "ABOUT" funktioniert nicht: 

http://www.google.com/intl/en/ABOUT/corporate/index.html   

Sollte die URL zwischen Groß- und Kleinschreibung unterscheiden?

249
Imageree

Laut W3s " HTML und URLs " sollten sie: 

Es kann URLs oder Teile von URLs geben, bei denen der Fall keine Rolle spielt, aber diese zu identifizieren, ist möglicherweise nicht einfach. Benutzer sollten immer bedenken, dass Bei URLs wird zwischen Groß- und Kleinschreibung unterschieden.

243
jldupont

Alle "insensitive" sind aus Gründen der Lesbarkeit verstärkt.

Domain-Namen unterscheiden zwischen insensitive gemäß RFC 4343 . Der Rest der URL wird über die GET-Methode an den Server gesendet. Dies kann die Groß-/Kleinschreibung sein oder nicht.

Nehmen Sie zum Beispiel diese Seite, stackoverflow.com erhält die Zeichenfolge GET string /questions/7996919/sollte-url-be-Groß Kleinschreibung -/und sendet ein HTML-Dokument an Ihren Browser. Stackoverflow.com ist case insensitive, weil es dasselbe Ergebnis für /QUEStions/7996919/Sollte-url-be-Groß Kleinschreibung abhängig macht - /.

Auf Wikipedia dagegen wird mit Ausnahme des ersten Zeichens des Titels die Groß- und Kleinschreibung beachtet. Die URLs https://en.wikipedia.org/wiki/Case_sensitivity und https://en.wikipedia.org/wiki/case_sensitivity führen zum gleichen Artikel, aber https: // de.wikipedia.org/wiki/CASE_SENSITIVITY gibt 404 zurück.

111
jdh8

Kommt auf das Hosting-Betriebssystem an. Sites, die unter Windows gehostet werden, sind in der Regel unabhängig von der Groß- und Kleinschreibung, da das zugrunde liegende Dateisystem die Groß- und Kleinschreibung nicht berücksichtigt. Auf Unix-Systemen gehostete Sites sind in der Regel von Groß- und Kleinschreibung abhängig, da die zugrunde liegenden Dateisysteme in der Regel von Groß- und Kleinschreibung abhängig sind. Der Host-Name-Teil der URL ist immer unabhängig von der Groß- und Kleinschreibung, der Rest des Pfads variiert.

66
Jim Nutt

Der Domänennamenteil einer URL unterscheidet nicht zwischen Groß- und Kleinschreibung, da DNS die Groß- und Kleinschreibung ignoriert: http://en.example.org/ und HTTP://EN.EXAMPLE.ORG/, die beide dieselbe Seite öffnen.

Der Pfad wird verwendet, um die angeforderte Ressource anzugeben und möglicherweise zu finden. Es wird zwischen Groß- und Kleinschreibung unterschieden, es kann jedoch von einigen Servern als unabhängig von der Groß- und Kleinschreibung unterschieden werden, insbesondere von Servern, die auf Microsoft Windows basieren.

Wenn bei dem Server die Groß- und Kleinschreibung beachtet wird und http://en.example.org/wiki/URL korrekt ist, zeigt http://en.example.org/WIKI/URL oder http://en.example.org/wiki/url eine HTTP 404-Fehlerseite an, sofern diese URLs nicht auf gültige Ressourcen verweisen.

29
Bhavin Shah

Ich bin kein Fan von alten Artikeln, aber da dies eine der ersten Antworten für dieses spezielle Thema war, hatte ich das Bedürfnis, etwas zu klären.

Wie in der Antwort von @ Bhavin Shah angegeben, ist der Domain-Teil der URL unabhängig von der Groß- und Kleinschreibung 

http://google.com 

und 

http://GOOGLE.COM 

und 

http://GoOgLe.CoM 

sind alle gleich, aber alles nach dem Teil des Domainnamens wird als Groß- und Kleinschreibung betrachtet. 

so...

http://GOOGLE.COM/ABOUT

und

http://GOOGLE.COM/about

sind anders.

Hinweis: Ich spreche in vielen Fällen "technisch" und nicht "wörtlich". Die meisten Server sind zwar so eingerichtet, dass sie diese Elemente gleich behandeln, aber es ist möglich, sie so einzustellen, dass sie NICHT gleich behandelt werden.

Unterschiedliche Server behandeln dies unterschiedlich und müssen in einigen Fällen die Groß- und Kleinschreibung berücksichtigen. In vielen Fällen werden Abfragezeichenfolgenwerte kodiert (z. B. Sitzungs-IDs oder Base64-Daten, die als Abfragezeichenfolgenwert übergeben werden.) Bei diesen Elementen wird die Groß- und Kleinschreibung beachtet.

Um die Frage zu beantworten: "Wenn" Server bei der Erfassung dieser Daten zwischen Groß- und Kleinschreibung unterscheiden, lautet die Antwort "Ja, auf jeden Fall".

Natürlich muss nicht alles auf Groß- und Kleinschreibung achten, aber der Server sollte wissen, was das ist und wie mit diesen Fällen umzugehen ist.


@Hart Simhas Kommentar sagt im Grunde dasselbe. Ich habe es verpasst, bevor ich gepostet habe, also möchte ich Gutschrift geben, wenn Gutschrift fällig ist.

14
Kenneth Garza

Sehen Sie sich die Spezifikation hier an: Abschnitt 2.7.3 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

Das Schema und der Host sind unabhängig von der Groß- und Kleinschreibung und werden normalerweise in Kleinbuchstaben angegeben. Alle anderen Komponenten werden in einer Groß-/Kleinschreibung verglichen Weise.

5
Nitin

Bei URLs sollte die Groß- und Kleinschreibung nicht beachtet werden, es sei denn, es gibt einen guten Grund, warum dies nicht der Fall sein sollte. 

Dies ist nicht obligatorisch (kein Bestandteil eines RFC), macht jedoch die Kommunikation und Speicherung von URLs wesentlich zuverlässiger. 

Wenn ich zwei Seiten auf einer Website habe:

http://stackoverflow.com/ABOUT.html

und

http://stackoverflow.com/about.html

Wie sollen sie sich unterscheiden? Vielleicht schreibt man "Shouting Style" (Caps) - aber aus IA-Sicht sollte die Unterscheidung niemals durch eine Änderung im Fall der URL gemacht werden.

Darüber hinaus ist es einfach, dies in Apache zu implementieren - verwenden Sie einfach CheckSpelling On von mod_Speling. 

2
konchog

Alte Frage, aber ich bin hier gestolpert. Warum also nicht einen Blick darauf werfen, denn die Frage sucht verschiedene Perspektiven und keine endgültige Antwort.

w3c mag seine Empfehlungen haben - was mich sehr interessiert -, möchte aber umdenken, da die Frage hier ist.

Warum hält w3c für Domain-Namen die Groß- und Kleinschreibung unberücksichtigt und hinterlässt die Groß- und Kleinschreibung nichts? 

Ich denke, dass der Grund dafür ist, dass der Domain-Teil der URL von einem Benutzer von Hand eingegeben wird. Alles, nachdem es sich um Hyper-Text handelt, wird vom Computer (Browser und Server im Hintergrund) aufgelöst.

Maschinen können mit der Fallunempfindlichkeit besser umgehen als mit Menschen (nicht mit der technischen Art :)).

Aber die Frage ist nur, dass die Maschinen damit umgehen können, sollte es so gemacht werden?

Ich meine, was sind die Vorteile der Benennung und des Zugriffs auf eine Ressource, die sich in hereIsTheResource vs. hereistheresource befindet?

Das Quer ist sehr unlesbar als das Kamelgehäuse, das besser lesbar ist. Lesbar für Menschen (einschließlich der technischen Art.)

Also hier meine Punkte: -

Resource Path liegt irgendwo in der Mitte der Programmierstruktur und befindet sich manchmal in der Nähe eines Endbenutzers hinter dem Browser.

Bei Ihrer URL (mit Ausnahme des Domänennamens) sollte die Groß- und Kleinschreibung nicht beachtet werden, wenn von Ihren Benutzern erwartet wird, dass Sie sie berühren oder eingeben. Sie sollten Ihre Anwendung zu AVOID entwickeln, indem die Benutzer den Pfad so oft wie möglich eingeben. 

Bei Ihrer URL (mit Ausnahme des Domänennamens) sollte die Groß- und Kleinschreibung beachtet werden, wenn Ihre Benutzer sie niemals manuell eingeben würden. 

Fazit

Der Pfad sollte die Groß- und Kleinschreibung berücksichtigen. Meine Punkte beziehen sich auf die case sensitive Pfade. 

0
bhantol

Fallbewahrung

URLs sind case-preserving zwischen Client und Server. Teile von URLs können jedoch aus verschiedenen Gründen zwischen Groß- und Kleinschreibung unterscheiden .

Groß-/Kleinschreibung

Die folgenden fett Teile von URLs können abhängig von der Site- und/oder Serverkonfiguration zwischen Groß- und Kleinschreibung unterscheiden .

http: // www. example.com / abc/def.ghi? jkl = mno # pqr

Benutzer @ example.com

Begründung

Groß- und Kleinschreibung in URLs kann mehrere Verwendungszwecke haben. Hauptsächlich:

  1. Native Kompatibilität mit Dateisystemen, bei denen zwischen Groß- und Kleinschreibung unterschieden wird.
  2. Kompaktere Datencodierung in URLs, z. B. für Serialisierung, Hashing, IDs, Permalinks und URL-Kürzungen.

Als Entwickler glaube ich, dass das oben Genannte oft besser gehandhabt werden kann, aber ich verstehe auch, dass es Fälle gibt, in denen eine Situation dies möglicherweise nicht zulässt.

Stellen Sie sich beispielsweise ein vorhandenes Produkt vor, für das viele Daten in der URL "GET" gespeichert werden müssen, das jedoch mit den maximalen URL-Längen aller wichtigen Server, Browser und Caching-/Proxy-Mechanismen kompatibel sein muss. Um auch eine mäßig lange Befehlszeichenfolge (unter 1.024 Zeichen für einige ältere Browser) zu verwenden, müssten Sie jedes eindeutige URL-sichere Zeichen verwenden (was im Grunde genommen die Base64URL-Codierung ist).

In einer idealen Welt

Ob URLs zwischen Groß- und Kleinschreibung unterscheiden sollen , ist umstritten. Ich persönlich bin der Meinung, dass dies der Einfachheit halber nicht der Fall sein sollte (obwohl dies längere URLs erzeugen kann, verfügen wir über prozentuale Escape-Zeichen, um Fälle zu behandeln, in denen die Beibehaltung genauer Zeichen sichergestellt werden muss, und es gibt Möglichkeiten, Daten zu übertragen, die nicht direkt in der URL enthalten sind). .

Viele scheinen sich auf der Grundlage der Tatsache einig zu sein, dass URLs, bei denen die Groß- und Kleinschreibung nicht berücksichtigt wird, für viele beliebte Websites und Dienste explizit aktiviert sind, um die Benutzerfreundlichkeit zu verbessern. Das bekannteste Beispiel ist der Benutzername-Teil der E-Mail-Adressen. Die meisten E-Mail-Anbieter ignorieren Groß- und Kleinschreibung und manchmal sogar Punkte und andere Symbole (z. B. "[email protected]" entspricht "[email protected]"). Auch wenn bei E-Mail-Benutzernamen laut Spezifikation standardmäßig die Groß- und Kleinschreibung beachtet wird.

Tatsache ist jedoch, dass dies der Zustand ist, in dem die Dinge derzeit funktionieren, ungeachtet dessen, was ich oder andere möchten. Und obwohl ein weltweiter Übergang zu einem URL-Standard, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird, sicherlich möglich ist, wird es wahrscheinlich ziemlich lange dauern, bis die Groß- und Kleinschreibung im Internet für verschiedene Zwecke verwendet wird.

Best Practices

Was Best Practices anbelangt, können Sie sich als Benutzer in den meisten Situationen vernünftigerweise an Kleinbuchstaben halten und erwarten, dass die Dinge funktionieren. Die Hauptausnahmen sind URLs, die fallbasierte Codierung oder Dokumentpfade mit direkten Dateisystemäquivalenten verwenden. Solche komplexen URLs werden jedoch in der Regel kopiert (oder einfach angeklickt) und nicht manuell eingegeben.

Als Webentwickler sollten Sie URLs so unabhängig von Groß- und Kleinschreibung wie möglich halten. Es gibt jedoch je nach Kontext einige schwer zu vermeidende Situationen, wie oben erwähnt.

0
Beejor

URL-Zeichen werden in Hex-Code umgewandelt (wenn Sie jemals festgestellt haben, dass Leerzeichen in URLs als% 20 angezeigt werden usw.). Da Klein- und Großbuchstaben unterschiedliche Hex-Werte haben, ist es absolut sinnvoll, dass bei URLs unbedingt die Groß- und Kleinschreibung beachtet wird. Der Geist der Frage scheint jedoch zu sein, dass dies der Standard ist, und ich sage nein, aber sie sind es. Es liegt an den Entwicklern/Anbietern, dies in ihrem Code zu berücksichtigen, wenn sie wollen, dass es für einen Endbenutzer funktioniert.

0
Guest

Folgendes berücksichtigen:

https://www.example.com/createuser.php?name=Paul%20McCartney

In diesem hypothetischen Beispiel sendet ein HTML-Formular mithilfe der GET-Methode den Parameter "name" an ein Skript PHP, das ein neues Benutzerkonto erstellt. 

Ich möchte mit diesem Beispiel sagen, dass dieser GET-Parameter die Groß- und Kleinschreibung berücksichtigen muss, um die Großschreibung von "McCartney" zu erhalten (oder als weiteres Beispiel "Walter d'Isney" zu erhalten, da es andere Möglichkeiten gibt für Namen, die gegen die üblichen Regeln für die Großschreibung verstoßen).

Es sind Fälle wie diese, die die W3C-Empfehlung dahingehend lenken, dass bei Schema und Host nicht zwischen Groß- und Kleinschreibung unterschieden wird, aber alles, was danach kommt, ist möglicherweise case sensitive - und bleibt dem Server überlassen. Durch Erzwingen der Groß- und Kleinschreibung nach Standard würde das obige Beispiel den Fall von Benutzereingaben, die als GET-Abfrageparameter übergeben werden, nicht beibehalten.

Ich würde jedoch sagen, dass, obwohl dies notwendigerweise der Buchstabe des Gesetzes ist, um solchen Fällen Rechnung zu tragen, der Geist des Gesetzes der ist, dass, wenn der Fall irrelevant ist, sich das Verhalten in einem Fall ohne Reaktion verhält. Die Standards können Ihnen jedoch nicht sagen, wo der Fall irrelevant ist, denn wie bei den Beispielen, die ich gegeben habe, ist es eine kontextabhängige Sache.

(Beispielsweise ist ein Kontonutzername wahrscheinlich am besten dazu gezwungen, die Groß- und Kleinschreibung zu berücksichtigen, da sich "User123" und "User123" auf unterschiedliche Konten beziehen können, dies kann verwirrend sein - selbst wenn der tatsächliche Name, wie oben angegeben, die Groß- und Kleinschreibung am besten beeinflusst.)

Manchmal ist es relevant, meistens nicht. Es muss jedoch dem Server/Web-Entwickler überlassen werden, diese Entscheidungen zu treffen - und kann nicht standardmäßig vorgeschrieben werden - da nur auf dieser Ebene der Kontext bekannt sein könnte.

Bei dem Schema und dem Host wird die Groß- und Kleinschreibung nicht berücksichtigt (was die Präferenz des Standards für die Groß- und Kleinschreibung widerspiegelt, sofern diese universell vorgeschrieben werden kann). Der Rest bleibt Ihnen überlassen, wenn Sie den Kontext besser verstehen. Aber, wie bereits erörtert wurde, sollten Sie im Sinne des Gesetzes wahrscheinlich der Fallunempfindlichkeit folgen, es sei denn, Sie haben einen guten Grund, dies nicht zu tun.

0
Bob

Ich denke, dass dies und viele der Antworten auf das, was die Spezifikation sagt oder nicht sagt, den Punkt der Frage verfehlt. Sollte sie sind case sensitive? Das ist wirklich eine geladene Frage. Aus Sicht des Anwenders ist die Empfindlichkeit des Falls ein Schmerzpunkt. Nicht alle wissen, dass es einen Unterschied macht. Die Frage, ob URIs sein sollen oder nicht, hängt vom Kontext der Frage ab. Für technische Flexibilität sollten sie es auch sein. Für die Benutzerfreundlichkeit, nein, sollten sie nicht sein.

0
rspring1975