URL

Normalleştirilmiş

URL Normalleştirici nedir?

"Aynı" olması gereken iki URL’nin büyük/küçük harf ya da sorgu sırası yüzünden karşılaştırmada eşit çıkmaması, yarım gününüzü yiyen şu klasik hatalardandır. HTTPS://Example.com/page ile https://example.com/page aynı kaynağa gider ama metin karşılaştırması farklı oldukları söyler. Normalleştirici bir URL alır ve RFC 3986 §6 ile WHATWG URL Standard’a göre kanonik biçimini üretir; böylece aynı şeyi ifade eden iki URL aynı metni verir.

Yapılan normalleştirmeler sıkıcı ama önemli olanlardır: şema ve host’u küçük harfe çevirmek (RFC 3986 §6.2.2.1’e göre büyük/küçük harf duyarsız), varsayılan portları kaldırmak (https’te :443, http’te :80), yüzde kodlu rezerve edilmemiş karakterleri çözmek (%41 → A), sorgu parametrelerini anahtara göre alfabetik sıralamak, boş fragment’i (arkası boş #) atmak ve . / .. yol parçalarını çözümlemek. Çıktı JSON’u; normalleştirilmiş URL’yi, orijinali ve tam olarak neyin yeniden yazıldığını gösteren bir changes dizisini içerir — böylece farklı görünen iki URL’nin neden aslında aynı olduğunu görürsünüz.

Her şey tarayıcınızda standart URL API ve URLSearchParams kullanılarak çalışır — sunucu yok, log yok. Girdiniz zaten kanonikse changes dizisi boş olur ve cevap budur: yapılacak bir şey yok. Bir sitemap yayınlamadan veya <link rel="canonical"> ayarlamadan önce sağlama yapmak için kullanışlıdır.

URL Normalleştirici nasıl kullanılır

Üç adım. Her biri bu sayfadaki bir butona karşılık gelir.

Bir URL yapıştırın veya örneği yükleyin

Sol panele bir URL bırakın. Gerçekçi şekilde dağınık bir URL yüklemek için Örnek’e tıklayın — şema ve host büyük harf, varsayılan port, karışık sorgu sırası, yüzde kodlu boşluk, boş fragment. Örnek URL:

HTTPS://API.Shop.Example.com:443/v1/orders/?status=active&customer=Ava%20Chen&page=2#

Uluslararasılaştırılmış alan adları (IDN) URL kurucusu tarafından Punycode’a çevrilir — bu, ağ üzerinde gerçekten gönderilen biçimdir, URI normalleştirme kurallarına uygundur. Kullanıcı bilgisi (user:pass@host) varsa korunur.

Çıktıyı okuyun

Sağ panel üç alanlı JSON gösterir: normalized (kanonik URL), original (yapıştırdığınız, kırpılmış hali) ve changes — her yeniden yazımı listeleyen { rule, from, to } girişleri dizisi. changes boşsa URL zaten kanonikti.

Kopyalayın veya indirin

JSON’u panonuza göndermek için Kopyala’ya, .json dosyası olarak kaydetmek için İndir’e tıklayın. Küçült JSON’u tek satıra sıkıştırır. Yeniden başlamak için giriş panelinde Temizle’yi kullanın.

Bunu gerçekten ne zaman kullanacaksınız

Önbellek anahtarları ve analitikte tekilleştirme

Analitik panonuz Example.com/page ile example.com/page’i iki farklı satır olarak görür. CDN önbelleğiniz de öyle. Girişte normalleştirin, kopya kaybolsun. Bir URL kısaltıcı ya da yer imi tekilleştirici inşa ediyorsanız da aynı numara — normalleştirilmiş biçimi arama anahtarı olarak saklayın.

SEO için kanonik URL’ler

Aynı sayfa birden çok URL’den erişilebilir olduğunda arama motorları tekrar eden içeriği cezalandırır. <link rel="canonical"> etiketiniz ve sitemap.xml URL’leriniz tek bir normalleştirilmiş biçimle eşleşmelidir. Google’ın kanoniğleştirme rehberi kuralları açıklar; bu araç onları el ile uygulamanın en hızlı yoludur.

İki URL’yi eşitlik için karşılaştırma

Bir yönlendirme döngüsü dedektörü yazıyor ya da bir webhook test ediyorsunuz. İki URL, normalleştirilmiş biçimleri eşleşiyorsa "aynı"dır. Normalleştirdikten sonra metinleri karşılaştırın — URL.toString() üzerine kendi eşitlik fonksiyonunuzu kurmayın, çünkü o ne sorgu parametrelerini sıralar ne de varsayılan portları kaldırır.

Saklamadan veya göstermeden önce URL temizleme

Bir kullanıcı formunuza HTTPS://www.SHOP.com:443/cart/?b=2&a=1# yapıştırıyor. Bunu veritabanınıza öyle koymak istemezsiniz, e-postayla geri göndermek de hiç istemezsiniz. Önce normalleştirin, sonra temiz biçimi kaydedin. Müşteriye dönük URL’ler öngörülebilir hale gelir.

Sık sorulan sorular

URL’im zaten kanonikse?

normalized ve original alanlarında aynı URL’yi görürsünüz ve changes dizisi boş olur ("changes": []). Cevap budur — yeniden yazılacak bir şey yoktu. Bu durumda sayfa istisna fırlatmaz veya hata göstermez.

Kök sondaki eğik çizgiyi kaldırmanın ötesinde yola dokunuyor mu?

Çoğunlukla hayır. . ve .. yol parçaları çözümlenir (URL kurucusu bunu otomatik yapar — RFC 3986 §5.2.4 buna "remove dot segments" der). Sondaki eğik çizgiler yalnızca yol sadece / ise kaldırılır; /v1/orders/ aynı kalır çünkü RFC 3986 sondaki eğik çizgilerin anlamlı olabileceğini söyler. Sunucu çatıları bunları farklı rotalar olarak ele alabilir.

Sorgu parametrelerim neden sıralanıyor? Sıra benim için önemliydi.

RFC 3986’ya göre sorgu sırası anlamsal olarak önemli değildir — ?a=1&b=2 ile ?b=2&a=1 URL düzeyinde eşdeğerdir. Alfabetik sıralama, eşdeğer iki URL’nin bayt bayt eşleşmesi için kararlı bir kanonik biçim verir. Uygulamanız gerçekten parametre sırasına bağımlıysa (olmaması gerekir ama eski sistemler öyledir), bu normalleştirici bu varsayımı bozar — sıraya önem veren bir sunucuya giden URL’leri normalleştirmeyin.

Normalleştirmeden sonra %20 neden bazen + oluyor?

Hem %20 hem de +, sorgu dizesinde boşluk anlamına gelir (application/x-www-form-urlencoded kurallarına göre, ki URLSearchParams serileştirme için bunu kullanır). URLSearchParams nesnesi sorguyu yeniden serileştirdiğinde + kullanır. Standartlara uyumlu herhangi bir URL ayrıştırıcısı için anlamsal olarak özdeştirler; sunucunuz farklı muamele ediyorsa bu sunucu hatasıdır.

café.example gibi uluslararasılaştırılmış alan adlarına ne olur?

URL kurucusu host’u Punycode’a çevirir — caf%C3%A9.example, xn--caf-dma.example olur. URL’nin DNS üzerinden gerçekten gönderileceği biçim budur ve RFC 3987 / WHATWG spesifikasyonu bunu söyler. Wikipedia’nın URI normalleştirme makalesi ayrıntıları istiyorsanız IDN işlenişini ele alır.

Kimlik bilgisi içeren URL’lerle (user:pass@host) güvenli mi?

Ayrıştırma tamamen tarayıcınızda olur — hiçbir şey hiçbir yere gönderilmez. Userinfo, normalleştirme boyunca korunur. Aslında bir URL’de kimlik bilgisi taşımanız gerekip gerekmediği ayrı bir konudur — çoğu tarayıcı ve HTTP istemcisi güvenlik riskleri nedeniyle artık userinfo’yu siliyor ya da uyarıyor; genelde Authorization başlığı çok daha iyidir.

Yinelenen sorgu parametrelerini kaldırır mı?

Hayır. ?tag=red&tag=red aynı şekilde ?tag=red&tag=red kalır. Tekrar eden anahtarlar anlamlı olabilir (bazı API’ler diziler için kullanır) ve yinelenenleri kaldırmak anlamı değiştirir. Sıralama kararlıdır, yani aynı anahtar içinde orijinal sıra korunur.

Diğer URL ve JSON araçları

Normalleştirme tek bir işlem. İşte yanına doğal şekilde yakışanlar: