URL Kodlama: Yüzde Kodlama, Sorgu Dizeleri ve Tuzaklar

URL kodlama, her arama Fransız aksanı içerdiğinde üretim ortamı400 Bad Request döndürmeye başlayana kadar önemsiz görünen bir konudur. Kurallar basittir, ancak tam olarak mutabık olmayan dört özelliğe yayılmıştır ve JavaScript yardımcıları aktif biçimde yanıltıcı isimler taşır. Bu rehber kuralları tek bir yerde toplar ve standartların sessizce anlaşmazlığa düştüğü yerleri işaretler.

“URL kodlama” gerçekte ne anlama gelir

URL’ler küçük bir ASCII alt kümesiyle sınırlıdır. Bu kümenin dışındaki veya ayrıştırıcının yorumlayacağı yapısal bir anlamı olan her karakter, %ile ön eklenen bir ya da daha fazla bayt olarak temsil edilmek zorundadır. Buna yüzde kodlama denir ve neyin kodlanacağına ilişkin kurallar RFC 3986’dan gelir. Aşağıdaki örneklerden herhangi biriniURL kodlayıcımız ile deneyebilirsiniz.

RFC 3986 karakterleri üç gruba ayırır. Ayrılmamışküme A-Z a-z 0-9 - . _ ~’dir; bunlar her zaman güvenlidir ve asla kodlanmaya ihtiyaç duymaz. Ayrılmış küme (: / ? # [ ] @ ! $ & ' ( ) * + , ; =), URL’nin bir bölümünde yapısal anlam taşır; gerçek karakteri kastettiğinizde kodlayın, sınırlayıcıyı kastettiğinizde olduğu gibi bırakın. Boşluk, ", <, >, { ve tüm ASCII dışı karakterler dahil geri kalanların hepsi yüzde kodlanmalıdır.

Her karakterin nerede kodlanması gerektiği

Aynı bayt, URL’nin hangi bileşeninde göründüğüne bağlı olarak kodlanmaya ihtiyaç duyabilir ya da duymayabilir. Pratikte neredeyse herkes bu ayrımları görmezden gelir ve bir URL’ye değer eklerken ayrılmamış kümenin dışındaki her şeyi kodlar. Bu, temkinli ve doğru bir yaklaşımdır.

Önemli olan tek yer: yol segmentlerinizi ayıran /karakterlerini kodlamayın. Her segmenti kodlayın, ardından/ ile birleştirin. Eğik çizgiyi de kodlarsanız yolda %2F elde edersiniz; çoğu sunucu güvenlik gerekçesiyle bunu reddeder.

JavaScript’te encodeURI ve encodeURIComponent

JavaScript iki kodlayıcıyla gelir ve aralarındaki fark, inanılmaz miktarda boşa harcanan hata ayıklama süresinin kaynağıdır.

• encodeURI(value), value’nun zaten tam bir URL olduğunu varsayar. URL’nin ayrıştırılabilir kalması için ayrılmış karakterleri (; / ? : @ & = + $ , #) olduğu gibi bırakır. Boşlukları, aksanları ve URL’nin hiçbir yerinde izin verilmeyen küçük bir karakter kümesini kodlar.
• encodeURIComponent(value), value’nun bir URL’ye eklenen tek bir bileşen — genellikle bir yol segmenti veya sorgu değeri — olduğunu varsayar. Ayrılmamış küme artı ! ' ( ) * dışında her şeyi kodlar.

Pratik kural: birleştirme yoluyla URL oluşturuyorsanız, her enterpolasyonlu değer için encodeURIComponentkullanın. Zaten oluşturulmuş bir URL’yi normalleştiriyorsanızencodeURI doğru araçtır. Her ikisini birden uygulamak isteyeceğiniz neredeyse hiçbir durum yoktur.

Form verisi: +/boşluk istisnası

HTML form gönderimleri, WHATWG URL standardında tanımlananapplication/x-www-form-urlencodedmedya türüyle kodlama yapar. Bu biçim RFC 3986’dan iki şekilde ayrılır. Birincisi, boşluklar %20 yerine +olur. İkincisi, değerdeki gerçek +, kod çözücünün ayırt edebilmesi için %2B olarak kodlanır.

Pratikte hem %20 hem de +, bir sorgu dizesinde boşluğa çözülür. Yayıcılar tutarlı olmalıdır: form gövdelerinde ve form gövdelerini taklit eden sorgu dizelerinde+ kullanın; özellikle +’un gerçek artı işareti olduğu yol segmentlerinde %20kullanın.

İç içe diziler ve nesneler: standart yok

Sorgu dizeleri düz anahtar=değer çiftleri için tasarlanmıştır. Yaygın kullanımdaki dört kural:

1. Tekrarlanan anahtarlar. ?tag=js&tag=ts, sunucuda bir diziye dönüşür. En basit kural; Express, Go’nun net/urlve çoğu Node ayrıştırıcısında varsayılandır.
2. PHP tarzı köşeli parantezler. Diziler için ?tag[]=js&tag[]=ts; iç içe nesneler için ?user[name]=alex. Köşeli parantezlerin kendisi standartlara tam uyum için yüzde kodlanmalıdır (%5B / %5D), ancak çoğu sunucu ham biçimi de kabul eder.
3. Rails nokta gösterimi. ?user.name=alex&user.age=30. Bugün daha az yaygın; bazı eski Ruby ve .NET API’lerinde görülür.
4. Virgülle ayrılmış. ?tag=js,ts. REST API’lerinde yaygın. Değerlerin kendisi virgül içerebiliyorsa belirsizdir.

API başına bir kural seçin ve belgeleyin. Bu alandaki en acı verici hatalar, köşeli parantez yayan bir istemcinin tekrarlanan anahtar bekleyen bir sunucuyla konuşmasından kaynaklanır.

CJK, emoji ve diğer ASCII dışı karakterler

ASCII dışındaki her karakter, UTF-8 baytlarına dönüştürülüp ardından bayt bayt yüzde kodlanmalıdır. Emoji de aynı kurala tabidir: 🔥 (U+1F525), F0 9F 94 A5dört baytıyla %F0%9F%94%A5 olarak kodlanır.

Uluslararasılaştırılmış alan adları

Ana makine adları farklı bir kurala tabidir. ASCII olmayan ana makine adları yüzde kodlama yerine Punycode (RFC 3492) ile kodlanır. Tarayıcılar tanınan betikler için Unicode biçimini görüntüler ancak kablo üzerinde Punycode biçimini iletir.

Yaygın tuzaklar

• Çift kodlama. Bir değeri kodlayıp sonucu başka bir kodlayıcıdan geçirmek, %20 yerine%2520üretir. Her kodlama adımını açıkça takip edin; üretmediğiniz bir değeri “emin olmak için” asla kodlamayın.
• Hash parçaları yalnızca istemci tarafındadır. #’den sonraki her şey sunucuya hiçbir zaman gönderilmez.
• mailto bağlantılarındaki artı işaretleri. mailto:[email protected], RFC 3986 kurallarını kullandığı için çalışır. mailto bağlantılarını elle oluşturun, form kodlayıcıyla değil.
• Uzunluk sınırları gerçektir.Çoğu sunucu URL’leri 8 KB ile sınırlar. Sorgu dizeniz bu aralığa yaklaşıyorsa yükü bir POST gövdesine taşıyın.

Dürüst sonuç

Her enterpolasyonlu değer için encodeURIComponentkullanın, tam URL’de asla. Form kodlamasını (boşluk-artı) taşıma bağlamınıza uydurun. API başına bir dizi kuralı seçin ve belgeleyin. UTF-8’e güvenin. Ve bir şey çift kodlanmış görünüyorsa neredeyse kesinlikle öyledir; ikinci kodlayıcıyı bir decode geçişiyle örtbas etmek yerine izleyin.