Miért az URL-ek megkülönböztetik a kis- és nagybetűket?

Miért nem “t” az URL-ben legyen különbség a kis- és nagybetűk között?

Megértem, hogy ez provokatív (és az “ördög” szószólója) típusú retorikai kérdésnek tűnhet, de szerintem hasznos megfontolni. A HTTP kialakítása hogy egy “kliens”, amelyet általában “webböngészőnek” hívunk, adatokat kér a “webszervertől”.

Sok-sok különböző webkiszolgáló van kiadva. A Microsoft kiadta az IIS-t a Windows rendszerrel Szerver operációs rendszerek (és mások, beleértve a Windows XP Professional rendszert is). A Unix olyan nehéz súlyokkal rendelkezik, mint az nginx és az Apache, nem beszélve a kisebb ajánlatokról, mint például az OpenBSD belső httpd, thttpd vagy lighttpd. Ezenkívül számos hálózatra képes eszköz beépített webszervereket tartalmaz, amelyek felhasználhatók az eszköz konfigurálására, beleértve a hálózatokra jellemző eszközöket is, például útválasztókat (köztük számos Wi-Fi hozzáférési pontot és DSL modemet) és más eszközöket, például nyomtatókat vagy más eszközöket. UPS-ek (akkumulátorral támogatott, megszakíthatatlan tápegységek), amelyek hálózati kapcsolattal rendelkeznek.

Tehát a „Miért fontosak az URL-ek kis- és nagybetűk között?” Kérdés: „Miért kezelik a webszerverek az URL-t nagybetű érzékeny? ” És a tényleges válasz: nem mind ezt teszik. Legalább egy, meglehetősen népszerű webszerver általában NEM különbözteti meg a kis- és nagybetűket. (A webszerver IIS.)

A különböző webkiszolgálók közötti eltérő viselkedés valószínűleg az egyszerűség kérdése. A webkiszolgáló elkészítésének egyszerű módja, ha ugyanúgy cselekszünk, mint ahogy a számítógép / eszköz operációs rendszere megtalálja a fájlokat. A webszerverek sokszor megkeresnek egy fájlt, hogy választ kapjanak. A Unixot a felsőbb kategóriájú számítógépek köré tervezték, és így a Unix biztosította a kívánt funkcionalitást a kis- és nagybetűk engedélyezéséhez. A Unix úgy döntött, hogy a nagybetűket és a kisbetűket másként kezeli, mivel ezek különböznek egymástól. Ez az egyszerű, természetes tennivaló. A Windows története nem különbözteti meg a kis- és nagybetűket a már létrehozott szoftverek támogatásának vágya miatt, és ez a történelem a DOS-ra vezethető vissza, amely egyszerűen nem támogatta a kisbetűket, esetleg erőfeszítéssel. egyszerűbbé téve a kevésbé memóriát használó számítógépeket, amelyek kevesebb memóriát használnak. Mivel ezek az operációs rendszerek különböznek, az eredmény az, hogy az egyszerűen megtervezett (korai verziójú) webszerverek ugyanazokat a különbségeket tükrözik.

Most mindezzel együtt háttér, íme néhány konkrét válasz a konkrét kérdésekre:

Amikor az URL-eket először tervezték, miért tették jellemzővé a kis- és nagybetűket?

Miért ne? Ha az összes szabványos webszerver nem különbözteti meg a kis- és nagybetűket, az azt jelentené, hogy a webszerverek a szabvány által meghatározott szabályok készletét követték. Egyszerűen nem volt szabályt, amely szerint ezt az esetet figyelmen kívül kell hagyni. Az oka, hogy nincs szabály, egyszerűen az, hogy nem volt rá ok legyen ilyen szabály. Miért bajlódnék felesleges szabályok kidolgozásával?

Ezt azért kérdezem, mert nekem úgy tűnik (azaz, laikus), hogy a felesleges hibák megelőzése és az amúgy is bonyolult szövegsor egyszerűsítése érdekében az eset-érzéketlenséget részesítenék előnyben.

Az URL-eket a gépek számára tervezték feldolgozásra . Bár egy személy beírhat egy teljes URL-t a címsorba, ez nem volt a tervezett tervezés nagy része. A terv az, hogy az emberek követik (“rákattintanak”) a hiperhivatkozásokat. Ha az átlag laikusok ezt teszik, akkor valóban nem érdekel, hogy a láthatatlan URL egyszerű vagy bonyolult-e.

Van-e valódi célja / előnye a kis- és nagybetűk megkülönböztetett URL-jének (mint szemben az URL-ek túlnyomó többségével, amelyek ugyanarra az oldalra mutatnak, függetlenül a nagybetűk használatától)?

A William Hay válasza egy technikai előnyt említ: az URL-ek hatékony módja lehet annak, hogy a webböngésző egy kis információt elküldjön egy webszerverre, és több információ is bekerülhet, ha kevesebb van korlátozások, így az eset-érzékenység korlátozása csökkentené az információmennyiséget.

Az esetek érzékenységének azonban sok esetben nincs “kiemelkedő előnye”, ami bizonyítja az a tény, hogy az IIS általában nem foglalkozik vele.

Összefoglalva, a legmeggyőzőbb ok valószínűleg csak az egyszerűség azok számára, akik a webszerver szoftvert tervezték, különösen egy olyan kis- és nagybetűket figyelembe vevő platformon, mint a Unix . (A HTTP nem volt valami, ami befolyásolta a Unix eredeti kialakítását, mivel a Unix lényegesen régebbi, mint a HTTP.)

Megjegyzések

• ” A különböző webböngészők közötti eltérő viselkedés egyik legfontosabb oka valószínűleg az egyszerűség kérdése. ” – feltételezem, hogy ön átlag ” webszerverek “, nem pedig ” webböngészők ” itt és még néhány helyen?
• Frissítve. Minden ” böngésző ” és többször is pótolt. Köszönöm, hogy felhívta a figyelmet erre, hogy javuljon a minőség.
• számos kiváló választ kaptam a kérdésemre, a történettől a habozom, hogy ellenkezzek a gabonával és elfogadjak egy alacsonyabb besorolású választ, de a @TOOGAM ‘ válasz volt a leginkább hasznos nekem. Ez a válasz alapos és átfogó, mégis bonyolult, beszélgetős módon magyarázza el a koncepciót, amit megértek. És úgy gondolom, hogy ez a válasz jó bevezetés a mélyebb magyarázatokba.
• A Windows kis- és nagybetűkkel nem rendelkező fájlrendszere annak köszönhető, hogy ‘ s DOS örökség. Az MS-DOS olyan számítógépeken kezdte az életét, mint a Tandy TRS-80, amelyek TV-t használtak kijelzőként, és a felbontás hiánya miatt eredetileg nem támogatták a kisbetűket. Mivel nem tudta ‘ t megjeleníteni kisbetűvel, a vegyes betűk nem voltak ‘ t támogatva. Az MS-DOS-t az IBM engedélyezte, hogy az eredeti PC-DOS legyen. Míg az eredeti számítógép kisbetűket tudott megjeleníteni, a fájlrendszert az MS-DOS-ból az aktuális állapotban portolták át.

Az URL-ek nem különböztetik meg a kis- és nagybetűket, csak azok egy részét.
Például semmi sem különbözteti meg a kis- és nagybetűket az URL-ben https://google.com,

Az RFC 3986 hivatkozással – Egységes erőforrás-azonosító (URI): Általános szintaxis

Először: Wikipedia , az URL a következőképpen néz ki:

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

(Eltávolítottam a user:password rész, mert nem érdekes és ritkán használják)

• scheme :

a sémák különbséget nem tesznek a kis- és nagybetűk között

• host :

A gazdagép alkomponense nem különbözteti meg a kis- és nagybetűket.

• path :

Az elérési út összetevője adatokat tartalmaz …

• query :

A lekérdezés összetevője nem hierarchikus adatokat tartalmaz …

• fragment :

Az egyes adathordozó-típusok megadhatják saját korlátozásaikat vagy struktúráikat a töredékazonosító szintaxisában a különböző típusú részhalmazok, nézetek vagy külső hivatkozások megadásához

Tehát a scheme és a host nem érzékeny a kis- és nagybetűkre.
A többi az URL megkülönbözteti a kis- és nagybetűket.

Miért a path megkülönbözteti a kis- és nagybetűket?

Úgy tűnik, ez a fő kérdés.
Nehéz válaszolni “miért” történt valami, ha nem dokumentálták, de nagyon jól kitalálhatjuk.
Nagyon konkrét idézeteket választottam a specifikációból, a data .
Nézzük meg újra az URL-t:

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

• Hely – A hely kanonikus formában van, és nem különbözteti meg a kis- és nagybetűket. Miért? Valószínűleg azért, hogy megvásárolhasson egy domain nevet anélkül, hogy több ezer változatot kellene megvásárolnia.

• Adatok – az adatokat használja a célszerver, és az alkalmazás kiválaszthatja, mit jelent . Semmi értelme nem lenne érzékeny adattípusra tenni az adatot. Az alkalmazásnak több opcióval kell rendelkeznie, és az eset-érzéketlenség meghatározása a specifikációban korlátozza ezeket a lehetőségeket.
  Ez a HTTPS esetében is hasznos megkülönböztetés: az adatok titkosítva vannak , de a gazdagép látható.

Hasznos?

Eset- Az érzékenységnek vannak buktatói a gyorsítótárban és a kanonikus URL-ekben, de minden bizonnyal hasznos. Néhány példa:

• Base64 , amelyet az Data URI-kban használnak.
• A webhelyek az Base64 adatait kódolhatják az URL-ben, például: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• Az URL-rövidítők nagybetű-érzékenységet használnak: a /a5B eltérhet a /a5b
• Amint említetted, a Wikipédia meg tudja különböztetni az “AIDS” -et az “AIDS” -től.

Megjegyzések

• ” Az URL-ek nem cas e-érzékeny. ” / ” Az URL többi része megkülönbözteti a kis- és nagybetűket. ” – Ez ellentmondásnak tűnik?
• Valójában a séma meghatározza, hogy mire számítson az URL többi részében. A http: és a kapcsolódó sémák azt jelentik, hogy az URL egy DNS hosztnévre vonatkozik. A DNS jóval az URL-ek feltalálása előtt nem volt érzékeny az ASCII esetekre. Lásd a ietf.org/rfc/rfc883.txt 55. oldalát.
• Szépen részletes! Történelmi szempontból mentem. Eredetileg a fájl elérési útjának kellett megkülönböztetnie a kis- és nagybetűket, ha a fájlrendszert ütötte meg. Egyébként nem az volt. De ma a dolgok megváltoztak. Például a paraméterek és a CGI eredetileg nem léteztek. A válasz az aktuális nap perspektíváját veszi figyelembe. Jutalmaznom kellett az erőfeszítéseidet !! Te nagyon belemélyedtél ebbe! Ki tudta, hogy ez úgy robbant fel, ahogyan ?? Sziasztok !!
• @ w3dk: ez ‘ nem túl érdekes furcsaság a terminológiában, de a ” kis- és nagybetű-érzékeny ” jelentése: ” egy karakter kis- és nagybetűk megváltoztatása megváltoztathatja az egész “, vagy úgy is fogalmazhat, hogy ” egy karakter kis- és nagybetűinek megváltoztatása mindig megváltoztatja az egész “. Úgy tűnik, hogy Kobi az utóbbit állítja, ő inkább azt szeretné, ha a kis- és nagybetűk közötti különbségek ” bármilyen jelentőségű változást jelentenének “, ami természetesen nem igaz az URL-ekre. Jobban kedveled az előbbit. ‘ csak kérdés, hogy mennyire érzékenyek a kis- és nagybetűkre.
• @ rybo111: Ha egy felhasználó beírja a example.com/fOObaR , a specifikáció megköveteli, hogy a www.example.com szerver a ” / fOObaR ” a megadott módon; hallgat arról a kérdésről, hogy a szervernek ezt kell-e másként kezelnie, mint a ” / foOBaR “.

Egyszerű. Az operációs rendszer megkülönbözteti a kis- és nagybetűket. A webszerverek általában nem érdekelnek, hacsak nem kell valamikor elérniük a fájlrendszert. Itt érvényesítik a Linux és más Unix alapú operációs rendszerek a fájlrendszer szabályait, ebben az esetben az érzékenység a fő. Ezért az IIS soha nem volt kis- és nagybetűk között; mert a Windows soha nem volt kis- és nagybetűk között.

[Frissítés]

A megjegyzésekben (törlés óta) néhány erős érv szólt arról, hogy az URL-ek kapcsolatban állnak-e a fájlrendszerrel, amint azt már említettem. Ezek az érvek hevesek lettek. Rendkívül rövidlátó azt hinni, hogy nincs kapcsolat. Abszolút van! Hadd magyarázzam el tovább.

Az alkalmazás-programozók általában nem a belső rendszerek programozói. Nem sértegetem. Két külön tudományterületről van szó, és a rendszeren belüli ismeretek nem szükségesek az alkalmazások megírásához, ha az alkalmazások egyszerűen hívhatnak az operációs rendszerre. Mivel az alkalmazásprogramozók nem a rendszer belső programozói, az operációs rendszer szolgáltatásainak megkerülése nem lehetséges.Ezt azért mondom, mert ez két különálló tábor, és ritkán keresztezik egymást. Az alkalmazásokat úgy írják, hogy általában az OS szolgáltatásokat használják. Természetesen ritka néhány kivétel.

A webszerverek megjelenésekor az alkalmazásfejlesztők nem próbálták megkerülni az operációs rendszer szolgáltatásait. Ennek több oka is volt. Egy, nem volt rá szükség. Két, az alkalmazás-programozók általában nem tudták, hogyan lehet megkerülni az operációs rendszer szolgáltatásait. Három, a legtöbb operációs rendszer rendkívül stabil és robusztus volt, vagy rendkívül egyszerű és könnyű, és nem érte meg a költségeit.

Ne feledje, hogy a korai webszerverek vagy drága számítógépeken futottak, például a DEC VAX / A VMS-kiszolgálók és a nap Unixja (Berkeley és Ultrix, valamint mások) a fő vagy közepes méretű számítógépeken, majd nem sokkal később olyan könnyű számítógépeken, mint a PC-k és a Windows 3.1. Amikor korszerűbb keresőmotorok jelentek meg, például a Google 1997/8-ban, a Windows átkerült a Windows NT rendszerbe, és más operációs rendszerek, például a Novell és a Linux is elkezdtek futtatni webszervereket. Az Apache volt a domináns webszerver, bár voltak olyanok, mint az IIS és az O “Reilly, amelyek szintén nagyon népszerűek voltak. Akkoriban egyikük sem kerülte el az operációs rendszer szolgáltatásait. Valószínű, hogy egyik webszerver sem teszi meg ma sem.

A korai webszerverek meglehetősen egyszerűek voltak, ma is így vannak. A merevlemezen létező HTTP-kérelem révén erőforrás iránti minden kérést a webszerver az operációs rendszer fájlrendszerén keresztül küldött / küld.

A fájlrendszerek meglehetősen egyszerű mechanizmusok. Mivel egy fájlhoz való hozzáférés iránti kérelmet nyújtanak be, ha ez a fájl létezik, a kérelmet továbbítják az engedélyezési alrendszernek, és ha megadják, akkor az eredeti kérés teljesül. nem létezik, vagy nincs engedélyezve, a rendszer kivételt dob. Amikor egy alkalmazás kérelmet nyújt be, akkor aktiválási szabályt állít be, és az alkalmazás várakozik. Amikor a kérelem megválaszolásra kerül, a ravaszt eldobja, és az alkalmazás feldolgozza a kérés válaszát. ma is így működik. Ha az alkalmazás úgy látja, hogy a kérés s atisfied folytatja, ha nem sikerült, az alkalmazás hibakört hajt végre a kódjában, vagy meghal, ha nem kezelik. Egyszerű.

Webkiszolgáló esetén, feltételezve, hogy egy elérési útra / fájlra vonatkozó URL-kérés érkezik, a webszerver átveszi az URL-kérés (URI) elérési útja / fájl részét, és kérést küld fájlrendszerre, és vagy elégedett, vagy kivételt vet. Ezután a webszerver feldolgozza a választ. Ha például a kért útvonalat és fájlt megtalálja, és a hozzáférést az engedélyezési alrendszer biztosítja, akkor a webkiszolgáló az I / O kérést a szokásos módon feldolgozza. Ha a fájlrendszer kivételt vet, akkor a webszerver egy 404-es hibát ad vissza, ha a fájl nem található, vagy egy 403-at tilt, ha az okkód jogosulatlan.

Mivel egyes operációs rendszerek nagybetűk és kis- és nagybetűk fájlrendszerei ehhez a típushoz pontos egyezésekre van szükség, a webkiszolgálótól kért elérési útnak / fájlnak pontosan meg kell egyeznie a merevlemezen lévő adatokkal. Ennek oka egyszerű. A webszerverek nem sejtik, mire gondol. Egyetlen számítógép sem teszi ezt anélkül, hogy be lenne programozva. A webkiszolgálók egyszerűen feldolgozzák a kéréseket, amint megkapják őket. Ha az URL-kérés közvetlenül a fájlrendszerhez továbbított elérési útja / fájlrésze nem egyezik a merevlemezen találhatóval, akkor a fájlrendszer kivételt dob, és a webszerver egy 404 Nem található hibát ad vissza.

Valóban ilyen egyszerű emberek. Ez nem rakétatudomány. Abszolút kapcsolat van az URL elérési útja / fájl része és a fájlrendszer között.

Megjegyzések

• Úgy gondolom, hogy az Ön argumentuma hibás. Míg Berners-Lee nem tudott ‘ választani az ftp URL-ek kis- és nagybetûsségérõl. Meg kellett terveznie a http URL-eket. Meghatározhatta volna őket csak az USA-ASCII-ként, és a kis- és nagybetűket nem. Ha valaha voltak olyan webszerverek, amelyek csak átadták az URL elérési útját a fájlrendszernek, akkor bizonytalanok voltak, és az URL kódolás bevezetése megszakította velük a kompatibilitást. Tekintettel arra, hogy az útvonal feldolgozása folyamatban van, mielőtt átadnák az operációs rendszer összetörő esetét, könnyen megvalósítható lett volna. Ezért úgy gondolom, hogy ezt egy tervezési döntésnek kell tekintenünk, nem pedig megvalósítási furcsaságnak.
• @WilliamHay Ennek semmi köze Berners-Lee-hez vagy a web tervezéséhez. Az operációs rendszer korlátairól és követelményeiről van szó. Nyugdíjas rendszerek belső mérnöke vagyok. Akkoriban ezeken a rendszereken dolgoztam. Pontosan elmondom, hogy az URL-ek miért különböztetik a kis- és nagybetűket. Ez nem tipp. Ez nem vélemény. Ez egy tény. Válaszomat szándékosan leegyszerűsítettem. Természetesen vannak fájlellenőrzések és egyéb folyamatok, amelyek elvégezhetők bármelyik nyitott utasítás kiadása előtt. És az Igen (!) Webkiszolgálók ennek eredményeként a mai napig részben bizonytalanok.
• Az, hogy az URL-ek megkülönböztetik-e a kis- és nagybetűket, semmi köze a web tervezéséhez? Igazán? A Hatóság érve, amelyet az Érvelés követ.Az, hogy a webszerverek többé-kevésbé közvetlenül továbbítják az URL útvonal-összetevőjét egy nyitott hívásnak, az URL-ek megtervezésének következménye, nem pedig annak oka. A szerverek (vagy intelligens kliensek FTP esetén) elrejthették a fájlrendszerek kis- és nagybetûsségét a felhasználó elõtt. Az, hogy nem ‘ t, tervezési döntés.
• @WilliamHay Lassítanod kell a fűtartályt, és újra kell olvasnod, amit írtam. Nyugdíjas rendszeren belüli mérnök vagyok, operációs rendszer-összetevőket, protokollhalmokat és útválasztókódokat írok az ARPA-Net-hez stb. Az Apache, az O ‘ Reilly és az IIS belső területeivel dolgoztam. Az FTP argumentum nem tart vizet, mivel legalább a fő FTP szerverek ugyanolyan okból megkülönböztetik a kis- és nagybetűket. Soha nem mondtam semmit az URL / URI tervezéséről. Sosem mondtam, hogy a webszerverek feldolgozás nélkül adtak át értékeket. Azt mondtam, hogy az operációs rendszer szolgáltatásait gyakran használják, és hogy a fájlrendszer pontos egyezést igényel a siker érdekében.
• @WilliamHay Kérjük, értse meg, hogy Ön és én keresztcélokon gondolkodunk. Csak annyit mondtam a válaszomban, hogy egyes operációs rendszerek esetén a fájlrendszer-hívások a kis- és nagybetűket figyelembe veszik. A rendszerhívásokat használó alkalmazások, amelyek a legtöbbjük, csak az operációs rendszer szabályainak betartására korlátozódnak – ebben az esetben az esetérzékenységre. Nem lehetetlen megkerülni ezt a szabályt. Valójában ez bizonyos esetekben kissé triviális lehet, bár nem praktikus. Munkám során rendszeresen megkerültem a fájlrendszert, hogy feloldjam a merevlemezeket, amelyek egy vagy másik okból mentek a kablooie-hoz, vagy elemeztem az adatbázisfájlok belső elemét stb.

1. Az URL-ek UNIFORM erőforrás-lokátornak vallják magukat, és az internetet megelőző erőforrásokra mutathatnak. Ezek egy része megkülönbözteti a kis- és nagybetűket (pl. Sok ftp-kiszolgáló), és az URL-eknek képeseknek kell lenniük arra, hogy ezeket az erőforrásokat ésszerűen intuitív módon képviseljék.

2. A kis- és nagybetűk közötti érzéketlenség több munkát igényel, amikor egy mérkőzés (akár az operációs rendszerben, akár felette).

3. Ha az URL-eket megkülönbözteti a kis- és nagybetűk között, akkor az egyes szerverek megkülönböztethetik kis- és nagybetűket. A fordítottja nem igaz.

4. Az esetérzékenység nemzetközi viszonylatban nem triviális lehet: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Az RFC1738 engedélyezte az ASCII tartományon kívüli karakterek használatát is, feltéve, hogy kódolták, de nem adtak meg karakterjelet. Ez meglehetősen fontos egy olyan dolog számára, amely magát a WORLD WEB-nek nevezi. Az URL-ek meghatározása kis- és nagybetűk nélkül nagy teret nyit meg a hibák.

5. Ha sok adatot próbál meg URI-be csomagolni (pl. egy Data URI ) többet csomagolhat, ha a kis- és nagybetűk különböznek egymástól.

Megjegyzések

• I ‘ eléggé biztos, hogy az URL-ek történelmileg csak az ASCII-re korlátozódtak. Tehát a nemzetközivé válás nem valószínű, hogy eredeti ok lenne. A Unix kis- és nagybetű-érzékeny története, az OTOH, valószínűleg hatalmas szerepet játszott.
• Míg az ASCII csak egy részhalmaza használható kódolatlanul egy URL-ben, az RFC1738 kifejezetten azt állítja, hogy az ASCII tartományon kívüli karakterek kódoltan használhatók. Jelkészlet megadása nélkül nem lehet tudni ‘ mely oktettek ugyanazt a karaktert képviselik acter, kivéve az esetet. Frissítve.
• Re # 4: ‘ valójában ennél rosszabb. Pontozott és pontatlan vagyok annak az általánosabb elvnek a bemutatása, hogy még akkor is, ha minden UTF-8 (vagy valamilyen más UTF), nem lehet nagybetűket vagy kisbetűket írni helyesen, ha nem ismerjük a szöveg területi beállításait . Az alapértelmezett területi beállításban az I nagybetűvel kisbetűket írunk egy kis i betűre, ami törökül helytelen, mert pontot ad hozzá (nincs ” török nagybetű nélküli I ” kódpont; ‘ az ASCII kódpontot akarja használni). Dobja be a kódolási különbségeket, és ez ” nagyon nehéz ” és ” között teljesen megoldhatatlan lesz . ”

A blogból loptam egy A régi új dolog szokása, hogy a “miért van ez így?” a “milyen lenne a világ, ha nem így lenne?” ellenkérdéssel

Tegyük fel, hogy beállítottam egy webszervert, hogy egy mappából kiszolgáljam magamnak a dokumentumfájljaimat, hogy tovább olvashassam őket a telefont, amikor kint voltam az irodában. Most a dokumentumok mappámban három fájlom van: todo.txt, ToDo.txt és TODO.TXT (Tudom, de volt értelme számomra, amikor elkészítettem a fájlokat).

Milyen URL-t szeretnék használni, hogy hozzáférhessek ezekhez a fájlokhoz? Intuitív módon szeretnék hozzájuk férni, a http://www.example.com/docs/filename használatával.

Tegyük fel, hogy van egy szkriptem, amellyel hozzáadhatok egy névjegyet a címjegyzékemhez, amit tudok az interneten keresztül is.Hogyan kell ennek megadnia a paramétereit? Nos, szeretném használni, például: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. De ha nem tudnám megadni a nevet esetenként, hogyan tenném?

Hogyan különböztetném meg a Cat és a CAT, a Text és a TEXT, a latex és a LaTeX wiki oldalait? Gondolom, a Disambig oldalak, de inkább csak megszerzem a kért dolgot.

De minden érzés amúgy rossz kérdésre válaszol.

Azt hiszem, valóban feltetted a kérdést: “Miért teszik a webszerverek 404-et csak esetkülönbségre, amikor számítógépek, úgy tervezték, hogy egyszerűbbé tegyék az életet” , és tökéletesen képesek megtalálni az általam beírt URL-ben legalább a legkézenfekvőbb eset-variációkat, amelyek működni fognak? “

A válasz az, hogy bár egyes webhelyek ezt megtették (és jobb, ha ellenőrizze, hogy vannak-e más elírások is), senki nem gondolta úgy, hogy érdemes megváltoztatni a webszerver alapértelmezett 404-es hibalehetőségét ehhez … de talán kellene?

Megjegyzések

• Egyes webhelyek valamilyen mechanizmust használnak a ny lekérdezés minden kisbetűvel vagy valami következetes. Bizonyos értelemben ez okos.
• Nem, nem kellene ‘ t. Ez a funkcionalitás hozzáadható, és gyakran hozzáadódik, amikor kívánatos (pl. Az apache-ban lévő modulok segítségével). Az ilyen jellegű változtatások alapértelmezett viselkedésként – vagy ami még rosszabb, megváltoztathatatlan viselkedésként – történő bevezetése zavaróbb lenne, mint a viszonylag ritka alkalom, amikor valakinek manuálisan kell beírnia a gazdagépnéven kívüli URL-t. Jó példa arra, hogy miért ne tenné ezt, idézze fel a fiaskót, amikor a Network Solutions ” javította a ” nem létező tartományhibákat a nyilvános DNS-ből lekérdezések.
• @SirNickity Senki sem javasolta a változtathatatlanságot semmilyen szinten, és a webszerver hibalehetőségei konfigurálhatók minden olyan webszerveren, amelyet valaha is használtam,

Bár a a fenti válasz helyes & jó. Szeretnék még néhány pontot hozzáadni.

A jobb megértéshez meg kell értenünk a Unix (Linux) Vs Windows szerver közötti alapvető különbséget. A Unix megkülönbözteti a kis- és nagybetűket & A Windows nem különbözteti meg a kis- és nagybetűket.

A HTTP-protokollt 1990 körül fejlesztették ki vagy kezdték bevezetni. A HTTP-protokollt a A CERN intézeteiben a napokban a tudósok Unix-gépeket használtak, nem pedig a Windows-ot.

A tudósok többsége ismerte a Unix-ot, ezért befolyásolhatta őket a Unix stílusú fájlrendszer.

A Windows szerver 2000 után jelent meg, jóval azelőtt, hogy a Windows Server népszerűvé vált volna. A HTTP protokoll jól érett és a specifikáció teljes volt.

Ez lehet az oka.

Megjegyzések

• ” A Windows szerver 2000 után jelent meg. ” A Windows NT 3.1 csapat 1993-ban nem értett volna egyet veled. NT 3.51 1995-ben valószínűleg akkor volt, amikor az NT elkezdett válni elég érett és megalapozott ahhoz, hogy támogassa az üzleti szempontból kritikus szerveralkalmazásokat.
• Az NT 3.51 rendelkezik a Win 3.1 felülettel. A Windows csak Windows 95 alatt indult el, és az NT 4.0 kellett ahhoz, hogy ugyanazt a felületet kapja.
• Michael Kj ö rling egyetértett. Engedje meg, hogy módosítsam.
• @Thorbj ø rnRavnAndersen A szerverpiacon az NT 3.51 meglehetősen sikeres volt. A fogyasztói / fogyasztói piacon addig tartott, amíg a Windows 2000 (NT 5.0) nem kezdte el, amíg az NT vonal komoly tapadást kezdett elérni.
• Valójában a WorldWideWebet eredetileg Unix-alapú rendszereken fejlesztették ki, amelyekben a kis- és nagybetűk különböznek egymástól. fájlrendszerek és a legtöbb URL, amelyek közvetlenül a fájlrendszer fájljaihoz vannak hozzárendelve.

Hogyan kell olvasni “miért tervezték így?” kérdés? Történelmileg pontos beszámolót kér a döntéshozatali folyamatról, vagy azt kérdezi, hogy “miért tervezné bárki is így?”?

Nagyon ritkán lehet történelmileg pontos képet kapni. számla.Néha, amikor a szabványügyi bizottságokban hoznak döntéseket, van egy dokumentális nyomvonal a vita lebonyolításáról, de a web kezdeteiben néhány ember – ebben az esetben valószínűleg maga a TimBL – siettette meg sietve a döntéseket, és az indoklás nem valószínű hogy leírták volna. De TimBL beismerte, hogy hibákat követett el az URL-ek megtervezésében – lásd: http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

A kezdeti időkben az URL-ek nagyon közvetlenül megfeleltek a fájlneveknek, és a fájlok általában Unix-szerű gépeken voltak, és a Unix-szerű gépeknél a kis- és nagybetűk különböznek. Tehát azt hiszem, hogy a megvalósítás kényelme érdekében éppen így történt, és a felhasználhatóságot (a végfelhasználók számára) soha nem is gondolták. Ismét a kezdeti idõkben a felhasználók amúgy is mind Unix programozók voltak.

Megjegyzések

• A végfelhasználók Unix-felhasználók is voltak (nem feltétlenül programozók, de nagy energiájú fizikusok és hasonlók), így ők is hozzászoktak az esetérzékenységhez.

Ez semmi köze ahhoz, hogy hol vásárolta meg a domainjét, a DNS nem különbözteti meg a kis- és nagybetűket. De a fájlrendszer a szerveren, amelyet tárhelyként használ, az.

Ez nem igazán kérdés, és meglehetősen gyakori a * nix gazdagépeken. Csak győződjön meg róla, hogy az összes link, amelyet az oldalaira írt, helytálló, és nem lesz problémája. A könnyebbség érdekében azt javaslom, hogy mindig csak kisbetűvel nevezze el az oldalakat, és soha nem kell még egyszer ellenőriznie a nevet egy link írásakor.

A Closetnoc-nak igaza van az operációs rendszerrel kapcsolatban. Egyes fájlrendszerek ugyanazt a nevet különböző betűkkel kezelik, mint különböző fájlokat.

Van-e valódi célja / előnye a kis- és nagybetűk megkülönböztetett URL-jének (szemben az URL-ek túlnyomó többségével, amelyek ugyanarra az oldalra mutatnak, mindegy a nagybetűs írásmód)?

Igen. az ismétlődő tartalmi problémák elkerülése érdekében.

Ha például a következő URL-ek voltak:

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 

és mindegyik pontosan ugyanarra az oldalra mutatott, pontosan ugyanazzal a tartalommal, akkor duplikált tartalma lenne, és biztos vagyok benne, hogy van Google kereső konzolja (webmestereszközök) fiókot, a Google ezt jelzi Önnek.

Mi vagyok Azt javasoljuk, hogy ha ilyen helyzetben van, akkor használja az összes kisbetűs URL-t, majd irányítsa át az URL-eket, amelyekben legalább egy nagybetű szerepel, a kisbetűs verzióra. Tehát a fenti URL-ek listájában irányítsa át az összes URL-t az első URL-re.

Megjegyzések

• ” Igen. az ismétlődő tartalmi problémák elkerülése érdekében. ” – De az ellenkezője igaznak tűnik? Az a tény, hogy az URL-ek megkülönböztethetik a kis- és nagybetűk megkülönböztetését (és a keresőmotorok így kezelik őket) okozza az Ön által említett ismétlődő tartalmi problémákat. Ha az URL-ek általában nem érzékenyek a kis- és nagybetűkre, akkor nem lennének ismétlődő tartalmi problémák eltérő betűkkel. A page-1 ugyanaz lenne mint a PAGE-1.
• Szerintem rossz a szerverkonfiguráció az okozhatja a tartalom megismétlését, ha a burkolatról van szó. Például a RewriteRule ^request-uri$ /targetscript.php [NC] .htaccess fájlban tárolt állítás megegyezik a http://example.com/request-uri és http://example.com/ReQuEsT-Uri adatokkal, mert A [NC] azt jelzi, hogy a burkolatnak nincs jelentősége az egy reguláris kifejezés kiértékelésekor.

A kis- és nagybetűk érzékenységének van értéke.

Ha 26 betű van, mindegyik nagybetűs képességgel rendelkezik, akkor ez 52 karakter.

A 4 karakter 52 * 52 * 52 * 52 kombinációval rendelkezik, egyenlő a 7311616 kombinációval.

Ha nem tudja nagybetűvel írni a karaktereket, akkor a kombinációk száma 26 * 26 * 26 * 26 = 456976

Több mint 14-szer több kombináció 52 karakternél, mint Adatok tárolásához az URL-ek rövidebbek lehetnek, és több információ továbbítható a hálózatokon, kevesebb adatátvitellel.

Ezért látja a youtube-ot olyan URL-ek használatával, mint a https://www.youtube.com/watch?v=xXxxXxxX