URL'mde ne zaman eğik çizgi kullanmalıyım?

283

Bir URL'de ne zaman eğik çizgi kullanılmalıdır? Örneğin, URL'm /about-us/benzer /about-usmi veya benzemeli mi?

Yinelenen içerik ve kanonik şey - SEO ile ilgili sorunların tamamen farkındayım; Sayfaları tek başına doğru bir şekilde sunma bağlamında hangisini kullanmam gerektiğini anlamaya çalışıyorum .

Örneğin, meslektaşım sonunda bir eğik çizgi olduğunu, bunun bir "klasör" - bir "dizin" anlamına geldiğini düşünüyor, bu yüzden bu doğru bir stil değil. Ama sonunda bir eğik çizgi olmadan düşünüyorum - bu da doğru değil, çünkü neredeyse bir klasör gibi görünüyor, ama değil ve normal bir dosya değil, uzantısız bir dosya adı.

Hangisini kullanacağınızı bilmenin uygun bir yolu var mı?

— Denis
kaynak

Sonunda eğik çizgi, ama bence bu çoğunlukla estetik. Bak ve hisset.

— Eric Herlitz

3

Profesyonel Web Yöneticileri için aynı soru: URL yolunuz bir eğik çizgi ile biterse veya bitmezse bir fark yaratır mı?

— Stephen Ostermiller

4

Bu soru bir tercih olarak sorulmaktadır ve bu nedenle öncelikli olarak fikir temelli olarak konu dışı görünmektedir . Ancak cevabımın da gösterdiği gibi, aslında bu soruyu tercih meselesi olarak göstermek bir hatadır: bu bir XY problemidir ve temeldeki "gerçek" sorunun kesin bir teknik cevabı vardır ve bu nedenle öncelikle görüş temelli değildir .

— Raedwald

Google'ın ne tür URL'leri beğendiğiyle ilgili sorular ( wiki etiketinde belirtildiği gibi) programlamayla ilgili değildir ve Stackoverflow için konu dışıdır.

— Quentin

Sorunuzda birkaç düzenleme yaptım, lütfen fırsatınız olduğunda bunları iki kez kontrol edin. Thanks :)

— Tim Post

131

Kişisel görüşüme göre, sondaki eğik çizgiler yanlış kullanılıyor.

Temel olarak URL biçimi, daha sonra DOS sistemlerinde ve son olarak web için uyarlanmış aynı UNIX dosya ve klasör biçiminden geldi.

Unix benzeri bir işletim sistemindeki bu kitap için tipik bir URL, yerel sabit diskteki bir dosyaya kaydedilen elektronik kitabı tanımlayan file: ///home/username/RomeoAndJuliet.pdf gibi bir dosya yolu olacaktır.

Kaynak: Wikipedia: Tekdüzen Kaynak Tanımlayıcısı

Okumak için iyi bir kaynak: Wikipedia: URI Şeması

1994 yılında URL'leri tanımlayan RFC 1738'e göre, kaynaklar başka kaynaklara referanslar içerdiğinde, ikinci kaynağın konumunu "aşağıdaki akraba dışında bu yerle aynı" demek istiyormuş gibi tanımlamak için göreli bağlantılar kullanabilirler. yol". Bu tür göreli URL'lerin, göreli bağlantının dayandığı hiyerarşik bir yapı içeren orijinal URL'ye bağlı olduğunu ve ftp, http ve dosya URL şemalarının , hiyerarşinin bileşenleri "/" ile ayrılıyor.

Kaynak: Wikipedia Tekdüzen Kaynak Konum Belirleyicisi (URL)

Ayrıca:

Sık sık duyduğumuz soru bu. Cevaplara doğru! Geçmişte, eğik çizgi içeren URL'lerin bir dizini belirtmesi ve eğik çizgi eğrisi olmayan URL'lerin bir dosyayı belirtmesi yaygındır:

http://example.com/foo/ (sonunda eğik çizgi, geleneksel olarak bir dizin)

http://example.com/foo (eğik çizgi olmadan, geleneksel olarak bir dosya)

Kaynak: Google WebMaster Central Blog - Eğik çizgi veya eğik çizgi

En sonunda:

URL'nin sonundaki eğik çizgi, adresin "güzel" görünmesini sağlar.
Sonunda eğik çizgi ve uzantı içermeyen bir URL biraz "garip" görünüyor.
CSS dosyanızı hiçbir zaman adlandırmayacaksınız (örneğin) http://www.sample.com/stylesheet/ ?

AMA çevre ne olursa olsun en iyi web uygulamalarının savunucusu olmaktayım. URL olmadan URL hakkında söylediğiniz gibi, sakıncalı ve belirsiz olabilir.

— Dementic
kaynak

1

Bu, bir dosyayı isim olamaz garip "stil /" - eğik çizgi veya hiç eğik çizgi ve sunucuda tamamen farklı kaynaklar, ne kadar URL görünüyor

— nico Gawenda

10

@nicogawenda, .htaccess her türlü büyüyü yapabilir;) CSS'niz aslında bir php dosyası olabilir!

— rmorse

4

Web sunucuları sık yayınlanabilir varsayılan olarak ayarlanan index.htmlbir dizin erişildiğinde, bu nedenle (veya benzer dosya olarak adlandırılır) /foo/olduğu /foo/index.htmlekstra karmaşa olmadan. Ayrıca, geçmişte, tarayıcılar /alan adına eklenirdi , ancak onlar (Firefox, Chrome, Opera) o zamandan beri /ana sayfaya erişirken atlanacak.

— 0b10011

4

@Bfrohs ile hemfikirim. Elbette dizinler için varsayılan sayfalar bu ilkeye aykırıdır. Eğer 'trailing slash = directory' uygulayacaksak, mutlaka bir dizini işaret eden tüm URL'lerin ya bir dizin listesi ya da 403 yasaklı http yanıtı döndürmesi gerekir.

— Marvin

11

"Son olarak" bölümündeki 1 ve 2. noktaların hala doğru olup olmadığından emin değilim. Başlangıçta yazıldığından bu yana geçen yıllar boyunca lezzetler değişti. Bunu ayrıntılı olarak incelemedim, ancak yeni web sitelerinde, eğik çizgiyi atlamak daha yaygın ve "daha güzel" gibi görünüyor.

— speedplane

172

Bu bir tercih meselesi değil. /baseve /base/farklı semantiğe sahip. Çoğu durumda, fark önemsizdir. Ancak, göreli URL'ler olduğunda önemlidir.

childbağıl etmek /base/olduğunu /base/child.
childgöreceli olarak /base(belki şaşırtıcı bir şekilde) /child.

— Raedwald
kaynak

5

Bununla ilgili derinlemesine inceleme yapan faydalı makale: cdivilly.wordpress.com/2014/03/11/…

— Hephaestus

3

Evet, bunun SEO ile birlikte bu sorunun en önemli şeyleri olduğunu düşünüyorum.

— user2875289

.Net'leri kullanırken bu sorunu yaşadım Uri.MakeRelativeUri. Sonuçlar tam olarak söylediklerinizi yansıtır. Tabanımın sonuna eğik çizgi ekleyerek sorunu çözdüm Uri.

— julealgon

61

Her zaman dizin dışı URL'lerde (diğerlerinin yanı sıra WordPress) eğik çizgilerin yaygın kullanımı beni şaşırttı. Bu gerçekten bir ya da tartışma olmamalı, çünkü bir kaynaktan sonra eğik çizgi koymak anlamsal olarak yanlıştır. Web, adreslenebilir kaynaklar sunmak için tasarlandı ve bu adresler - URL'ler * bir * nix tarzı dosya sistemi hiyerarşisini taklit etmek için tasarlandı. Bu bağlamda:

Eğik çizgiler her zaman dizinleri gösterir, asla dosyaları göstermez.
Dosyalar herhangi bir adla (uzantılı veya uzantısız) adlandırılabilir, ancak eğik çizgiler içeremez veya bitiremez.

Bu yönergeleri kullanarak, dizin olmayan bir kaynaktan sonra eğik çizgi koymak yanlıştır.

— Yarin
kaynak

50

"kaynaklardan sonra değil, dizinlerden sonra eğik çizgi": URL'ler "kaynak" ve "dizinler" olmak üzere iki tür şeyi ifade etmez; bir tür şeye atıfta bulunurlar: kaynaklar. İpucu URL'nin R'sindedir.

— Raedwald

31

Ve * nix dosya sistemindeki her şey bir dosyadır, ancak dizinler hala mevcuttur. Ne demek istiyorsun?

— Yarin

6

İster bir dosya ister bir dizin tarafından dahili olarak sunulsun, kullanıcının gördüğü sadece bir web sayfasıdır. Ve example.com/about aslında okuma olabilir example.com/about/index.html .

— musiphil

1

@DavidRR: Haklısın. Ad çözümlemesi içeriden gerçekleşmesi gerekiyor çünkü tarayıcı yönlendirme ihtiyacı directory(aksi image.pngde http://hostname/directoryişaret olacaktır http://hostname/image.png). Sadece bir dosya ile bir dizin arasındaki ayrımın kullanıcının bakış açısından çok önemli olmayabileceğini söylüyordum.

— musiphil

2

Sonucunuza katılıyorum, ancak URL sistemimizi * nix tarzı dosya sistemlerini taklit edecek şekilde tasarlamamız gerektiğinden emin değilim. Bu aslında bir amaca hizmet etmiş olabilir, ama şimdi çok daha az.

— speedplane

27

Bu gerçekten bir estetik sorunu değil, aslında teknik bir fark. Dizin düşünce tamamen doğru ve hemen hemen her şeyi açıklıyor. Hadi halledelim:

Artık taş çağına geri döndünüz veya sadece statik sayfalar sunuyorsunuz

Web sunucunuzda sabit bir dizin yapınız vardır ve yalnızca resimler, html vb. Gibi statik dosyalar vardır - sunucu tarafı komut dosyaları veya herhangi bir şekilde.

Bir tarayıcı ister /index.htm, var ve istemciye teslim edilir. Daha sonra /dvd/dizinde her biri için DVD filmleri incelendi ve bir html sayfası var . Şimdi birisi talep ediyor /dvd/adams_apples.htmve orada olduğu için teslim ediliyor.

Bir gün, birisi sadece istekte bulunur /dvd/- bu bir dizin ve sunucu ne sunacağını anlamaya çalışıyor. Erişim kısıtlamaları yanında ve benzeri iki olasılık vardır: Kullanıcıya dizin içeriğini göster (Ben zaten bu bir yere gördük bahis) ya da varsayılan bir dosyayı göstermek (Apache öyle: DirectoryIndex: sets the file that Apache will serve if a directory is requested.)

Şimdiye kadar iyi, beklenen durum bu. Zaten kullanımdaki farkı gösteriyor, bu yüzden içine girelim:

Saat 5:34'te dosyalarınızı yüklerken bir hata mı yaptınız?

(Bu arada tamamen anlaşılabilir.) Yani, tamamen yanlış bir şey yaptınız ve yüklemek yerine /dvd/the_big_lebowski.htmbu dosyayı dvd(uzantısız) olarak yüklediniz /.

Birisi /dvd/dizin listenizi işaretledi (elbette bu şıklığı oluşturmak ve her zaman güncellemek istemediniz index.htm) ve web sitenizi ziyaret ediyor. Dizin içeriği dağıtılır - her şey yolunda.

Birisi listenizi duydu ve yazıyor /dvd. Ve şimdi vidalandı. DVD dizini listelemek yerine, sunucu bu ada sahip bir dosya bulur ve Big Lebowski dosyanızı teslim eder.

Böylece, bu dosyayı siler ve adama sayfayı yeniden yüklemesini söylersiniz. Sunucunuz /dvddosyayı arar , ancak gitti. Çoğu sunucu bu ada sahip bir dizin olduğunu fark eder ve istemciye aradığı şeyin gerçekten başka bir yerde olduğunu söyler. Yanıt büyük olasılıkla şöyle olacaktır:

Status Code:301 Moved Permanently ile Location: http://[...]/dvd/

Yani, tamamen yoksayıyorsunuz Eğer farklı söylendi sürece - - dizinleri veya dosyaları hakkında, sunucu ancak böyle şeyler işlemek ve düşünüyorum "eğik çizgi veya olmasın" anlamı hakkında size karar verir.

Sonunda bu yanıtı aldıktan sonra istemci yüklenir /dvd/ve her şey yolunda gider.

İyi mi? Hayır.

"Sadece iyi" senin için yeterince iyi değil

Her şeyin aktarıldığı /index.phpve işlendiği dinamik bir sayfanız var . Şimdiye kadar her şey çok iyi çalıştı, ama tüm bunlar daha yavaş hissetmeye başlar ve siz araştırırsınız.

Yakında, fark edeceksiniz /dvd/listaynı yapıyor: Yönlendirme için /dvd/list/hangi sonra dahili çevrilir index.php?controller=dvd&action=list. Bir ek istek - ama daha da kötüsü! customer/loginyönlendirmeleri için customer/login/bu da HTTPS URL'sini yönlendirir customer/login/. Kullanıcı deneyimini yavaşlatan tonlarca gereksiz HTTP yönlendirmesi (= ek istek) elde edersiniz .

Büyük olasılıkla burada da varsayılan bir dizin dizininiz var: sadece dahili yükler index.php?controller=dvdolmadan .actionindex.php?controller=dvd&action=list

Özet:

Eğer bitiyorsa asla bir dosya /olamaz . Sunucu tahmini yok.
Eğik çizgi veya eğik çizgi tamamen farklı anlamlardır. "Eğik çizgi veya eğik çizgi yok" arasında teknik / kaynak farkı var ve bunun farkında olmalı ve buna göre kullanmalısınız. Sunucunun büyük olasılıkla /dvd/index.htmdoğru komut dosyasını yüklemesi - veya yüklemesi - derken /dvd: Bunu yapar, ancak doğru isteği yaptığınız için değil. Hangi olurdu /dvd/.
Kesik çizgili sürümü gerçekten de kastetmişseniz , ek bir HTTP isteği cezası verir. Bu her zaman kötüdür (mobil gecikmeyi düşünün) ve bir "güzel URL" den daha fazla ağırlığa sahiptir - özellikle tarayıcılar SEO'ların inandığı veya inanmanızı istediği kadar aptal olmadığı için;)

— nico gawenda
kaynak

2

Özet olarak, sonunda eğik çizgiyi eklemek için hepiniz misiniz? :)

— Denis

2

Bunu kastettiğiniz zaman kullanmak için kullanıyorum;) Örneğin denetleyicilerden ve eylemlerden bahsetmek şöyle olur: Denetleyiciler eğik çizgi ile bitmelidir. Bir dosyaya veya bir eyleme

— başvurduğunuzda

Bir dakika, neden bir eylem için eğik çizgiyi atlasın ki? Örneğinize göre, bu fazladan yönlendirilmiş istekle sonuçlanmayacak mı? Yani, muhtemelen sunucunuz bir denetleyici eylemini tanıyacak kadar akıllıdır ve aslında bu durumda dosya veya dizin aramak için yönlendirmez, ancak yine de örneğinize aykırı değil mi?

— Adam Goodwin

7

Örneğini anlamıyorum. Hangi dosya sistemi bir dizine ve aynı ada sahip başka bir normal dosyaya ( dvd) izin verir ?

— musiphil

19

Eğer URL yaptığınızda /about-us/(sondaki eğik çizgi ile), tek dosya ile başlamak çok kolaydır index.htmlve daha sonra genişletmek ve daha fazla dosya (örneğin eklemek our-CEO-john-doe.jpgo (örn altında bir hiyerarşi inşa çift) veya /about-us/company/, /about-us/products/gerektiği gibi, vs.) olmadan yayınlanan URL'yi değiştirme . Bu size büyük bir esneklik sağlar.

— musiphil
kaynak

9

Üzgünüm, anlamadım. ile başlarsam /about-usveya /about-us/dizini genişletirsem her iki durumda da yayınlanan URL'yi değiştirmem gerekir. yeni dosya her /about-us/new-file.htmliki durumda da olacak !! burada ne eksik?

— Muhasebeci م

2

@ Muhasebeci OP düşünüyorum eğer bir eğik çizgi olmadan "/ about-us" yayınlamak o zaman daha sonra göreceli yolları kullanarak alt kaynakları ekleyemez düşünüyorum. Sondaki eğik çizginiz olmadığında, tarayıcı, yaklaşık sayfadaki "ceo.jpg" referansının alan adınızın kökünde yaşayacağına ve example.com/ceo.jpg isteğinde bulunacağına inanır. Eğik çizgi ile tarayıcı example.com/about-us/ceo.jpg dosyasını isteyecektir ve genişlettikçe siteniz için tüm klasör ağacını statik olarak yönlendirebilirsiniz.

— 17'de

1

FYI - Yukarıdakilerin hiçbirinin doğru olduğuna inanmıyorum - Neden bir /about-usve olamaz /about-us/company? Dosyaları sunma açısından, hem Apache hem de IIS bunu iyi işleyebilir, bu yüzden katılmıyorum.

— sean2078

1

@ sean2078 Evet, ama eğer /about-usbağlantı kurmak /about-us/companyistiyorsan kullanmalısın href="https://stackoverflow.com/about-us/company"ya da href="./company"(bundan emin değilsin). Eğer biri /about-us/olsa da, 's basit: href="company".

— Adowrath

11

Buradaki diğer cevaplar, sondaki eğik çizgiyi atlamayı tercih ediyor gibi görünüyor. Orada bir sondaki eğik çizgi arama motoru optimizasyonu (SEO) ile yardımcı olacaktır. Bu, belgenizde olmayan bir dosya uzantısı gibi görünen bir durumdur .html. Bu, web sitelerini derecelendiren sitelerde bir sorun haline gelir. Bu iki url arasında seçim yapabilirler:

http://mysite.example.com/rated.example.com
http://mysite.example.com/rated.example.com/

Böyle bir durumda, sonunda eğik çizgi olanı seçerdim . Bunun nedeni, .comuzantının Windows yürütülebilir komut dosyaları için bir uzantı olmasıdır. Arama motorları ve virüs denetleyicileri, genellikle bu tür mekanizmalar aracılığıyla dağıtılan kötü amaçlı yazılım içerebildikleri görünen URL'lerden hoşlanmazlar. Sondaki eğik çizgi, sayfanın arama motorlarında sıralanmasına ve virüs denetleyicileri tarafından alınmasına izin vererek endişeleri hafifletiyor gibi görünüyor.

URL'leriniz .dosya bölümünde yoksa , basitlik için eğik çizgiyi atlamayı öneririm.

— Stephen Ostermiller
kaynak

Hiçbir gerçek arama motoru bu kadar aptal değil. Bu cevap saf spekülasyon.

— Navin

1

Aslında bu sorunu Google'da gördüm. Birkaç yıl önceydi, bu yüzden bugün hala böyle olup olmayacağından emin değilim.

— Stephen Ostermiller

Ha, bu iyi bir veri noktası. Yine de başka bir şeyden kaynaklanıp kaynaklanmadığını bilmiyoruz.

— Navin

10

Kim bir dosya adının bir uzantıya ihtiyacı olduğunu söylüyor ?? bir ara bir * nix makinesine bir göz atın ...
Arkadaşınıza katılıyorum, sondaki eğik çizgi yok.

— Aaron Gage
kaynak

3

SEO açısından bakıldığında, bir URL'nin sonuna bir eğik çizgi eklenip eklenmeyeceğini seçmek önemsizdir. Bu günlerde, web'de her ikisinin de örneklerini görmek yaygındır. Bir site her iki şekilde de cezalandırılmayacak ve bu seçim web sitenizin arama motoru sıralamasını veya diğer SEO hususlarını etkilemeyecektir.

Tercih ettiğiniz bir URL adlandırma kuralı seçin ve <head>her web sayfasının bölümüne standart bir meta etiket ekleyin .

Onlar, yani birlikte ve bölü çizgisi onu karşılaştıklarında iki ayrı yinelenen URL'ler gibi tek bir web sayfası düşünebilir arama motorlarına example.com/about-us/ve example.com/about-us.

Diğer sitelerin URL'lerinize nasıl bağlandığını kontrol edemediğiniz için her sayfaya standart bir meta etiket eklemek en iyi yöntemdir.

Kanonik etiketi şuna benzer: <link rel="canonical" href="https://example.com/about-us" />. Standart bir meta etiket kullanmak, diğer web sitelerinin sitenize bağlanırken bir eğik çizgi içerip içermediğine bakılmaksızın, arama motorlarının URL'lerinizin her birini yalnızca bir kez saymasını sağlar.

— isyan
kaynak