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

54

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.

Kyle
quelle
11
Offensichtlich führen Sie IIS nicht unter Windows aus
John Conde
53
Ich stelle mir vor, dass itscrap.com, expertsexchange und whorepresents.com es vorziehen würden, dass mehr Menschen Namen verwenden, bei denen die Groß- und Kleinschreibung beachtet wird. Weitere Informationen finden Sie unter boredpanda.com/worst-domain-names .
Eric Towers
22
URLs wurden entwickelt, als Dinosaurier, die auf Unix-Systemen gerendert wurden, die Erde durchstreiften und bei Unix die Groß- und Kleinschreibung beachtet wurde.
Thorbjørn Ravn Andersen
11
Wikipedia versucht, die korrekte Groß- und Kleinschreibung für den Betreff zu verwenden, und verwendet Weiterleitungen für häufig auftretende Unterschiede. z.B. html, htmUnd Htmlalle umleiten zu HTML. Wichtig ist jedoch, dass aufgrund des enormen Themas mehr als eine Seite vorhanden sein kann, bei der die URL nur von Fall zu Fall unterschiedlich ist. Zum Beispiel: Latex und LaTeX
MrWhite
7
@ edc65 Kobi gibt jedoch an, dass bei Teilen der URL (insbesondere beim Pfad ) die Groß- und Kleinschreibung beachtet werden muss.
MrWhite

Antworten:

8

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.)

TOOGAM
quelle
"Ein Hauptgrund für das unterschiedliche Verhalten verschiedener Webbrowser ist wahrscheinlich die Einfachheit." - Ich nehme an, Sie meinen hier und an einigen anderen Orten "Webserver" und nicht "Webbrowser"?
MrWhite
2
Aktualisiert. Überprüfte jeden Fall von "Browsern" und ersetzte sie mehrfach. Vielen Dank, dass Sie darauf hingewiesen haben, damit die Qualität verbessert werden kann.
TOOGAM
1
Ich habe mehrere ausgezeichnete Antworten auf meine Frage erhalten, die von historisch bis technisch reichen. Ich zögere, gegen den Strich zu gehen und eine Antwort mit niedrigerer Bewertung zu akzeptieren, aber die Antwort von @ TOOGAM war für mich die hilfreichste. Diese Antwort ist gründlich und ausführlich, erklärt aber das Konzept auf eine unkomplizierte und verständliche Art und Weise. Und ich denke, diese Antwort ist eine gute Einführung in die tiefergehenden Erklärungen.
Kyle
74

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.)

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

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

Die Pfadkomponente enthält Daten ...

Die Abfragekomponente enthält nicht hierarchische Daten ...

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:

Kobi
quelle
1
"URLs unterscheiden nicht zwischen Groß- und Kleinschreibung." / "Der Rest der URL unterscheidet zwischen Groß- und Kleinschreibung." - Dies scheint ein Widerspruch zu sein?
MrWhite
8
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. Lange vor der Erfindung von URLs wurde bei DNS die Groß- und Kleinschreibung von ASCII nicht berücksichtigt. Siehe Seite 55 von ietf.org/rfc/rfc883.txt
O. Jones,
3
Schön detailliert! Ich ging aus historischer Sicht. Es war ursprünglich der Dateipfad, bei dem nur 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 Tagesperspektive ein. Ich musste deine Bemühungen belohnen !! Du hast dich wirklich in dieses eingegraben! Wer wusste, dass dies so explodieren würde? Prost!!
Closetnoc
2
@ w3dk: Es ist eine nicht sehr interessante Terminologie, aber man kann "Groß- und Kleinschreibung beachten", "die Groß- und Kleinschreibung eines Zeichens ändern" oder "die Groß- und Kleinschreibung ändern" Bei einem Zeichen ändert sich immer das Ganze ". Kobi scheint letzteres zu behaupten, er zieht es vor, dass Groß- und Kleinschreibung "jede Änderung in Groß- und Kleinschreibung ist signifikant" bedeuten sollte, was natürlich nicht für URLs gilt. Sie bevorzugen den ersteren. Es ist nur eine Frage, wie sensibel sie für die Groß- und Kleinschreibung sind.
Steve Jessop
2
@ rybo111: Wenn ein Benutzer example.com/fOObaR eingibt , erfordert die Spezifikation, dass der Server unter www.example.com den angegebenen Pfad "/ fOObaR" erhält. es ist still über die frage, ob der server das anders behandeln muss als "/ foOBaR".
Supercat
59

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.

closetnoc
quelle
1
Ich denke, Ihr Argument ist fehlerhaft. Während Berners-Lee keine Wahl hatte, was die Groß- und Kleinschreibung von FTP-URLs anbelangt. Er muss 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 weitergegeben haben, waren sie unsicher und die Einführung der URL-Codierung hat die Kompatibilität mit ihnen beeinträchtigt. Angesichts der Tatsache, dass der Pfad verarbeitet wird, bevor er an den OS-Smashing-Fall übergeben wird, wäre die Implementierung einfach gewesen. Daher denke ich, dass wir dies als Entwurfsentscheidung und nicht als Umsetzungskompromiss betrachten müssen.
William Hay
@WilliamHay Das 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 Systeminternalingenieur. Ich habe damals an diesen Systemen gearbeitet. Ich sage Ihnen genau, warum bei URLs zwischen Groß- und Kleinschreibung unterschieden wird. 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 dadurch teilweise noch bis heute unsicher.
closetnoc
Ob bei URLs zwischen Groß- und Kleinschreibung unterschieden wird, hat nichts mit dem Design des Webs zu tun? "Ja wirklich?" Argument von Behörde gefolgt von Argument von Behauptung. Dass Webserver die Pfadkomponente einer URL mehr oder weniger direkt an einen offenen Aufruf weitergeben, ist eine Folge der Gestaltung von URLs, nicht eine Ursache dafür. Server (oder Smart Clients bei FTP) haben möglicherweise die Groß- und Kleinschreibung von Dateisystemen vor dem Benutzer verborgen. Dass dies nicht der Fall ist, ist eine Designentscheidung.
William Hay
@WilliamHay Sie müssen den Grasbehälter verlangsamen und noch einmal lesen, was ich geschrieben habe. Ich bin ein pensionierter Ingenieur für Systeminterna, der Betriebssystemkomponenten, Protokollstapel und Router-Code für das ARPA-Net usw. schreibt. Ich habe mit Interna von Apache, O'Reilly und IIS gearbeitet. Ihr FTP-Argument enthält kein Wasser, da zumindest die wichtigsten FTP-Server aus demselben Grund die Groß- und Kleinschreibung berücksichtigen. Zu keinem Zeitpunkt habe ich etwas über das Design von URL / URI gesagt. Zu keinem Zeitpunkt habe ich angegeben, dass Webserver Werte ohne Verarbeitung übergeben haben. Ich habe gesagt, dass OS-Dienste häufig verwendet werden und dass das Dateisystem eine genaue Übereinstimmung erfordert, um erfolgreich zu sein.
Closetnoc
@WilliamHay Bitte haben Sie Verständnis dafür, dass Sie und ich gegenseitig überlegen. Alles, was ich in meiner Antwort gesagt habe, ist, dass bei einigen Betriebssystemen bei Dateisystemaufrufen die Groß- und Kleinschreibung berücksichtigt wird. Anwendungen, die Systemaufrufe verwenden, und die meisten von ihnen, beschränken sich auf die Durchsetzung der Betriebssystemregeln - in diesem Fall auf die Berücksichtigung der Groß- und Kleinschreibung. Es ist nicht unmöglich, diese Regel zu umgehen. In der Tat kann dies in einigen Fällen etwas trivial sein, wenn auch nicht praktikabel. Ich habe das Dateisystem in meiner Arbeit routinemäßig umgangen, um Festplatten zu entwirren, die aus dem einen oder anderen Grund kablooie wurden, oder um Interna von Datenbankdateien usw. zu analysieren
closetnoc
21
  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.

William Hay
quelle
1
Ich bin mir ziemlich sicher, dass URLs historisch auf ASCII beschränkt waren. Die Internationalisierung dürfte also kein ursprünglicher Grund sein. Die Geschichte der Groß- und Kleinschreibung unter Unix, OTOH, spielte wahrscheinlich eine große Rolle.
Derobert
Während nur eine Teilmenge von ASCII in einer URL unverschlüsselt verwendet werden kann, gibt RFC1738 an, dass Zeichen außerhalb des ASCII-Bereichs verschlüsselt verwendet werden dürfen. Ohne Angabe eines Zeichensatzes ist es nicht möglich zu wissen, welche Oktette mit Ausnahme von Groß- und Kleinschreibung dasselbe Zeichen darstellen. Aktualisiert.
William Hay
1
Zu 4: Es ist tatsächlich schlimmer. Gepunktet und ohne Punkte Ich bin eine Demonstration des allgemeineren Prinzips, dass Sie, auch wenn alles UTF-8 (oder ein anderes UTF) ist, keine Groß- oder Kleinschreibung vornehmen 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 umgewandelt, der auf Türkisch falsch ist, weil er einen Punkt hinzufügt (es gibt keinen Codepunkt "Türkisch ohne Punkt"; Sie müssen den ASCII-Code verwenden Punkt). Codierungsunterschiede einwerfen, und das geht von "sehr schwer" bis "völlig unlösbar".
Kevin
5

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?

Dewi Morgan
quelle
1
Einige Sites verwenden einen Mechanismus, um Abfragen in Kleinbuchstaben oder in etwas Konsistentes umzuwandeln. In gewisser Weise ist das klug.
Closetnoc
Nein, das sollten sie nicht. Diese Funktionalität kann und wird häufig hinzugefügt, wenn dies erwünscht ist (z. B. durch Module in Apache). Eine solche Änderung als Standardverhalten - oder schlimmer noch: unveränderliches Verhalten - wäre störender als das relativ seltene Verhalten Gelegenheit, in der jemand eine URL jenseits des Hostnamens manuell eingeben muss. Wenn Sie ein gutes Beispiel dafür suchen, warum Sie dies nicht tun sollten, erinnern Sie sich an das Fiasko, als Network Solutions nicht vorhandene Domänenfehler aus öffentlichen DNS-Abfragen "behoben" hat.
SirNickity
@SirNickity Niemand hat Unveränderlichkeit auf irgendeiner Ebene vorgeschlagen und Webserver-Fehlerseiten sind auf jedem Webserver konfigurierbar, den ich jemals benutzt habe. niemand schlug vor, 404 durch 30 * -Codes zu ersetzen, sondern eine Liste von durch den Menschen anklickbaren Vorschlagslinks zur Fehlerseite 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 "repariert" bereits automatisch (durch Ignorieren) Groß- und Kleinschreibung im Pfad oder in den Dateinamen von URIs.
Dewi Morgan
Seit 1996 lässt Apache dies mit mod_speling zu . Es scheint einfach nicht sehr beliebt zu sein. Unter Unix / Linux wird die Groß- und Kleinschreibung als die Regel und die Groß- und Kleinschreibung als die Ausnahme angesehen.
Reinierpost
4

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.

Mani
quelle
2
"Windows Server wurde nach 2000 veröffentlicht." Das Windows NT 3.1- Team wäre 1993 nicht mit Ihnen einverstanden gewesen. NT 3.51 war 1995 wahrscheinlich der Zeitpunkt, an dem NT ausgereift und etabliert genug wurde, um geschäftskritische Serveranwendungen zu unterstützen.
ein Lebenslauf
NT 3.51 hatte die Win 3.1-Schnittstelle. Windows startete erst wirklich, als Windows 95 und NT 4.0 die gleiche Schnittstelle benötigten.
Thorbjørn Ravn Andersen
Michael Kjörling war einverstanden. Lass es mich modifizieren.
Mani
1
@ ThorbjørnRavnAndersen Auf dem Servermarkt war NT 3.51 einigermaßen erfolgreich. Im Consumer- / Prosumer-Markt dauerte es bis zu Windows 2000 (NT 5.0), bis die NT-Linie ernsthafte Fortschritte erzielte.
ein Lebenslauf
Das WorldWideWeb wurde ursprünglich auf Unix-basierten Systemen entwickelt, bei denen zwischen Groß- und Kleinschreibung unterschieden wird und die meisten URLs direkt auf Dateien im Dateisystem abgebildet werden.
Reinierpost
4

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.

Michael Kay
quelle
Die Endbenutzer waren ebenfalls Unix-Benutzer (nicht unbedingt Programmierer, aber Hochenergiephysiker und dergleichen), und daher waren auch sie daran gewöhnt, die Groß- und Kleinschreibung nicht zu berücksichtigen.
Reinierpost
3

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.

adnan3344
quelle
2

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.

Mike
quelle
"Ja. Um doppelte Inhalte zu vermeiden." - Aber das Gegenteil scheint wahr zu sein? Die Tatsache, dass bei URLs zwischen Groß- und Kleinschreibung unterschieden werden kann (und Suchmaschinen behandeln sie auf diese Weise), führt zu den von Ihnen erwähnten Problemen mit doppeltem Inhalt. Wenn bei URLs die Groß- und Kleinschreibung nicht berücksichtigt würde, gäbe es keine doppelten Inhaltsprobleme mit unterschiedlichen Groß- und Kleinschreibungen. page-1wäre das gleiche wie PAGE-1.
MrWhite
Ich denke, eine schlechte Serverkonfiguration kann zu doppelten Inhalten führen, wenn es um Gehäuse geht. Zum Beispiel RewriteRule ^request-uri$ /targetscript.php [NC]würde die in .htaccess gespeicherte Anweisung übereinstimmen, http://example.com/request-uriund http://example.com/ReQuEsT-Uriweil dies [NC]anzeigt, dass die Groß- / Kleinschreibung bei der Auswertung dieses einen regulären Ausdrucks keine Rolle spielt.
Mike
1

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

Michael d
quelle