URL kodlayıcı / çözücü

Yüzde kodlaması ne içindir

Bir URL yalnızca küçük bir karakter kümesi içerebilir: A–Z ve a–z harfleri, rakamlar, - . _ ~ gibi bir avuç işaret ve adrese biçimini veren bir ayrılmış karakter kümesi — / ? # & = : @ ve birkaçı daha. Bir boşluktan bir İbranice kelimeye ve bir emojiye kadar başka her şey dolaylı olarak temsil edilmelidir. Yüzde kodlaması bu temsildir: karakter UTF-8 baytlarına çevrilir ve her bayt, bir yüzde işaretinin ardından iki on altılık basamak olarak yazılır. Bir boşluk %20 olur ve א, %D7%90 olur.

Ayrılmış karakterler ilginç durumdur. Bir URL'de yasaldırlar, ama yapısal bir şey ifade ederler: ? sorguyu başlatır, & parametreleri ayırır, = bir anahtarı değerinden ayırır. Bu karakterlerden biri yapının değil, verinizin parçası olduğunda, kodlanmalıdır — yoksa diğer uçtaki ayrıştırıcı onu noktalama olarak okur ve değerinizi yanlış yerde böler.

Bileşen mi tam URL mi — bağlantıları bozan ayrım

Bu, URL hatalarının en yaygın tek kaynağıdır ve bu aracın tahmin etmek yerine bir kapsam seçmenizi istemesinin nedenidir.

• Bileşen kapsamı ayırıcıları da kaçışlar: / ? : @ & = + $ , ve #. Daha büyük bir URL'nin içine yerleştirilen tek bir veri parçası için — bir arama terimi, bir yönlendirme hedefi, bir token — kullanın.
• Tam URL kapsamı bu ayırıcılara dokunmaz ve yalnızca gerçekten yasa dışı olanı kaçışlar, boşluklar ve ASCII olmayan metin gibi. Zaten doğru yapılandırılmış ve yalnızca temizlenmesi gereken tam bir adresiniz olduğunda kullanın.

Her iki yönde de tersine çevirin ve bir şey bozulur. Tüm bir URL'yi bileşen kapsamında kodlayın, her eğik çizgi ve soru işareti %2F ve %3F'ye dönüşür, kullanılamaz uzun bir dize üretir. Tek bir değeri tam URL kapsamında kodlayın, içindeki bir ve işareti bir ayırıcı olarak sağ çıkar; böylece «cats & dogs» araması sessizce iki parametre olur ve değerinizin ikinci yarısı kaybolur.

// The value contains a delimiter, so it must be escaped:
const q = 'cats & dogs'
`/search?q=${encodeURIComponent(q)}`  // /search?q=cats%20%26%20dogs
`/search?q=${encodeURI(q)}`           // /search?q=cats%20&%20dogs  ✗

// Better still, let the platform assemble it:
const url = new URL('https://example.com/search')
url.searchParams.set('q', 'cats & dogs')

O son yaklaşım bir alışkanlık olarak benimsemeye değer. URL ve URLSearchParams her tarayıcıda ve Node'da yerleşiktir ve her parçaya doğru kodlamayı sizin için uygularlar — bu, kararı her seferinde elle doğru yapmanızı sağlamak yerine tümüyle kaldırır.

Neden bir boşluk bazen + bazen %20

İki farklı belirtim iş başındadır ve tam olarak tek bir karakter konusunda anlaşamazlar. URL'leri genel olarak yöneten RFC 3986, bir boşluğu %20 olarak kodlar. HTML formlarının gönderdiği ve dolayısıyla çoğu sorgu dizesinin benzediği eski application/x-www-form-urlencoded biçimi, bir boşluğu + olarak kodlar.

Tuzak, decodeURIComponent'in yalnızca ilk kuralı uygulamasıdır. Ona hello+world verin, hello+world'ü geri alırsınız, artı ve hepsi — hata yok, uyarı yok, yalnızca ince biçimde yanlış bir değer. Bu aracın «+ karakterini boşluk olarak değerlendir» seçeneği sunmasının ve seçenek kapalıyken girdiniz bir artı içerdiğinde bunu belirtmesinin nedeni budur.

Aracın altındaki ayrıştırma tablosunu çalıştıran URLSearchParams'ın form kurallarını izlediğine ve +'yı bir boşluğa çevirdiğine dikkat edin. Yani aynı sorgu dizesi, başvurduğunuz API'ye bağlı olarak farklı çözülebilir — bilerek ve her iki durumda da doğru biçimde.

Hatırlamaya değer bir sonuç: bir artı gerçekten verinizin parçasıysa — bir telefon numarası, bir filtre ifadesi — %2B olarak kodlanmalıdır. Bir sorgu dizesinde değişmez bir +, en iyi ihtimalle belirsizdir ve çoğu ayrıştırıcı tarafından bir boşluk olarak okunur.

Bir URL'yi okuma

Mutlak bir URL yapıştırın ve araç onu parçalarına ayırır. Her birinin ne olarak adlandırıldığını bilmeye değer, çünkü hata mesajları ve belgeler bu sözcük dağarcığını varsayar:

• Şema — https, mailto, ftp. İki noktadan önceki her şey ve geri kalanın nasıl yorumlanacağına karar veren şey.
• Kullanıcı bilgisi — ana bilgisayardan önce isteğe bağlı bir user:password. Hâlâ yasal ve hâlâ kötü bir fikir: her istekle yolculuk eder ve günlüklere, tarayıcı geçmişine ve yönlendiren başlıklarına düşer.
• Ana bilgisayar — alan adı ya da IP adresi. Ondan sonraki her şey ağ tarafından değil, o sunucu tarafından işlenir.
• Bağlantı noktası — genellikle yoktur, çünkü https için 443 ve http için 80 örtüktür.
• Köken — şema, ana bilgisayar ve bağlantı noktası birlikte. Bu, tarayıcı güvenliğinin üzerine kurulduğu birimdir: aynı köken politikası, CORS ve çerez kapsamı, yolları değil, kökenleri karşılaştırır.
• Yol — ana bilgisayardan sonraki ve herhangi bir ? ya da #'ten önceki kısım.
• Sorgu — ?'den sonraki, & ile ayrılmış anahtar/değer çiftleri.
• Parça — #'ten sonraki her şey. Benzersiz biçimde, bu asla sunucuya gönderilmez; tümüyle tarayıcı tarafından işlenir.

Parça ayrıntısı kulağa geldiğinden daha önemlidir. Tarayıcıdan asla ayrılmadığı için, bir #'ten sonra koyduğunuz her şey sunucu günlüklerine görünmezdir — bazı tek sayfa uygulamalarının tarihsel olarak onu yönlendirme için kullanmasının ve asla ulaşmayan bir isteği ayıklarken bakılacak bir yer olmamasının nedeni budur.

Kodlamanın yapmadığı şey hakkında son bir uyarı. Yüzde kodlaması, metni bir URL içinde taşımak için güvenli kılar; bu bir arındırma değildir ve bir güvenlik denetimi değildir. Bir değeri kodlamak, onu HTML, SQL ya da bir kabuk komutuna eklemeyi güvenli kılmaz ve güvenilmez girdiyi çözmek, kodlanmış biçimin gizlediği karakterleri — yol ayırıcıları, null baytları — açığa çıkarabilir. Bir değerin ne olduğunu, nasıl yolculuk ettiğini kodlamaktan ayrı olarak doğrulayın.

Yazdığınız adres her zaman gönderilen adres değildir

Bir URL herhangi bir yere gitmeden önce normalleştirilir ve yeniden yazma sessizdir. Bu araç, girdiden farklı olduğunda sonucu gösterir, çünkü sunucuya ulaşan ve bir günlükte görünen şey, yazdığınız değil, o dizedir:

HTTPS://Example.COM:443\a\b     typed
https://example.com/a/b         sent

Orada dört ayrı kural tetiklendi. Şema ve ana bilgisayar, hiçbiri büyük/küçük harfe duyarlı olmadığı için küçük harfe çevrilir. Bağlantı noktası, 443 https için varsayılan olduğundan atılır. Ters eğik çizgiler eğik çizgi olur; bu, Windows tarzı yollar yazan insanları şaşırtan bir uyumluluk kuralıdır. Ve boş bir yol tek bir eğik çizgi olurdu. Bunların hiçbiri bir hata değildir, ama iki URL'yi eşitlik için karşılaştırıyorsanız ya da birini bir izin listesine karşı eşleştiriyorsanız, normalleştirilmiş biçimleri karşılaştırmalısınız, yoksa yanlış yanıtı alırsınız.

ASCII olmayan karakterler içeren bir ana bilgisayar adı da yeniden yazılır, xn-- ile başlayan ve punycode denen bir ASCII biçimine. Araç her iki yönü de gösterir: okunabilir ad ve gerçekte yolculuk eden. Bunu atlamak yerine bakmaya değer, çünkü iki farklı Unicode adı ekranda özdeş görünebilir — bir Latin «a» ve bir Kiril «а» ayrı karakterlerdir — tümüyle farklı punycode üretirken. ASCII biçimlerini karşılaştırmak, böyle bir çifti ayırt etmenin tek güvenilir yoludur.

Bir şey asla normalleştirilmez: yinelenen bir sorgu parametresi. ?tag=a&tag=b yazmak tümüyle yasaldır ve standart onun ne anlama geldiğini söylemez; bu yüzden her yığın kendi yanıtını seçti. PHP son değeri tutar, Express onları bir diziye toplar, birçok çatı ve URLSearchParams.get ilkini alır. Araç, yinelenen anahtarları yorumsuzca iki kez listelemek yerine işaretler, çünkü ortaya çıkan hata — bir hizmette çalışıp bir diğerinde kaybolan bir değer — okuyarak fark etmek gerçekten zordur.