Miksi URL-osoitteet erottavat kirjainkoon?

Miksi ei ”t URL-osoitteen tulee olla kirjainkokoinen?

Ymmärrän, että se voi näyttää provosoivalta (ja ”paholainen puolestapuhuja”) tyyppiseltä retorikysymykseltä, mutta mielestäni on hyödyllistä harkita sitä. HTTP: n suunnittelu on että ”asiakas”, jota kutsumme yleensä ”verkkoselaimeksi”, pyytää tietoja ”verkkopalvelimelta”.

On olemassa monia, monia erilaisia verkkopalvelimia, jotka on julkaistu. Microsoft on julkaissut IIS: n Windowsissa Palvelinkäyttöjärjestelmät (ja muut, mukaan lukien Windows XP Professional). Unixilla on raskas paino, kuten nginx ja Apache, puhumattakaan pienemmistä tarjonnoista, kuten OpenBSD: n sisäinen httpd, thttpd tai lighttpd. Lisäksi monissa verkkoyhteydessä olevissa laitteissa on sisäänrakennetut verkkopalvelimet, joita voidaan käyttää laitteen määrittämiseen, mukaan lukien laitteet, jotka on tarkoitettu verkkoihin, kuten reitittimet (mukaan lukien monet Wi-Fi-tukiasemat ja DSL-modeemit) ja muut laitteet, kuten tulostimet tai UPS: t (akkukäyttöiset keskeytymättömät virtalähteet), joilla voi olla verkkoyhteys.

Joten kysymys ”Miksi URL-osoitteet erottavat kirjainkoon?” Kysyy: ”Miksi verkkopalvelimet käsittelevät URL-osoitetta onko kirjainkoko merkitsevä? ” Ja varsinainen vastaus on: ne eivät tee niin. Ainakin yksi melko suosittu verkkopalvelin EI tyypillisesti EI erota kirjainkokoja. (Verkkopalvelin on IIS.)

Tärkein syy erilainen käyttäytyminen eri verkkopalvelimien välillä johtuu todennäköisesti yksinkertaisuudesta: Yksinkertainen tapa tehdä verkkopalvelin on tehdä asiat samalla tavalla kuin miten tietokoneen / laitteen käyttöjärjestelmä etsii tiedostoja. Monta kertaa verkkopalvelimet etsivät tiedoston vastauksen tarjoamiseksi. Unix suunniteltiin ylemmän tason tietokoneiden ympärille, joten Unix tarjosi toivotun toiminnallisuuden sallia isot ja pienet kirjaimet. Unix päätti kohdella isoja ja pieniä kirjaimia erilaisina, koska ne ovat hyvin erilaisia. Se on suoraviivainen, luonnollinen tehtävä. Windowsilla on ollut historiaa kirjainkoon erottumattomuudesta johtuen halusta tukea jo luotuja ohjelmistoja, ja tämä historia juontaa juurensa DOS: ään, joka yksinkertaisesti ei tue pieniä kirjaimia, mahdollisesti ponnisteluna. yksinkertaistaa asioita vähemmän tehokkailla tietokoneilla, jotka käyttävät vähemmän muistia. Koska nämä käyttöjärjestelmät ovat erilaisia, tuloksena on, että yksinkertaisesti suunnitellut (varhaiset) verkkopalvelimet heijastavat samoja eroja.

Nyt kaikella muulla tausta, tässä on joitain erityisiä vastauksia tiettyihin kysymyksiin:

Miksi URL-osoitteet suunniteltiin ensimmäisen kerran, miksi kirjainkoon muuttamisesta tehtiin ominaisuus?

Miksi et? Jos kaikki tavalliset verkkopalvelimet eivät erottele isoja ja pieniä kirjaimia, se tarkoittaa, että verkkopalvelimet noudattavat standardin määrittelemiä sääntöjä. Yksinkertaisesti ei ollut Sääntö, joka sanoo, että tapaus on jätettävä huomiotta. Syy, että sääntöä ei ole, johtuu yksinkertaisesti siitä, ettei siihen ollut mitään syytä on olemassa sellainen sääntö. Miksi vaivautua laatimaan tarpeettomia sääntöjä?

Kysyn tätä, koska se tuntuu minulta (ts., maallikko), että tapauskohtaus olisi parempi estää tarpeettomat virheet ja yksinkertaistaa jo monimutkaista tekstiä.

URL-osoitteet on suunniteltu koneiden prosessoitaviksi . Vaikka henkilö voi kirjoittaa kokonaisen URL-osoitekentän osoiteriville, se ei ollut ”suurin osa suunnitellusta suunnittelusta. Tarkoitettu malli on, että ihmiset seuraavat (” napsauttavat ”) hyperlinkkejä. Jos tavalliset maallikot tekevät niin, he todella älä välitä onko näkymättömän URL-osoitteen yksinkertainen vai monimutkainen.

Onko isoilla kirjainkoolla URL-osoitteilla todellista tarkoitusta / etua (kuten vastustaa suurinta osaa samalle sivulle osoittavista URL-osoitteista riippumatta isoista kirjaimista)?

Viides numeroitu piste William Hayn vastauksessa mainitaan yksi tekninen etu: URL-osoitteet voivat olla tehokas tapa selaimen lähettää vähän tietoa web-palvelimelle, ja enemmän tietoja voidaan sisällyttää, jos niitä on vähemmän rajoituksia, joten tapausherkkyysrajoitukset vähentäisivät sitä, kuinka paljon tietoa voidaan sisällyttää.

Monissa tapauksissa ei kuitenkaan ole ”erittäin houkuttelevaa hyötyä kirjainkokoille”, mikä on todistettu siitä, että IIS ei yleensä vaivaudu sen kanssa.

Yhteenvetona voidaan todeta, että kaikkein pakottavin syy on yksinkertaisesti yksinkertainen niille, jotka suunnittelivat verkkopalvelinohjelmiston, etenkin Unix-kaltaisella kirjainkoon mukaisella alustalla. . (HTTP ei ollut jotain, joka vaikutti Unixin alkuperäiseen suunnitteluun, koska Unix on huomattavasti vanhempi kuin HTTP.)

Kommentit

• ” Keskeinen syy erilaiseen käyttäytymiseen eri verkkoselainten välillä johtuu todennäköisesti yksinkertaisuudesta. ” – Oletan sinun tarkoita ” -palvelimia ” kuin ” -selaimissa ” täällä ja muutamassa muussa paikassa?
• Päivitetty. Tarkasteli jokaisen ” -selaimen ” ja teki useita korvauksia. Kiitos huomautuksestasi, jotta laatua voitaisiin parantaa.
• Olen saanut useita erinomaisia vastauksia kysymykseeni, historiallisesta Olen epäröivä mennä vasten viljaa ja hyväksyä matalamman vastauksen, mutta @TOOGAM ’ vastauksesta oli eniten hyötyä minä. Tämä vastaus on perusteellinen ja laaja, mutta se selittää käsitteen mutkattomalla, ymmärrettävällä keskustelutavalla. Ja mielestäni tämä vastaus on hyvä johdatus syvällisempiin selityksiin.
• Syy Windowsille on kirjainkoon erottamaton tiedostojärjestelmä johtuen siitä ’ s DOS-perintö. MS-DOS aloitti elämänsä tietokoneilla, kuten Tandy TRS-80, joka käytti televisiota näytöllä, eikä alun perin tukenut pieniä kirjaimia tarkkuuden puutteen takia. Koska se ei voinut ’ t näyttää pientä kirjainta, sekatapausta ei tuettu ’. IBM on myöntänyt MS-DOS: lle luvan tulla alkuperäiseksi PC-DOS: ksi. Vaikka alkuperäinen tietokone pystyi näyttämään pieniä kirjaimia, tiedostojärjestelmä siirrettiin sellaisenaan MS-DOS: sta.

URL-osoitteet eivät ole isoja ja pieniä kirjaimia, vain osa niistä.
Esimerkiksi URL-osoitteessa https://google.com,

Viitaten RFC 3986 – yhtenäinen resurssitunniste (URI): yleinen syntakse

Ensinnäkin, alkaen Wikipedia , URL-osoite näyttää tältä:

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

(Olen poistanut user:password osa, koska se ei ole mielenkiintoinen ja sitä käytetään harvoin)

• scheme :

mallit eivät eroa isoja ja pieniä kirjaimia

• host :

Isännän alikomponentti ei eroa kirjainkokoja.

• path :

Polkuosa sisältää tietoja …

• query :

Kyselykomponentti sisältää ei-hierarkkisia tietoja …

• fragment :

Yksittäiset mediatyypit voivat määritellä omat rajoituksensa tai rakenteensa fragmenttitunnisteen syntaksissa erityyppisten alijoukkojen, näkymien tai ulkoisten viitteiden määrittämiseksi

Joten scheme ja host eivät erottele kirjainkoona.
Loput URL-osoite on isot ja pienet kirjaimet.

Miksi path erotetaan isot ja pienet kirjaimet?

Tämä näyttää olevan pääkysymys.
On vaikea vastata ”miksi” jotain tehtiin, jos sitä ei ollut dokumentoitu, mutta voimme arvata erittäin hyvin.
Olen valinnut tarkat lainaukset teknisistä tiedoista korostaen data .
Tarkastellaan URL-osoitetta uudelleen:

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

• Sijainti – sijainti on kanoninen muoto, ja se ei eroa isoja ja pieniä kirjaimia. Miksi? Todennäköisesti voisit ostaa verkkotunnuksen ilman, että sinun tarvitsee ostaa tuhansia muunnelmia.

• Tiedot – tietoja käytetään kohdepalvelimelle, ja sovellus voi valita, mitä se tarkoittaa . Ei ole mitään järkevää tehdä kirjainkoko merkityksettömäksi. Sovelluksella pitäisi olla enemmän vaihtoehtoja, ja kirjainkoon erottelun määrittäminen teknisissä tiedoissa rajoittaa näitä vaihtoehtoja.
  Tämä on myös hyödyllinen ero HTTPS: lle: tiedot on salattu , mutta isäntä on näkyvissä.

Onko siitä hyötyä?

Tapaus- herkkyydellä on aukkoja välimuistiin tallentamisen ja ensisijaisten URL-osoitteiden suhteen, mutta siitä on varmasti hyötyä. Joitakin esimerkkejä:

• Base64 , jota käytetään data-URI-tunnuksissa .
• Sivustot voivat koodata Base64-tietoja URL-osoitteessa, esimerkiksi: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• URL-osoitteen lyhentäjät käyttävät kirjainkokoa: /a5B saattaa olla erilainen kuin /a5b
• Kuten mainitsit, Wikipedia pystyy erottamaan aidsin AIDSista.

Kommentit

• ” URL-osoitteet eivät ole satunnaisia e-arkaluontoinen. ” / ” Loput URL-osoitteet erottavat kirjainkoon. ” – Tämä näyttäisi olevan ristiriita?
• Itse asiassa järjestelmä määrittää, mitä odottaa muusta URL-osoitteesta. http: ja siihen liittyvät mallit tarkoittavat, että URL-osoite viittaa DNS-isäntänimeen. DNS ei ollut ASCII-kirjainkoon erottava kauan ennen URL-osoitteiden keksimistä. Katso sivun ietf.org/rfc/rfc883.txt sivu
• Hyvin yksityiskohtainen! Menin historiallisesta näkökulmasta. Alun perin tiedostopolun täytyi olla kirjainkoon mukainen vain, jos osui tiedostojärjestelmään. Muuten se ei ollut. Mutta tänään asiat ovat muuttuneet. Esimerkiksi parametreja ja CGI: tä ei ollut alun perin olemassa. Vastauksesi vie nykyisen päivän näkökulman. Minun piti palkita ponnistelusi !! Kaivoit todella tämän! Kuka tiesi, että tämä räjähtäisi samalla tavalla kuin se teki? Kippis !!
• @ w3dk: se ’ ei ole kovin mielenkiintoinen terminologia, mutta voit ottaa ” kirjainkoko ” tarkoittaa, ” merkin kirjainkoon muuttaminen voi muuttaa koko ” tai voisit ottaa sen tarkoittavan ” merkin kirjainkoon muuttaminen aina muuttaa koko ”. Kobi näyttää väittävän jälkimmäistä, hän pitää parempana, että kirjainkoon mukaan ” kaikki muutokset tapauksiin ovat merkittäviä ”, mikä tietysti ei päde URL-osoitteisiin. Pidät mieluummin entisestä. ’ on vain kysymys siitä, kuinka arkaluonteiset ne ovat.
• @ rybo111: Jos käyttäjä kirjoittaa esimerkki.com/fOObaR , tekniset tiedot edellyttävät, että palvelin www.esimerkki.fi saa polun ” / fOObaR ” kuten on annettu; ei ole kysymys siitä, onko palvelimen kohdeltava sitä eri tavalla kuin ” / foOBaR ”.

Yksinkertainen. Käyttöjärjestelmä on isot ja pienet kirjaimet. Verkkopalvelimet eivät yleensä välitä, ellei heidän tarvitse osua tiedostojärjestelmään jossain vaiheessa. Tässä Linux ja muut Unix-pohjaiset käyttöjärjestelmät valvovat tiedostojärjestelmän sääntöjä, jolloin herkkyys on pääosa. Siksi IIS ei ole koskaan erottanut kirjainkokoa. koska Windows ei ole koskaan erottanut kirjainkokoa.

[Päivitä]

Kommenteissa (poistamisen jälkeen) on ollut joitain vahvoja argumentteja siitä, onko URL-osoitteilla mitään yhteyttä tiedostojärjestelmään, kuten olen todennut. Nämä väitteet ovat tulleet kuumiksi. On erittäin lyhytnäköistä uskoa, ettei suhdetta ole. Siellä on ehdottomasti! Haluan selittää tarkemmin.

Sovellusohjelmoijat eivät yleensä ole järjestelmän sisäisiä ohjelmoijia. En loukkaa. Ne ovat kaksi erillistä tieteenalaa, eikä järjestelmän sisäisiä tietoja tarvita sovellusten kirjoittamiseen, kun sovellukset voivat yksinkertaisesti soittaa puheluita käyttöjärjestelmään. Koska sovellusohjelmoijat eivät ole järjestelmän sisäisiä ohjelmoijia, käyttöjärjestelmän palveluiden ohittaminen ei ole mahdollista.Sanon tämän, koska nämä ovat kaksi erillistä leiriä ja ne kulkevat harvoin yli. Sovellukset kirjoitetaan käyttämään käyttöjärjestelmän palveluita pääsääntöisesti. Joitakin poikkeuksia on tietysti harvinaisia.

Kun verkkopalvelimia alkoi ilmestyä, sovelluskehittäjät eivät yrittäneet ohittaa käyttöjärjestelmän palveluita. Tähän oli useita syitä. Yksi, se ei ollut välttämätöntä. Kaksi, sovellusohjelmoijat eivät yleensä tienneet, miten ohittaa käyttöjärjestelmän palvelut. Kolme, useimmat käyttöjärjestelmät olivat joko erittäin vakaita ja kestäviä tai erittäin yksinkertaisia ja kevyitä eivätkä olleet kustannusten arvoisia.

Muista, että varhaiset verkkopalvelimet joko juoksivat kalliilla tietokoneilla, kuten DEC VAX / VMS-palvelimet ja päivän Unix (Berkeley ja Ultrix sekä muut) pääkehys- tai keskikehystietokoneissa, sitten pian sen jälkeen kevyissä tietokoneissa, kuten tietokoneissa ja Windows 3.1. Kun alkoi ilmestyä nykyaikaisempia hakukoneita, kuten Google vuosina 1997/8, Windows oli siirtynyt Windows NT: hen, ja muut käyttöjärjestelmät, kuten Novell ja Linux, olivat myös alkaneet käyttää verkkopalvelimia. Apache oli hallitseva verkkopalvelin, vaikka siellä oli muitakin, kuten IIS ja O ”Reilly, jotka olivat myös erittäin suosittuja. Kukaan heistä ei ohittanut tuolloin käyttöjärjestelmän palveluita. On todennäköistä, ettei yksikään verkkopalvelimista tee niin tänään.

Varhaiset verkkopalvelimet olivat melko yksinkertaisia. Ne ovat edelleen nykyäänkin. Kaikki palvelimet, jotka on tehty resurssille kiintolevyllä olevan HTTP-pyynnön kautta, on tehty verkkopalvelimen käyttöjärjestelmän tiedostojärjestelmän kautta.

Tiedostojärjestelmät ovat melko yksinkertaisia mekanismeja. Koska tiedostoon pääsyä pyydetään, jos tiedosto on olemassa, pyyntö välitetään valtuutusalijärjestelmälle ja jos se myönnetään, alkuperäinen pyyntö täytetään. Jos resurssi ei järjestelmää ei ole tai sitä ei ole valtuutettu, järjestelmä heittää poikkeuksen. Kun sovellus tekee pyynnön, liipaisin asetetaan ja sovellus odottaa. Kun pyyntöön vastataan, liipaisin heitetään ja sovellus käsittelee pyynnön vastauksen. toimii edelleen tällä tavalla. Jos sovellus havaitsee, että pyyntö on ollut s atisfied se jatkuu, jos se on epäonnistunut, sovellus suorittaa virhetilan koodissaan tai kuolee, jos sitä ei käsitellä. Yksinkertainen.

Jos kyseessä on verkkopalvelin, olettaen, että polulle / tiedostolle tehdään URL-pyyntö, verkkopalvelin ottaa URL-pyynnön (URI) polku / tiedosto-osan ja tekee pyynnön tiedostojärjestelmään ja se on joko tyytyväinen tai aiheuttaa poikkeuksen. Verkkopalvelin käsittelee vastauksen. Jos esimerkiksi valtuutusalijärjestelmä löytää pyydetyn polun ja tiedoston ja myöntää pääsyn, web-palvelin käsittelee I / O-pyynnön normaalisti. Jos tiedostojärjestelmä heittää poikkeuksen, verkkopalvelin palauttaa 404-virheen, jos tiedostoa ei löydy, tai 403 on kielletty, jos syykoodia ei ole luvattu.

Koska jotkut käyttöjärjestelmät ovat kirjainkoon ja tiedostojärjestelmiä tämä tyyppi vaatii tarkkoja vastaavuuksia, verkkopalvelimen pyytämän polun / tiedoston on vastattava kiintolevyllä olevaa tarkalleen. Syy tähän on yksinkertainen. Verkkopalvelimet eivät arvaa mitä tarkoitat. Mikään tietokone ei tee niin ilman ohjelmointia. Verkkopalvelimet yksinkertaisesti käsittelevät pyyntöjä niiden vastaanotettua. Jos suoraan tiedostojärjestelmään välitetyn URL-pyynnön polku / tiedosto-osa ei ole sama kuin kiintolevyllä, tiedostojärjestelmä heittää poikkeuksen ja verkkopalvelin palauttaa 404-virheilmoituksen.

Se on todella yksinkertaisia ihmisiä. Se ei ole rakettitiede. URL-osoitteen polku / tiedosto-osan ja tiedostojärjestelmän välillä on ehdoton suhde.

Kommentit

• Mielestäni argumenttisi on virheellinen. Vaikka Berners-Lee ei ’ ole valinnut ftp-URL-osoitteiden kirjainkoon herkkyyttä. Hänen oli suunniteltava http-URL-osoitteet. Hän olisi voinut määritellä ne vain Yhdysvaltain ASCII-luokkiksi ja kirjainkoon erottumattomiksi. Jos joskus oli Web-palvelimia, jotka vain välittivät URL-polun tiedostojärjestelmään, he olivat epävarmoja ja URL-koodauksen käyttöönotto hajosi yhteensopivuuden heidän kanssaan. Ottaen huomioon, että polkua käsitellään ennen käyttöjärjestelmän käyttöjärjestelmän törmäämistä, olisi ollut helppo toteuttaa. Siksi mielestäni meidän on pidettävä tätä suunnittelupäätöksenä, joka ei ole toteutusmomentti.
• @WilliamHay Tällä ei ole mitään tekemistä Berners-Leen tai verkon suunnitteluun. Kyse on käyttöjärjestelmän rajoituksista ja vaatimuksista. Olen eläkkeellä oleva sisäinen insinööri. Olen työskennellyt näiden järjestelmien kanssa tuolloin. Kerron sinulle, miksi URL-osoitteet erottavat kirjainkoon. Se ei ole arvaus. Se ei ole mielipide. Se on tosiasia. Vastaukseni yksinkertaistettiin tarkoituksella. Tietenkin on olemassa tiedostotarkistuksia ja muita prosesseja, jotka voidaan tehdä ennen avoimen lausunnon antamista. Ja kyllä (!) Web-palvelimet ovat osittain epävarmoja tämän vuoksi.
• URL-osoitteiden kirjainkoon erottamisella ei ole mitään tekemistä verkon suunnittelun kanssa? Todella? Viranomaisen väite, jota seuraa väite väitteellä.Se, että verkkopalvelimet välittävät URL-osoitteen polun komponentin enemmän tai vähemmän suoraan avoimeen puheluun, on seurausta URL-osoitteiden suunnittelusta, ei syystä. Palvelimet (tai älypuhelimet FTP: n tapauksessa) ovat voineet piilottaa tiedostojärjestelmien kirjainkoon herkkyyden käyttäjältä. Se, että he eivät pidä ’ t, on suunnittelupäätös.
• @WilliamHay Sinun täytyy hidastaa ruohosäiliötä ja lukea uudelleen kirjoittamani. Olen eläkkeellä oleva järjestelmän sisäisten insinööri, joka kirjoittaa käyttöjärjestelmän komponentteja, protokollapinoja ja reitittimen koodia ARPA-Netille jne. Työskentelin Apache-, O ’ Reillyn ja IIS-sisäisten kanssa. FTP-argumenttisi ei pidä vettä, koska ainakin suurimmat FTP-palvelimet pysyvät isoissa kirjaimissa samasta syystä. En koskaan sanonut mitään URL / URI: n suunnittelusta. En missään vaiheessa sanonut, että verkkopalvelimet välittivät arvoja ilman käsittelyä. Sanoin, että käyttöjärjestelmäpalveluja käytetään yleisesti ja että tiedostojärjestelmä vaatii täsmällisen vastaavuuden menestyäkseen.
• @WilliamHay Ymmärrä, että sinä ja minä ajattelemme ristiin. Ainoa mitä sanoin vastauksessani, on se, että joissakin käyttöjärjestelmissä tiedostojärjestelmäpuhelut ovat suunnittelun mukaan kirjainkoon mukaisia. Järjestelmäkutsuja käyttävät sovellukset, ja useimmat käyttävätkin, rajoittuvat käyttöjärjestelmän sääntöjen – tässä tapauksessa kirjainkoon herkkyyteen – täytäntöönpanoon. Tämän säännön ohittaminen ei ole mahdotonta. Itse asiassa tämä voi olla joissakin tapauksissa vähäpätöistä, mutta ei käytännöllistä. Ohitin työssäni tiedostojärjestelmän rutiininomaisesti purkamaan kiintolevyt, jotka menivät kablooieen syystä tai toisesta, tai analysoimaan tietokantatiedostojen sisäisiä jne.

1. URL-osoitteet väittävät olevansa UNIFORM-resurssipaikantimet ja voivat osoittaa verkkoa edeltäviä resursseja. Jotkut näistä ovat isot ja pienet kirjaimet (esim. Monet ftp-palvelimet), ja URL-osoitteiden on kyettävä edustamaan näitä resursseja kohtuullisen intuitiivisella tavalla.

2. Kirjainten välinen herkkyys vaatii enemmän työtä etsiessään ottelu (joko käyttöjärjestelmässä tai sen yläpuolella).

   Päinvastoin ei ole totta.

3. Tapausherkkyys voi olla ei-triviaalia kansainvälisissä yhteyksissä: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Myös RFC1738 salli ASCII-alueen ulkopuolisten merkkien käytön edellyttäen, että ne koodattiin, mutta ei määritetty merkistöä. Tämä on melko tärkeää sellaiselle, joka kutsuu itseään WORLD-verkoksi. URL-osoitteiden määritteleminen kirjainkoon poissulkeviksi avaisi paljon mahdollisuuksia virheitä.

4. Jos yrität pakata paljon tietoja URI: hen (esim. Data URI ) voit pakata lisää, jos isot ja pienet kirjaimet ovat erilliset.

Kommentit

• I ’ olin melko varma, että URL-osoitteet rajoitettiin historiallisesti ASCII: een. Joten kansainvälistyminen ei todennäköisesti ole alkuperäinen syy. Unixin historia on kirjainkoko, OTOH, todennäköisesti ollut valtava rooli.
• Vaikka URL-osoitteessa voi käyttää vain ASCII: n alajoukkoa koodaamattomana, RFC1738: n nimenomaisesti todetaan, että ASCII-alueen ulkopuolisia merkkejä voidaan käyttää koodattuina. Ilmoittamatta merkkisarjaa ei ole mahdollista tietää mitkä oktetit edustavat samaa merkkiä acter paitsi tapaus. Päivitetty.
• Re # 4: Se on ’ todella huonompi. Pisteviiva ja täplätön olen osoitus yleisemmästä periaatteesta, että vaikka kaikki on UTF-8 (tai jokin muu UTF), et voi isoja tai pieniä kirjaimia tuntea tuntematta aluetta, johon teksti kuuluu . Oletuskielessä latinalaisen ison kirjaimen I pienet kirjaimet ovat pieniä latinalaisia kirjaimia i, mikä on väärin turkkilaisessa kielessä, koska se lisää pisteen (turkin isoa kirjainta ” ei ole pistettä I ” koodipiste; ’ halusit käyttää ASCII-koodipistettä). Heitä koodauksen erot, ja tämä siirtyy ” todella kovasta ” arvoon ” täysin käsittelemätön . ”

Varastin blogista an Vanhan uuden asian tapa lähestyä kysymyksiä, joiden muoto on ”miksi jotain on niin?” vastakysymyksellä ”millainen maailma olisi, jos näin ei olisi?”

Sanoin, että asetin verkkopalvelimen palvelemaan itseäni asiakirjatiedostoni kansiosta, jotta voisin lukea ne edelleen puhelinta, kun olin toimistossa. Nyt asiakirjakansiossa on kolme tiedostoa, todo.txt, ToDo.txt ja TODO.TXT (Tiedän, mutta minulle oli järkevää, kun tein tiedostot.)

Mitä URL-osoitetta haluaisin käyttää, jotta voin käyttää näitä tiedostoja? Haluaisin käyttää niitä intuitiivisella tavalla käyttämällä http://www.example.com/docs/filename.

Sano, että minulla on komentosarja, jonka avulla voin lisätä yhteystiedon osoitekirjaani, jonka voin tehdä myös verkossa.Kuinka sen pitäisi ottaa parametrit? No, haluaisin käyttää sitä kuten: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Mutta jos minulla ei olisi mitään tapaa määrittää nimeä tapauskohtaisesti, miten tekisin sen?

Kuinka erottaisin kissan ja kissan, tekstin ja tekstin, lateksin ja LaTeXin wiki-sivut? Luultavasti Disambig-sivut, mutta mieluummin saan vain pyytämäni asian.

Mutta kaikki tuntuu tykkää se vastaamisesta väärään kysymykseen joka tapauksessa.

Kysymys, jonka luulit todella kysyneen, on ”Miksi verkkopalvelimet 404 teet vain tapauseron vuoksi, kun ne ovat tietokoneita, on suunniteltu tekemään elämästä yksinkertaisempaa. , ja he pystyvät täysin löytämään ainakin ilmeisimmät kirjoittamasi URL-osoitteen tapausmuunnelmat, jotka toimisivat? ”

Vastaus on, että vaikka jotkut sivustot ovat tehneet tämän (ja paremmin, he tarkista myös muut kirjoitusvirheet), kukaan ei pitänyt kannattavana muuttaa verkkopalvelimen 404-oletusvirhesivua … mutta ehkä heidän pitäisi?

Kommentit

• Jotkut sivustot käyttävät jonkinlaista mekanismia muuntaa a ny kysely kaikille pienille kirjaimille tai jotain johdonmukaista. Tavallaan tämä on fiksua.
• Ei, heidän ei pitäisi ’ t. Tämä toiminto voidaan lisätä ja usein lisätään, kun se on toivottavaa (esim. Apache-moduulien avulla.) Tällaisen muutoksen asettaminen oletuskäyttäytymiseksi – tai pahempaa, muuttumattomaksi käytöksi – olisi häiritsevämpää kuin suhteellisen harvinainen Jos joku joutuu kirjoittamaan URL-osoitteen isäntänimen ulkopuolella. Hyvän esimerkin siitä, miksi et tekisi tätä, muista fiasko, kun verkkoratkaisut ” korjattu ” julkisen DNS: n olemattomia toimialueiden virheitä kyselyt.
• @SirNickity Kukaan ei ehdottanut muuttumattomuutta millään tasolla, ja verkkopalvelimen virhesivut ovat määritettävissä jokaisella verkkopalvelimella, jota olen ’ koskaan käyttänyt; kukaan ei ehdottanut, että 404 korvataan 30 * koodilla, vaan pikemminkin lisätään luettelo ihmisen napsautettavista ehdotuslinkeistä virhesivulle; verkkotunnukset ovat hyvin erilainen aihe ja asia, joka ei eroa kirjainkokoja ja on eri suojauskontekstissa; ja IIS jo automaattisesti ” korjaa ” (jättämällä huomiotta) tapauserot URI-tiedostojen polussa tai tiedostonimessä.
• Vuodesta 1996 Apache on antanut sinun tehdä tämän mod_speling -toiminnolla. Se ei vain näytä olevan kovin suosittu asia tehdä. ’ Unix- / Linux-ihmiset pitävät kirjainkoon merkitsemättömyyttä säännönä, kirjainkoon poikkeavuutta poikkeuksena.

Vaikka yllä oleva vastaus on oikea & hyvä. Haluaisin lisätä vielä joitain pisteitä.

Paremman ymmärtämisen vuoksi on ymmärrettävä Unix (Linux) Vs: n Windows-palvelimen perusero. Unix on isot ja pienet kirjaimet & Windows ei ole kirjainkoon erottava käyttöjärjestelmä.

HTTP-protokollaa kehitettiin tai se alkoi ottaa käyttöön noin vuonna 1990. HTTP-protokollan suunnittelivat insinöörit, jotka työskentelivät CERN-instituutit, suurin osa niistä päivistä tutkija käytti Unix-koneita eikä Windowsia.

Suurin osa tutkijoista tunsi Unixin, joten Unix-tyylinen tiedostojärjestelmä on saattanut vaikuttaa heihin.

Windows-palvelin julkaistiin vuoden 2000 jälkeen paljon ennen Windows-palvelimen suosittua HTTP-protokollaa oli kypsynyt hyvin ja tekniset tiedot olivat täydelliset.

Tämä voi olla syy.

kommentit

• ” Windows-palvelin julkaistiin vuoden 2000 jälkeen. ” Windows NT 3.1 -tiimi olisi ollut eri mieltä kanssasi vuonna 1993. NT 3.51 vuonna 1995 oli todennäköisesti silloin, kun NT alkoi tulla kypsät ja riittävän vakiintuneet tukemaan yrityskriittisiä palvelinsovelluksia.
• NT 3.51: ssä oli Win 3.1 -käyttöliittymä. Windows lähti vasta Windows 95: stä, ja saman käyttöliittymän saaminen vaati NT 4.0: n.
• Michael Kj ö rling oli samaa mieltä. Haluan muokata sitä.
• @Thorbj ø rnRavnAndersen Palvelinmarkkinoilla NT 3.51 oli kohtuullisen onnistunut. Kuluttaja- / kuluttajamarkkinoilla kesti Windows 2000: een (NT 5.0), ennen kuin NT-linja alkoi saada vakavaa pitoa.
• WorldWideWeb kehitettiin alun perin Unix-pohjaisiin järjestelmiin, joissa kirjainkoko on merkitsevä tiedostojärjestelmät ja useimmat URL-osoitteet, jotka on kartoitettu suoraan tiedostojärjestelmän tiedostoihin.

Kuinka pitäisi lukea ”miksi se on suunniteltu tällä tavalla?” kysymys? Pyydätkö historiallisesti tarkkaa selontekoa päätöksentekoprosessista vai kysytkö ”miksi kukaan suunnittelisi sen tällä tavalla?”?

Hyvin harvoin on mahdollista saada historiallisesti tarkka tili.Joskus, kun päätökset tehdään standardikomiteoissa, on dokumentaarinen polku siitä, miten keskustelu käytiin, mutta webin alkuaikoina muutamat yksilöt – tässä tapauksessa luultavasti TimBL itse – tekivät päätökset kiireesti, ja perustelut ovat epätodennäköiset olla kirjoitettu muistiin. Mutta TimBL on myöntänyt tekevänsä virheitä URL-osoitteiden suunnittelussa – katso http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

Alkuaikoina URL-osoitteet kartoitettiin hyvin suoraan tiedostonimiin, ja tiedostot olivat yleensä Unix-tyyppisillä koneilla, ja Unix-tyyppisillä koneilla on isot ja pienet kirjaimet. Joten arvaukseni on, että se tapahtui juuri tavalla toteutuksen mukavuuden vuoksi, ja käytettävyyttä (loppukäyttäjille) ei koskaan edes harkittu. Jälleen alkuaikoina käyttäjät olivat joka tapauksessa kaikki Unix-ohjelmoijia.

Kommentit

• Myös loppukäyttäjät olivat Unix-käyttäjiä (eivät välttämättä ohjelmoijia, mutta korkean energian fyysikot ja vastaavat), joten myös he olivat tottuneet tapausten tuntemattomuuteen.

Tämä ei ole mitään tekemistä sen kanssa, mistä ostit verkkotunnuksesi, DNS ei eroa isoja ja pieniä kirjaimia. Mutta palvelimella käyttämäsi tiedostojärjestelmä on.

Tämä ei ole oikeastaan ongelma ja se on melko yleinen * nix-isännöissä. Varmista vain, että kaikki sivuillesi kirjoittamasi linkit ovat oikeita ja sinulla ei ole ongelmaa. Sen helpottamiseksi suosittelen, että nimeät sivusi aina pienillä kirjaimilla, niin sinun ei tarvitse koskaan tarkistaa nimeä kirjoittaessasi linkkiä.

Closetnoc on oikeassa käyttöjärjestelmässä. Jotkut tiedostojärjestelmät käsittelevät samaa nimeä eri kirjaimilla eri tiedostoina.

Onko kirjaimella merkityllä URL-osoitteella todellista tarkoitusta / etua (toisin kuin suurin osa URL-osoitteista, jotka osoittavat samalle sivulle riippumatta isot kirjaimet)?

Kyllä. päällekkäisten sisältöongelmien välttämiseksi.

Jos sinulla olisi esimerkiksi seuraavat URL-osoitteet:

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 

ja kaikki viittasivat täsmälleen samalle sivulle, jolla on täsmälleen sama sisältö, sinulla olisi päällekkäistä sisältöä, ja olen varma, että sinulla on Google-hakukonsoli (verkkovastaavan työkalut) -tili, Google ilmoittaa tämän sinulle.

Mitä minä Suosittelen, että jos olet tilanteessa, on käyttää kaikkia pieniä URL-osoitteita ja ohjata sitten URL-osoitteet, joissa on vähintään yksi iso kirjain, pieniin kirjaimiin. Joten ohjaa kaikki URL-osoitteet yllä olevaan URL-luetteloon ensimmäiseen URL-osoitteeseen.

Kommentit

• ” Kyllä. välttää päällekkäisiä sisältöongelmia. ” – Mutta päinvastoin näyttää olevan totta? Se, että URL-osoitteet voivat olla isot ja pienet kirjaimet (ja näin hakukoneet kohtelevat niitä) aiheuttaa mainitsemasi päällekkäisen sisällön ongelmat. Jos URL-osoitteet eivät ole yleensä kirjainkoon merkitseviä, silloin ei ole päällekkäisiä sisältöongelmia erilaisten kirjainten kanssa. page-1 olisi sama kuin PAGE-1.
• Mielestäni palvelimen kokoonpano on huono on se, mikä voi aiheuttaa päällekkäistä sisältöä kotelon suhteen. Esimerkiksi lause, RewriteRule ^request-uri$ /targetscript.php [NC], joka on tallennettu .htaccess-tiedostoon, vastaisi http://example.com/request-uri ja http://example.com/ReQuEsT-Uri, koska [NC] osoittaa, että kotelolla ei ole merkitystä ’, kun arvioidaan yhtä säännöllistä lauseketta.

Kirjainkoon merkityksellä on arvo.

Jos kirjaimia on 26, joista jokaisessa on kyky käyttää isoja, tämä on 52 merkkiä.

4 merkkiä on mahdollista 52 * 52 * 52 * 52 yhdistelmää, yhtä suuri kuin 7311616 yhdistelmä.

Jos et voi kirjoittaa isoja merkkejä, yhdistelmien määrä on 26 * 26 * 26 * 26 = 456976

Ne ovat yli 14 kertaa enemmän yhdistelmiä 52 merkille kuin niitä on 26: ta. Tietojen tallentamiseksi URL-osoitteet voivat olla lyhyempiä ja enemmän tietoa voidaan siirtää verkoissa, joissa siirretään vähemmän tietoja.

Siksi näet YouTuben URL-osoitteilla, kuten https://www.youtube.com/watch?v=xXxxXxxX