Warum wird bei URLs zwischen Groß- und Kleinschreibung unterschieden?

Warum nicht? Bei der URL muss zwischen Groß- und Kleinschreibung unterschieden werden.

Ich verstehe, dass dies wie eine provokative (und „Teufelsanwalt“) rhetorische Frage aussehen mag, aber ich denke, es ist nützlich, darüber nachzudenken. Das Design von HTTP ist dass ein „Client“, den wir üblicherweise als „Webbrowser“ bezeichnen, den „Webserver“ nach Daten fragt.

Es werden viele, viele verschiedene Webserver freigegeben. Microsoft hat IIS mit Windows freigegeben Server-Betriebssysteme (und andere, einschließlich Windows XP Professional). Unix verfügt über Schwergewichte wie Nginx und Apache, ganz zu schweigen von kleineren Angeboten wie OpenBSDs internem httpd oder thttpd oder lighttpd. Darüber hinaus verfügen viele netzwerkfähige Geräte über integrierte Webserver, mit denen das Gerät konfiguriert werden kann, einschließlich Geräten mit netzwerkspezifischen Zwecken wie Routern (einschließlich vieler Wi-Fi-Zugangspunkte und DSL-Modems) und anderen Geräten wie Druckern oder USVs (batteriegepufferte unterbrechungsfreie Netzteile), die möglicherweise über eine Netzwerkverbindung verfügen.

Bei der Frage „Warum wird bei URLs zwischen Groß- und Kleinschreibung unterschieden?“ Wird die Frage gestellt: „Warum behandeln die Webserver die URL als Groß- und Kleinschreibung beachten? “ Und die eigentliche Antwort lautet: Das tun nicht alle. Mindestens ein Webserver, der ziemlich beliebt ist, unterscheidet normalerweise NICHT zwischen Groß- und Kleinschreibung. (Der Webserver ist IIS.)

Ein Hauptgrund dafür Das unterschiedliche Verhalten zwischen verschiedenen Webservern ist wahrscheinlich auf eine einfache Sache zurückzuführen. Die einfache Möglichkeit, einen Webserver zu erstellen, besteht darin, die gleichen Schritte auszuführen wie das Betriebssystem des Computers / Geräts. Oft suchen Webserver eine Datei, um eine Antwort zu geben. Unix wurde für High-End-Computer entwickelt, und daher bot Unix die wünschenswerte Funktionalität, Groß- und Kleinbuchstaben zuzulassen. Unix hat beschlossen, Groß- und Kleinbuchstaben als unterschiedlich zu behandeln, da sie unterschiedlich sind. Dies ist die unkomplizierte, natürliche Vorgehensweise. Windows hat in der Vergangenheit die Groß- und Kleinschreibung nicht berücksichtigt, da bereits erstellte Software unterstützt werden soll. Diese Geschichte geht auf DOS zurück, das möglicherweise keine Kleinbuchstaben unterstützt hat, möglicherweise aus Aufwand Um die Dinge mit weniger leistungsfähigen Computern zu vereinfachen, die weniger Speicher verbrauchen. Da diese Betriebssysteme unterschiedlich sind, spiegeln einfach gestaltete (frühe Versionen von) Webservern dieselben Unterschiede wider.

Nun zu all dem Im Hintergrund finden Sie einige spezifische Antworten auf die spezifischen Fragen:

Als URLs zum ersten Mal entworfen wurden, warum wurde die Groß- und Kleinschreibung als Funktion verwendet?

Warum nicht? Wenn bei allen Standard-Webservern die Groß- und Kleinschreibung nicht berücksichtigt wird, bedeutet dies, dass die Webserver einem vom Standard festgelegten Regelwerk folgen. Es gab einfach keine Regel, die besagt, dass der Fall ignoriert werden muss. Der Grund, warum es keine Regel gibt, ist einfach, dass es keinen Grund dafür gab es soll eine solche Regel geben. Warum sich die Mühe machen, unnötige Regeln zu erfinden?

Ich frage dies, weil es mir scheint (d. H., ein Laie), dass Groß- und Kleinschreibung nicht bevorzugt wird, um unnötige Fehler zu vermeiden und eine bereits komplizierte Textfolge zu vereinfachen.

URLs wurden für Maschinen zur Verarbeitung entwickelt . Obwohl eine Person eine vollständige URL in eine Adressleiste eingeben kann, war dies kein wesentlicher Bestandteil des beabsichtigten Designs. Das beabsichtigte Design besteht darin, dass Personen Hyperlinks folgen („darauf klicken“). Wenn durchschnittliche Laien dies tun, dann tun sie dies wirklich Es ist egal, ob die unsichtbare URL einfach oder kompliziert ist.

Gibt es auch einen echten Zweck / Vorteil, eine URL zu haben, bei der zwischen Groß- und Kleinschreibung unterschieden wird (as im Gegensatz zu der überwiegenden Mehrheit der URLs, die unabhängig von der Groß- und Kleinschreibung auf dieselbe Seite verweisen)

Der fünfte nummerierte Punkt von In der Antwort von William Hay wird ein technischer Vorteil erwähnt: URLs können eine effektive Möglichkeit für einen Webbrowser sein, Informationen an einen Webserver zu senden, und weitere Informationen können enthalten sein, wenn weniger vorhanden sind Einschränkungen, so dass eine Einschränkung der Groß- und Kleinschreibung die Anzahl der Informationen reduzieren würde.

In vielen Fällen bietet die Groß- und Kleinschreibung jedoch keinen besonders überzeugenden Vorteil Dies wird durch die Tatsache bewiesen, dass IIS sich normalerweise nicht darum kümmert.

Zusammenfassend ist der überzeugendste Grund wahrscheinlich nur die Einfachheit für diejenigen, die die Webserver-Software entwickelt haben, insbesondere auf einer Plattform wie Unix, bei der zwischen Groß- und Kleinschreibung unterschieden wird . (HTTP hat das ursprüngliche Design von Unix nicht beeinflusst, da Unix deutlich älter als HTTP ist.)

Kommentare

• “ Ein Hauptgrund für das unterschiedliche Verhalten zwischen verschiedenen Webbrowsern ist wahrscheinlich eine Frage der Einfachheit. “ – Ich nehme an, Sie Mittelwert “ Webserver “ anstelle von “ Webbrowsern “ hier und an einigen anderen Stellen?
• Aktualisiert. Alle Fälle von “ Browsern “ und hat mehrere Ersetzungen vorgenommen. Vielen Dank, dass Sie darauf hingewiesen haben, damit die Qualität verbessert werden kann.
• Ich habe mehrere ausgezeichnete Antworten auf meine Frage erhalten, von historisch bis Ich zögere, gegen den Strich zu gehen und eine Antwort mit niedrigerer Bewertung zu akzeptieren, aber die Antwort von @TOOGAM ‚ war die hilfreichste mich. Diese Antwort ist gründlich und ausführlich, erklärt jedoch das Konzept auf eine unkomplizierte, gesprächige Weise, die ich verstehen kann. Und ich denke, diese Antwort ist eine gute Einführung in die ausführlicheren Erklärungen.
• Der Grund, warum Windows ein Dateisystem ohne Berücksichtigung der Groß- und Kleinschreibung verwendet, liegt in den ‚ s DOS-Erbe. MS-DOS wurde auf Computern wie dem Tandy TRS-80 eingeführt, der einen Fernseher als Display verwendete und aufgrund der mangelnden Auflösung ursprünglich keine Kleinbuchstaben unterstützte. Da ‚ keine Kleinbuchstaben anzeigen konnte, wurde ‚ nicht unterstützt. MS-DOS wurde von IBM als ursprüngliches PC-DOS lizenziert. Während der ursprüngliche PC Kleinbuchstaben anzeigen konnte, wurde das Dateisystem von MS-DOS unverändert portiert.

URLs unterscheiden nicht zwischen Groß- und Kleinschreibung, sondern nur aus Teilen.
In der URL https://google.com,

wird beispielsweise nichts zwischen Groß- und Kleinschreibung unterschieden Mit Bezug auf RFC 3986 – URI (Uniform Resource Identifier): Generische Syntax

Zunächst von Wikipedia , eine URL sieht folgendermaßen aus:

 scheme:[//host[:port]][/]path[?query][#fragment] 

(Ich habe die user:password Teil, weil es nicht interessant ist und selten verwendet wird)

• scheme :

Schemata unterscheiden nicht zwischen Groß- und Kleinschreibung

• host :

Die Host-Unterkomponente unterscheidet nicht zwischen Groß- und Kleinschreibung.

• path :

Die Pfadkomponente enthält Daten …

• query :

Die Abfragekomponente enthält nicht hierarchische Daten …

• fragment :

Einzelne Medientypen können ihre eigenen Einschränkungen oder Strukturen innerhalb der Fragmentkennungssyntax definieren, um verschiedene Arten von Teilmengen, Ansichten oder externen Referenzen anzugeben.

Bei scheme und host wird die Groß- und Kleinschreibung nicht berücksichtigt.
Der Rest von Bei der URL wird zwischen Groß- und Kleinschreibung unterschieden.

Warum wird bei path zwischen Groß- und Kleinschreibung unterschieden?

Dies scheint die Hauptfrage zu sein.
Es ist schwierig zu beantworten „warum“ etwas wurde getan, wenn es nicht dokumentiert wurde, aber wir können eine sehr gute Vermutung anstellen.
Ich habe sehr spezifische Zitate aus der Spezifikation ausgewählt, mit Schwerpunkt auf data .
Sehen wir uns die URL noch einmal an:

 scheme:[//host[:port]][/]path[?query][#fragment] \____________________/\________________________/ Location Data 

• Ort – Der Ort hat eine kanonische Form und unterscheidet nicht zwischen Groß- und Kleinschreibung. Warum? Wahrscheinlich könnten Sie einen Domainnamen kaufen, ohne Tausende von Varianten kaufen zu müssen.

• Daten – Die Daten werden von der verwendet Zielserver, und die Anwendung kann auswählen, was es bedeutet . Es wäre nicht sinnvoll, die Groß- und Kleinschreibung von Daten nicht zu berücksichtigen. Die Anwendung sollte über mehr Optionen verfügen, und das Definieren der Groß- und Kleinschreibung in der Spezifikation schränkt diese Optionen ein.
  Dies ist auch eine nützliche Unterscheidung für HTTPS: die Daten sind verschlüsselt , aber der Host ist sichtbar.

Ist es nützlich?

Fall- Sensitivität hat ihre Tücken beim Caching und bei kanonischen URLs, ist aber sicherlich nützlich. Einige Beispiele:

• Base64 , Dies wird in Daten-URIs verwendet.
• Sites können Base64-Daten in der URL codieren, zum Beispiel: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL-Kürzungen verwenden die Groß- und Kleinschreibung: /a5B unterscheidet sich möglicherweise von /a5b
• Wie Sie bereits erwähnt haben, kann Wikipedia „AIDS“ von „Aids“ unterscheiden.

Kommentare

• “ URLs sind nicht cas E-Sensitivität. “ / “ Der Rest der URL unterscheidet zwischen Groß- und Kleinschreibung. “ – Dies scheint ein Widerspruch zu sein?
• In Wahrheit definiert das Schema, was im Rest der URL zu erwarten ist. http: und verwandte Schemata bedeuten, dass die URL auf einen DNS-Hostnamen verweist. DNS unterschied ASCII lange vor der Erfindung von URLs nicht zwischen Groß- und Kleinschreibung. Siehe Seite 55 von ietf.org/rfc/rfc883.txt
• Schön detailliert! Ich ging aus historischer Sicht. Es war ursprünglich der Dateipfad, bei dem nur dann zwischen Groß- und Kleinschreibung unterschieden werden musste, wenn Sie auf das Dateisystem trafen. Ansonsten war es nicht. Aber heute haben sich die Dinge geändert. Beispielsweise waren Parameter und CGI ursprünglich nicht vorhanden. Ihre Antwort nimmt eine aktuelle Tagesperspektive ein. Ich musste deine Bemühungen belohnen !! Du hast dich wirklich in diese Sache vertieft! Wer hätte gedacht, dass dies so in die Luft jagen würde? Prost !!
• @ w3dk: es ‚ ist eine nicht sehr interessante Eigenart der Terminologie, aber Sie könnten “ Groß- und Kleinschreibung beachten “ bedeutet, dass “ das Ändern der Groß- / Kleinschreibung eines Zeichens das gesamte „, oder Sie könnten es so verstehen: “ Wenn Sie die Groß- und Kleinschreibung eines Zeichens ändern, ändert immer das gesamte „. Kobi scheint letzteres zu behaupten, er zieht es vor, dass Groß- und Kleinschreibung “ bedeuten sollte. Jede Änderung im Fall ist signifikant „, was natürlich gilt nicht für URLs. Sie bevorzugen das erstere. ‚ ist nur eine Frage der Empfindlichkeit für Groß- und Kleinschreibung.
• @ rybo111: Wenn ein Benutzer example.com/fOObaR erfordert die Spezifikation, dass der Server unter www.example.com einen Pfad “ / fOObaR “ wie angegeben; Über die Frage, ob der Server dies anders behandeln muss als “ / foOBaR „.

Einfach. Das Betriebssystem unterscheidet zwischen Groß- und Kleinschreibung. Webserver kümmern sich im Allgemeinen nicht darum, es sei denn, sie müssen irgendwann auf das Dateisystem zugreifen. Hier setzen Linux und andere Unix-basierte Betriebssysteme die Regeln des Dateisystems durch. In diesem Fall spielt die Empfindlichkeit eine wichtige Rolle. Aus diesem Grund wurde bei IIS nie zwischen Groß- und Kleinschreibung unterschieden. weil Windows nie zwischen Groß- und Kleinschreibung unterschied.

[Update]

In den Kommentaren (seitdem gelöscht) gab es einige starke Argumente dafür, ob URLs eine Beziehung zum Dateisystem haben, wie ich angegeben habe. Diese Argumente sind hitzig geworden. Es ist äußerst kurzsichtig zu glauben, dass es keine Beziehung gibt. Das gibt es absolut! Lassen Sie mich das näher erläutern.

Anwendungsprogrammierer sind im Allgemeinen keine systeminternen Programmierer. Ich beleidige nicht. Es handelt sich um zwei separate Disziplinen, und zum Schreiben von Anwendungen sind keine systeminternen Kenntnisse erforderlich, wenn Anwendungen einfach das Betriebssystem aufrufen können. Da Anwendungsprogrammierer keine systeminternen Programmierer sind, ist das Umgehen der Betriebssystemdienste nicht möglich.Ich sage das, weil dies zwei getrennte Lager sind und sie sich selten kreuzen. Anwendungen sind so geschrieben, dass sie in der Regel Betriebssystemdienste verwenden. Natürlich gibt es einige seltene Ausnahmen.

Als Webserver angezeigt wurden, versuchten Anwendungsentwickler nicht, die Betriebssystemdienste zu umgehen. Dafür gab es mehrere Gründe. Erstens war es nicht notwendig. Zweitens wussten Anwendungsprogrammierer im Allgemeinen nicht, wie sie Betriebssystemdienste umgehen sollten. Drittens waren die meisten Betriebssysteme entweder extrem stabil und robust oder extrem einfach und leicht und die Kosten nicht wert.

Beachten Sie, dass die frühen Webserver entweder auf teuren Computern wie dem DEC VAX / liefen. VMS-Server und das Unix des Tages (Berkeley und Ultrix sowie andere) auf Haupt- oder Mittelbildcomputern, kurz darauf auf leichten Computern wie PCs und Windows 3.1. Als 1997/8 modernere Suchmaschinen wie Google auftauchten, war Windows auf Windows NT umgestiegen, und andere Betriebssysteme wie Novell und Linux hatten ebenfalls begonnen, Webserver auszuführen. Apache war der dominierende Webserver, obwohl es andere wie IIS und O „Reilly gab, die ebenfalls sehr beliebt waren. Keiner von ihnen umging zu dieser Zeit die Betriebssystemdienste. Es ist wahrscheinlich, dass keiner der Webserver dies auch heute noch tut.

Frühe Webserver waren recht einfach. Sie sind es noch heute. Jede Anforderung für eine Ressource über eine HTTP-Anforderung, die auf einer Festplatte vorhanden ist, wurde / wird vom Webserver über das Betriebssystem-Dateisystem gestellt.

Dateisysteme sind recht einfache Mechanismen. Wenn eine Anforderung für den Zugriff auf eine Datei gestellt wird und diese Datei vorhanden ist, wird die Anforderung an das Autorisierungssubsystem übergeben, und wenn sie gewährt wird, wird die ursprüngliche Anforderung erfüllt. Wenn die Ressource dies tut nicht vorhanden oder nicht autorisiert, eine Ausnahme wird vom System ausgelöst. Wenn eine Anwendung eine Anforderung stellt, wird ein Auslöser gesetzt und die Anwendung wartet. Wenn die Anforderung beantwortet wird, wird der Auslöser ausgelöst und die Anwendung verarbeitet die Anforderungsantwort funktioniert heute noch so. Wenn die Anwendung sieht, dass die Anfrage s war Wenn es nicht funktioniert, führt die Anwendung eine Fehlerbedingung im Code des Codes aus oder stirbt, wenn sie nicht behandelt wird. Einfach.

Im Fall eines Webservers nimmt der Webserver unter der Annahme, dass eine URL-Anforderung für einen Pfad / eine Datei erfolgt, den Pfad- / Dateiteil der URL-Anforderung (URI) und stellt eine Anforderung an das Dateisystem und es ist entweder zufrieden oder löst eine Ausnahme aus. Der Webserver verarbeitet dann die Antwort. Wenn beispielsweise der angeforderte Pfad und die angeforderte Datei gefunden und der Zugriff vom Autorisierungssubsystem gewährt wird, verarbeitet der Webserver diese E / A-Anforderung wie gewohnt. Wenn das Dateisystem eine Ausnahme auslöst, gibt der Webserver einen 404-Fehler zurück, wenn die Datei nicht gefunden wird, oder einen 403-Fehler, wenn der Ursachencode nicht autorisiert ist.

Da einige Betriebssysteme zwischen Groß- und Kleinschreibung unterscheiden und Dateisysteme von Für diesen Typ sind genaue Übereinstimmungen erforderlich. Der vom Webserver angeforderte Pfad / die Datei muss genau mit dem übereinstimmen, der auf der Festplatte vorhanden ist. Der Grund dafür ist einfach. Webserver raten nicht, was Sie meinen. Kein Computer tut dies, ohne dafür programmiert zu sein. Webserver verarbeiten Anforderungen einfach so, wie sie empfangen werden. Wenn der Pfad- / Dateiteil der URL-Anforderung, die direkt an das Dateisystem übergeben wird, nicht mit dem auf der Festplatte übereinstimmt, löst das Dateisystem eine Ausnahme aus und der Webserver gibt einen Fehler 404 Not Found zurück.

Es sind wirklich so einfache Leute. Es ist keine Raketenwissenschaft. Es gibt eine absolute Beziehung zwischen dem Pfad / Datei-Teil einer URL und dem Dateisystem.

Kommentare

• Ich denke, Ihr Argument ist fehlerhaft. Während Berners-Lee ‚ keine Wahl über die Groß- und Kleinschreibung von FTP-URLs hatte. Er musste http-URLs entwerfen. Er hätte sie nur als US-ASCII und ohne Berücksichtigung der Groß- und Kleinschreibung angeben können. Wenn es jemals Webserver gab, die gerade den URL-Pfad an das Dateisystem übergeben haben, waren sie unsicher und die Einführung der URL-Codierung hat die Kompatibilität mit ihnen unterbrochen. Angesichts der Tatsache, dass der Pfad vor der Übergabe an den Betriebssystem-Smashing-Fall verarbeitet wird, wäre die Implementierung einfach gewesen. Daher denke ich, dass wir dies als Designentscheidung und nicht als Implementierungs-Eigenart betrachten müssen.
• @WilliamHay Dies hat nichts mit Berners-Lee oder dem Design des Webs zu tun. Es geht um Einschränkungen und Anforderungen des Betriebssystems. Ich bin ein pensionierter Systemingenieur. Ich habe damals an diesen Systemen gearbeitet. Ich sage Ihnen genau, warum URLs zwischen Groß- und Kleinschreibung unterscheiden. Es ist keine Vermutung. Es ist keine Meinung. Es ist eine Tatsache. Meine Antwort wurde absichtlich vereinfacht. Natürlich gibt es Dateiprüfungen und andere Prozesse, die durchgeführt werden können, bevor eine offene Anweisung ausgegeben wird. Und ja (!) Webserver sind daher bis heute teilweise unsicher.
• Ob bei URLs zwischen Groß- und Kleinschreibung unterschieden wird, hat nichts mit dem Design des Webs zu tun? „Ja wirklich?“ Argument von Authority gefolgt von Argument von Assertion.Dass Webserver die Pfadkomponente einer URL mehr oder weniger direkt an einen offenen Aufruf übergeben, ist eine Folge des Entwurfs von URLs und keine Ursache dafür. Server (oder Smart Clients im Fall von FTP) haben möglicherweise die Groß- und Kleinschreibung von Dateisystemen vor dem Benutzer verborgen. Dass sie nicht ‚ t sind, ist eine Entwurfsentscheidung.
• @WilliamHay Sie müssen den Grasbehälter verlangsamen und erneut lesen, was ich geschrieben habe. Ich bin ein pensionierter Systeminternaltechniker, der Betriebssystemkomponenten, Protokollstapel und Routercode für das ARPA-Net usw. schreibt. Ich habe mit Apache, O ‚ Reilly und IIS-Interna gearbeitet. Ihr FTP-Argument enthält kein Wasser, da zumindest die wichtigsten FTP-Server aus demselben Grund zwischen Groß- und Kleinschreibung unterscheiden. Zu keinem Zeitpunkt habe ich etwas über das Design von URL / URI gesagt. Zu keinem Zeitpunkt habe ich gesagt, dass Webserver Werte ohne Verarbeitung übergeben haben. Ich habe gesagt, dass Betriebssystemdienste häufig verwendet werden und dass das Dateisystem eine genaue Übereinstimmung erfordert, um erfolgreich zu sein.
• @WilliamHay Bitte haben Sie Verständnis dafür, dass Sie und ich uns gegenseitig denken. In meiner Antwort habe ich lediglich gesagt, dass bei Dateisystemaufrufen bei einigen Betriebssystemen die Groß- und Kleinschreibung beachtet wird. Anwendungen, die Systemaufrufe verwenden, und die meisten tun dies, beschränken sich auf die Durchsetzung der Betriebssystemregeln – in diesem Fall auf die Groß- und Kleinschreibung. Es ist nicht unmöglich, diese Regel zu umgehen. In der Tat kann dies in einigen Fällen etwas trivial sein, obwohl es nicht praktikabel ist. Früher habe ich das Dateisystem in meiner Arbeit routinemäßig umgangen, um Festplatten zu entschlüsseln, die aus dem einen oder anderen Grund kablooie wurden, oder um Interna von Datenbankdateien usw. zu analysieren.

1. URLs behaupten, ein UNIFORM Resource Locator zu sein und können auf Ressourcen verweisen, die vor dem Web liegen. Einige davon unterscheiden zwischen Groß- und Kleinschreibung (z. B. viele FTP-Server), und URLs müssen in der Lage sein, diese Ressourcen auf eine einigermaßen intuitive Weise darzustellen.

2. Die Berücksichtigung der Groß- und Kleinschreibung erfordert mehr Arbeit bei der Suche eine Übereinstimmung (entweder im Betriebssystem oder darüber).

3. Wenn Sie URLs als Groß- und Kleinschreibung definieren, können einzelne Server sie bei Bedarf als Groß- und Kleinschreibung implementieren. Das Gegenteil ist nicht der Fall.

4. Die Unempfindlichkeit gegenüber Groß- und Kleinschreibung kann in internationalen Kontexten nicht trivial sein: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Auch RFC1738 erlaubte die Verwendung von Zeichen außerhalb des ASCII-Bereichs, sofern diese codiert waren, aber keinen Zeichensatz angaben. Dies ist ziemlich wichtig für etwas, das sich selbst als WORLD Wide Web bezeichnet. Das Definieren von URLs als Groß- und Kleinschreibung würde viel Spielraum eröffnen Fehler.

5. Wenn Sie versuchen, viele Daten in einen URI zu packen (z. B. einen Daten-URI ) Sie können mehr einpacken, wenn Groß- und Kleinschreibung unterschiedlich sind.

Kommentare

• I ‚ Ich bin mir ziemlich sicher, dass URLs historisch auf ASCII beschränkt waren. Daher ist es unwahrscheinlich, dass die Internationalisierung ein ursprünglicher Grund ist. Die Geschichte, dass Unix zwischen Groß- und Kleinschreibung unterscheidet, OTOH, spielte wahrscheinlich eine große Rolle.
• Während nur eine Teilmenge von ASCII uncodiert in einer URL verwendet werden kann, gibt RFC1738 spezifisch an, dass Zeichen außerhalb des ASCII-Bereichs codiert verwendet werden dürfen. Ohne Angabe eines Zeichensatzes ist es nicht möglich, ‚ zu wissen welche Oktette das gleiche Zeichen darstellen Schauspieler außer für den Fall. Aktualisiert.
• Re # 4: Es ist ‚ tatsächlich schlimmer als das. Gepunktet und punktlos Ich bin eine Demonstration des allgemeineren Prinzips, dass selbst wenn alles UTF-8 (oder ein anderes UTF) ist, Sie nicht richtig groß- oder klein schreiben können, ohne das Gebietsschema zu kennen, zu dem der Text gehört . Im Standardgebietsschema wird ein lateinischer Großbuchstabe I in einen lateinischen Kleinbuchstaben i geschrieben, was auf Türkisch falsch ist, weil er einen Punkt hinzufügt (es gibt kein “ türkisches Großbuchstaben dotless I “ Codepunkt; Sie ‚ sollen den ASCII-Codepunkt verwenden). Wenn Sie Codierungsunterschiede einbringen, reicht dies von “ wirklich schwer “ bis “ vollständig unlösbar “

Ich habe aus dem Blog gestohlen Old New Thing die Gewohnheit, sich Fragen der Form „Warum ist etwas so?“ Zu nähern. mit der Gegenfrage „Wie wäre die Welt, wenn es nicht der Fall wäre?“

Angenommen, ich habe einen Webserver eingerichtet, um meine Dokumentdateien aus einem Ordner zu bedienen, damit ich sie weiterlesen kann das Telefon, als ich nicht im Büro war. Jetzt habe ich in meinem Dokumentenordner drei Dateien: todo.txt, ToDo.txt und TODO.TXT (Ich weiß, aber es hat für mich Sinn gemacht, als ich die Dateien erstellt habe.)

Welche URL möchte ich verwenden können, um auf diese Dateien zuzugreifen? Ich möchte auf intuitive Weise mit http://www.example.com/docs/filename darauf zugreifen.

Angenommen, ich habe ein Skript, mit dem ich meinem Adressbuch einen Kontakt hinzufügen kann, den ich kann auch über das Web tun.Wie soll das seine Parameter nehmen? Nun, ich würde es gerne so verwenden: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Aber wenn ich den Namen nicht von Fall zu Fall angeben könnte, wie würde ich das tun?

Wie würde ich die Wiki-Seiten für Cat und CAT, Text und TEXT, Latex und LaTeX unterscheiden? Disambig-Seiten, denke ich, aber ich ziehe es vor, nur das zu bekommen, wonach ich gefragt habe.

Aber all das fühlt sich an Als würde es sowieso die falsche Frage beantworten.

Die Frage, die Sie meiner Meinung nach wirklich gestellt haben, lautet: „Warum machen Webserver 404 Sie nur für einen Fallunterschied, wenn es sich um Computer handelt, die das Leben einfacher machen sollen?“ und sie sind perfekt in der Lage, zumindest die offensichtlichsten Fallvariationen in der von mir eingegebenen URL zu finden, die funktionieren würden? „

Die Antwort darauf lautet, dass einige Websites dies getan haben (und besser, sie auch nach anderen Tippfehlern suchen), niemand hat es für sinnvoll gehalten, die Standard-404-Fehlerseite eines Webservers zu ändern, um dies zu tun … aber vielleicht sollten sie das?

Kommentare

• Einige Websites verwenden einen Mechanismus zum Konvertieren von a Keine Abfrage an alle Kleinbuchstaben oder etwas Konsistentes. In gewisser Weise ist dies klug.
• Nein, sie sollten nicht ‚ t. Diese Funktionalität kann und wird häufig hinzugefügt, wenn dies wünschenswert ist (z. B. durch Module in Apache). Diese Art von Änderung als Standardverhalten – oder schlimmer noch als unveränderliches Verhalten – durchzusetzen, wäre störender als das relativ seltene Gelegenheit, bei der jemand manuell eine URL eingeben muss, die über den Hostnamen hinausgeht. Ein gutes Beispiel dafür, warum Sie dies nicht tun sollten, ist das Fiasko, wenn Network Solutions “ “ nicht vorhandene Domänenfehler aus öffentlichem DNS behoben hat Abfragen.
• @SirNickity Niemand hat Unveränderlichkeit auf irgendeiner Ebene vorgeschlagen, und Webserver-Fehlerseiten können auf jedem Webserver konfiguriert werden, den ich ‚ jemals verwendet habe. Niemand schlug vor, 404 durch 30 * -Codes zu ersetzen, sondern der Fehlerseite eine Liste mit von Menschen anklickbaren Vorschlagslinks hinzuzufügen. Domain-Namen sind ein ganz anderes Thema, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird, und in einem anderen Sicherheitskontext. und IIS behebt bereits automatisch “ “ (durch Ignorieren) von Fallunterschieden im Pfad oder Dateinamen von URIs.
• Seit 1996 können Sie dies mit Apache mit mod_speling tun. Es scheint nur nicht sehr beliebt zu sein, ‚ zu tun. Unix / Linux-Benutzer sehen Groß- und Kleinschreibung als Regel und Groß- und Kleinschreibung als Ausnahme an.

Obwohl die Die obige Antwort ist richtig. & gut. Ich möchte noch einige Punkte hinzufügen.

Um besser zu verstehen, sollte man den grundlegenden Unterschied zwischen Unix (Linux) und Windows Server verstehen. Bei Unix wird zwischen Groß- und Kleinschreibung unterschieden. & Windows unterscheidet nicht zwischen Groß- und Kleinschreibung.

Das HTTP-Protokoll wurde um 1990 entwickelt oder mit der Implementierung begonnen CERN-Institute, die meisten Wissenschaftler verwendeten Unix-Maschinen und nicht Windows.

Die meisten Wissenschaftler waren mit Unix vertraut, daher wurden sie möglicherweise vom Dateisystem im Unix-Stil beeinflusst.

Windows Server wurde nach 2000 veröffentlicht. Viel bevor Windows Server populär wurde, war das HTTP-Protokoll ausgereift und die Spezifikation war vollständig.

Dies könnte der Grund sein.

Kommentare

• “ Windows Server wurde nach 2000 freigegeben. “ Das Windows NT 3.1 -Team hätte Ihnen 1993 nicht zugestimmt. NT 3.51 im Jahr 1995 war wahrscheinlich der Zeitpunkt, an dem NT zu werden begann Ausgereift und etabliert genug, um geschäftskritische Serveranwendungen zu unterstützen.
• NT 3.51 verfügte über die Win 3.1-Schnittstelle. Windows startete erst mit Windows 95 und NT 4.0, um dieselbe Benutzeroberfläche zu erhalten.
• Michael Kj ö rling stimmte zu. Lassen Sie es mich ändern.
• @Thorbj ø rnRavnAndersen Auf dem Servermarkt war NT 3.51 einigermaßen erfolgreich. Auf dem Consumer / Prosumer-Markt dauerte es bis Windows 2000 (NT 5.0), bis die NT-Linie ernsthaft an Fahrt gewann.
• In der Tat wurde das WorldWideWeb ursprünglich auf Unix-basierten Systemen entwickelt, bei denen zwischen Groß- und Kleinschreibung unterschieden wird Dateisysteme und die meisten URLs, die direkt Dateien im Dateisystem zugeordnet sind.

Wie soll man lesen? a „Warum wurde es so entworfen?“ Frage? Fragen Sie nach einer historisch korrekten Darstellung des Entscheidungsprozesses oder fragen Sie „Warum sollte jemand dies so gestalten?“?

Es ist sehr selten möglich, eine historisch korrekte Darstellung zu erhalten Konto.Manchmal, wenn Entscheidungen in Normungsausschüssen getroffen werden, gibt es eine dokumentarische Spur darüber, wie die Debatte geführt wurde, aber in den frühen Tagen des Web wurden Entscheidungen von einigen wenigen Personen – in diesem Fall wahrscheinlich von TimBL selbst – hastig getroffen, und die Begründung ist unwahrscheinlich niedergeschrieben worden sein. TimBL hat jedoch zugegeben, dass er Fehler beim Design von URLs gemacht hat – siehe http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

In den frühen Tagen wurden URLs sehr direkt Dateinamen zugeordnet, und die Dateien befanden sich im Allgemeinen auf Unix-ähnlichen Computern, und Unix-ähnliche Computer haben Dateinamen, bei denen zwischen Groß- und Kleinschreibung unterschieden wird. Ich vermute also, dass dies aus Gründen der Implementierungskomfort einfach so passiert ist und die Benutzerfreundlichkeit (für Endbenutzer) nie in Betracht gezogen wurde. Auch in den frühen Tagen waren die Benutzer ohnehin alle Unix-Programmierer.

Kommentare

• Endbenutzer waren ebenfalls Unix-Benutzer (nicht unbedingt Programmierer, aber Hochenergiephysiker und dergleichen), so waren auch sie an Groß- und Kleinschreibung gewöhnt.

Dies hat nichts damit zu tun, wo Sie Ihre Domain gekauft haben, DNS unterscheidet nicht zwischen Groß- und Kleinschreibung. Das Dateisystem auf dem Server, den Sie für das Hosting verwenden, ist jedoch.

Dies ist kein wirkliches Problem und auf * nix-Hosts ziemlich häufig. Stellen Sie einfach sicher, dass alle Links, die Sie auf Ihre Seiten schreiben, korrekt sind und Sie kein Problem haben. Um dies zu vereinfachen, empfehle ich, Ihre Seiten immer in Kleinbuchstaben zu benennen. Dann müssen Sie den Namen beim Schreiben eines Links nie überprüfen.

Closetnoc hat Recht mit dem Betriebssystem. Einige Dateisysteme behandeln denselben Namen mit unterschiedlichem Gehäuse als unterschiedliche Dateien.

Gibt es auch einen echten Zweck / Vorteil, wenn eine URL mit Groß- und Kleinschreibung beachtet wird (im Gegensatz zu der überwiegenden Mehrheit der URLs, die auf dieselbe Seite verweisen, unabhängig davon die Großschreibung)?

Ja, um doppelte Inhaltsprobleme zu vermeiden.

Wenn Sie beispielsweise die folgenden URLs hatten:

http://example.com/page-1 http://example.com/Page-1 http://example.com/paGe-1 http://example.com/PAGE-1 http://example.com/pAGE-1 

und alle zeigten auf genau dieselbe Seite mit genau demselben Inhalt, dann hätten Sie doppelten Inhalt, und ich bin sicher, wenn Sie eine Google-Suchkonsole haben (Webmaster-Tools) Konto, Google wird Ihnen dies anzeigen.

Was ich wou Wenn Sie sich in einer solchen Situation befinden, empfehlen wir Ihnen, alle Kleinbuchstaben-URLs zu verwenden und die URLs mit mindestens einem Großbuchstaben in die Kleinbuchstaben-Version umzuleiten. Leiten Sie daher in der Liste der oben genannten URLs alle URLs zur ersten URL um.

Kommentare

• “ Ja. um doppelte Inhaltsprobleme zu vermeiden. “ – Aber das Gegenteil scheint der Fall zu sein? Die Tatsache, dass URLs zwischen Groß- und Kleinschreibung unterscheiden können (und so werden sie von Suchmaschinen behandelt) verursacht die von Ihnen erwähnten Probleme mit doppelten Inhalten. Wenn URLs generell nicht zwischen Groß- und Kleinschreibung unterscheiden, gibt es keine doppelten Inhaltsprobleme mit unterschiedlicher Groß- und Kleinschreibung. page-1 wäre dasselbe wie PAGE-1.
• Ich denke, eine schlechte Serverkonfiguration Dies kann zu doppelten Inhalten führen, wenn es um Gehäuse geht. Beispielsweise würde die in .htaccess gespeicherte Anweisung RewriteRule ^request-uri$ /targetscript.php [NC] mit http://example.com/request-uri und http://example.com/ReQuEsT-Uri übereinstimmen, da die [NC] gibt an, dass das Gehäuse ‚ keine Rolle spielt, wenn dieser eine reguläre Ausdruck ausgewertet wird.

Groß- und Kleinschreibung hat einen Wert.

Wenn es 26 Buchstaben gibt, von denen jeder großgeschrieben werden kann, sind dies 52 Zeichen.

4 Zeichen haben die Möglichkeit von 52 * 52 * 52 * 52 Kombinationen. entspricht 7311616 Kombinationen.

Wenn Sie die Zeichen nicht groß schreiben können, beträgt die Anzahl der Kombinationen 26 * 26 * 26 * 26 = 456976

Das sind mehr als 14-mal mehr Kombinationen für 52 Zeichen als Für das Speichern von Daten können URLs kürzer sein und mehr Informationen können über Netzwerke mit weniger übertragenen Daten übertragen werden.

Aus diesem Grund sehen Sie YouTube mit URLs wie https://www.youtube.com/watch?v=xXxxXxxX