Proč se v URL rozlišují velká a malá písmena?

Proč bych neměl v adrese URL se rozlišují velká a malá písmena?

Chápu, že to může vypadat jako provokativní (a „ďábelský obhájce“) typ rétorické otázky, ale myslím, že je užitečné ji zvážit. Návrh protokolu HTTP je že „klient“, kterému běžně říkáme „webový prohlížeč“, žádá „webový server“ o data.

Existuje mnoho různých webových serverů. Společnost Microsoft vydala IIS s Windows Serverové operační systémy (a další, včetně Windows XP Professional). Unix má těžké váhy jako nginx a Apache, nemluvě o menších nabídkách, jako je interní httpd OpenBSD, thttpd nebo lighttpd. Mnoho síťových zařízení má navíc zabudované webové servery, které lze použít ke konfiguraci zařízení, včetně zařízení se specifickými účely pro sítě, jako jsou směrovače (včetně mnoha přístupových bodů Wi-Fi a modemy DSL) a další zařízení, jako jsou tiskárny nebo Jednotky UPS (nepřerušitelné napájecí zdroje zálohované baterií), které mohou mít síťové připojení.

Takže otázka „Proč se v URL rozlišují velká a malá písmena?“ Se ptá: „Proč webové servery považují URL za rozlišovat velká a malá písmena? “ A skutečná odpověď je: nedělají to všichni. Alespoň jeden webový server, který je docela populární, obvykle NENÍ citlivý na velká a malá písmena. (Webový server je IIS.)

Klíčovým důvodem rozdílné chování mezi různými webovými servery se pravděpodobně scvrkává na jednoduchost. Jednoduchý způsob, jak vytvořit webový server, je dělat věci stejným způsobem, jakým operační systém počítače / zařízení vyhledává soubory. Webové servery mnohokrát vyhledají soubor, aby poskytly odpověď. Unix byl navržen kolem počítačů vyšší třídy, a proto Unix poskytoval žádoucí funkce umožňující velká a malá písmena. Unix se rozhodl považovat velká a malá písmena za odlišná, protože se liší. To je ta přímá, přirozená věc. Windows mají historii nerozlišování malých a velkých písmen kvůli touze podporovat již vytvořený software a tato historie sahá až k DOSu, který jednoduše nepodporoval malá písmena, možná ve snaze zjednodušit věci s méně výkonnými počítači, které využívají méně paměti. Protože se tyto operační systémy liší, výsledkem je, že jednoduše navržené (dřívější verze) webových serverů odrážejí stejné rozdíly.

Nyní, se vším tím pozadí, zde je několik konkrétních odpovědí na konkrétní otázky:

Když byly adresy URL poprvé navrženy, proč byla funkce rozlišována velká a malá písmena?

Proč ne? Pokud by všechny standardní webové servery nerozlišovaly velká a malá písmena, znamenalo by to, že webové servery dodržovaly sadu pravidel stanovených normou. Nebylo prostě žádné pravidlo, které říká, že tento případ je třeba ignorovat. Důvod, proč neexistuje žádné pravidlo, je prostě ten, že nebyl žádný důvod musí existovat takové pravidlo. Proč se obtěžovat vymýšlet zbytečná pravidla?

Ptám se na to, protože se mi to zdá (tj., laik), že by se upřednostňovala malá a velká písmena, aby se zabránilo zbytečným chybám a zjednodušil se i tak komplikovaný řetězec textu.

Adresy URL byly navrženy pro stroje ke zpracování . I když člověk může do adresního řádku zadat celou adresu URL, nebyla to hlavní část zamýšleného designu. Zamýšlený design je ten, že by lidé sledovali („klikali“) hypertextové odkazy. Pokud to dělají průměrní laici, opravdu nezajímejte se o to, zda je neviditelná adresa URL jednoduchá nebo komplikovaná.

Existuje také skutečný účel / výhoda použití adresy URL citlivé na velká a malá písmena (jako na rozdíl od velké většiny adres URL, které odkazují na stejnou stránku bez ohledu na velikost písmen)?

Pátý očíslovaný bod Odpověď Williama Haye zmiňuje jednu technickou výhodu: adresy URL mohou být pro webový prohlížeč účinným způsobem, jak odeslat trochu informací na webový server, a pokud je jich méně, mohou být zahrnuty další informace omezení, takže omezení citlivosti na malá a velká písmena by snížilo, kolik informací lze zahrnout.

V mnoha případech však neexistuje velká přesvědčivá výhoda pro citlivost na velká a malá písmena, která je dokazuje to skutečnost, že se s ním IIS obvykle neobtěžuje.

Stručně řečeno, nejpřesvědčivějším důvodem je pravděpodobně jen jednoduchost pro ty, kdo navrhli software webového serveru, zejména na platformě citlivé na velká a malá písmena, jako je Unix . (HTTP nebyl něco, co ovlivnilo původní design Unixu, protože Unix je výrazně starší než HTTP.)

Komentáře

• “ Klíčový důvod odlišného chování mezi různými webovými prohlížeči se pravděpodobně zkrátí na jednoduchost. “ – předpokládám, že znamená “ webové servery “ spíše než “ webové prohlížeče “ tady a na několika dalších místech?
• Aktualizováno. Zkontrolováno každý případ “ prohlížečů “ a provedl několik nahrazení. Děkuji, že jste na to upozornili, aby bylo možné zlepšit určitou kvalitu.
• Dostal jsem několik vynikajících odpovědí na mou otázku, od historických po technický. Váhám, zda jít proti proudu a přijmout odpověď s nižším hodnocením, ale odpověď @TOOGAM ‚ byla nejužitečnější pro mě. Tato odpověď je důkladná a obsáhlá, přesto vysvětluje koncept nekomplikovaným, konverzačním způsobem, kterému rozumím. A myslím si, že tato odpověď je dobrým úvodem do podrobnějších vysvětlení.
• Důvod, proč má Windows souborový systém nerozlišující velká a malá písmena, je způsoben tím ‚ s DOS dědictví. Systém MS-DOS zahájil život na počítačích, jako je Tandy TRS-80, který jako displej používal televizi a původně kvůli nedostatečnému rozlišení nepodporoval malá písmena. Protože ‚ t zobrazit malá písmena, smíšený případ nebyl ‚ t podporován. MS-DOS byl licencován IBM, aby se stal původním PC-DOS. Zatímco původní počítač mohl zobrazit malá písmena, souborový systém byl přenesen tak, jak je, z MS-DOS.

V adresách URL se nerozlišují velká a malá písmena, pouze jejich části.
Například v adrese URL nic nerozlišuje velká a malá písmena https://google.com,

S odkazem na RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax

Nejprve z Wikipedia , adresa URL vypadá takto:

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

(Odstranil jsem user:password část, protože není zajímavá a používá se jen zřídka)

• scheme :

schémata nerozlišují velká a malá písmena

• host :

V hostitelské podkomponentě se nerozlišují velká a malá písmena.

• path :

Součást cesty obsahuje data …

• query :

Komponenta dotazu obsahuje nehierarchická data …

• fragment :

Jednotlivé typy médií mohou definovat svá vlastní omezení nebo struktury v syntaxi identifikátoru fragmentu pro specifikaci různých typů podmnožin, pohledů nebo externích odkazů

Takže scheme a host nerozlišují velká a malá písmena.
Zbytek adresa URL rozlišuje velká a malá písmena.

Proč se v path rozlišují velká a malá písmena?

Zdá se, že to je hlavní otázka.
Je těžké odpovědět „proč“ něco se stalo, pokud to nebylo zdokumentováno, ale můžeme udělat velmi dobrý odhad.
Ze specifikace jsem vybral velmi konkrétní citáty s důrazem na data .
Podívejme se na adresu URL znovu:

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

• Umístění – umístění má kanonický tvar a nerozlišuje velká a malá písmena. Proč? Pravděpodobně byste si mohli koupit název domény, aniž byste museli kupovat tisíce variant.

• Data – data používá cílový server a aplikace si může vybrat, co to znamená . Nemělo by smysl dávat necitlivost na velká a malá písmena dat. Aplikace by měla mít více možností a definování necitlivosti na malá a velká písmena ve specifikaci tyto možnosti omezí.
  Toto je také užitečné rozlišení pro HTTPS: data jsou šifrována , ale hostitel je viditelný.

Je to užitečné?

Případ – citlivost má při ukládání do mezipaměti a kanonických adres URL svá úskalí, ale je určitě užitečná. Některé příklady:

• Base64 , který se používá v Data URI .
• Weby mohou kódovat data Base64 do adresy URL, například: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAlADIBCJgG4AvkA
• zkracovače adres URL využívají velká a malá písmena: /a5B se může lišit od /a5b
• Jak jste již zmínil, Wikipedia dokáže „AIDS“ odlišit od „Aids“.

Komentáře

• “ adresy URL nejsou cas e-sensitive. “ / “ Zbytek adresy URL rozlišuje velká a malá písmena. “ – Zdá se, že to je rozpor?
• Ve skutečnosti schéma definuje, co lze očekávat ve zbytku adresy URL. http: a související schémata znamenají, že adresa URL odkazuje na název hostitele DNS. DNS nerozlišoval velká a malá písmena v ASCII dlouho před vynálezem adres URL. Viz strana 55 v ietf.org/rfc/rfc883.txt
• Pěkně podrobné! Šel jsem z historického hlediska. Původně to byla cesta k souboru, která vyžadovala velká a malá písmena, pouze pokud jste narazili na systém souborů. Jinak tomu tak nebylo. Ale dnes se věci změnily. Například parametry a CGI původně neexistovaly. Vaše odpověď bere perspektivu aktuálního dne. Musel jsem odměnit vaše úsilí !! Opravdu jste se do toho pustili! Kdo věděl, že to vybuchne tak, jak to dopadlo ?? Na zdraví !!
• @ w3dk: je to ‚ nepříliš zajímavá terminologie, ale můžete si vzít “ malá a velká písmena “ to znamená, “ změna velikosti znaku může změnit celou “ nebo to můžete chápat tak, že “ změna velikosti znaku vždy změní celou „. Zdá se, že to Kobi prosazuje, dává přednost tomu, aby malá a velká písmena měla znamenat “ jakákoli změna v případě, že je významná „, což samozřejmě neplatí pro adresy URL. Dáváte přednost tomu prvnímu. ‚ Jde jen o to, jak jsou citlivé na velikost písmen.
• @ rybo111: Pokud uživatel zadá example.com/fOObaR , specifikace vyžaduje, aby server na adrese www.example.com obdržel cestu “ / fOObaR “ jak je uvedeno; mlčí o otázce, zda s tím server musí zacházet jinak než “ / foOBaR „.

Jednoduché. OS rozlišuje velká a malá písmena. Webovým serverům je to obecně jedno, pokud v určitém okamžiku nebudou muset zasáhnout souborový systém. To je místo, kde Linux a další operační systémy založené na Unixu prosazují pravidla souborového systému, přičemž citlivost je hlavní částí. Proto IIS nikdy nerozlišovala velká a malá písmena; protože Windows nikdy nerozlišovala velká a malá písmena.

[Aktualizace]

V komentářích (od odstranění) byly silné argumenty o tom, zda mají adresy URL nějaký vztah k systému souborů, jak jsem uvedl. Tyto argumenty se začaly zahřívat. Je nesmírně krátkozraké věřit, že neexistuje žádný vztah. Tam absolutně je! Vysvětlím to dále.

Programátoři aplikací nejsou obecně programátoři interních systémů. Neurážám. Jedná se o dvě samostatné disciplíny a znalost vnitřních systémů není nutná k psaní aplikací, když aplikace mohou jednoduše volat do OS. Jelikož aplikační programátoři nejsou interní programátoři systémů, obejití služeb operačního systému není možné.Říkám to proto, že se jedná o dva samostatné tábory a jen zřídka přecházejí. Aplikace jsou psány tak, aby zpravidla používaly služby OS. Samozřejmě existují vzácné výjimky.

Když se začaly objevovat webové servery, vývojáři aplikací se nepokusili obejít služby OS. Bylo pro to několik důvodů. Jeden, to nebylo nutné. Za druhé, aplikační programátoři obecně nevěděli, jak obejít služby OS. Tři, většina operačních systémů byla buď extrémně stabilní a robustní, nebo extrémně jednoduchá a lehká a nestála za cenu.

Pamatujte, že první webové servery fungovaly buď na drahých počítačích, jako je DEC VAX / Servery VMS a Unix dneška (Berkeley a Ultrix i další) na počítačích s hlavním nebo středním rámcem, brzy poté na lehkých počítačích, jako jsou PC a Windows 3.1. Když se začaly objevovat modernější vyhledávače, například Google v letech 1997/8, Windows se přesunul do Windows NT a další OS, jako Novell a Linux, začaly také provozovat webové servery. Apache byl dominantním webovým serverem, i když existovaly i jiné, jako jsou IIS a O „Reilly, které byly také velmi populární. Žádný z nich v té době služby OS neobcházel. Je pravděpodobné, že žádný z webových serverů to neudělá dodnes.

Brzy webové servery byly poměrně jednoduché. Stále jimi jsou dodnes. Veškerý požadavek na zdroj prostřednictvím požadavku HTTP, který existuje na pevném disku, byl / je podán webovým serverem prostřednictvím systému souborů OS.

Systémy souborů jsou poměrně jednoduché mechanismy. Jelikož je podán požadavek na přístup k souboru, pokud tento soubor existuje, je požadavek předán autorizačnímu podsystému a pokud je udělen, je původní požadavek splněn. Pokud prostředek ano neexistuje nebo není autorizován, systém vyvolá výjimku. Když aplikace provede požadavek, nastaví se aktivační událost a aplikace čeká. Po zodpovězení požadavku se aktivuje aktivační událost a aplikace zpracuje odpověď na požadavek. tak to funguje dodnes. Pokud aplikace vidí, že požadavek byl s pokud je přesvědčen, že pokračuje, pokud selhal, aplikace provede chybový stav v rámci svého kódu nebo zemře, pokud není zpracována. Jednoduché.

V případě webového serveru, za předpokladu, že je vytvořen požadavek na URL pro cestu / soubor, webový server vezme část cesty / souboru v požadavku na URL (URI) a provede požadavek do systému souborů a je buď spokojen, nebo vyvolá výjimku. Webový server poté zpracuje odpověď. Pokud je například nalezena požadovaná cesta a soubor a přístup je udělen autorizačním podsystémem, pak webový server zpracuje tento I / O požadavek jako obvykle. Pokud souborový systém vyvolá výjimku, vrátí webový server chybu 404, pokud soubor není nalezen, nebo 403 zakázán, pokud je kód příčiny neoprávněný.

Protože některé operační systémy rozlišují velká a malá písmena a souborové systémy tento typ vyžaduje přesné shody, cesta / soubor, který je vyžadován od webového serveru, musí přesně odpovídat tomu, co existuje na pevném disku. Důvod je jednoduchý. Webové servery nehádají, co tím myslíte. Žádný počítač tak nedělá, aniž by byl naprogramován. Webové servery jednoduše zpracovávají požadavky, jakmile je obdrží. Pokud část cesty / souboru požadavku URL předávaného přímo do systému souborů neodpovídá tomu, co je na pevném disku, pak souborový systém vyvolá výjimku a webový server vrátí chybu 404 Nenalezeno.

Je to opravdu tak jednoduché lidi. Není to raketová věda. Existuje absolutní vztah mezi částí cesty / souboru adresy URL a systémem souborů.

Komentáře

• Myslím, že váš argument je chybný. Zatímco Berners-Lee neměl ‚ žádnou volbu ohledně rozlišování malých a velkých písmen adres URL ftp. Dostal se k návrhu http URL. Mohl je specifikovat pouze jako US-ASCII a nerozlišovat velká a malá písmena. Pokud někdy existovaly nějaké webové servery, které právě předaly cestu URL do systému souborů, byly nezabezpečené a zavedení kódování URL narušilo kompatibilitu s nimi. Vzhledem k tomu, že cesta se zpracovává před předáním do operačního systému, by bylo snadné implementovat rozbíjení. Proto si myslím, že to musíme považovat za rozhodnutí o návrhu, nikoli za implementaci.
• @WilliamHay To nemá nic společného s Berners-Lee ani s designem webu. Jde o omezení a požadavky OS. Jsem inženýr interních systémů v důchodu. V té době jsem pracoval na těchto systémech. Říkám vám přesně, proč se v URL rozlišují velká a malá písmena. To není odhad. Není to názor. Je to fakt. Moje odpověď byla záměrně zjednodušena. Samozřejmě existují kontroly souborů a další procesy, které lze provést před vydáním jakéhokoli otevřeného příkazu. A proto jsou webové servery Yes (!) Částečně nejisté dodnes.
• Zda URL rozlišuje velká a malá písmena, nemá nic společného s designem webu? Opravdu? Argument autority následovaný argumentem tvrzení.To, že webové servery předávají komponentu cesty adresy URL víceméně přímo do otevřeného volání, je důsledkem návrhu adres URL, který není jeho příčinou. Servery (nebo inteligentní klienti v případě FTP) mohli uživateli skrýt citlivost malých a velkých souborů. To, že ‚ t, není rozhodnutí o designu.
• @WilliamHay Musíte zpomalit násypku trávy a znovu si přečíst, co jsem napsal. Jsem technik interních techniků ve výslužbě, který píše komponenty OS, protokolové sady a směrovací kódy pro ARPA-Net atd. Pracoval jsem s interními aplikacemi Apache, O ‚ Reilly a IIS. Váš argument FTP neobstojí, protože přinejmenším hlavní servery FTP zůstávají ze stejného důvodu citlivé na velká a malá písmena. Nikdy jsem neřekl nic o designu URL / URI. Nikdy jsem neřekl, že webové servery předaly hodnoty bez zpracování. Řekl jsem, že služby OS se běžně používají a že souborový systém vyžaduje k úspěchu přesnou shodu.
• @WilliamHay Pochopte prosím, že vy a já myslíme na různé účely. Ve své odpovědi jsem řekl jen to, že u některých operačních systémů jsou volání systému souborů záměrná. Aplikace, které používají systémová volání, se většinou omezují na vynucování pravidel operačního systému – v tomto případě se rozlišují velká a malá písmena. Toto pravidlo není možné obejít. Ve skutečnosti to může být v některých případech poněkud triviální, i když ne praktické. Při práci jsem rutinně obcházel souborový systém, abych dešifroval pevné disky, které z nějakého důvodu šly do kablooie, nebo jsem analyzoval interní soubory databázových souborů atd.

1. Adresy URL tvrdí, že jsou UNIFORMním vyhledávačem zdrojů, a mohou odkazovat na zdroje, které předcházejí webu. Některé z nich rozlišují velká a malá písmena (např. Mnoho serverů ftp) a adresy URL musí být schopny reprezentovat tyto zdroje rozumně intuitivním způsobem.

2. Rozlišování malých a velkých písmen vyžaduje více práce při hledání shoda (buď v OS nebo nad ní).

3. Pokud definujete adresy URL jako malá a velká písmena, mohou je jednotlivé servery implementovat jako malá a velká písmena, pokud chtějí. Opak není pravdivý.

4. Necitlivost písmen může být v mezinárodních kontextech netriviální: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . RFC1738 také umožňoval použití znaků mimo rozsah ASCII za předpokladu, že byly kódovány, ale neurčil charset. To je docela důležité pro něco, co si říká WORLD wide web. Definování URL jako malých a velkých písmen by otevřelo velký prostor pro chyby.

5. Pokud se snažíte zabalit velké množství dat do URI (např. Data URI ) můžete zabalit více, pokud se liší velká a malá písmena.

Komentáře

• I ‚ Jsem si jistý, že adresy URL byly historicky omezeny na ASCII. Internacionalizace tedy pravděpodobně nebude původním důvodem. Historie OTOH, v níž se rozlišují velká a malá písmena Unixu, pravděpodobně hrála velkou roli.
• I když lze v adrese URL použít nekódovanou pouze podmnožinu ASCII, RFC1738 konkrétně uvádí, že znaky mimo rozsah ASCII lze použít zakódované. Bez zadání charsetu to není možné ‚ vědět které oktety představují stejný znak herec kromě případu. Aktualizováno.
• Re # 4: Je to ‚ ve skutečnosti horší. Tečkovaný a bezbodový jsem ukázkou obecnějšího principu, že i když je vše UTF-8 (nebo nějaký jiný UTF), nemůžete správně psát velkými písmeny nebo malými písmeny, aniž byste znali národní prostředí, do kterého text patří . Ve výchozím národním prostředí je velké písmeno latinky I malé a malé písmeno latinky i, což je v turečtině špatné, protože přidává tečku (není zde “ turecké písmeno bez tečky I “ kódový bod; ‚ jste chtěli použít kódový bod ASCII). Vrhněte se na rozdíly v kódování, a to od “ opravdu těžké “ po “ zcela neřešitelné . “

Ukradl jsem z blogu a Old New Thing zvyk přistupovat k otázkám v podobě „proč je to tak?“ s protiotázkou „jaký by byl svět, kdyby tomu tak nebylo?“

Řekněme, že jsem nastavil webový server, aby si sám sloužil své soubory dokumentů ze složky, abych si je mohl přečíst na telefon, když jsem byl v kanceláři. Nyní mám ve složce s dokumenty tři soubory, todo.txt, ToDo.txt a TODO.TXT (Vím, ale při vytváření souborů mi to dávalo smysl.)

Jakou adresu URL bych chtěl použít, abych měl přístup k těmto souborům? Chtěl bych k nim přistupovat intuitivně pomocí http://www.example.com/docs/filename.

Řekněme, že mám skript, který mi umožňuje přidat kontakt do mého adresáře, který můžu také přes web.Jak by to mělo brát jeho parametry? Chtěl bych to použít jako: http://www.example.com/addcontact.php?name=Tom McHenry von der O"Reilly. Pokud bych ale nemohl název určit případem, jak bych to udělal?

Jak bych odlišil wiki stránky pro Cat a CAT, Text a TEXT, latex a LaTeX? Myslím, že disambigové stránky, ale dávám přednost tomu, abych dostal to, o co jsem žádal.

Ale vše, co cítím líbí se, stejně tak odpovídá na špatnou otázku.

Otázka, o které si myslím, že jste se opravdu ptali, je „Proč vám webové servery 404 slouží jen pro malý rozdíl, když jsou to počítače, jejichž cílem je zjednodušit život „a jsou dokonale schopni najít alespoň nejviditelnější případné variace adresy URL, které jsem zadal, které by fungovaly?“

Odpověď zní, že i když to některé stránky dokázaly (a ještě lépe, zkontrolujte i další překlepy), nikdo si nemyslel, že by to mělo smysl změnit výchozí chybovou stránku 404 webového serveru, aby to udělalo … ale možná by měli?

Komentáře

• Některé weby používají k převodu a. nějaký mechanismus ny dotaz na všechna malá písmena nebo něco konzistentního. Svým způsobem je to chytré.
• Ne, neměly by ‚ t. Tato funkce může být a často je přidána, když je to žádoucí (např. Pomocí modulů v apache.) Zavést tento druh změny jako výchozí chování – nebo horší, neměnné chování – by bylo rušivější než relativně vzácné příležitost, kdy někdo musí ručně zadat adresu URL za název hostitele. Dobrým příkladem, proč to neudělat, je fiasko, když Network Solutions “ opravila “ neexistující chyby domény z veřejného DNS dotazy.
• @SirNickity Nikdo nenavrhoval neměnnost na jakékoli úrovni a chybové stránky webového serveru jsou konfigurovatelné na každém webovém serveru, který jsem kdy používal; ‚ nikdo nenavrhoval nahrazení 404 30 * kódy, ale spíše přidání seznamu návrhových odkazů, na které lze kliknout, na chybovou stránku; názvy domén jsou velmi odlišné téma a problém nerozlišují velká a malá písmena a v jiném kontextu zabezpečení; a IIS již automaticky “ opravuje “ (ignorováním) případových rozdílů v části cesty nebo názvu souboru URI.
• Od roku 1996 vám to Apache umožňuje pomocí mod_speling . Prostě se to ‚ nejeví jako velmi populární věc. Lidé v systému Unix / Linux považují necitlivost na velká a malá písmena za pravidlo, necitlivost na velká a malá písmena jako výjimku.

Ačkoli výše uvedená odpověď je správná & dobrá. Chtěl bych přidat ještě několik bodů.

Abyste lépe porozuměli, měli byste pochopit základní rozdíl mezi serverem Unix (Linux) Vs Windows. Unix rozlišuje velká a malá písmena & Windows nerozlišuje velká a malá písmena.

Protokol HTTP byl vyvinut nebo se začal implementovat kolem roku 1990. Protokol HTTP byl navržen inženýry pracujícími na V ústavech CERN, většinou vědec používal unixové stroje a ne Windows.

Většina vědců znala Unix, takže na ně mohl mít vliv souborový systém stylu Unix.

Server Windows byl vydán po roce 2000. mnohem dříve, než se server Windows stal populárním, protokol HTTP byl dobře vyzrálý a specifikace byla kompletní.

To by mohl být důvod.

Komentáře

• “ Windows server byl vydán po roce 2000. “ Tým Windows NT 3.1 by s vámi v roce 1993 nesouhlasil. NT 3.51 v roce 1995 byl pravděpodobně v době, kdy se NT začal stávat dostatečně vyspělá a dobře zavedená podpora důležitých podnikových serverových aplikací.
• NT 3.51 měl rozhraní Win 3.1. Windows vzlétly opravdu až v systému Windows 95 a získání stejného rozhraní si vyžádalo NT 4.0.
• Michael Kj ö rling, souhlasil. Dovolte mi to upravit.
• @Thorbj ø rnRavnAndersen Na trhu serverů byl NT 3.51 přiměřeně úspěšný. Na trhu se spotřebiteli / prosumeri trvalo, než Windows NT (NT 5.0), než řada NT začala získávat vážnou trakci.
• Ve skutečnosti byl WorldWideWeb původně vyvinut na systémech založených na Unixu, které rozlišují velká a malá písmena. souborové systémy a většina adres URL mapovaných přímo na soubory v systému souborů.

Jak by se mělo číst a „proč to bylo navrženo takhle?“ otázka? Žádáte o historicky přesný popis rozhodovacího procesu, nebo se ptáte „proč by to někdo navrhoval takto?“?

Je velmi zřídka možné získat historicky přesný popis účet.Někdy, když se rozhodují ve výborech pro normalizaci, existuje dokumentární stopa toho, jak byla debata vedena, ale v raných dobách webových rozhodnutí byla spěšně učiněna několika jednotlivci – v tomto případě pravděpodobně samotným TimBL – a odůvodnění je nepravděpodobné být zapsán. TimBL ale připustil, že udělal chyby v designu adres URL – viz http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address-mistake.html

V raných dobách byly adresy URL mapovány velmi přímo na názvy souborů a soubory byly obvykle na unixových strojích a unixové stroje mají malá a velká písmena. Můj odhad je tedy takový, že se to právě stalo kvůli pohodlí implementace a použitelnost (pro koncové uživatele) nikdy nebyla vůbec zvážena. V počátcích byli uživatelé stejně všichni unixoví programátoři.

Komentáře

• Koncoví uživatelé byli také uživatelé Unixu (ne nutně programátoři, ale vysoce energetičtí fyzici a podobně), takže i oni byli zvyklí na necitlivost na velká a malá písmena.

Toto nemá nic společného s místem, kde jste doménu zakoupili, DNS nerozlišuje velká a malá písmena. Ale souborový systém na serveru, který používáte pro hostování, je.

To opravdu není problém a na hostitelích * nix je to docela běžné. Jen se ujistěte, že všechny odkazy, které na své stránky píšete, jsou správné a že nebudete mít problém. Aby to bylo jednodušší, doporučuji, abyste své stránky pojmenovávali vždy malými písmeny, takže při psaní odkazu nikdy nemusíte dvakrát překontrolovat jejich název.

Closetnoc má v OS pravdu. Některé systémy souborů zacházejí se stejným názvem jako s jinými soubory jako s jinými soubory.

Existuje také skutečný účel / výhoda použití adresy URL, která rozlišuje velká a malá písmena (na rozdíl od velké většiny adres URL, které odkazují na stejnou stránku bez ohledu na to, velká písmena)?

Ano. abyste se vyhnuli problémům s duplicitním obsahem.

Pokud byste měli například následující adresy URL:

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 

a všichni poukazovali na přesně stejnou stránku se stejným obsahem, pak byste měli duplicitní obsah, a jsem si jist, jestli máte vyhledávací konzolu Google účtu (nástroje pro webmastery), Google vám to oznámí.

Co bych chtěl Navrhuji, abyste v této situaci použili všechny malé adresy URL a poté adresy URL s alespoň jedním velkým písmenem přesměrovali na verzi s malými písmeny. V seznamu výše uvedených adres URL tedy přesměrujte všechny adresy URL na první adresu URL.

Komentáře

• “ Ano. abyste se vyhnuli problémům s duplicitním obsahem. “ – Zdá se však, že je to naopak? Skutečnost, že adresy URL mohou rozlišovat velká a malá písmena (a tak s nimi zacházejí vyhledávače) způsobuje problémy s duplicitním obsahem, které zmiňujete. Pokud by adresy URL obecně nerozlišovaly velká a malá písmena, nevznikly by problémy s duplicitním obsahem s odlišnými velkými a malými písmeny. page-1 by byl stejný jako PAGE-1.
• Myslím, že špatná konfigurace serveru je to, co může způsobit duplicitní obsah, pokud jde o velikost písmen. Například příkaz RewriteRule ^request-uri$ /targetscript.php [NC] uložený v souboru .htaccess by odpovídal http://example.com/request-uri a http://example.com/ReQuEsT-Uri, protože [NC] označuje, že při hodnocení tohoto regulárního výrazu nezáleží na ‚.

Citlivost malých a velkých písmen má svoji hodnotu.

Pokud existuje 26 písmen, každé z nich se schopností psát velkými písmeny, to je 52 znaků.

4 znaky mají možnost 52 * 52 * 52 * 52 kombinací, rovná se 7311616 kombinací.

Pokud znaky nemůžete psát velkými písmeny, je počet kombinací 26 * 26 * 26 * 26 = 456976

Je to více než 14krát více kombinací na 52 znaků než je jich 26. Takže pro ukládání dat může být URL kratší a více informací může být předáváno po sítích s menším množstvím přenesených dat.

Proto vidíte youtube pomocí URL jako https://www.youtube.com/watch?v=xXxxXxxX