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

Meine Frage: Als URLs zum ersten Mal entworfen wurden, warum wurde die Berücksichtigung der Groß- und Kleinschreibung zu einer Funktion gemacht? Ich frage dies, weil es mir (dh einem Laien) so vorkommt, als würde Groß- und Kleinschreibung vermieden, um unnötige Fehler zu vermeiden und eine bereits komplizierte Textfolge zu vereinfachen.

Hat eine URL, bei der die Groß- und Kleinschreibung beachtet wird, auch einen echten Zweck / Vorteil (im Gegensatz zu den meisten URLs, die unabhängig von der Groß- und Kleinschreibung auf dieselbe Seite verweisen)?

Wikipedia ist beispielsweise eine Website, bei der die Groß- und Kleinschreibung beachtet wird (mit Ausnahme des ersten Zeichens):

https://en.wikipedia.org/wiki/St A ck_Exchange ist DOA.

Warum wird bei der URL nicht zwischen Groß- und Kleinschreibung unterschieden?

Ich verstehe, dass das wie eine provokative (und "Devil's Advocate") Art rhetorischer 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 gibt viele, viele verschiedene Webserver, die freigegeben werden. Microsoft hat IIS mit Windows Server-Betriebssystemen (und anderen, einschließlich Windows XP Professional) veröffentlicht. Unix hat Schwergewichte wie Nginx und Apache, ganz zu schweigen von kleineren Angeboten wie OpenBSDs internem httpd, 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 Stromversorgungen), die möglicherweise über eine Netzwerkverbindung verfügen.

Bei der Frage "Warum wird bei URLs zwischen Groß- und Kleinschreibung unterschieden?" Und die eigentliche Antwort lautet: Das machen nicht alle. Mindestens ein Webserver, der recht beliebt ist, unterscheidet in der Regel NICHT zwischen Groß- und Kleinschreibung. (Der Webserver ist IIS.)

Ein Hauptgrund für das unterschiedliche Verhalten zwischen verschiedenen Webservern liegt wahrscheinlich in der Einfachheit. Die einfache Möglichkeit, einen Webserver zu erstellen, besteht darin, die gleichen Schritte wie beim Auffinden von Dateien durch das Betriebssystem des Computers / Geräts auszuführen. Häufig suchen Webserver eine Datei, um eine Antwort bereitzustellen. Unix wurde für Computer der gehobenen Klasse entwickelt. Daher bot Unix die wünschenswerte Funktionalität, Groß- und Kleinbuchstaben zuzulassen. Unix hat entschieden, Groß- und Kleinschreibung als unterschiedlich zu behandeln, da sie sich unterscheiden. Das ist ganz einfach und natürlich. In Windows wurde die Groß- und Kleinschreibung nicht berücksichtigt, da bereits erstellte Software unterstützt werden soll. Dieser Verlauf geht auf DOS zurück, das Kleinbuchstaben einfach nicht unterstützt hat. möglicherweise in dem Bestreben, die Dinge mit weniger leistungsfähigen Computern zu vereinfachen, die weniger Speicher verbrauchen. Da diese Betriebssysteme unterschiedlich sind, weisen einfach gestaltete (frühe Versionen von) Webservern dieselben Unterschiede auf.

Vor diesem Hintergrund finden Sie hier einige spezifische Antworten auf die spezifischen Fragen:

Warum wurde bei der ersten Erstellung von URLs die Groß- und Kleinschreibung berücksichtigt?

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

Ich frage dies, weil es mir (dh einem Laien) so vorkommt, als würde Groß- und Kleinschreibung vermieden, um unnötige Fehler zu vermeiden und eine bereits komplizierte Textfolge zu vereinfachen.

URLs wurden für die Verarbeitung durch Computer entwickelt. Obwohl eine Person eine vollständige URL in eine Adressleiste eingeben kann, war dies kein wesentlicher Bestandteil des beabsichtigten Designs. Das beabsichtigte Design ist, dass Leute Hyperlinks folgen ("klicken"). Wenn durchschnittliche Laien das tun, ist es ihnen wirklich egal, ob die unsichtbare URL einfach oder kompliziert ist.

Hat eine URL, bei der die Groß- und Kleinschreibung beachtet wird, auch einen echten Zweck / Vorteil (im Gegensatz zu den meisten URLs, die unabhängig von der Groß- und Kleinschreibung auf dieselbe Seite verweisen)?

Der fünfte nummerierte Punkt in der Antwort von William Hay erwähnt einen technischen Vorteil: URLs können eine effektive Möglichkeit für einen Webbrowser sein, Informationen an einen Webserver zu senden, und es können mehr Informationen eingefügt werden, wenn weniger Einschränkungen bestehen Einschränkung würde reduzieren, wie viele Informationen enthalten sein können.

In vielen Fällen ist die Unterscheidung zwischen Groß- und Kleinschreibung jedoch nicht sehr überzeugend. Dies wird durch die Tatsache belegt, dass sich IIS 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 mit Groß- und Kleinschreibung wie Unix. (HTTP hat das ursprüngliche Design von Unix nicht beeinflusst, da Unix deutlich älter als HTTP ist.)

URLs unterscheiden nicht zwischen Groß- und Kleinschreibung, sondern nur Teile davon.
Zum Beispiel unterscheidet nichts zwischen Groß- und Kleinschreibung in der URL https://google.com.

Unter Bezugnahme auf RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax

Erstens sieht eine URL aus Wikipedia folgendermaßen aus:

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

(Ich habe das user:passwordTeil entfernt, weil es nicht interessant ist und nur selten verwendet wird.)

• scheme:

Bei Schemata wird die Groß- und Kleinschreibung nicht berücksichtigt

• host:

Bei der Host-Unterkomponente wird die Groß- und Kleinschreibung nicht berücksichtigt.

• 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 in der Fragment-ID-Syntax definieren, um verschiedene Arten von Teilmengen, Ansichten oder externen Referenzen anzugeben

Also, die schemeund hostGroß- und Kleinschreibung.
Der Rest der URL unterscheidet zwischen Groß- und Kleinschreibung.

Warum ist die pathGroß- und Kleinschreibung wichtig?

Dies scheint die Hauptfrage zu sein.
Es ist schwer zu beantworten, warum etwas getan wurde, wenn es nicht dokumentiert wurde, aber wir können eine sehr gute Vermutung anstellen.
Ich habe sehr spezifische Zitate aus der Spezifikation ausgewählt, wobei der Schwerpunkt auf Daten liegt .
Schauen 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 so einen Domainnamen kaufen, ohne Tausende von Varianten kaufen zu müssen.

• Daten - Die Daten werden vom Zielserver verwendet, und die Anwendung kann auswählen, was dies bedeutet . Es würde keinen Sinn machen, die Groß- und Kleinschreibung von Daten zu ignorieren. Die Anwendung sollte über mehr Optionen verfügen, und die Festlegung von 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?

Die Unterscheidung zwischen Groß- und Kleinschreibung hat ihre Tücken, wenn es um Caching und kanonische URLs geht, ist aber sicherlich nützlich. Einige Beispiele:

• Base64 , das in Daten-URIs verwendet wird .
• Seiten können Base64 - Daten in der URL, zum Beispiel kodieren: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• Bei URL-Kürzern wird die Groß- und Kleinschreibung berücksichtigt: /a5BMöglicherweise unterscheidet sie sich von/a5b
• Wie Sie bereits erwähnt haben, kann Wikipedia "AIDS" von "Aids" unterscheiden.

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, wobei die Vertraulichkeit eine wichtige Rolle spielt. Aus diesem Grund wurde bei IIS nie zwischen Groß- und Kleinschreibung unterschieden. weil Windows nie zwischen Groß- und Kleinschreibung unterschied.

[Aktualisieren]

In den (seitdem gelöschten) Kommentaren gab es einige starke Argumente, ob URLs in irgendeiner Beziehung zum Dateisystem stehen, wie ich angegeben habe. Diese Argumente sind hitzig geworden. Es ist äußerst kurzsichtig zu glauben, dass es keine Beziehung gibt. Da ist absolut was! Lassen Sie mich weiter erklären.

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 anrufen können. Da Anwendungsprogrammierer keine systeminternen Programmierer sind, ist das Umgehen der Betriebssystemdienste nicht möglich. Ich sage das, weil es sich um zwei getrennte Lager handelt und sie sich selten überschneiden. Anwendungen sind in der Regel für die Verwendung von Betriebssystemdiensten geschrieben. Es gibt natürlich einige Ausnahmen.

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

Denken Sie daran, dass die frühen Webserver entweder auf teuren Computern wie den DEC VAX / VMS-Servern und dem Unix des Tages (Berkeley und Ultrix sowie andere) auf Mainframe- oder Midframe-Computern liefen und bald darauf leichte Computer wie PCs und Windows 3.1. Als modernere Suchmaschinen wie Google 1997/98 auf den Markt kamen, war Windows auf Windows NT umgestiegen, und andere Betriebssysteme wie Novell und Linux hatten ebenfalls begonnen, Webserver zu betreiben. Apache war der dominierende Webserver, obwohl es andere wie IIS und O'Reilly gab, die ebenfalls sehr beliebt waren. Keiner von ihnen überbrückte zu diesem Zeitpunkt 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 durchgeführt.

Dateisysteme sind eher einfache Mechanismen. Wenn eine Anforderung für den Zugriff auf eine Datei gestellt wird, wird die Anforderung an das Autorisierungssubsystem weitergeleitet, und wenn sie erteilt wird, wird die ursprüngliche Anforderung erfüllt. Wenn die Ressource nicht vorhanden oder nicht autorisiert ist, wird vom System eine Ausnahme ausgelöst. Wenn eine Anwendung eine Anfrage stellt, wird ein Auslöser gesetzt und die Anwendung wartet. Wenn die Anforderung beantwortet wird, wird der Trigger ausgelöst und die Anwendung verarbeitet die Anforderungsantwort. So funktioniert es auch heute noch. Wenn die Anwendung feststellt, dass die Anforderung erfüllt wurde, wird sie fortgesetzt. Wenn sie fehlgeschlagen ist, führt die Anwendung eine Fehlerbedingung im Code 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 / eine Datei-Teil der URL-Anforderung (URI) und sendet eine Anforderung an das Dateisystem, und diese wird entweder erfüllt oder wirft eine Ausnahme. Der Webserver verarbeitet dann die Antwort. Wenn beispielsweise der angeforderte Pfad und die angeforderte Datei gefunden werden 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 wurde, oder einen 403-Fehler, wenn der Ursachencode nicht autorisiert wurde.

Da bei einigen Betriebssystemen die Groß- und Kleinschreibung beachtet wird und Dateisysteme dieses Typs genaue Übereinstimmungen erfordern, muss der vom Webserver angeforderte Pfad / die angeforderte Datei genau mit den auf der Festplatte vorhandenen übereinstimmen. 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, gibt das Dateisystem eine Ausnahme aus und der Webserver gibt den Fehler 404 Not Found zurück.

Es ist wirklich so einfach Leute. Es ist keine Raketenwissenschaft. Es besteht eine absolute Beziehung zwischen dem Pfad- / Dateiteil einer URL und dem Dateisystem.

1. URLs erheben den Anspruch, ein UNIFORM-Ressourcen-Locator zu sein, und können auf Ressourcen verweisen, die älter sind als das Web. Einige von ihnen unterscheiden zwischen Groß- und Kleinschreibung (z. B. viele FTP-Server), und URLs müssen in der Lage sein, diese Ressourcen auf einigermaßen intuitive Weise darzustellen.

2. Groß- / Kleinschreibung erfordert mehr Arbeit bei der Suche nach einer Übereinstimmung (entweder im Betriebssystem oder darüber).

3. Wenn Sie URLs als case sensitive definieren, können einzelne Server diese bei Bedarf als case insensitive implementieren. Das Gegenteil ist nicht wahr.

4. Die Unterscheidung zwischen Groß- und Kleinschreibung kann im internationalen Kontext nicht trivial sein: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . RFC1738 erlaubte auch 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 das World Wide Web nennt. Das Definieren von URLs, bei denen die Groß- und Kleinschreibung nicht berücksichtigt wird, würde viel Raum für Fehler eröffnen.

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

Ich habe dem Blog ein altes neues Ding gestohlen, um mich Fragen der Form zu nähern: "Warum ist es so, dass etwas der Fall ist?" mit der Gegenfrage "Wie wäre die Welt, wenn es nicht so wäre?"

Angenommen, ich habe einen Webserver eingerichtet, auf dem ich meine Dokumentdateien aus einem Ordner bereitstellen kann, damit ich sie auf dem Telefon lesen kann, wenn ich nicht im Büro bin. Nun, in meinem Dokumentenordner, ich habe drei Dateien, todo.txt, ToDo.txtund TODO.TXT(ich weiß, aber es machte Sinn für mich , wenn ich die Dateien gemacht).

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

Angenommen, ich habe ein Skript, mit dem ich einen Kontakt zu meinem Adressbuch hinzufügen kann, was ich auch über das Web tun kann. Wie sollte das seine Parameter nehmen? Nun, ich möchte , es benutzen , wie: http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. Aber wenn ich den Namen nicht fallweise 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? Seiten mit Begriffsklärung, denke ich, aber ich ziehe es vor, nur das zu bekommen, wonach ich gefragt habe.

Aber alles, was sich anfühlt, ist die Beantwortung der falschen Frage.

Die Frage, die Sie sich wirklich gestellt haben, ist: "Warum machen Sie Webserver, wenn es sich um Computer handelt, die das Leben vereinfachen sollen, und die durchaus in der Lage sind, zumindest die offensichtlichsten Fallvarianten im Internet zu finden?" Ich habe eine URL eingegeben, die funktionieren würde. "

Die Antwort darauf ist, dass einige Websites dies bereits getan haben (und besser, sie prüfen auch auf andere Tippfehler), aber niemand hat es für sinnvoll gehalten, die Standard-404-Fehlerseite eines Webservers zu ändern, um dies zu tun ... aber vielleicht sollten sie das tun?

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

Zum besseren Verständnis sollte man den grundlegenden Unterschied zwischen Unix (Linux) und Windows Server verstehen. Unix unterscheidet zwischen Groß- und Kleinschreibung und Windows unterscheidet nicht zwischen Groß- und Kleinschreibung.

Das HTTP-Protokoll wurde entwickelt oder begann um 1990 mit der Implementierung. Das HTTP-Protokoll wurde von Ingenieuren an CERN-Instituten entwickelt. Die meisten Wissenschaftler verwendeten damals Unix-Maschinen und nicht Windows.

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

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

Das könnte der Grund sein.

Wie sollte man ein "Warum wurde es so entworfen?" Frage? Fragen Sie nach einer historisch korrekten Darstellung des Entscheidungsprozesses oder nach der Frage "Warum sollte jemand das so gestalten?"?

Es ist sehr selten möglich, ein historisch korrektes Konto zu erhalten. Manchmal, wenn Entscheidungen in Normungsausschüssen getroffen werden, gibt es eine dokumentarische Spur, wie die Debatte geführt wurde, aber in den frühen Tagen der Internet-Entscheidungen wurden hastig von einigen Einzelpersonen getroffen - in diesem Fall wahrscheinlich von TimBL selbst - und die Begründung ist unwahrscheinlich aufgeschrieben worden sein. Aber TimBL hat 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 Anfängen wurden URLs sehr direkt Dateinamen zugeordnet, und die Dateien befanden sich im Allgemeinen auf Unix-ähnlichen Computern. Auf Unix-ähnlichen Computern wird zwischen Groß- und Kleinschreibung unterschieden. Ich vermute also, dass dies nur der Einfachheit halber passiert ist und die Benutzerfreundlichkeit (für Endbenutzer) nie in Betracht gezogen wurde. In den Anfängen waren die Benutzer sowieso alle Unix-Programmierer.

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

Dies ist nicht wirklich ein Problem und es ist ziemlich häufig auf * nix-Hosts. Stellen Sie einfach sicher, dass alle Links, die Sie auf Ihre Seiten schreiben, korrekt sind und Sie kein Problem haben. Um es einfacher zu machen, empfehle ich, Ihre Seiten immer in Kleinbuchstaben zu benennen, dann müssen Sie den Namen beim Schreiben eines Links nie noch einmal überprüfen.

Closetnoc hat recht mit dem Betriebssystem. Einige Dateisysteme behandeln denselben Namen mit unterschiedlicher Schreibweise als unterschiedliche Dateien.

Hat eine URL, bei der die Groß- und Kleinschreibung beachtet wird, auch einen echten Zweck / Vorteil (im Gegensatz zu den meisten URLs, die unabhängig von der Groß- und Kleinschreibung auf dieselbe Seite verweisen)?

Ja. um doppelte Inhalte zu vermeiden.

Wenn Sie zum Beispiel 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 sie alle zeigten auf genau dieselbe Seite mit genau demselben Inhalt, dann hätten Sie doppelten Inhalt, und ich bin sicher, wenn Sie ein Konto für die Google-Suchkonsole (Webmaster-Tools) haben, wird Google Ihnen dies anzeigen.

In diesem Fall würde ich vorschlagen, alle URLs in Kleinbuchstaben zu verwenden und dann die URLs mit mindestens einem Großbuchstaben in die Kleinbuchstabenversion umzuleiten. Leiten Sie in der obigen URL-Liste alle URLs zur ersten URL um.

Groß- / Kleinschreibung hat Wert.

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

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

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 26. Zum Speichern von Daten können die URLs kürzer sein und mehr Informationen können über Netzwerke mit weniger übertragenen Daten übertragen werden.

Aus diesem Grund wird YouTube unter Verwendung von URLs wie https://www.youtube.com/watch?v=xXxxXxxX angezeigt