URL

Doğrulama Raporu

URL Doğrulayıcı nedir?

Bir URL yapıştırırsın ve yapılandırılmış bir rapor alırsın: doğru biçimlendirilmiş mi, her bileşen nasıl görünüyor, neye dikkat etmelisin. Doğrulayıcı, URL’yi tarayıcının yerel URL constructor’ından geçirir — bu da WHATWG URL Standardı’nı uygular — ve üzerine bileşen bazlı kontroller ekler.

"Geçerli URL" sadece parse edilen demek değildir. http://10.0.0.5/admin?token=abc123 gibi bir URL sorunsuz parse edilir, ama muhtemelen işaretlemek isteyeceğin üç şeyi vardır: https:// yerine http://, host olarak IP literal ve query string’de bir token. Doğrulayıcı bu üçünü de pass/fail kontrolünden ayrı uyarı olarak çıkarır. Temel sözdizimi kuralları RFC 3986’dan, host adlandırma değerlendirmeleri RFC 1034’ten ve operasyonel deneyimden gelir.

Çıktı JSON’dur, yani bir CI script’ine veya debug log’a doğrudan akıtabilirsin. Her şey tarayıcında çalışır — URL makineni asla terk etmez. URL’yi doğrulama katmanı olmadan sadece bileşenlerine ayırmak istiyorsan, onun yerine URL Parser’ı kullan. Uluslararasılaştırılmış alan adları IDNA kurallarına göre işlenir.

URL Doğrulayıcı’yı kullanma

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

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

Sol panele bir URL bırak. Yüzde kodlanmış query parametreli, temiz, doğru biçimlendirilmiş bir URL yüklemek için Örnek’e tıkla:

https://api.shop.example.com/v1/orders?customer=Ava%20Chen&status=active

Doğrulayıcı sen yazdıkça güncellenir. Sınır durumlarını dene: http:// URL’ler, IP literal hostlar, kimlik bilgili URL’ler, tek etiketli hostlar (TLD’siz), Punycode alan adları. Her biri farklı bir uyarı ortaya çıkarır.

Raporu oku

Sağ panel, üst seviyede üç alanı olan bir JSON raporu gösterir: isValid (URL parse edilebildi mi), checks (bileşen bazlı durum — protocol, hostname, port, pathname) ve warnings (sözdizimi hatası olmayan ama muhtemelen umursadığın bilgilendirici noktalar).

Kopyala veya indir

JSON raporu panoya göndermek için Kopyala’ya tıkla, .json olarak kaydetmek için İndir’i kullan. Sıkıştır, log girdisinde lazımsa raporu tek satıra sıkıştırır.

Bunu gerçekten ne zaman kullanırsın

Deploy öncesi bir config dosyasını denetlemek

Servisinin config’inde 40 URL var — webhook endpoint’leri, OAuth callback’leri, üçüncü parti entegrasyonlar. Birinde unutulmuş bir testten gömülü parola var, ikisi hâlâ http:// staging hostlarına bakıyor. Onları tek tek doğrulayıcıdan geçirmek üçünü de canlıya çıkmadan yakalar. URL formatına bağımlılıklar redirect URI’lar için OAuth 2.0 spec’inde de geçer.

Bir formdaki kullanıcı tarafından girilen URL’leri gözden geçirmek

Bir kullanıcı "site" alanına aslında example girer — protokol yok, TLD yok, sadece bir kelime. Ya da https://192.168.1.5 — geçerli görünür, geçerli parse olur, ama bunu profil bağlantısı olarak render etmek istemediğin neredeyse kesin. Doğrulayıcı her ikisini de gösterir: ilkinde TLD-eksik uyarısı, ikincisinde IP-literal-host uyarısı.

Bir redirect’in neden başarısız olduğunu teşhis etmek

OAuth callback’in "invalid redirect_uri" ile 400 dönüyor. URL tarayıcıda iyi görünüyor. Doğrulayıcıya yapıştırıyorsun ve fark ediyorsun: yolda gerçek bir boşluk var ve auth sağlayıcın canonicalize sonrası string’leri bayt bayt karşılaştırıyor. Uyarı ("path contains unencoded space") cevabıydı.

Bir Punycode-Unicode uyumsuzluğunu yakalamak

Raporda münchen.example.com görmeyi bekliyordun ama yerine xn--mnchen-3ya.example.com gördün. Bu Punycode formu — kabloda gönderilen — ve doğrulayıcı bunu işaretler ki orijinal girdide ASCII dışı karakterler olduğunu bilesin. Bir bug raporundaki kullanıcı IDN alanından URL kopyala-yapıştır yaptığında işe yarar.

Sık sorulan sorular

Burada "geçerli" aslında ne demek?

İki katman. isValid: true, tarayıcının URL constructor’ının girdiyi kabul ettiği anlamına gelir — yani sözdizimi WHATWG URL Standardı’na göre doğru biçimlendirilmiştir. warnings ayrıdır: sözdizimsel olarak geçerli ama muhtemelen istediğin şey olmayan durumlar (güvensiz protokol, IP literal, gömülü kimlik bilgileri, eksik TLD vb.). Bir URL geçerli olabilir ama yine de uyarıları olabilir.

URL’nin gerçekten bir şeye çözümlenip çözümlenmediğini kontrol ediyor mu?

Hayır — bu bir ağ isteği gerektirir ve bu araç tarayıcında dışarı çağrı yapmadan tamamen çalışır. Doğrulayıcı yalnızca sözdizimi ve yüzeysel sezgisel kontroller yapar. Erişilebilirlik kontrolleri için curl -I veya özel bir uptime aracı kullan.

Neden http://example.com uyarı olarak işaretleniyor?

Çünkü 2026’da düz metin bir URL neredeyse her zaman bir hatadır — modern tarayıcılar http:// üzerinden form göndermeden önce kullanıcıyı uyarır, Google’ın "why HTTPS matters" yazısı uzun versiyonu kapsar ve HSTS preload’lı alan adları HTTP üzerinden hiç yüklemeyi reddeder. Uyarı bilgilendiricidir; gerçekten http:// niyetin varsa (legacy intranet, yerel dev), yoksay.

/api/orders gibi göreli URL’ler ne olacak?

URL constructor mutlak bir URL ister — bir base olmadan protokolü veya hostu belirleyemez. Bu durumda doğrulayıcı net bir hata ile isValid: false döner. Göreli bir URL’yi doğrulamak için önce başına https://example.com gibi bir base ekle.

URL’lerdeki kimlik bilgileri her zaman yanlış mıdır?

Neredeyse her zaman. RFC 3986 §3.2.1, URL’lerdeki kimlik bilgilerinin güvenlik nedenleriyle kullanım dışı bırakıldığını belirtir. Tarayıcı geçmişine, sunucu erişim loglarına ve proxy önbelleklerine düşerler. Modern tarayıcılar pano yapıştırmalarında onları sessizce siler. Doğrulayıcı, olmaması gereken bir yere sızmadan önce sende açık bir kayıt olsun diye onları işaretler.

IDN alan adlarına dikkat ediyor mu?

Evet — doğrulayıcı, hostname’in Punycode formunda mı (xn--...) yoksa saf ASCII’de mi olduğunu not eder. Tarayıcılar kullanıcılara Unicode formunu gösterirken kabloda Punycode formunu iletebilir, ki bu da IDN homograf saldırılarının kaynağıdır. Punycode’u görünür kılmak küçük ama faydalı bir sinyaldir.

Diğer URL ve JSON araçları

Doğrulama tek bir işlemdir. İşte onunla doğal eşleşen araçlar: