Kolay URL için güvenli karakterler [kapalı]


168

Makaleler içeren bir web sitesi yapmam gerekiyor ve bunun için kolay URL'ler, örneğin sayfanın URL'si ile

Başlık: Makale Testi

haline gelmelidir: http://www.example.com/articles/article_test.

Tabii ki başlıktan bazı karakterleri ?veya gibi #çıkarmam gerekiyor, ancak hangilerini kaldıracağından emin değilim.

Birisi bana hangi karakterlerin saklanabileceğini söyleyebilir mi?


Burada da benzer bir soru vardı . Göz atın, orada bazı yararlı cevaplar da bulabilirsiniz (oldukça fazla vardı).
Kale

Yanıtlar:


210

RFC 3986'nın 2.3 bölümünü alıntılamak için :

"Bir URI'de izin verilen, ancak ayrılmış bir amacı olmayan karakterlere, rezerve edilmez denir. Bunlar büyük ve küçük harfler, ondalık basamaklar, kısa çizgi, nokta, alt çizgi ve tilde içerir."

ALPHA  DIGIT  "-" / "." / "_" / "~"

RFC 3986'nın eski RFC 2396'dan daha az ayrılmış noktalama işareti listelediğini unutmayın .


@Skip Head, "karakterler" çve gibi Latin kodlamalı karakterler içeriyor õmu?
Mohamad

6
@Mohamad: Hayır, yalnızca ASCII, UTF-8 desteği iyileşiyor.
Dietrich Epp

@Dietrich Epp, teşekkür ederim. Www.mysite.com/[postId]/post-title-with-ç-and-õ: Ben gerektiği önemli değil URL gibi, dekorasyon ve SEO amaçlı olup olmadığını tahmin
Mohamad

1
@Mohamad: Buradaki son bölüm, kaputun altına değiştirilecek post-title-with-%C3%A7-and-%C3%B5, ancak kullanıcının konum çubuğunda olarak görüntülenmeye devam edecek post-title-with-ç-and-õ.
Dietrich Epp

7
Okuyucularınız Portekizce, bu yüzden Portekizce karakterler kullanın.
Dietrich Epp

107

Dikkat etmeniz gereken iki karakter grubu vardır: ayrılmış ve güvensiz .

Ayrılmış karakterler şunlardır:

  • ve işareti ("&")
  • dolar ("$")
  • artı işareti ("+")
  • virgül (",")
  • eğik çizgi ("/")
  • kolon (":")
  • noktalı virgül (";")
  • eşittir ("=")
  • soru işareti ("?")
  • 'At' sembolü ("@")
  • pound ("#").

Genellikle güvensiz olarak kabul edilen karakterler şunlardır:

  • Uzay (" ")
  • küçüktür ve büyüktür ("<>")
  • köşeli parantez açma ve kapatma ("[]")
  • kaşlı ayraçları açma ve kapatma ("{}")
  • boru ("|")
  • ters eğik çizgi ("\")
  • düzeltme işareti ("^")
  • yüzde ("%")

Bir ya da daha fazlasını unutmuş olabilirim, bu da Carl V'nin cevabını tekrarlamamı sağlıyor. Uzun vadede, sunucular ve sistemler tarafından izin verilmeyen karakterlerden haberdar olmaya çalışmak yerine, izin verilen karakterlerin "beyaz listesini" kullanmak ve daha sonra dizeyi kodlamak daha iyidir.


#, belirli bir sayfadaki yer imleri için kullanılan, eşleşen ad özniteliğine veya id özniteliğine (sans #-symbol) sahip bir HTML öğesine sahip olarak oluşturulan ayrılmış bir karakterdir .
TheLonelyGhost

Teşekkürler - Cevabı güncelledim.
Gary.Ray

Soru işareti burada hem ayrılmış hem de güvensiz olarak ortaya çıkıyor - Ben sadece ayrılmış olarak düşünüyorum, ama yanlış olabilir
Jonathan Basile

6
Diğerleri tilde ~güvensiz olduğunu kabul etmiyor . Emin misin?
drs

3
İngilizce dışındaki dilleri işlerseniz beyaz liste o kadar iyi değildir. Unicode çok fazla OK kod noktasına sahip. Bu nedenle, güvensiz olanları kara listeye almak normal ifadelerde uygulanması en kolay yöntemdir.
Patanjali

41

Belirli karakterleri (kara liste) kaldırmak yerine yalnızca bazı karakterleri (beyaz liste) saklarsınız.

Doğru şekilde kodladığınız sürece herhangi bir karaktere teknik olarak izin verebilirsiniz. Ancak, sorunun ruhuna cevap vermek için sadece şu karakterlere izin vermelisiniz:

  1. Küçük harfler (büyük harfleri küçük harfe dönüştür)
  2. 0'dan 9'a kadar sayılar
  3. Kısa çizgi - veya alt çizgi _
  4. Tilde ~

Diğer her şeyin potansiyel olarak özel bir anlamı vardır. Örneğin, + kullanabileceğinizi düşünebilirsiniz, ancak bir boşlukla değiştirilebilir. & özellikle bazı yeniden yazma kuralları kullanılıyorsa tehlikelidir.

Diğer yorumlarda olduğu gibi, tüm ayrıntılar için standartları ve teknik özellikleri inceleyin.


15
Bugün keşfettiğim bir preiod, URL güvenli Base64 kodlayıcı için kullanılacak kötü bir karakter seçimidir, çünkü kodlanmış verilerinizin birbirini izleyen iki nokta ("..") üretebileceği nadir durumlar olacaktır. üst dizine atıfta bulunur.
pohl

5
@pohl: Bu yalnızca URL'niz kodunuzda bir dosya yolu olarak kullanılıyorsa veya web sunucunuz, isteği bir komut dosyasına iletmeden önce URL'yi dosyalarla eşlemeye çalışırsa (ne yazık ki çok yaygın) bu bir sorundur.
André Caron

4
Aslında, bizim durumumuzda bunu bir dosya yolu olarak kullanmak tamam olurdu, çünkü unix dosyalarında isimlerinde birden fazla ve hatta ardışık nokta bulunmasına izin verilir. Bizim için sorun, bir hataya (belki de naif bir regex) sahip Site Kapsamı adlı bir izleme aracında ortaya çıktı ve sahte sahte duruş sürelerini bildiriyordu. Bizim için, Site Kapsamı'nın eski bir sürümüne takılı kalıyoruz, yönetici ekibi bir yükseltme için ödeme yapmayı reddediyor ve çok önemli bir müşterinin sözleşmesine yazılı Site Kapsamı (eşdeğeri değil) var. Kuşkusuz, çoğu kendilerini ayakkabılarımda bulamazlar.
pohl

8
Çok şüphe duymadan birisinin bir liste yayınladığı için şükürler olsun. Nokta (.) Gelince - @pohl'un dediği gibi kullanmayın! IIS'de başka bir garip durum (bunun diğer Web Sunucularında olup olmadığını bilmiyorum): URL'nizin sonunda büyük olasılıkla 404 hatası alırsınız ([/ pagename] aramaya çalışır) . sayfa)
nikib3ro

34

Daima Güvenli

Bunlar güvenlidir (teoride / spesifikasyonda), temel olarak alan adı dışında herhangi bir yerde.
Listelenmeyen herhangi bir şeyin yüzdesini kodlayın ve hazırsınız.

    A-Z a-z 0-9 - . _ ~ ( ) ' ! * : @ , ;

Bazen Güvenli

Yalnızca belirli URL bileşenlerinde kullanıldığında güvenlidir; dikkatli kullanın.

    Paths:     + & =
    Queries:   ? /
    Fragments: ? / # + & =
    

Asla Güvenli Değil

URI spesifikasyonuna (RFC 3986) göre, diğer tüm karakterlerin yüzde kodlu olması gerekir. Bu içerir:

    <space> <control-characters> <extended-ascii> <unicode>
    % < > [ ] { } | \ ^
    

Maksimum uyumluluk önemliyse karakter kümesini AZ az 0-9 - _ ile sınırlandırın.
(yalnızca dosya adı uzantıları için noktalarla).

Bağlamı Akılda Tutun

Spesifikasyon başına geçerli olsa bile, bağlama bağlı olarak bir URL yine de "güvensiz" olabilir. Dosya: /// Geçersiz dosya adı karakterleri içeren URL veya sınırlayıcı olarak kullanılmadığında "?", "=" Ve "&" içeren bir sorgu bileşeni. Bu vakaların doğru kullanımı genellikle komut dosyalarınıza bağlıdır ve çözülebilir, ancak akılda tutulması gereken bir şeydir.


İkinci talebiniz için herhangi bir kaynak sağlayabilir misiniz ("Bazen Güvenli")? Özellikle, bunun =sorgular için güvenli olmadığını söylemenin yanlış olduğuna inanıyorum . Örneğin, FIQL eşit işaretleri kabul eder ve kendisini "URI-dostu" ve "sorgu bileşeninde kullanılmak üzere optimize edilmiş ve amaçlanmıştır" olarak tanımlar. Benim yorumumda, RFC 3986 sorgularda açıkça "=", "&", "+" ve diğerlerine izin verir.
DanielM

@DanielM "?", "=" Ve "&", spesifikasyon başına sorgularda geçerlidir, ancak pratikte sorguda ad-değer çiftlerini ayrıştırmak için yaygın olarak kullanılırlar. Böylece isimlerin / değerlerin kendilerinin bir parçası olarak güvensiz olabilirler. Bunun "güvensiz" olup olmadığı bir görüş meselesi olabilir.
Beejor

Bazı kaynaklar, istendiği gibi. (1) RFC 3986, Sec 3.4: "[...] sorgu bileşenleri genellikle 'anahtar = değer' çiftleri [...]" şeklinde tanımlayıcı bilgileri taşımak için kullanılır (2) WhatWG URL Spec, Sec. 6.2: "Bir URLSearchParams nesnesinin oluşturulması ve dizilmesi oldukça basittir: [...] params.toString() // "key=730d67"" (3) PHP Manual, http-build-query: "URL kodlu sorgu dizesi oluştur. [...] Yukarıdaki örnek çıkacaktır: 0=foo&1=bar[...]"(4) J. Starr, Bozulabilir Baskı:" Web sayfaları oluştururken, genellikle parametrelenmiş sorgu dizeleri gerektiren bağlantılar eklemek gerekir. "
Beejor

@Beejor: Bir URL oluşturuyorum ve '-' ve ';' Inşaat sırasında. Bir web uygulaması değil, bir mobil uygulama. Bir web geliştiricisi değil ve bu nedenle, Path özelliğinde yukarıdaki iki karakteri kullanırsam güvenli olur muyum? docs.microsoft.com/tr-tr/dotnet/api/…
karsnen

1
@karsnen Bunlar geçerli URL karakterleri. Yerel bir dosya sistemindeki yollara başvurmak için kullanılıyor olsa da, bazı sistemlerin dosya adlarındaki belirli karakterlere izin vermediğini unutmayın. Örneğin, "file: /// path / to / my: file.ext" Mac'te geçersiz olur.
Beejor

17

RFC3986 - Tekdüzen Kaynak Tanımlayıcısı (URI): Genel Sözdizimi'ne baktığınızda, sorunuz bir URI'nin yol bileşeni etrafında döner .

    foo://example.com:8042/over/there?name=ferret#nose
     \_/   \______________/\_________/ \_________/ \__/
      |           |            |            |        |
   scheme     authority       path        query   fragment
      |   _____________________|__
     / \ /                        \
     urn:example:animal:ferret:nose

Bölüm 3.3, bir URI için geçerli karakterler segmentbelirtilmiştir pchar:

pchar = kaydedilmemiş / pct kodlu / alt sınırlar / ":" / "@"

Hangi yıkılır:

ALPHA / DIGIT / "-" / "." / "_" / "~"

pct-encoded

"!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

":" / "@"

Veya başka bir deyişle: Eğer herhangi bir (non-control-) karakterini kullanabilir ASCII tablosunun , hariç / , ?, #, [ve ].

Bu anlayış RFC1738 - Tekdüzen Kaynak Konum Belirleyicileri (URL) tarafından desteklenmektedir .


2
Bu, teorik olarak doğru bir cevabın harika bir örneğidir, bu aslında yaşadığımız gerçek dünyaya uygulandığında belaya yol açar. Bu karakterlerin çoğunun çoğu zaman soruna neden olmayacağı doğrudur. Ancak gerçek dünyada, hepsi URL'leri teorik standardı göz ardı eden şekillerde incelemeyi ve onlarla etkileşime girmeyi "seven" vekiller, yönlendiriciler, ağ geçitleri, röleler vb. Bu tuzaklardan kaçınmak için alfanümerik, kısa çizgi, alt çizgi ve dönem hariç her şeyden kaçmakla sınırlısınız.
deltamind106

1
@ deltamind106 RFC'lere göre bu karakterlerden hangilerinin güvenli olmadığını açıklığa kavuşturmak için örnekler ve / veya referanslar sağlayabilir misiniz? Cevabımda standartların desteklediği gerçeklere sadık kalmayı tercih ederim ve ihmal etmiş olabileceğim gerçekleri saptayabilirseniz cevabımı güncellemekten memnuniyet duyarım.
Philzen

2
@ deltamind106 Devs'e söylememek yerine standartlara uygun ürünler elde etmeyi denememizi öneririm. Uyarınızın haklı olduğunu düşünüyorum, ancak gerekirse satıcılara uygunsuzluğu bildirme konusunda üzerimize düşeni yapmalıyız.
Lo-Tan

@Philzen: Bir URL oluşturuyorum ve '-' ve ';' Inşaat sırasında. Bir web uygulaması değil, bir mobil uygulama. Bir web geliştiricisi değil ve bu nedenle, Path özelliğinde yukarıdaki iki karakteri kullanırsam güvenli olur muyum? docs.microsoft.com/tr-tr/dotnet/api/…
karsnen

1
@karsnen Evet elbette -ve ;güvende, cevabım ve RFC bunu açıkça ifade ediyor.
Philzen

12

kaydedilmemiş = ALPHA / DIGIT / "-" / "." / "_" / "~"


3
"ALFA", "DİJİT" anlamına gelmez mi? ALPHA'nın "alfasayısal" kısaltması olduğunu ve alfanümerik büyük, küçük harf ve rakam anlamına geldiğini düşünüyorum.
Luc

11
Aslında alfa alfasayısal anlamına gelmez. Alfa ve sayısal 2 ayrı şeydir ve alfanümerik bu şeylerin birleşimidir. Cevabını şöyle yazmış olabilir: ALFANUMERİK / "-" / ". / "_" / "~"
MacroMan

1
RFC 3986'daki 'kaydedilmemiş' için ABNF gösterimi bunları ayrı olarak listeler.
Patanjali

11

Açıkladığınız bağlamdan, aslında yapmaya çalıştığınız şeyin 'SEO slug' adı verilen bir şey olduğundan şüpheleniyorum. Bunlar için bilinen en iyi genel uygulama:

  1. Küçük harfe dönüştür
  2. Az ve 0-9 dışındaki tüm karakter dizilerini bir tireye (-) dönüştürün (alt çizgi değil)
  3. 'Durdur kelimeleri' URL'den, yani 'a', 'an' ve 'the' gibi anlamlı olmayan dizine eklenemeyen kelimeleri kaldırın; Kapsamlı listeler için Google 'kelimeleri durdur'

Bu nedenle, bir örnek olarak, "Çizgi Romanlarda Küfür Temsil Etmek İçin! @% $ * Kullanımı" başlıklı bir makale "kullanım-temsil-küfür-çizgi romanlar" hakkında bir bilgi alacaktır.


Bu "dur sözcükleri" URL'den kaldırmak gerçekten iyi bir yaklaşım mı? Arama motorları bu nedenle bir web sitesini cezalandırır mı?
Paulo

Arama motorlarının genellikle URL'nin yalnızca bir kısmını kabul ettiğine ve / veya daha sonraki bölümlere daha az önem kazandığına inanılmaktadır. aslında sıralama.
kaos

1
@chaos Bunu dikkate alırsanız, yine de StopWord'u soymanızı tavsiye ediyor musunuz: seobythesea.com/2008/08/google-stopword-patent Ayrıca, iyi bir şifre listesi de önerebilir misiniz? Bu şimdiye kadar bulduğum en iyi liste - link-assistant.com/seo-stop-words.html
nikib3ro

@ kape123 Bu benim için çok iyi bir liste gibi görünmüyor. "c" ve "d" programlama dilleridir ve diğer kelimelerin çoğu da anlamlı görünmektedir. Muhtemelen sadece temel olanları soyurumdur: a, ve, ile, üzerinde, arasında veya ile.
mpen


6

SEO bakış açısına göre, tireler alt çizgilere göre tercih edilir. Küçük harfe dönüştürün, tüm kesme işaretlerini kaldırın, ardından alfasayısal olmayan tüm karakter dizelerini tek bir tire ile değiştirin. Fazla tireleri başlangıçtan ve bitişten kesin.


3

Benzer bir sorunum vardı, güzel URL'lere sahip olmak istedim ve URL'lerde yalnızca harflere, rakamlara ve _'e izin vermem gerektiği sonucuna vardım. Bu iyi, o zaman bazı güzel normal ifade yazdım ve tüm UTF8 karakterlerinin .NET'te harf olmadığını ve vidalandığını fark ettiğini fark ettim. Bu, .NET regex motoru için bir sorun gibi görünüyor. Yani bu çözüme ulaştım:

private static string GetTitleForUrlDisplay(string title)
{
    if (!string.IsNullOrEmpty(title))
    {
        return Regex.Replace(Regex.Replace(title, @"[^A-Za-z0-9_-]", new MatchEvaluator(CharacterTester)).Replace(' ', '-').TrimStart('-').TrimEnd('-'), "[-]+", "-").ToLower();
    }
    return string.Empty;
}


/// <summary>
/// All characters that do not match the patter, will get to this method, i.e. useful for unicode chars, because
/// .NET impl of regext do not handle unicode chars. So we use char.IsLetterOrDigit() which works nicely and we 
/// return what we approve and return - for everything else.
/// </summary>
/// <param name="m"></param>
/// <returns></returns>
private static string CharacterTester(Match m)
{
    string x = m.ToString();
    if (x.Length > 0 && char.IsLetterOrDigit(x[0]))
    {
        return x.ToLower();
    }
    else
    {
        return "-";
    }
}

3
.NET regexes aslında unicode oldukça iyi destekler. Tüm harfler için unicode karakter sınıfları kullanmanız gerekir, örneğin \ p {L}. Bkz msdn.microsoft.com/en-us/library/20bw873z.aspx#CategoryOrBlock
TheCycoONE

1

Ben ajax / php aracılığıyla bir değer bir URL döndürdüğümde daha sonra sayfa tarafından tekrar okundu zaman benim url güvenli bir kodlamak için çok yararlı buldum.

Özel karakter için url kodlayıcılı PHP çıktısı

//PHP returning the sucess info of ajax request
echo "".str_replace('&','%26',$_POST['name'])." category was changed";

//javascript sending the value to url
window.location.href='time.php?return=updated&val='+msg;

//javascript/php executing the function printing the value of the url,
//now with the text normally lost in space because of the reserved & character.

setTimeout("infoApp('updated','<?php echo $_GET['val'];?>');",360);

Herkes benim küçük kod özleri yararlı bulur umut! :)


0

Ben "URL Kodlama" gibi bir şey arıyor düşünüyorum - bir URL kodlamak böylece web üzerinde kullanmak için "güvenli":

İşte bunun için bir referans. Herhangi bir özel karakter istemiyorsanız, URL kodlaması gerektiren karakterleri kaldırın:

http://www.w3schools.com/TAGS/ref_urlencode.asp


-4

3-50 karakter arasında. Küçük harfler, sayılar ve özel karakterler içerebilir - nokta (.), Tire (-), alt çizgi (_) ve oran (@).


4
Bunun için referans var mı?
dakab
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.