URL'ler neden büyük / küçük harf duyarlıdır?

Sorum şu: URL'ler ilk tasarlandığında neden büyük / küçük harfe duyarlılık bir özellik haline getirildi? Bunu sordum, çünkü bana (yani, bir uzmana), gereksiz hataları önlemek ve zaten karmaşık bir metin dizisini basitleştirmek için büyük / küçük harfe duyarsızlığın tercih edileceği düşünülüyor.

Ayrıca, büyük / küçük harfe duyarlı bir URL’ye sahip olmanın gerçek bir amacı / avantajı var mı (büyük harf kullanımı olursa olsun, aynı sayfaya işaret eden URL’lerin büyük çoğunluğunun aksine)?

Vikipedi, örneğin, harf büyüklüğüne duyarlı bir web sitesidir (ilk karakter hariç):

https://en.wikipedia.org/wiki/St Bir ck_Exchange DOA'dır .

URL neden büyük / küçük harf duyarlı olmasın?

Provokatif (ve "şeytanın savunucusu") bir retorik sorusu gibi görünebileceğini biliyorum, ama düşünmenin faydası olduğunu düşünüyorum. HTTP'nin tasarımı, genellikle "web tarayıcısı" olarak adlandırdığımız "istemci" nin, veri için "web sunucusu" nu istediğidir.

Yayımlanan birçok, birçok farklı web sunucusu var. Microsoft, Windows Server işletim sistemleriyle (ve Windows XP Professional dahil olmak üzere diğerleri) IIS'yi yayımladı. Unix, OpenBSD'nin dahili httpd'si veya thttpd veya lighttpd gibi daha küçük tekliflerden bahsetmeksizin nginx ve Apache gibi ağır ağırlıklara sahiptir. Ek olarak, ağ özellikli cihazların çoğu, yönlendiriciler (özellikle Wi-Fi erişim noktaları ve DSL modemleri dahil) ve diğer yazıcılar gibi diğer aygıtlar dahil olmak üzere, aygıtı yapılandırmak için kullanılabilen yerleşik web sunucularına sahiptir. Ağ bağlantısı olan UPS'ler (akü destekli kesintisiz güç kaynağı üniteleri).

Öyleyse, "URL’ler neden büyük / küçük harf duyarlıdır?" Sorusu soruyor, "Web sunucuları neden URL’yi büyük / küçük harf duyarlı olarak değerlendirir?" Ve gerçek cevap şudur: hepsi bunu yapmaz. Oldukça popüler olan en az bir web sunucusu genellikle büyük / küçük harfe duyarlı değildir. (Web sunucusu IIS'dir.)

Farklı web sunucuları arasındaki farklı davranışların kilit nedeni muhtemelen basitlik sorunudur. Bir web sunucusu yapmanın basit yolu, bilgisayarın / aygıtın işletim sisteminin dosyaları nasıl bulduğuyla aynı şeyleri yapmaktır. Çoğu zaman, web sunucuları bir cevap vermek için bir dosya bulur. Unix, daha yüksek uçlu bilgisayarların etrafında tasarlandı ve bu nedenle Unix, büyük ve küçük harflere izin vermek için istenen işlevselliği sağladı. Unix, büyük ve küçük harfleri farklı olarak ele almaya karar verdi, çünkü farklılar. Bu yapılacak basit ve doğal bir şey. Windows, önceden oluşturulmuş yazılımı destekleme arzusu nedeniyle büyük / küçük harf duyarlı olma geçmişine sahiptir ve bu tarih küçük harfleri desteklemeyen DOS'a geri döner, muhtemelen daha az bellek kullanan daha az güçlü bilgisayarlara sahip olanları basitleştirmek için. Bu işletim sistemleri farklı olduğu için, sonuç basitçe tasarlanmış (erken sürümlerde) web sunucularının aynı farklılıkları yansıtmasıdır.

Şimdi, tüm bu arkaplanla ilgili olarak, belirli soruların bazı özel cevapları:

URL'ler ilk kez tasarlandığında, büyük küçük harf duyarlılığı neden bir özellik haline getirildi?

Neden olmasın? Tüm standart web sunucuları büyük / küçük harf duyarlı değildir, bu, web sunucularının standart tarafından belirtilen bir dizi kurala uyduğunu gösterir. Bu davanın göz ardı edilmesi gerektiğini söyleyen hiçbir kural yoktu. Kural olmamasının nedeni, böyle bir kuralın olmasının hiçbir sebebi olmamasıdır. Gereksiz kuralları telafi etmek için neden uğraşasınız?

Bunu sordum, çünkü bana (yani, bir uzmana), gereksiz hataları önlemek ve zaten karmaşık bir metin dizisini basitleştirmek için büyük / küçük harfe duyarsızlığın tercih edileceği düşünülüyor.

URL'ler, makinelerin işlemesi için tasarlanmıştır. Bir kişi bir adres çubuğuna tam bir URL girebilse de, bu amaçlanan tasarımın büyük bir parçası değildi. Amaçlanan tasarım, insanların ("klik") köprülerini takip etmesidir. Ortalama meslekten olmayanlar bunu yapıyorsa, görünmez URL'nin basit veya karmaşık olup olmadığıyla gerçekten ilgilenmiyorlar.

Ayrıca, büyük / küçük harfe duyarlı bir URL’ye sahip olmanın gerçek bir amacı / avantajı var mı (büyük harf kullanımı olursa olsun, aynı sayfaya işaret eden URL’lerin büyük çoğunluğunun aksine)?

William Hay'ın cevabının beşinci noktası, bir teknik avantajdan bahsetmektedir: URL'ler, bir web tarayıcısının bir web sunucusuna biraz bilgi göndermesi için etkili bir yol olabilir ve daha az kısıtlama varsa daha fazla bilgi dahil edilebilir; kısıtlama, ne kadar bilginin dahil edilebileceğini azaltır.

Bununla birlikte, çoğu durumda, büyük olasılıkla IIS'nin genellikle bununla uğraşmadığı kanıtlanmış olan, büyük / küçük harfe duyarlılığa büyük bir yararı yoktur.

Özetle, en ilgi çekici neden, web sunucusu yazılımını tasarlayanlar için, özellikle de Unix gibi büyük küçük harf duyarlı bir platformda basitlik olabilir. (HTTP, Unix'in HTTP'den çok daha büyük olması nedeniyle, Unix'in orijinal tasarımını etkileyen bir şey değildi).

URL'ler büyük / küçük harfe duyarlı değildir, yalnızca bir kısmı bulunur.
Örneğin, URL’de hiçbir şey büyük / küçük harf duyarlı değildir https://google.com,

Atıfla Jenerik Dizim: Uniform Resource Identifier (URI) - RFC 3986

İlk olarak, Wikipedia'dan bir URL şöyle görünür:

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

(Parçayı kaldırdım user:passwordçünkü ilginç değil ve nadiren kullanılıyor)

• scheme:

şemaları büyük / küçük harf duyarlı değildir

• host:

Ana bilgisayar alt bileşeni büyük / küçük harf duyarlı değildir.

• path:

Yol bileşeni veri içeriyor ...

• query:

Sorgu bileşeni hiyerarşik olmayan veriler içeriyor ...

• fragment:

Bireysel medya türleri, farklı alt grup türlerini, görünümleri veya dış referansları belirlemek için parça tanımlayıcı sözdizimindeki kendi kısıtlamalarını veya yapılarını tanımlayabilir.

Yani, schemeve hostbüyük / küçük harf duyarsız.
URL'nin geri kalanı büyük / küçük harf duyarlıdır.

Neden büyük / pathküçük harfe duyarlı?

Bu ana soru gibi görünüyor. Belgelenmediyse bir şey yapıldığını "neden"
olarak cevaplamak zor , ancak çok iyi bir tahminde bulunabiliriz. Spesifikasyondan verilere vurgu yaparak çok spesifik alıntılar seçtim . URL’ye tekrar bakalım:

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

• Konum - Konum kurallı bir biçime sahiptir ve büyük / küçük harf duyarlı değildir. Neden? Muhtemelen binlerce çeşit satın almak zorunda kalmadan bir alan adı satın alabilirsiniz.

• Veri - veri hedef sunucu tarafından kullanılır ve uygulama ne anlama geldiğini seçebilir . Veri olayını duyarsız hale getirmek hiç mantıklı olmaz. Uygulama daha fazla seçeneğe sahip olmalı ve teknik özelliklerde büyük / küçük harf duyarlılığının tanımlanması bu seçenekleri sınırlayacaktır.
  Bu aynı zamanda HTTPS için de yararlı bir ayrımdır: veriler şifrelenir , ancak ana bilgisayar görülebilir.

Yararlı mı

Büyük / küçük harfe duyarlılık, önbelleğe alma ve kanonik URL'ler söz konusu olduğunda tuzakları vardır, ancak kesinlikle kullanışlıdır. Bazı örnekler:

• Veri URI'lerinde kullanılan Base64 .
• Siteler, URL'deki Base64 verilerini kodlayabilir, örneğin: http://tryroslyn.azurewebsites.net/#f:r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgACLGFLGFLFFFA
• URL kısaltıcılardan harf duyarlılığı kullanmaktadır: /a5Bdaha farklı olabilir/a5b
• Bahsettiğiniz gibi, Wikipedia “AIDS” i “AIDS” den ayırt edebilir.

Basit. İşletim sistemi büyük / küçük harf duyarlıdır. Web sunucuları genellikle dosya sistemine bir noktada vurmaları gerekmedikçe umursamazlar. Linux ve diğer Unix tabanlı işletim sistemlerinin dosya sisteminin kurallarını uyguladığı nokta burasıdır ki bu durumda duyarlılık büyük bir parçasıdır. Bu yüzden IIS hiç bir zaman büyük / küçük harf duyarlı olmamıştır; çünkü Windows hiçbir zaman büyük / küçük harfe duyarlı değildi.

[Güncelleme]

URL’lerin belirttiğim gibi dosya sistemiyle herhangi bir ilişkisi olup olmadığına ilişkin (silindiğinden beri) yorumlarda bazı güçlü tartışmalar oldu. Bu argümanlar ısıtıldı. Bir ilişki olmadığına inanmak son derece kısa görüşlü. Kesinlikle var! Daha fazla açıklayayım.

Uygulama programcıları genellikle sistem dahili programcıları değildir. Hakaret etmiyorum. Bunlar iki ayrı disiplindir ve uygulamaların işletim sistemine kolayca çağrı yapabileceği durumlarda uygulamalar yazmak için sistem iç bilgileri gerekmez. Uygulama programcıları sistemlerin dahili programcıları olmadığından, işletim sistemi hizmetlerini atlamak mümkün değildir. Bunu söylüyorum çünkü bunlar iki ayrı kamp ve nadiren karşıya geçiyorlar. OS servislerini kural olarak kullanmak için uygulamalar yazılır. Elbette bazı nadir istisnalar vardır.

Web sunucuları görünmeye başladığında, uygulama geliştiricileri işletim sistemi servislerini atlamaya çalışmadılar. Bunun birkaç nedeni vardı. Bir, gerekli değildi. İkincisi, uygulama programcıları genellikle işletim sistemi servislerini nasıl atlayacağını bilmiyorlardı. Üç, çoğu işletim sistemi ya son derece istikrarlı ve sağlam ya da son derece basit ve hafif ve maliyete değmezdi.

İlk web sunucularının DEC VAX / VMS sunucuları ve günün Unix'i (Berkeley ve Ultrix gibi diğerleri) gibi pahalı bilgisayarlarda, ana kasa veya orta kasa bilgisayarlarda çalıştıklarını, sonradan kısa bir süre sonra çalıştığını unutmayın. PC'ler ve Windows 3.1 gibi hafif bilgisayarlar. 1997 / 8’de Google gibi daha modern arama motorları görünmeye başladığında, Windows Windows NT’ye taşınmıştı ve Novell ve Linux gibi diğer işletim sistemleri de web sunucuları çalıştırmaya başlamıştı. Apache baskın web sunucusuydu ancak IIS ve O'Reilly gibi çok popüler olan başkaları da vardı. O zamanlar hiçbiri işletim sistemi hizmetlerini atlamamıştır. Web sunucularından hiçbirinin bugün bile yapmaması muhtemeldir.

Erken web sunucuları oldukça basitti. Hala bugünler. Bir sabit sürücüde bulunan bir HTTP isteği aracılığıyla bir kaynak için yapılan herhangi bir istek, web sunucusu tarafından OS dosya sistemi aracılığıyla yapılmıştır / yapılmıştır.

Dosya sistemleri oldukça basit mekanizmalardır. Bir dosyaya erişim için bir istek yapıldığında, bu dosya mevcutsa, istek yetkilendirme alt sistemine iletilir ve izin verilirse orijinal istek karşılanır. Kaynak yoksa veya yetkilendirilmemişse, sistem tarafından bir istisna atılır. Bir uygulama talepte bulunduğunda, bir tetikleyici ayarlanır ve uygulama bekler. İstek cevaplandığında, tetikleyici atılır ve uygulama istek yanıtını işler. Hala bugün bu şekilde çalışıyor. Uygulama isteğin yerine getirildiğini görürse devam eder, başarısız olursa, uygulama kodu içinde bir hata koşulu uygular veya işlenmezse ölür. Basit.

Bir web sunucusu söz konusu olduğunda, bir yol / dosya için bir URL isteğinin yapıldığını varsayarsak, web sunucusu, URL isteğinin yolunu / dosya kısmını alır (URI) ve dosya sistemine bir istek yapar; veya bir istisna atar. Web sunucusu daha sonra yanıtı işler. Örneğin, istenen yol ve dosya yetkilendirme alt sistemi tarafından bulunursa ve erişildiyse, web sunucusu bu G / Ç isteğini normal şekilde işler. Dosya sistemi bir istisna atarsa, dosya bulunmazsa web sunucusu 404 hatası, neden kodu izinsizse bir 403 Yasaktır.

Bazı işletim sistemleri büyük / küçük harf duyarlı olduğundan ve bu tür dosya sistemleri tam eşleşmeler gerektirdiğinden, web sunucusundan istenen yolun / dosyanın tam olarak sabit sürücüde var olanla eşleşmesi gerekir. Bunun nedeni basit. Web sunucuları ne demek istediğinizi tahmin etmiyor. Hiçbir bilgisayar programlanmadan bunu yapmaz. Web sunucuları istekleri aldıkça işler. URL isteğinin yol / dosya bölümü doğrudan dosya sistemine aktarılıyorsa, sabit sürücüde bulunanlarla eşleşmiyorsa, dosya sistemi bir istisna atar ve web sunucusu bir 404 Bulunamadı hatası verir.

Gerçekten bu kadar basit millet. Bu roket bilimi değil. Bir URL'nin yol / dosya kısmı ile dosya sistemi arasında mutlak bir ilişki vardır.

1. URL’ler bir UNIFORM Kaynak bulucu olduğunu iddia ediyor ve web’den önceki kaynakları işaret ediyor. Bunlardan bazıları büyük / küçük harf duyarlıdır (örneğin birçok ftp sunucusu) ve URL'lerin bu kaynakları makul bir şekilde sezgisel bir şekilde gösterebilmesi gerekir.

2. Büyük küçük harf duyarsızlığı, bir eşleşme ararken daha fazla çalışma gerektirir (işletim sisteminde veya üzerinde).

3. URL'leri büyük / küçük harf duyarlı olarak tanımlarsanız, tek tek sunucular bunları isterlerse büyük / küçük harf duyarlı olarak uygulayabilir. Tersi doğru değil.

4. Dava duyarsızlığı uluslararası bağlamlarda önemsiz olabilir: https://en.wikipedia.org/wiki/Dotted_and_dotless_I . Ayrıca RFC1738, kodlanmış ancak bir karakter kümesi belirtmemiş olması şartıyla ASCII aralığının dışındaki karakterlerin kullanımına izin vermiştir. Bu, dünya çapında web denen bir şey için oldukça önemlidir. URL'leri büyük / küçük harf duyarsız olarak tanımlamak, hatalar için çok fazla alan açacaktır.

5. Bir URI'ye (örneğin bir Veri URI'si ) çok fazla veri paketlemeye çalışıyorsanız, büyük ve küçük harflerin farklı olması durumunda daha fazla paketleyebilirsiniz.

Blogdan Eski Bir Yeni Şey çaldım "neden bir şey böyle?" Şeklindeki sorulara yaklaşma alışkanlığı. karşı soru ile "durum olmasaydı dünya nasıl olurdu?"

Diyelim ki bir klasörden kendime belge dosyalarımı sunmak için bir web sunucusu kurduğumu ve böylece ofisteyken telefonda okuyabilmemi sağladım. Şimdi, belgelerim klasöründe, ben üç dosya var todo.txt, ToDo.txtve TODO.TXT(ı biliyorum ama dosyaları yaptığında bana mantıklı geldi).

Bu dosyalara erişmek için hangi URL’yi kullanabilmek isterdim? Kullanarak sezgisel bir şekilde onlara erişmek istiyorum http://www.example.com/docs/filename.

Diyelim ki adres defterime web üzerinden de yapabileceğim bir kişi eklememe izin veren bir komut dosyası var. Bu parametreleri nasıl almalı? Peki, onu kullanmak istiyorum http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly. Ancak adı duruma göre belirtmem için bir yol olmasaydı, bunu nasıl yapardım?

Cat ve CAT, Text ve TEXT, lateks ve LaTeX için wiki sayfalarını nasıl ayırt edebilirim? Ben dezavantajlı sayfalar sanırım ama sadece istediğim şeyi almayı tercih ediyorum.

Ama yine de, yanlış soruya cevap veriyor gibi geliyor.

Gerçekten sorduğunu düşündüğüm soru şudur: "Neden web sunucuları 404'ü sadece bir dava farkı için, bilgisayar olduklarında, hayatı kolaylaştırmak için tasarlandılar ve en azından en belirgin durum değişikliklerini bulabilecekler. URL’nin işe yarayacağını yazdım? "

Bu sorunun cevabı, bazı siteler bunu yapmış olsa da (ve daha iyisi, diğer yazım hatalarını da kontrol ederler), hiç kimse bir web sunucusunun varsayılan 404 hata sayfasını değiştirmenin faydalı olacağını düşünmedi ... ama belki de yapmalı mı?

Yukarıdaki cevap doğru ve iyi olmasına rağmen. Biraz daha puan eklemek istiyorum.

Daha iyi anlamak için, Unix (Linux) Vs Windows sunucusu arasındaki temel farkı anlamak gerekir. Unix büyük / küçük harfe duyarlıdır ve Windows büyük / küçük harfe duyarlı değildir.

HTTP protokolü 1990 yılında geliştirildi veya uygulamaya geçmeye başladı. HTTP protokolü, CERN enstitülerinde çalışan mühendisler tarafından tasarlandı, o günlerin çoğu bilim adamı Unix makinelerini kullanıyordu, Windows kullanıyordu.

Bilim adamlarının çoğu Unix'e aşinaydı, bu yüzden Unix tarzı dosya sisteminden etkilenmiş olabilirler.

Windows sunucusu 2000'den sonra piyasaya sürüldü. Windows sunucusu popüler hale gelmeden çok önce HTTP protokolü iyi olgunlaştı ve şartname tamamlandı.

Sebep bu olabilir.

Kişi nasıl "neden bu şekilde tasarlandı" okumalı? soru? Karar verme sürecinin tarihsel olarak doğru bir hesabını mı soruyorsunuz, yoksa "neden birileri bu şekilde tasarlar?" Mı soruyorsunuz?

Tarihsel olarak doğru bir hesap almak çok nadiren mümkün. Bazen standart komitelerde kararlar alındığında, tartışmanın nasıl yapıldığına dair bir belgesel iz vardır, ancak web kararlarının ilk günlerinde birkaç kişi tarafından aceleyle yapıldı - bu durumda muhtemelen TimBL'nin kendisi tarafından - ve gerekçenin olasılığı düşüktür. yazılmış olması. Ancak TimBL, URL'lerin tasarımında hatalar yaptığını itiraf etti - bkz. Http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address -mistake.html

URL'lerin başında, URL'ler doğrudan dosya adlarıyla eşleştirilir ve dosyalar genellikle Unix benzeri makinelerdedir ve Unix benzeri makinelerde büyük / küçük harf duyarlı dosya adları bulunur. Bu yüzden benim tahminim, uygulama kolaylığı için bu şekilde gerçekleştiğini ve kullanılabilirliğin (son kullanıcılar için) hiç dikkate alınmadığı yönünde. Yine, ilk günlerde kullanıcılar zaten tüm Unix programcılarıydı.

Bunun etki alanınızı satın aldığınız yerle ilgisi yoktur, DNS büyük / küçük harf duyarlı değildir. Ancak, hosting için kullandığınız sunucudaki dosya sistemidir.

Bu gerçekten bir sorun değil ve * nix ana bilgisayarlarında oldukça yaygındır. Sayfalarınıza yazdığınız tüm bağlantıların doğru olduğundan ve bir sorun yaşamadığınızdan emin olun. Kolaylaştırmak için sayfalarınızı her zaman küçük harflerle adlandırmanızı öneririm, ardından bir bağlantı yazarken adı iki kez kontrol etmeniz gerekmez.

Closetnoc işletim sistemi konusunda haklıdır. Bazı dosya sistemleri, aynı adı, farklı dosyalar ile aynı kasada kullanır.

Ayrıca, büyük / küçük harfe duyarlı bir URL’ye sahip olmanın gerçek bir amacı / avantajı var mı (büyük harf kullanımı olursa olsun, aynı sayfaya işaret eden URL’lerin büyük çoğunluğunun aksine)?

Evet. yinelenen içerik sorunlarını önlemek için.

Örneğin, aşağıdaki URL’lere sahipseniz:

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

Hepsi de aynı içeriğe sahip aynı sayfaya dikkat çekti, sonra yinelenen içeriğiniz olacak ve bir Google arama konsolu (web yöneticisi araçları) hesabınız varsa, Google bunu size bildirecektir.

Bu durumda iseniz, küçük harfli URL'lerin hepsini kullanmak, daha sonra da en az bir büyük harf içeren URL'leri küçük harf sürümüne yönlendirmektir. Bu yüzden yukarıdaki URL’ler listesinde, tüm URL’leri ilk URL’ye yönlendirin.

Büyük küçük harf duyarlılığının değeri var.

26 harf varsa, her biri büyük harfle yazılabilir, bu 52 karakterdir.

4 karakter, 7311616 kombinasyona eşit 52 * 52 * 52 * 52 kombinasyon olasılığına sahiptir.

Karakterleri büyük harf yapamıyorsanız, kombinasyon miktarı 26 * 26 * 26 * 26 = 456976

52 karakterden 14 kat daha fazla kombinasyon vardır. 26'dan daha fazladır. Böylece, veri depolamak için URL'ler daha kısa olabilir ve daha az veri aktarımı olan ağlar üzerinden daha fazla bilgi iletilebilir.

Bu yüzden youtube'u https://www.youtube.com/watch?v=xXxxXxxX gibi URL’leri kullanarak görüyorsunuz.