URLs and Hashing
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Bu bölümde, istemcilerin URL'leri nasıl kontrol ettiğine dair ayrıntılı özellikler yer almaktadır.
URL'lerin standartlaştırılması
Herhangi bir URL kontrol edilmeden önce istemcinin bu URL üzerinde bazı standartlaştırma işlemleri yapması beklenir.
Başlangıç olarak, istemcinin URL'yi ayrıştırdığını ve RFC 2396'ya göre geçerli hale getirdiğini varsayıyoruz. URL'de uluslararası hâle getirilmiş alan adı (IDN) kullanılıyorsa istemci, URL'yi ASCII Punycode gösterimine dönüştürmelidir. URL bir yol bileşeni içermelidir. Yani alan adından sonra en az bir eğik çizgi bulunmalıdır (http://google.com yerine http://google.com/).
Öncelikle URL'den sekme (0x09), satır başı (0x0d) ve satır sonu (0x0a) karakterlerini kaldırın. Bu karakterlerin kod dışına alma dizelerini kaldırmayın (ör. %0a).
İkinci olarak, URL bir parçayla bitiyorsa parçayı kaldırın. Örneğin, http://google.com/#frag'ü http://google.com/ olarak kısaltın.
Üçüncü olarak, URL'de artık yüzde kaçış karakteri kalmayana kadar URL'den yüzde kaçış karakterlerini tekrar tekrar kaldırın. (Bu işlem, URL'yi geçersiz kılabilir.)
Barındırıcı adını standartlaştırmak için:
URL'den ana makine adını ayıklayın ve ardından:
- Baştaki ve sondaki tüm noktaları kaldırın.
- Art arda gelen noktaları tek bir noktayla değiştirin.
- Ana makine adı IPv4 adresi olarak ayrıştırılabiliyorsa 4 noktayla ayrılmış ondalık değerlere normalize edin. İstemci, sekizli, onaltılık ve dörtten az bileşen içeren tüm yasal IP adresi kodlamalarını işlemelidir.
- Ana makine adı, köşeli parantez içinde IPv6 adresi olarak ayrıştırılabiliyorsa bileşenlerdeki gereksiz ön sıfırları kaldırarak ve çift iki nokta işareti söz dizimini kullanarak sıfır bileşenleri daraltarak normalleştirin. Örneğin,
[2001:0db8:0000::1], [2001:db8::1] olarak dönüştürülmelidir. Ana makine adı aşağıdaki iki özel IPv6 adres türünden biriyse bunları IPv4'e dönüştürün:
[::ffff:1.2.3.4] gibi IPv4 ile eşlenmiş bir IPv6 adresi (1.2.3.4 olarak dönüştürülmelidir);[64:ff9b::1.2.3.4] gibi tanınmış 64:ff9b::/96 ön ekini kullanan bir NAT64 adresi. Bu adres, 1.2.3.4 olarak dönüştürülmelidir.
- Dizinin tamamını küçük harfle yazın.
Yolu standartlaştırmak için:
/./'u / ile değiştirip /../'ü önceki yol bileşeniyle birlikte kaldırarak yoldaki /../ ve /./ dizilerini çözün.- Art arda gelen eğik çizgileri tek bir eğik çizgi karakteriyle değiştirin.
Bu yol standartlaştırmalarını sorgu parametrelerine uygulamayın.
URL'de, ASCII 32'den küçük, 127'den büyük, # veya % olan tüm karakterler için yüzdelik kaçış karakteri kullanın. Kaçış karakterleri büyük harfli onaltılık karakterler kullanmalıdır.
Ana Makine-Son Eki Yol Ön Eki İfadeleri
URL normalleştirildikten sonra sonraki adım, son ek/ön ek ifadelerini oluşturmaktır. Her son ek/ön ek ifadesi, bir ana makine son ekinden (veya tam ana makine adından) ve bir yol ön ekinden (veya tam yoldan) oluşur.
İstemci, 30'a kadar farklı olası ana makine son eki ve yol ön ek kombinasyonu oluşturur. Bu kombinasyonlarda yalnızca URL'nin ana makine ve yol bileşenleri kullanılır. Şema, kullanıcı adı, şifre ve bağlantı noktası atılır. URL sorgu parametreleri içeriyorsa en az bir kombinasyon tam yolu ve sorgu parametrelerini içerir.
Ana makine için istemci en fazla beş farklı dize dener. Bunları şöyle sıralayabiliriz:
- Ana makine adı bir IPv4 veya IPv6 tam adı değilse eTLD+1 alan adından başlayıp art arda ön bileşenler ekleyerek oluşturulan en fazla dört ana makine adı. eTLD+1'in belirlenmesi Genel Ek Listesi'ne dayalı olmalıdır. Örneğin,
a.b.example.com, example.com'un eTLD+1 alanının yanı sıra b.example.com adlı ek bir barındırıcı bileşenine sahip barındırıcıyı oluşturur.
- URL'deki tam ana makine adı. Önceki örnekte
a.b.example.com kontrol edilir.
Yol için istemci en fazla altı farklı dize dener. Bunları şöyle sıralayabiliriz:
- Sorgu parametreleri dahil, URL'nin tam yolu.
- Sorgu parametreleri olmadan URL'nin tam yolu.
- Kökten (/) başlayıp art arda yol bileşenleri (son eğik çizgi dahil) eklenerek oluşturulan dört yol.
Aşağıdaki örneklerde kontrol davranışı gösterilmektedir:
http://a.b.com/1/2.html?param=1 URL'si için istemci şu olası dizeleri dener:
a.b.com/1/2.html?param=1
a.b.com/1/2.html
a.b.com/
a.b.com/1/
b.com/1/2.html?param=1
b.com/1/2.html
b.com/
b.com/1/
http://a.b.c.d.e.f.com/1.html URL'si için istemci şu olası dizeleri dener:
a.b.c.d.e.f.com/1.html
a.b.c.d.e.f.com/
c.d.e.f.com/1.html
c.d.e.f.com/
d.e.f.com/1.html
d.e.f.com/
e.f.com/1.html
e.f.com/
f.com/1.html
f.com/
(Not: Yalnızca son beş ana makine adı bileşenini ve tam ana makine adını alacağımız için b.c.d.e.f.com öğesini atlayın.)
http://1.2.3.4/1/ URL'si için istemci şu olası dizeleri dener:
1.2.3.4/1/
1.2.3.4/
http://example.co.uk/1 URL'si için istemci şu olası dizeleri dener:
example.co.uk/1
example.co.uk/
Karma oluşturma
Google Güvenli Tarama, karma oluşturma işlevi olarak yalnızca SHA256'yı kullanır. Bu karma oluşturma işlevi, yukarıdaki ifadelere uygulanmalıdır.
32 baytlık tam karma, koşullara bağlı olarak 4 bayt, 8 bayt veya 16 bayta kısaltılır:
hashes.search yöntemi kullanılırken şu anda istekteki karma oluşturma işlemlerinin tam olarak 4 bayt olacak şekilde kısaltılması gerekir. Bu istekte ek bayt göndermek kullanıcı gizliliğini ihlal eder.
hashList.get yöntemi veya hashLists.batchGet yöntemi kullanılarak yerel veritabanı listeleri indirilirken sunucu tarafından gönderilen karma oluşturma işlemlerinin uzunluğu, karma oluşturma işlemi uzunluğunu belirten son ek içeren listelerin adlandırma kuralına kodlanır. Daha fazla bilgi için Kullanılabilir Listeler bölümüne bakın.
Aksi belirtilmediği sürece bu sayfanın içeriği Creative Commons Atıf 4.0 Lisansı altında ve kod örnekleri Apache 2.0 Lisansı altında lisanslanmıştır. Ayrıntılı bilgi için Google Developers Site Politikaları'na göz atın. Java, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-25 UTC.
[null,null,["Son güncelleme tarihi: 2025-07-25 UTC."],[],[],null,["# URLs and Hashing\n\nThis section contains detailed specifications of how clients check URLs.\n\n### Canonicalization of URLs\n\nBefore any URLs are checked, the client is expected to perform some canonicalization on that URL.\n\nTo begin, we assume that the client has parsed the URL and made it valid according to RFC 2396. If the URL uses an internationalized domain name (IDN), the client should convert the URL to the ASCII Punycode representation. The URL must include a path component; that is, it must have at least one slash following the domain (`http://google.com/` instead of `http://google.com`).\n\nFirst, remove tab (0x09), CR (0x0d), and LF (0x0a) characters from the URL. Do not remove escape sequences for these characters (e.g. `%0a`).\n\nSecond, if the URL ends in a fragment, remove the fragment. For example, shorten `http://google.com/#frag` to `http://google.com/`.\n\nThird, repeatedly percent-unescape the URL until it has no more percent-escapes. (This may render the URL invalid.)\n\n**To canonicalize the hostname:**\n\nExtract the hostname from the URL and then:\n\n1. Remove all leading and trailing dots.\n2. Replace consecutive dots with a single dot.\n3. If the hostname can be parsed as an IPv4 address, normalize it to 4 dot-separated decimal values. The client should handle any legal IP-address encoding, including octal, hex, and fewer than four components.\n4. If the hostname can be parsed as a bracketed IPv6 address, normalize it by removing unnecessary leading zeroes in the components and collapsing zero components by using the double-colon syntax. For example `[2001:0db8:0000::1]` should be transformed into `[2001:db8::1]`. If the hostname is one of the two following special IPv6 address types, transform them into IPv4:\n - An IPv4-mapped IPv6 address, such as `[::ffff:1.2.3.4]`, which should be transformed into `1.2.3.4`;\n - A NAT64 address using [the well-known prefix 64:ff9b::/96](https://datatracker.ietf.org/doc/html/rfc6052#section-2.1), such as `[64:ff9b::1.2.3.4]`, which should be transformed into `1.2.3.4`.\n5. Lowercase the whole string.\n\n**To canonicalize the path:**\n\n1. Resolve the sequences `/../` and `/./` in the path by replacing `/./` with `/`, and removing `/../` along with the preceding path component.\n2. Replace runs of consecutive slashes with a single slash character.\n\nDo not apply these path canonicalizations to the query parameters.\n\nIn the URL, percent-escape all characters that are \\\u003c= ASCII 32, \\\u003e= 127, `#`, or `%`. The escapes should use uppercase hex characters.\n\n### Host-Suffix Path-Prefix Expressions\n\nOnce the URL is canonicalized, the next step is to create the suffix/prefix expressions. Each suffix/prefix expression consists of a host suffix (or full host) and a path prefix (or full path).\n\nThe client will form up to 30 different possible host suffix and path prefix combinations. These combinations use only the host and path components of the URL. The scheme, username, password, and port are discarded. If the URL includes query parameters, then at least one combination will include the full path and query parameters.\n\n**For the host**, the client will try at most five different strings. They are:\n\n- If the hostname is not an IPv4 or IPv6 literal, up to four hostnames formed by starting with the eTLD+1 domain and adding successive leading components. The determination of eTLD+1 should be based on the [Public Suffix List](https://publicsuffix.org/). For example, `a.b.example.com` would result in the eTLD+1 domain of `example.com` as well as the host with one additional host component `b.example.com`.\n- The exact hostname in the URL. Following the previous example, `a.b.example.com` would be checked.\n\n**For the path**, the client will try at most six different strings. They are:\n\n- The exact path of the URL, including query parameters.\n- The exact path of the URL, without query parameters.\n- The four paths formed by starting at the root (/) and successively appending path components, including a trailing slash.\n\nThe following examples illustrate the check behavior:\n\nFor the URL `http://a.b.com/1/2.html?param=1`, the client will try these possible strings: \n\n a.b.com/1/2.html?param=1\n a.b.com/1/2.html\n a.b.com/\n a.b.com/1/\n b.com/1/2.html?param=1\n b.com/1/2.html\n b.com/\n b.com/1/\n\nFor the URL `http://a.b.c.d.e.f.com/1.html`, the client will try these possible strings: \n\n a.b.c.d.e.f.com/1.html\n a.b.c.d.e.f.com/\n c.d.e.f.com/1.html\n c.d.e.f.com/\n d.e.f.com/1.html\n d.e.f.com/\n e.f.com/1.html\n e.f.com/\n f.com/1.html\n f.com/\n\n(Note: skip `b.c.d.e.f.com`, since we'll take only the last five hostname components, and the full hostname.)\n\nFor the URL `http://1.2.3.4/1/`, the client will try these possible strings: \n\n 1.2.3.4/1/\n 1.2.3.4/\n\nFor the URL `http://example.co.uk/1`, the client will try these possible strings: \n\n example.co.uk/1\n example.co.uk/\n\n### Hashing\n\nGoogle Safe Browsing exclusively uses SHA256 as the hash function. This hash function should be applied to the above expressions.\n\nThe full 32-byte hash will, depending on the circumstances, be truncated to 4 bytes, 8 bytes, or 16 bytes:\n\n- When using the [hashes.search method](/safe-browsing/reference/rest/v5/hashes/search), we currently require the hashes in the request to be truncated to exactly 4 bytes. Sending additional bytes in this request will compromise user privacy.\n\n- When downloading the lists for the local database using the [hashList.get method](/safe-browsing/reference/rest/v5/hashList/get) or the [hashLists.batchGet method](/safe-browsing/reference/rest/v5/hashLists/batchGet), the length of the hashes sent by the server is encoded within the naming convention of the lists that contain suffix indicating hash length. See [Available Lists](/safe-browsing/reference/Local.Database#available-lists) section for more details."]]
