HTML entiteleri vs URL kodlama: hangisini kullanmalisiniz

HTML entiteleri, HTML icindeki ayrilmis karakterlerin ve ozel sembollerin oldugu gibi gorunmesini saglar. `<div>` ifadesini tarayicinin bir etiket olarak islemesi yerine duz metin olarak gostermek istiyorsaniz dogru cozum HTML entiteleridir. Ampersand, tirnak, apostrof, euro isareti ve markup yapisini degistirebilen diger karakterler icin de aynisi gecerli olur.

URL kodlama, yani percent encoding, baska bir problemi cozer. Bir deger query string, path segment, redirect hedefi veya paylasilan bir link icinde yasamak zorundaysa onu URL soz dizimi icinde guvende tutar. Bosluklar, ampersandler, esittir isaretleri, soru isaretleri ve diger ayrilmis URL karakterleri ham halde kalirsa linkin anlamini bozabilir veya yeniden sekillendirebilir. URL kodlama, yapinin korunmasini saglar ki bir sonraki parser beklenen degeri dogru okuyabilsin.

Bu nedenle dogru soru Hangi kodlama daha teknik gorunuyor degildir. Dogru soru Bu degeri siradaki hangi parser okuyacak sorusudur. Siradaki parser HTML render etme katmaniysa HTML entitelerini dusunun. Siradaki parser URL soz dizimiyse URL kodlamayi dusunun.

Kullaniciya gosterilecek metnin HTML ortaminda gorunur ve literal kalmasi gerektiginde HTML entiteleri dogru secimdir. Dokumantasyon sayfalari buna klasik bir ornektir; cunku `<a>` veya `<section>` gibi ornek tagleri render etmeden gostermek isterler. Ayni durum CMS yardim metinlerinde, destek snippetlerinde, surum notlarinda ve bilgi bankasi makalelerindeki orneklerde de gorulur.

Bu sadece kod ornekleri icin degil, normal metin icin de onemlidir. Bir CMS blogu HTML olarak render ediliyorsa ve metin `&`, `<` veya hassas attribute baglamindaki tirnaklar gibi ayrilmis karakterler iceriyorsa ham metin markup'i bozabilir veya kafa karistiran bir sonuc uretebilir. Gosterilecek surumu HTML entiteleriyle encode etmek, gorunen ciktiyi korurken orijinal kaynak metni ayri bir yerde bozmadan birakir.

Basit bir zihinsel kisayol soyledir: kullanici karakterin kendisini gorecekse ve tarayici onun yapisal anlamini yorumlamayacaksa, genellikle HTML entiteleri dogru cevaptir.

Bir degerin URL sinirini guvenli bicimde gecmesi gerekiyorsa dogru secim URL kodlamadir. Redirect parametreleri, arama sorgulari, filtre durumu, kampanya linkleri, callback URL'leri ve query degeri olarak gecen ic ice URL'ler buna sik ornektir. Bu akislarda tarayici, framework router'i, proxy veya backend parser oncelikle gecerli bir URL soz dizimi gormek ister.

Gercekci bir ornek, `/checkout?step=shipping&plan=pro` gibi bir redirect degerinin `/login?next=...` gibi baska bir URL icine yerlestirilmesidir. Icte kalan degeri ham bicimde koyarsaniz ampersand ve esittir isaretleri dis query string'in parcasi olarak yorumlanabilir. URL kodlama, icteki degeri butun halde saklar; boylece daha sonra yapi kaybetmeden decode edilebilir.

Pek cok ekip burada yanlis secim yapar. Bir ampersand gorur ve HTML tarafinda da sorunlu oldugu icin HTML entitelerini dusunur. Ama bir sonraki sinir URL parser ise dogru katman percent encoding katmanidir. Problem gorunen markup degildir. Problem URL soz dizimidir.

Gercek akislarda genelde birden fazla sinir vardir; bu yuzden kafa karisikligi surekli geri gelir. Ayni deger bir katmanda URL kodlama, baska bir katmanda HTML entiteleri gerektirebilir. Ornegin bir redirect URL kendi query parametrelerini korumak icin iceride percent encoding isteyebilir. Fakat siz o tam redirect URL'yi daha sonra dokumantasyon sayfasinda gorunen kod olarak gosterirken, gosterilen surum ampersand veya aci parantezler etrafinda HTML entitelerine de ihtiyac duyabilir.

Ayni desen admin panellerinde, CMS onizlemelerinde ve destek dokumantasyonunda da gorulur. Bir link teknik olarak URL olarak dogru olabilir ama HTML olarak render edilen bir makaleye yapistirildiginda kotu gorunebilir. Ya da bir string literal gosterim icin entity encode edilir ve daha sonra biri onu query parametresi icinde yeniden kullandiginda basarisiz olur; cunku o noktada siradaki parser HTML degil, URL parser olur.

Bu yuzden tum akis icin tek bir kodlama etiketi secmek yerine sira dusuncesiyle hareket etmek faydalidir. Mevcut katman ne bekliyor, o katman icin encode edin ve tek bir donusumun sonraki tum baglamlari cozecegini varsaymayin.

Yaygin hatalardan biri, calisan bir URL parametresi olarak kalmasi gereken bir degerde HTML entiteleri kullanmaktir. Bu, markup icinde hos gorunen fakat redirect, filtre veya callback linklerinden gecince dogru davranmayan degerler uretir. Tersi de yaygindir: HTML dokumantasyonunda literal gosterilmesi gereken bir kod ornegini percent encode etmek. Link teknik olarak URL icin guvenli hale gelir ama insan tarafindaki ciktiyi okunmasi zorlastirir ve yanlis problemi cozer.

Ucuncu hata fazla erken encode etmek ve sonra hangi surumun kanonik oldugunu unutmaktir. Ekipler entity encode edilmis bir string'i URL alanina kopyalar veya percent encode edilmis redirect hedefini literal gosterim amaciyla dokumantasyonda yeniden kullanir. Encode edilmis formlar ilgisiz baglamlar arasinda dolasmaya basladiginda hata ayiklama karmasik hale gelir; cunku her sistem yanlis katmani okumaya baslar.

Dorduncu hata, HTML entiteleri ile URL kodlamanin birbirinin yerine gecebildigini sanmaktir. Ikisi de ampersand, tirnak veya noktalama karakterlerini degistirebilir ama birbirinin yerine gecmezler. Farkli parserlara aittirler. Yuzeydeki karakter benzerligi de yanlis secimi makul gosteren seydir.

Tek bir soruyla baslayin: siradaki parser ne. Siradaki parser HTML render eden tarayiciysa HTML entiteleri buyuk ihtimalle ilgilidir. Siradaki parser URL parser ise buyuk ihtimalle URL kodlama ilgilidir. Sonra ikinci soruyu sorun: bu deger literal mi gosterilmeli, yoksa bir yapinin parcasi olarak mi islenmeli. Literal gosterilecekse entity dusunun. URL'nin bir parcasi olarak parse edilecekse percent encoding dusunun.

Gercek bir is akisi ornegi bunu netlestirir. Bir destek makalesinin query parametreleri iceren bir redirect link ornegi gostermesi gerektigini dusunun. Gercek redirect hedefi sentaktik olarak gecerli kalmak icin URL kodlama isteyebilir. Ama makalede gorunen snippet de tarayicinin onu canli markup olarak yorumlamamasi icin HTML entiteleri gerektirebilir. Her iki kodlama da dogru olabilir, ama yalnizca dogru asamada uygulandiginda.

Bu kural, karakter listeleri ezberlemekten daha guvenilirdir. Dikkatinizi sinira ve amaca odaklar; cunku hatalarin cogu tam olarak orada baslar.

Bir sey bozuk gorundugunde karakterleri rastgele degistirerek baslamayin. Once degerin nereden geldigine, su an hangi encode edilmis formda olduguna ve sirada hangi parserin onu okuyacagina bakin. Bir deger zaten `&amp;` iceriyorsa muhtemelen ham metne degil, HTML gosterim formuna bakiyorsunuzdur. Deger `%26` veya `%3D` gibi yuzde dizileriyle doluysa muhtemelen URL-guvenli bir temsile bakiyorsunuzdur; dogrudan icerikte gosterilecek bir surume degil.

Sonra her seferinde bir siniri test edin. Once ham kaynak metni veya ham URL'yi dogrulayin. Sonra anlik hedef icin gerekli encode edilmis formu dogrulayin. Son olarak asagidaki baska bir katmanin kendi kodlamasina hala ihtiyac duyup duymadigini kontrol edin. Bu yaklasim, ayni metnin farkli parser kurallari olan arayuzler arasinda kopyalandigi CMS akislari, destek dokumantasyonu ve admin araclarinda ozellikle faydalidir.

Katmanlari ayirdiginizda encoding hatalarinin buyuk kismi gizemli gorunmeyi birakir. Zor kisim nadiren donusumun kendisidir. Zor kisim hangi temsilin hangi baglama ait oldugunu fark etmektir.