Hvorfor er nettadresser store og små bokstaver?

Hvorfor ville ikke t URL-en være mellom store og små bokstaver?

Jeg forstår at det kan se ut som en provoserende (og «djevelens talsmann») type retorisk spørsmål, men jeg synes det er nyttig å vurdere. Utformingen av HTTP er at en «klient», som vi ofte kaller en «nettleser», ber «webserveren» om data.

Det er mange, mange forskjellige webservere som frigjøres. Microsoft har gitt ut IIS med Windows Serveroperativsystemer (og andre, inkludert Windows XP Professional). Unix har tungvektere som nginx og Apache, for ikke å nevne mindre tilbud som OpenBSDs interne httpd, eller thttpd eller lighttpd. I tillegg har mange nettverkskompatible enheter innebygd webservere som kan brukes til å konfigurere enheten, inkludert enheter med formål som er spesifikke for nettverk, som rutere (inkludert mange Wi-Fi-tilgangspunkter og DSL-modemer) og andre enheter som skrivere eller UPS-er (batteristøttede avbruddsfrie strømforsyningsenheter) som kan ha nettverkstilkobling.

Så spørsmålet «Hvorfor er URL-er store og små bokstaver?», Spør: «Hvorfor behandler webserverne URL-en som å være mellom store og små bokstaver? » Og det faktiske svaret er: de gjør ikke alle det. Minst en webserver, som er ganske populær, er vanligvis IKKE skiftesensitiv. (Webserveren er IIS.)

En viktig årsak til forskjellig oppførsel mellom forskjellige webservere kommer sannsynligvis ned til et spørsmål om enkelhet. Den enkle måten å lage en webserver på er å gjøre ting på samme måte som hvordan datamaskinen / enhetens operativsystem finner filer. Mange ganger finner webservere en fil for å gi et svar. Unix ble designet rundt datamaskiner av høyere enden, og derfor ga Unix den ønskelige funksjonaliteten for å tillate store og små bokstaver. Unix bestemte seg for å behandle store og små bokstaver som forskjellige fordi de er forskjellige. Det er den enkle, naturlige tingen å gjøre. Windows har en historie som store og små bokstaver på grunn av et ønske om å støtte allerede opprettet programvare, og denne historikken går tilbake til DOS som ganske enkelt ikke støttet små bokstaver, muligens i et forsøk for å forenkle ting med mindre kraftige datamaskiner som brukte mindre minne. Siden disse operativsystemene er forskjellige, blir resultatet at enkelt utformede (tidlige versjoner av) webservere gjenspeiler de samme forskjellene.

Nå, med alt det bakgrunn, her er noen spesifikke svar på de spesifikke spørsmålene:

Når nettadresser ble designet, hvorfor ble store bokstaver til en funksjon?

Hvorfor ikke? Hvis alle vanlige webservere var uten store og små bokstaver, ville det indikere at webserverne fulgte et sett med regler spesifisert av standarden. Det var rett og slett ingen regel som sier at saken må ignoreres. Årsaken til at det ikke er noen regel er ganske enkelt at det ikke var noen grunn til det skal være en slik regel. Hvorfor gidder å gjøre opp unødvendige regler?

Jeg spør dette fordi det ser ut til meg (dvs., en lekmann) at store og små bokstaver ville være å foretrekke for å forhindre unødvendige feil og forenkle en allerede komplisert tekststreng.

URL-er ble designet for maskiner å behandle . Selv om en person kan skrive en full URL i en adresselinje, var det ikke en stor del av den tiltenkte designen. Den tiltenkte designen er at folk vil følge («klikk på») hyperkoblinger. Hvis gjennomsnittlige lekere gjør det, så bryr deg ikke om den usynlige nettadressen er enkel eller komplisert.

Er det også et reelt formål / fordel med å ha en saksfølsom URL (som i motsetning til det store flertallet av nettadresser som peker til samme side, uansett om du bruker store bokstaver)?

Det femte nummererte punktet til William Hays svar nevner en teknisk fordel: URL-er kan være en effektiv måte for en nettleser å sende litt informasjon til en webserver, og mer informasjon kan inkluderes hvis det er mindre begrensninger, så en begrensning i saksfølsomhet vil redusere hvor mye informasjon som kan inkluderes.

I mange tilfeller er det imidlertid ikke en veldig overbevisende fordel for saksfølsomhet, som er bevist av det faktum at IIS vanligvis ikke bryr seg med det.

Oppsummert er den mest overbevisende årsaken sannsynligvis bare enkelhet for de som designet webserverprogramvaren, spesielt på en saksfølsom plattform som Unix . (HTTP var ikke noe som påvirket den opprinnelige utformingen av Unix, siden Unix er spesielt eldre enn HTTP.)

Kommentarer

• » En nøkkelårsak til ulik oppførsel mellom forskjellige nettlesere koker sannsynligvis til et spørsmål om enkelhet. » betyr » webservere «, i stedet for » nettlesere » her og et par andre steder?
• Oppdatert. Gjennomgått hvert tilfelle av » nettlesere » og gjort flere erstatninger. Takk for at du påpekte dette slik at noe av kvaliteten kan forbedres.
• Jeg har mottatt flere gode svar på spørsmålet mitt, alt fra det historiske til Det tekniske. Jeg er nølende med å gå mot kornet og akseptere et lavere rangert svar, men @TOOGAM ‘ svaret var det mest nyttige for meg. Dette svaret er grundig og omfattende, men det forklarer konseptet på en ukomplisert, samtalemåte som jeg kan forstå. Og jeg synes dette svaret er en god introduksjon til de mer inngående forklaringene.
• Årsaken til at Windows har et skiftesensitivt filsystem, skyldes at det ‘ s DOS arv. MS-DOS startet livet på datamaskiner som Tandy TRS-80, som brukte en TV som skjerm, og støttet ikke opprinnelig små bokstaver på grunn av manglende oppløsning. Siden det ikke kunne ‘ t vise små bokstaver, ble ikke blandet versjon ‘ støttet. MS-DOS ble lisensiert av IBM til å bli den originale PC-DOS. Mens den opprinnelige PC-en kunne vise små bokstaver, ble filsystemet overført som det er fra MS-DOS.

URL-er er ikke store og små bokstaver, bare deler av dem.
Ingenting er for eksempel store og små bokstaver i URL-en https://google.com,

Med referanse til RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax

Først fra Wikipedia , en URL ser ut som:

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

(Jeg har fjernet user:password del fordi det ikke er interessant og sjelden brukes)

• scheme :

ordninger er ikke store og små bokstaver

• host :

Vertsunderkomponenten er uten store og små bokstaver.

• path :

Banekomponenten inneholder data …

• query :

Spørringskomponenten inneholder ikke-hierarkiske data …

• fragment :

Individuelle medietyper kan definere sine egne begrensninger på eller strukturer i fragmentidentifikatorens syntaks for å spesifisere forskjellige typer delsett, visninger eller eksterne referanser

Så, scheme og host er ikke store og små bokstaver.
Resten av URL-en er mellom store og små bokstaver.

Hvorfor er path store og små bokstaver?

Dette ser ut til å være hovedspørsmålet.
Det er vanskelig å svare på «hvorfor» noe ble gjort hvis det ikke ble dokumentert, men vi kan gi et veldig godt gjetning.
Jeg har plukket veldig spesifikke sitater fra spesifikasjonen, med vekt på data .
La oss se på nettadressen igjen:

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

• Plassering – Plasseringen har en kanonisk form og er uten store og små bokstaver. Hvorfor? Sannsynligvis slik at du kunne kjøpe et domenenavn uten å måtte kjøpe tusenvis av varianter.

• Data – dataene brukes som brukes av målserver, og applikasjonen kan velge hva det betyr . Det ville ikke ha noen mening å gjøre store og små bokstaver for data. Applikasjonen burde ha flere muligheter, og definering av store og små bokstaver i spesifikasjonen vil begrense disse alternativene.
  Dette er også et nyttig skille for HTTPS: dataene er kryptert , men verten er synlig.

Er det nyttig?

Sak- følsomhet har sine fallgruver når det gjelder caching og kanoniske nettadresser, men det er absolutt nyttig. Noen eksempler:

• Base64 , som brukes i Data-URI-er .
• Nettsteder kan kode Base64-data i url, for eksempel: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL-forkortere bruker store bokstaver: /a5B kan være annerledes enn /a5b
• Som du har nevnt, kan Wikipedia skille «AIDS» fra «Aids».

Kommentarer

• » URL-er er ikke tilfelle e-sensitiv. » / » Resten av URL-en er mellom store og små bokstaver. » – Dette ser ut til å være en motsigelse?
• I sannhet definerer ordningen hva du kan forvente i resten av URL-en. http: og relaterte ordninger betyr at URL-adressen refererer til et DNS-vertsnavn. DNS var ASCII uavhengig av store og små bokstaver lenge før oppfinnelsen av nettadresser. Se side 55 i ietf.org/rfc/rfc883.txt
• Pent detaljert! Jeg gikk fra et historisk synspunkt. Det var opprinnelig filstien som bare måtte skille mellom store og små bokstaver hvis du traff filsystemet. Ellers var det ikke. Men i dag har ting endret seg. For eksempel eksisterte ikke parametere og CGI opprinnelig. Svaret ditt tar et dags perspektiv. Jeg måtte belønne innsatsen din !! Du gravde deg virkelig inn på denne! Hvem visste at dette ville sprenge slik det gjorde ?? Skål !!
• @ w3dk: det ‘ er en ikke veldig interessant terminologi, men du kan ta » store og små bokstaver » for å bety, » endring av store og små bokstaver kan endre hele «, eller du kan forstå det, » endring av tegn på endrer alltid hele «. Kobi ser ut til å hevde sistnevnte, han foretrekker at store og små bokstaver bør bety » enhver endring i saken er betydelig «, noe som selvfølgelig gjelder ikke nettadresser. Du foretrekker førstnevnte. Det ‘ er bare et spørsmål om hvor følsomme de er for store og små bokstaver.
• @ rybo111: Hvis en bruker skriver eksempel.com/fOObaR , spesifikasjonen krever at serveren på www.example.com mottar en bane » / fOObaR » som gitt; det er stille om spørsmålet om serveren må behandle det på en annen måte enn » / foOBaR «.

Enkelt. Operativsystemet er skiftende mellom store og små bokstaver. Webservere bryr seg vanligvis ikke med mindre de må treffe filsystemet på et tidspunkt. Dette er hvor Linux og andre Unix-baserte operativsystemer håndhever reglene for filsystemet, i hvilket tilfelle følsomhet er en viktig del. Dette er grunnen til at IIS aldri har vært store og små bokstaver; fordi Windows aldri var mellom store og små bokstaver.

[Oppdater]

Det har vært noen sterke argumenter i kommentarene (siden slettet) om URL-adresser har noe forhold til filsystemet slik jeg har uttalt. Disse argumentene har blitt opphetede. Det er ekstremt kortsiktig å tro at det ikke er et forhold. Det er absolutt! La meg forklare videre.

Applikasjonsprogrammerere er vanligvis ikke systeminterne programmerere. Jeg er ikke fornærmende. De er to separate disipliner, og systeminnvendinger er ikke nødvendig for å skrive applikasjoner når applikasjoner bare kan ringe til operativsystemet. Siden applikasjonsprogrammerere ikke er systeminterne programmerere, er det ikke mulig å omgå OS-tjenestene.Jeg sier dette fordi dette er to separate leirer og sjelden krysser over. Applikasjoner er skrevet for å bruke OS-tjenester som regel. Det er sjelden noen unntak selvfølgelig.

Tilbake da webservere begynte å vises, forsøkte ikke programutviklere å omgå OS-tjenester. Det var flere grunner til dette. En, det var ikke nødvendig. To, applikasjonsprogrammerere visste generelt ikke hvordan de skulle omgå OS-tjenester. Tre, de fleste operativsystemer var enten ekstremt stabile og robuste, eller ekstremt enkle og lette og ikke verdt prisen.

Husk at de tidlige webserverne enten kjørte på dyre datamaskiner som DEC VAX / VMS-servere og Unix of the Day (Berkeley og Ultrix så vel som andre) på hovedramme- eller midtrammedatamaskiner, så kort tid etter på lette datamaskiner som PCer og Windows 3.1. Da mer moderne søkemotorer begynte å dukke opp, som for eksempel Google i 1997/8, hadde Windows flyttet inn i Windows NT og andre operativsystemer som Novell og Linux hadde også begynt å kjøre webservere. Apache var den dominerende webserveren, selv om det var andre som IIS og O «Reilly som også var veldig populære. Ingen av dem gikk den gang utenom OS-tjenester. Det er sannsynlig at ingen av webserverne gjør det i dag.

Tidlige webservere var ganske enkle. De er fortsatt i dag. Enhver forespørsel om en ressurs via en HTTP-forespørsel som eksisterer på en harddisk, er / blir gjort av webserveren via OS-filsystemet.

Filsystemer er ganske enkle mekanismer. Ettersom det blir bedt om tilgang til en fil, hvis filen eksisterer, sendes forespørselen til autorisasjonssystemet, og hvis den blir gitt, blir den opprinnelige forespørselen oppfylt. ikke eksisterer eller ikke er autorisert, blir et unntak kastet av systemet. Når en applikasjon gjør en forespørsel, settes en utløser og applikasjonen venter. Når forespørselen blir besvart, kastes utløseren og applikasjonen behandler forespørselssvaret. fungerer fortsatt slik i dag. Hvis søknaden ser at forespørselen har blitt s atisfied fortsetter det, hvis det mislykkes, utfører applikasjonen en feiltilstand i koden eller dør hvis den ikke håndteres. Enkelt.

Når det gjelder en webserver, forutsatt at det blir laget en URL-forespørsel for en bane / fil, tar webserveren stien / fildelen av URL-forespørselen (URI) og sender en forespørsel til filsystemet, og det er enten fornøyd eller kaster et unntak. Webserveren behandler deretter svaret. Hvis for eksempel stien og filen som er forespurt blir funnet og tilgang gitt av autorisasjonssystemet, behandler webserveren den I / O-forespørselen som vanlig. Hvis filsystemet kaster et unntak, returnerer webserveren en 404-feil hvis filen ikke blir funnet eller en 403 forbudt hvis årsakskoden er uautorisert.

Siden noen operativsystemer er store og små bokstaver og filsystemer til denne typen krever nøyaktige samsvar, banen / filen som blir bedt om av webserveren, må samsvare med det som finnes på harddisken nøyaktig. Årsaken til dette er enkel. Webservere gjetter ikke hva du mener. Ingen datamaskiner gjør det uten å være programmert til. Webservere behandler bare forespørsler når de mottar dem. Hvis stien / fildelen av URL-forespørselen som sendes direkte til filsystemet ikke samsvarer med hva som er på harddisken, kaster filsystemet et unntak, og webserveren returnerer en 404 Not Found-feil.

Det er virkelig så enkle folkens. Det er ikke rakettvitenskap. Det er en absolutt sammenheng mellom banen / fildelen til en URL og filsystemet.

Kommentarer

• Jeg synes argumentet ditt er feil. Mens Berners-Lee ikke hadde ‘ t noe valg om saksfølsomhet for ftp URL-er. Han måtte designe http URL-er. Han kunne ha spesifisert dem som bare US-ASCII og ikke store og små bokstaver. Hvis det noen gang var noen webservere som nettopp passerte URL-banen til filsystemet, var de usikre, og innføringen av URL-koding brøt kompatibiliteten med dem. Gitt at banen blir behandlet før overlevering til OS-smashing-saken, ville det vært enkelt å implementere. Derfor tror jeg at vi må se på dette som en designbeslutning, ikke en implementeringsbesvær.
• @WilliamHay Dette har ingenting å gjøre med Berners-Lee eller utformingen av nettet. Det handler om begrensninger og krav til operativsystemet. Jeg er en pensjonert systemingeniør. Jeg jobbet med disse systemene på den tiden. Jeg forteller deg nøyaktig hvorfor nettadresser er mellom store og små bokstaver. Det er ikke en gjetning. Det er ikke en mening. Det er fakta. Svaret mitt var med vilje forenklet. Selvfølgelig er det filkontroller og andre prosesser som kan gjøres før du gir ut en åpen uttalelse. Og Ja (!) Webservere er delvis usikre frem til i dag som et resultat.
• Hvorvidt nettadresser er store og små bokstaver, har ikke noe å gjøre med utformingen av nettet? Egentlig? Argument fra autoritet etterfulgt av argument ved påstand.At webservere sender banekomponenten til en URL mer eller mindre direkte til en åpen samtale er en konsekvens av at utformingen av URL-er ikke er en årsak til det. Servere (eller smarte klienter i tilfelle FTP) kunne ha skjult saksfølsomheten til filsystemer for brukeren. At de ikke ‘ t er en designbeslutning.
• @WilliamHay Du må bremse gressbeholderen og lese det jeg har skrevet på nytt. Jeg er pensjonert systemintern ingeniør som skriver OS-komponenter, protokollstabler og ruterkode for ARPA-Net osv. Jeg jobbet med Apache, O ‘ Reilly og IIS internals. FTP-argumentet ditt holder ikke vann, da i det minste de viktigste FTP-serverne forblir skiftesensitive av samme grunn. På ingen tid sa jeg noe om design av URL / URI. På ingen tid sa jeg at webservere passerte verdier uten behandling. Jeg sa at OS-tjenester ofte brukes, og at filsystemet krever nøyaktig samsvar for å lykkes.
• @WilliamHay Vær så snill å forstå at du og jeg tenker på tvers. Alt jeg sa i svaret mitt er at for noen operativsystemer er filsystemanrop store og små bokstaver av design. Programmer som bruker systemanrop, og de fleste gjør, er begrenset til håndhevelse av OS-reglene – i dette tilfellet saksfølsomhet. Det er ikke umulig å omgå denne regelen. Dette kan faktisk være noe trivielt i noen tilfeller, men ikke praktisk. Jeg pleide rutinemessig å omgå filsystemet i arbeidet mitt for å fjerne koding av harddisker som gikk av kablooie av en eller annen grunn eller for å analysere interne databasefiler osv.

1. URL-er hevder å være en UNIFORM ressurssøker og kan peke på ressurser som er forut for nettet. Noen av disse er store og små bokstaver (f.eks. Mange ftp-servere), og nettadresser må kunne representere disse ressursene på en rimelig intuitiv måte.

2. Saksfølsomhet krever mer arbeid når du leter etter en kamp (enten i operativsystemet eller over det).

3. Hvis du definerer nettadresser som store og små bokstaver, kan individuelle servere implementere dem som store og små bokstaver hvis de vil. Det motsatte er ikke sant.

4. Saksfølsomhet kan være lite triviell i internasjonale sammenhenger: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Også RFC1738 tillot bruk av tegn utenfor ASCII-området, forutsatt at de var kodet, men ikke spesifiserte et tegnsett. Dette er ganske viktig for noe som kaller seg verdensnettet. Å definere nettadresser som store og små bokstaver ville åpne for mye rom for bugs.

5. Hvis du prøver å pakke mye data i en URI (f.eks. en Data URI ) du kan pakke mer hvis store og små bokstaver er forskjellige.

Kommentarer

• I ‘ Jeg er ganske sikker på at nettadresser historisk sett var begrenset til ASCII. Så internasjonalisering er neppe en original årsak. Historien om at Unix var store og små bokstaver, OTOH, spilte sannsynligvis en enorm rolle.
• Selv om bare en delmengde av ASCII kan brukes ukodet i en URL, angir RFC1738 spesifikt at tegn utenfor ASCII-området kan brukes kodet. Uten å spesifisere et tegnsett er det ikke ‘ ikke mulig å vite hvilke oktetter representerer samme røye handling bortsett fra tilfelle. Oppdatert.
• Re # 4: Det ‘ er faktisk verre enn det. Prikket og prikkfritt Jeg er en demonstrasjon av det mer generelle prinsippet om at selv om alt er UTF-8 (eller noe annet UTF), kan du ikke bruke store eller små bokstaver riktig uten å vite lokaliteten som teksten tilhører . I standardområdet er en stor latinsk bokstav I med små bokstaver i, som er galt på tyrkisk fordi den legger til en prikk (det er ingen » Tyrkisk hovedstad punktfri I » kodepunkt; du ‘ er ment å bruke ASCII-kodepunktet). Kast inn kodingsforskjeller, og dette går fra » veldig hardt » til » helt ukomplisert . »

Jeg stjal fra bloggen en Gammel ny ting vanen med å nærme seg spørsmål ved skjemaet «hvorfor er det noe som er tilfelle?» med motspørsmålet «hvordan ville verden vært, hvis det ikke var tilfelle?» telefonen da jeg var ute på kontoret. Nå, i dokumentmappen min, har jeg tre filer, todo.txt, ToDo.txt og TODO.TXT (Jeg vet, men det var fornuftig for meg da jeg laget filene).

Hvilken URL vil jeg kunne bruke, for å få tilgang til disse filene? Jeg ønsker å få tilgang til dem på en intuitiv måte ved å bruke http://www.example.com/docs/filename.

Si at jeg har et skript som lar meg legge til en kontakt i adresseboken min, som jeg kan gjør det også på nettet.Hvordan skal det ta parametrene? Vel, jeg vil gjerne bruke den som: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Men hvis det ikke var noen måte for meg å spesifisere navnet etter sak, hvordan ville jeg gjøre det?

Hvordan vil jeg skille mellom wikisidene for Cat og CAT, Text og TEXT, latex og LaTeX? Ufattelige sider antar jeg, men jeg foretrekker bare å få det jeg ba om.

Men alt som føles liker at det svarer på feil spørsmål, uansett.

Spørsmålet jeg tror du virkelig stilte er «Hvorfor gjør webservere 404 deg bare for en saksforskjell, når de er datamaskiner, designet for å gjøre livet enklere , og de er i stand til å finne i det minste de mest åpenbare tilfellevariasjonene i nettadressen jeg skrev som ville fungere? » se etter andre skrivefeil også), ingen syntes det var verdt å endre en webservers standard 404-feilside for å gjøre det … men kanskje de burde gjøre det?

Kommentarer

• Noen nettsteder bruker en slags mekanisme for å konvertere en ny spørring til alle små bokstaver eller noe konsistent. På en måte er dette smart.
• Nei, de burde ikke ‘ t. Denne funksjonaliteten kan, og blir ofte lagt til, når det er ønskelig (f.eks. Av moduler i apache.) Å pålegge denne typen endringer som standard atferd – eller verre, uforanderlig oppførsel – ville være mer forstyrrende enn den relativt sjeldne anledning der noen må skrive inn en URL utover vertsnavnet manuelt. For et godt eksempel på hvorfor ikke gjøre dette, husk fiaskoen når Network Solutions » fikset » ikke-eksisterende domenefeil fra offentlig DNS spørsmål.
• @SirNickity Ingen foreslo uforanderlighet på noe nivå, og webserverfeilsider kan konfigureres på hver webserver jeg ‘ noen gang har brukt; ingen foreslo å erstatte 404 med 30 * koder, men heller legge til en liste over menneskeklikkbare forslagslinker til feilsiden; domenenavn er et veldig annet tema og spørsmål som ikke skiller mellom store og små bokstaver, og i en annen sikkerhetskontekst; og IIS fikser allerede » » (ved å ignorere) saksforskjeller i banen eller filnavnene til URI-er.
• Siden 1996 har Apache latt deg gjøre dette med mod_speling . Det synes bare ikke ‘ å være en veldig populær ting å gjøre. Unix / Linux-personer ser på sakfølsomhet som regel, uten sakstilstand som unntak.

Selv om svaret ovenfor er riktig & bra. Jeg vil gjerne legge til noen flere poeng.

For å forstå bedre, bør man forstå den grunnleggende forskjellen mellom Unix (Linux) Vs Windows-server. Unix er mellom store og små bokstaver & Windows er ikke store og små bokstaver.

HTTP-protokollen ble utviklet eller begynte å implementeres rundt 1990. HTTP-protokollen ble designet av ingeniører som jobber på CERN-institutter, de fleste av de dagene forskere brukte Unix-maskiner og ikke Windows.

De fleste forskere var kjent med Unix, så de kan ha blitt påvirket av Unix-stilfilsystemet.

Windows-server ble utgitt etter 2000. mye før windows-server ble populær HTTP-protokoll var godt modnet og spesifikasjonen var komplett.

Dette kan være grunnen.

Kommentarer

• » Windows-serveren ble utgitt etter 2000. » Windows NT 3.1 teamet ville ha vært uenig med deg i 1993. NT 3.51 i 1995 var sannsynligvis da NT begynte å bli moden og veletablert nok til å støtte virksomhetskritiske serverapplikasjoner.
• NT 3.51 hadde Win 3.1-grensesnittet. Windows tok ikke av før Windows 95, og det tok NT 4.0 å få samme grensesnitt.
• Michael Kj ö rling, enig. La meg endre det.
• @Thorbj ø rnRavnAndersen I servermarkedet var NT 3.51 rimelig vellykket. I forbruker- / prosumermarkedet tok det helt til Windows 2000 (NT 5.0) før NT-linjen begynte å få alvorlig grep.
• WorldWideWeb ble faktisk opprinnelig utviklet på Unix-baserte systemer, som har store og små bokstaver filsystemer, og de fleste URL-er kartlagt direkte til filer i filsystemet.

Hvordan skal man lese en «hvorfor ble den designet på denne måten?» spørsmål? Ber du om en historisk nøyaktig redegjørelse for beslutningsprosessen, eller spør du «hvorfor skulle noen utforme det på denne måten?»?

Det er svært sjelden mulig å få en historisk nøyaktig regnskap.Noen ganger når beslutninger tas i standardkomiteer, er det en dokumentarisk oversikt over hvordan debatten ble ført, men i de tidlige dagene av nettet ble beslutninger tatt raskt av noen få individer – i dette tilfellet sannsynligvis av TimBL selv – og begrunnelsen er usannsynlig. å ha blitt skrevet ned. Men TimBL har innrømmet at han gjorde feil i utformingen av nettadresser – se http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

I de første dagene ble URL-er kartlagt veldig direkte til filnavn, og filene var vanligvis på Unix-lignende maskiner, og Unix-lignende maskiner har store og små bokstaver. Så jeg antar at det nettopp skjedde på den måten for implementeringskomfort, og brukervennlighet (for sluttbrukere) ble aldri engang vurdert. Igjen, i de tidlige dagene var brukerne alle Unix-programmerere uansett.

Kommentarer

• Sluttbrukere var også Unix-brukere (ikke nødvendigvis programmerere, men høyenergifysikere og lignende), så de var også vant til ufølsomhet i store og små bokstaver.

Dette har ingenting å gjøre med hvor du kjøpte domenet ditt, DNS er ikke mellom store og små bokstaver. Men filsystemet på serveren du bruker for hosting er.

Dette er egentlig ikke et problem, og det er ganske vanlig på * nix-verter. Bare vær sikker på at alle lenkene du skriver på sidene dine er korrekte, og at du ikke har et problem. For å gjøre det lettere, anbefaler jeg alltid å navngi sidene i små bokstaver, så du trenger aldri å dobbeltsjekke navnet når du skriver en lenke.

Closetnoc har rett i operativsystemet. Noen filsystemer behandler samme navn med forskjellige hylser som forskjellige filer.

Er det også et reelt formål / fordel med å ha en sakssensitiv URL (i motsetning til de aller fleste nettadresser som peker til samme side uansett store bokstaver)?

Ja. for å unngå dupliserte innholdsproblemer.

Hvis du for eksempel hadde følgende nettadresser:

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 

og de pekte alle på nøyaktig samme side med nøyaktig samme innhold, så ville du ha duplikatinnhold, og jeg er sikker på at hvis du har en Google-søkekonsoll (kontoansvarlig for nettredaktører), vil Google indikere dette for deg.

Hva jeg vil Jeg foreslår at du bruker alle små bokstaver hvis du er i den situasjonen, og omdirigerer nettadressene med minst en stor bokstav i den til små versjonen. Så i listen over nettadresser ovenfor, omdiriger alle nettadressene til den første nettadressen.

Kommentarer

• » Ja. for å unngå dupliserte innholdsproblemer. » – Men det motsatte ser ut til å være sant? Det faktum at nettadresser kan være store og små bokstaver (og slik behandler søkemotorer dem) forårsaker duplikatproblemene du nevner. Hvis nettadresser var uavhengige av store og små bokstaver, ville det ikke være dupliserte innholdsproblemer med forskjellig sak. page-1 ville være det samme som PAGE-1.
• Jeg tror en dårlig serverkonfigurasjon er det som kan forårsake duplikatinnhold når det gjelder casing. For eksempel vil setningen RewriteRule ^request-uri$ /targetscript.php [NC] lagret i .htaccess matche http://example.com/request-uri og http://example.com/ReQuEsT-Uri fordi [NC] indikerer at foringsrør ikke ‘ t betyr noe når du vurderer det ene regulære uttrykket.

Saksfølsomhet har verdi.

Hvis det er 26 bokstaver, som hver har store bokstaver, er det 52 tegn.

4 tegn har muligheten til å kombinere 52 * 52 * 52 * 52, tilsvarer 7311616 kombinasjoner.

Hvis du ikke kan bruke store bokstaver, er mengden kombinasjoner 26 * 26 * 26 * 26 = 456976

Det er mer enn 14 ganger flere kombinasjoner for 52 tegn enn det er for 26. Så for lagring av data kan URL-er være kortere og mer informasjon kan sendes over nettverk med mindre dataoverført.

Dette er grunnen til at du ser youtube ved hjelp av nettadresser som https://www.youtube.com/watch?v=xXxxXxxX