Browsertrix Crawler İncelemesi: Kodun Söylediğini Değil, Tarayıcının Yaptığını Arşivler

Browsertrix Crawler, Webrecorder’ın arşivleme odaklı tarayıcısıdır: Gerçek bir Chromium’u Puppeteer üzerinden çalıştıran tek bir Docker imajı; tarayıcının aldığı her şeyi kaydeder ve bunları standart web arşiv formatı olan WARC içine yazar — isteğe bağlı olarak bir indeks, sayfa listesi ve günlüklerle birlikte WACZ paketi halinde de sunulabilir. Onu yüzeyde benzer görünen kazıma araçlarından ayıran şey tam da budur. Bir scraper veriyi toplar ve gerekli alanları aldıktan sonra sayfayı geride bırakır; bir arşivci ise ziyaretin kendisini — baytları, başlıkları, hangi sırayla geldiklerini — saklar, böylece site değişse ya da tamamen kaybolsa bile sayfa daha sonra yeniden açılabilir. Webrecorder, arşivleme bir ürün kategorisi gibi görünmeye başlamadan çok önce web’in bu altyapı katmanını, formatlarını ve oynatma yığınını ayakta tutuyordu; bugün de kütüphaneler, haber merkezleri ve araştırmacılar buna dayanıyor.

v1.14.0 sürümünü Docker içinde, bilinçli olarak farklılaştırılmış dört uç nokta sınıfı içeren yerel bir örnekleme karşı çalıştırdım ve taramanın iki tarafını da ölçtüm: arşiv içeriği için WARC kayıtları ve gerçek istekler için sunucu tarafındaki hit sayacı. Buradaki işe yarar ayrım sadece statik ile dinamik arasında değildi. Browsertrix, çalışma anında oluşturulan bir bağlantıyı ve sayfanın başlattığı bir fetch() isteğini yakaladı; ancak çağrılmamış bir JavaScript fonksiyonu içindeki iki sabit URL metnini istemedi.

Bağlantılı app.js dosyası, içindeki iki sabit yolu da dahil ederek eksiksiz arşivlendi; buna rağmen bu uç noktaların hiçbiri için ne yanıt kaydı, ne istek kaydı, ne de sunucu hit’i oluştu. Çünkü bu fonksiyon hiç çalışmadı. Bu yüzden bu yazı, Browsertrix’i kaynak kodda geçen her URL’nin envanterini çıkaran bir araç değil, bir tarayıcı oturumunun arşivcisi olarak değerlendiriyor.

Browsertrix Crawler gerçekte nedir

Birçok kişi onu scraper sanarak geliyor ve hayal kırıklığıyla ayrılıyor. Varsayılan akışta size ürün fiyatlarından oluşan bir CSV sunan hiçbir şey yok; bunu beklemek, bir araç kamerasının size trafik raporu yazmasını beklemeye benzer. Çıktı, yeniden oynatılabilir bir tarama oturumu kaydıdır ve aşağıdaki tüm tasarım kararları bunun sonucudur.

v1.14.0 sürümünü 27 Temmuz 2026’da test ettim: webrecorder/browsertrix-crawler:latest imajı sha256:9d6800a8… digest’i ile, crawl --version çıktısı da derlemeyi doğruluyordu. Projenin lisansı AGPL-3.0. Tüm ölçümler, macOS arm64 üzerinde Colima aracılığıyla Docker içinde, kontrol altındaki yerel örnekleme karşı yapıldı; sunucu tarafındaki sayaç, Browsertrix günlüklerinden ve arşiv ayrıştırmasından bağımsız kanıt sağladı.

AGPL-3.0 burada ayrıca önem taşıyor. Ağ kullanım koşulları içeren güçlü copyleft. Eğer Browsertrix Crawler’ı bağımsız bir araç olarak çalıştırmak yerine ticari bir ürünün içine yerleştirecekseniz, ürünü yayınlamadan önce lisansın doğru okunmuş olduğundan emin olun. Bu bir uyarıdır, hukuki tavsiye değil.

Arşiv oturumu kaydeder, kaynak kodu değil

Örneklemem, arşivci bunlara tamamen farklı davrandığı için özellikle ayrılmış dört uç nokta türü sunuyordu:

• Sınıf A — HTML içinde düz <a href>. Dört sayfa ve üç seviyelik bir derinlik zinciri. Dünyadaki her crawler bunları bulur.
• Sınıf B — hiç çalışmayan bir fonksiyon içindeki URL sabitleri. İki yol, /api/js-endpoint-7 ve /api/js-endpoint-8, bağlı bir app.js içindeki çağrılmamış loadData() fonksiyonunda string olarak duruyor.
• Sınıf C — çalışma anında oluşturulan bağlantı. JavaScript içinde parçalardan birleştirilip DOM’a eklenen bir <a href> ('endpoint' + (6 * 7)). Sürekli yol olan /runtime-only/endpoint42, servis edilen byte’ların hiçbirinde düz metin olarak yok.
• Sınıf D — sayfanın gerçekten yaptığı bir fetch(). Yol aynı şekilde oluşturuluyor ('runtime-xhr-' + (33 * 3)), ardından yükleme sırasında gerçekten isteniyor.

C ve D sınıflarında tam yollar, servis edilen dosyalarda bitişik string olarak yer almıyordu. Dolayısıyla sunucu tarafındaki hit’ler ve yanıt kayıtları, bu örneklemede çalışma anındaki kurulumun ve istek yollarının gerçekten kullanıldığını gösteren kanıttır.

Ne yakalandı, ne yakalanmadı

İki araç, her hücrede birbirini doğrulayacak şekilde kontrol edildi: WARC yanıt kayıtları (arşivde ne var) ve (Host header, path) ile anahtarlanan sunucu tarafı hit sayacı (gerçekte ne istendi). Her yerde aynı sonuç verdi.

Sınıf C, gerçek bir tarayıcı ile statik bir crawl’ı ayıran şeydir. Varsayılan bağlantı çıkarımı, render edilmiş DOM’u okur (a[href]->href, common options docs dokümantasyonuna göre); yani JavaScript çalıştıktan sonra ortaya çıkan bir bağlantı bile sıraya alınır, istenir ve arşivlenir. Sınıf D ise başka bir nedenle yakalanır — sayfanın kendisi isteği yaptı ve arşivci ağ hattında olup biten her şeyi kaydediyordu.

Sınıf C için dürüst bir sınır var: Benim bağlantım sayfa yüklenirken senkron olarak eklendi. Browsertrix davranışları sırasında sonradan beliren bağlantılar ayrı bir durumdur ve tam da bu konu için açık bir issue var — #723, "Links on pages that are discovered during behaviors are not extracted". Bu senaryoyu test etmedim; dolayısıyla bunun hakkında bir iddiam yok.

Dosya arşivlendi. Uç noktalar arşivlenmedi.

Sınıf B’deki kaçırmayı doğrulamak için özet bir sayım yerine WARC içinde kayıt kayıt ilerlemek gerekti.

app.js arşivde var — tek bir yanıt kaydı, 222 baytlık bir JavaScript gövdesi — ve sınıf B’deki iki sabit yol da bunun içinde birebir görünüyor. Buna karşılık, ne /api/js-endpoint-7 ne de /api/js-endpoint-8 tüm dosya içinde tek bir kaydın hedef URI’si değil: sıfır yanıt kaydı, sıfır istek kaydı. Her bir sabit string tüm arşiv boyunca tam olarak bir kez geçiyor ve ikisi de app.js içindeki saklanmış gövdede yer alıyor.

Bu, sıkıcı açıklamayı (“app.js hiç alınmadı”) devre dışı bırakıyor. Arşivci, bu uç noktaları referans gösteren dosyayı sakladı ama onlara hiç istek göndermedi; çünkü loadData() hiç çağrılmadı. Browsertrix’in varsayılan davranışları açıktı — autoplay, autofetch, autoscroll, siteSpecific — ancak autofetch de onları kurtaramadı. Bu da autofetch’in ne yaptığını okuyunca mantıklı: img srcset girdilerini, stylesheet’leri ve data-* URL’lerini hedef alır; fonksiyon gövdelerine gömülmüş string sabitlerini değil.

Aynı örneklemeyi karşılaştırma amaçlı olarak Katana v1.6.1 ile de katana -u <seed> -jc -silent -nc -d 4 şeklinde çalıştırdım. Onun ham discovery summary dosyası, özellikle oluşturulmuş iki JavaScript sınıfında ters sonucu kaydediyor:

Her iki komut da aynı örneklemeyi ve uç nokta adlarını kullandı. Tablo, browser ve statik crawler’lar için genel bir sıralama değildir; uç nokta envanteri ile oturum korumasının neden farklı kapsama testleri gerektirdiğini gösterir.

“Gerçek tarayıcıysa JavaScript’in yaptığı her şeyi yakalar” ifadesi, incelemelerde sık tekrar edilir. Fazlasıyla iddialı bir cümledir. O sadece çalıştırılmış trafiği yakalar. Bir URL’den söz eden ama onu hiç çağırmayan kod, trafik üretmez; trafik yoksa kayıt da yoktur.

Oynatma gövdeleri mevcut; ama kontrol etmediğim bir şey var

Çalışma anında üretilen iki uç nokta için, arşivlenmiş HTTP yanıt gövdelerini WARC’tan çıkardım ve bunların servis edilen JSON’u içerdiğini doğruladım: çalışma anında eklenen bağlantının hedefi için 206 bayt, çalışma anındaki fetch() hedefi için 201 bayt. Yani bunlar boşluğa işaret eden indeks iskeletleri değil; içerik doğrudan arşivin içinde. Bu da oynatma sırasında sunulabilmeleri için ön koşuldur.

Yapmadığım şey ise pywb ya da replayweb.page kurup arşivi gerçekten render etmek oldu. Gövdenin arşivde olması ile doğru, render edilmiş oynatma ayrı şeylerdir; bu test yalnızca ilkini kapsıyor. Oynatma davranışı, özgünlük kontrolleri, zincirleme muhafaza ve delil olarak kabul edilebilirlik ayrı ayrı doğrulama gerektirir.

Üretim seviyesinde bir yakalama daha geniş bir kabul testi ister

Bu örneklem dar bir soruyu net biçimde yanıtlıyor: Senkron bir çalışma anı bağlantısı ve sayfa tarafından başlatılan bir istek ağ trafiğine ve arşiv kayıtlarına dönüştü mü? Üretim amaçlı bir koruma işi ise geçerli bir WACZ üretirken başka pek çok noktada başarısız olabilir.

Önce oynatmayı kontrol edin. Paketi, koleksiyonun gerçekte kullanacağı oynatma sisteminde açın ve sabit sayfaları yakalama zamanındaki referansla karşılaştırın. Render edilmiş metni, görselleri, stilleri, gezinmeyi ve kayıt açısından önemli olan etkileşimleri denetleyin. Ardından oynatma tarayıcısının network panel’ini eksik alt kaynaklar için inceleyin. Bir yanıt gövdesi WARC içinde mevcut olabilir; buna rağmen yeniden yazım, indeksler, zamanlama, origin’ler veya bağımlılıklar uyuşmadığı için oynatma yine başarısız olabilir. Bu inceleme o sınırı geçmedi.

Dinamik davranışlar kendi örneklem setini hak eder. Buradaki sınıf C bağlantısı sayfa yüklenirken senkron olarak görünüyordu. Gerçek uygulamalar ise içerikleri zamanlayıcılar, kaydırma, onay kapatma, rota değişiklikleri, özel elementler veya uzun API zincirleri sonrasında açabilir. Güvendiğiniz her davranışın arkasına bilinen bir hedef yerleştirin ve hem sunucu hit’ini hem de arşivlenmiş gövdeyi doğrulayın. Browsertrix’in varsayılan davranışları bu test için yararlı girdilerdir; her gecikmeli duruma ulaşıldığının kanıtı değildir. Özellikle bağlantılar davranışlar sırasında, ilk sayfa yürütmesi sırasında değil de, ortaya çıkıyorsa #723 daha da önemlidir.

Kimlik doğrulamalı yakalamalar oturum sorularını da beraberinde getirir. Giriş durumunun tarayıcı profilinize geçtiğini, gereken gezinmeler boyunca korunduğunu ve izole olması gereken koleksiyonlara sızmadığını doğrulayın. Token yenileme ve çıkış yollarını da çalıştırın. Arşiv özel ya da kişisel materyal içeriyorsa, aynı kabul planının parçası olarak erişim kontrollerini ve saklama politikalarını da test edin. Teknik olarak eksiksiz bir yakalama, toplandıktan sonra yine de yanlış yönetilebilir.

Service worker’lar, streaming medya, WebSocket’ler, indirmeler, cross-origin frame’ler ve imzalı URL’ler hedef için önemliyse, her biri için temsilî bir sayfa ayırın. On bir sayfalık örneklem bunlar hakkında hiçbir şey söylemez. Aynı şekilde, bir sayfanın dakikalarca aktif kalması, olağan bekleme penceresinden sonra istek göndermesi veya kullanıcı hareketi gerektirmesi durumunda crawler’ın nasıl davrandığını da ortaya koymaz. “Gerçek Chromium” ifadesini kapsama garantisi gibi kullanmaktan kaçının; koleksiyonun koruması gereken tarayıcı davranışlarını tanımlayın ve her birini gözlemlenebilir hale getirin.

Son olarak, kaçırmaları teşhis etmek için gereken kanıtı saklayın. Tam imaj digest’ini ve komutu, Browsertrix günlüklerini, sayfa listelerini, indeksleri, WARC/WACZ checksum’larını, varsa sunucu tarafı istek kanıtlarını ve küçük bir ground-truth manifest’i kaydedin. Tekrarlanan yakalamalarda, zaman, konfigürasyon ve ortamı da artifact ile birlikte kaydedin. Bu kayıtlar hukuki kabul edilebilirlik yaratmaz; ancak teknik iddiayı yeniden üretilebilir hale getirir ve daha sonraki bir farkın kaynaktan mı, crawler’dan mı yoksa oynatma yığınından mı geldiğini ortaya çıkarır.

Bu küçük gövdeli örneklem bayt olarak neye mal oldu

Bu örneklem sayfa başına yalnızca birkaç yüz bayt servis ediyor; bu yüzden overhead oranları, varlık ağırlıklı sitelere aynen uygulanmamalı. Bu dar aralıkta arşivin toplam boyutundan ziyade bileşimini ölçtüm:

Tür bazında adetler ve bayt toplamları kamuya açık capture-summary.json dosyasında yer alır; paylar için 17,024 baytlık toplam kayıt içeriği esas alınmıştır.

Bu küçük gövdeli çalışmada istek kayıtları yanıt içeriğinden daha ağır bastı; istek + urn:pageinfo: baytları, yanıt yükünün yaklaşık 2.1 katıydı. Bu, bu örneklemin kayıt karışımını anlatır; genel bir WARC oranını değil.

Diskte, üç izole çalışmada:

Medyana bakınca dört oran ortaya çıkıyor:

Ve WACZ’in kendi içinde:

Beni en çok şaşırtan son satır oldu. Küçük bir crawl’da arşiv paketinin neredeyse üçte biri web’in kendisi değil, crawl’un kaydı.

Ölçüm kararlıydı: Yanıt yükü üç çalışmanın her birinde de bayt bayt aynı döndü (her seferinde 5,339 B); WARC.gz ve WACZ ise %0.4’ün altında değişti.

Bu oranlar, görseller, fontlar ve büyük script paketleri olan gerçek sayfalara taşınamaz. Yapısal nokta şu: istek ve page-info kayıtları, yük boyutundan bağımsız bir ek yük oluşturur. Üretim depolamasını planlamadan önce temsili bir örnekleme ölçüm yapın; 10× örneklem oranını korpus tahmininizle çarpmayın.

Kurulum ve planlamanız gereken disk alanı

Docker veya Colima kurulu ve çalışır durumdaysa, Browsertrix’e özel kurulum docker pull webrecorder/browsertrix-crawler:latest ve ardından docker run … crawl --url … --generateWACZ komutundan ibarettir. İmaj Chromium’u birlikte getirdiği için ayrıca bir tarayıcıya ya da Python ortamına gerek yoktu.

Bu kolaylığın ölçülen maliyeti şuydu:

Sürtünmenin büyük kısmı konteyner tarafında; tarayıcı paketlemenin bedeli de bu indirme ve açma satırında yatıyor. Bunu --shm-size 1g ile çalıştırdım ve örneklem host üzerinde dururken crawl konteyner içinde koştuğu için --add-host=host.docker.internal:host-gateway ve loopback yerine 0.0.0.0’a bağlanmış bir örneklem gerekiyordu. Kamu internetini tarıyorsanız bu ağ adımını tamamen atlayabilirsiniz; fakat kendi makinenizde ya da iç bir staging host’ta bir şeyi arşivliyorsanız, buna bir öğleden sonra ayırın.

Çıktı dizini hafife alınması en kolay satırdır. Bu büyümeyi gerçek bir crawl’a taşıyın ve disk dolmadan önce, iş bittikten sonra değil, depolamayı planlayın.

Tarayıcının açılışı, yalnızca on bir sayfalık bir crawl’un 28–30 saniye sürmesine anlamlı katkıda bulunuyor olabilir; ancak startup süresini gezinme veya paketleme süresinden ayırmadım. Bu çalışmadan sayfa başına throughput sonucu çıkarılamaz.

Örneklem oranlarını kötüye kullanmadan depolama planlamak

Bir koleksiyonu boyutlandırmanın doğru yolu ampirik olandır. Hedefin gerçek dağılımını temsil eden sayfaları seçin: ince uygulama kabukları, görsel ağırlıklı açılış sayfaları, belge indirmeleri, uzun makaleler ve kapsam içindeyse kimlik doğrulamalı görünümler. Her sınıfı, amaçlanan davranışlar ve paketleme ayarlarıyla yakalayın. Yanıt yükünü, WARC’ı, WACZ’ı, indeksleri, günlükleri, tarayıcı profil kalıntılarını ve çalışma sırasında kalan geçici çalışma alanını ölçün. Paketleme kısa süreliğine birden fazla kopya tutuyorsa, tepe disk kullanımı nihai paket kadar önemlidir.

Sabit ve değişken bileşenleri ayırın. 3.51 GB’lık konteyner imajı, bir işçi üzerinde birçok yakalama tarafından paylaşılabilen bir dağıtım yüküdür. İstek kayıtları, page-info kayıtları, indeksler ve sayfa listeleri crawl etkinliğiyle birlikte büyür. Yanıt gövdeleri büyük ölçüde hedefe bağlıdır; günlükler ise çalışma süresi ve ayrıntı düzeyine bağlıdır. Saklama ve çoğaltma, nihai koleksiyonu crawl davranışından bağımsız olarak katlar. Tüm bunları “sayfa başına bayt” içine sıkıştıran bir kapasite modeli kırılgan olur.

Sıkıştırma ve deduplikasyon da temsili içerik ister. Bu örneklemin yanıt yükü üç çalışmada da bayt olarak birebirdi; fakat bu, reklamları, zaman damgaları, kişiselleştirilmiş yanıtları veya cache-busting asset URL’leri değişen sayfaları anlatmaz. Programın bir parçası olarak tekrarlı yakalamalar varsa, aynı sayfaların ardışık yakalamalarını ölçün ve görünüşte değişmeyen sayfaların gerçekten iyi deduplikasyon yapıp yapmadığını görmek için revisit kayıtlarını inceleyin. Benzer şekilde, günlüklerin ve indekslerin koruma yüküyle aynı çoğaltma seviyesinde saklanıp saklanmadığını test edin.

Operasyonel olarak, koleksiyon başlamadan önce uyarı eşikleri belirleyin. Boş alanı, koleksiyon başına büyümeyi, başarısız paketlemeyi ve tarayıcı profillerinin ya da geçici dizinlerin boyutunu izleyin. Yalnızca checksum kontrolü değil, saklanan WACZ üzerinden bir geri yükleme denemesi de yapın. Yukarıdaki oranlar hangi bileşenlerin var olduğunu gösterdiği için yararlıdır; bunların siteniz için ne kadar büyük olacağını ise temsili örnek belirler.

Bu varsayımları kapasite tahmininin yanına not edin ve pilot crawl’dan sonra yeniden gözden geçirin.

Kapsam disiplini, iki kontrol ile test edildi

Dolanıp duran arşivleyici crawler’lar gerçek bir operasyon riskidir — aynı anda hem hukuki sorun hem depolama faturası yaratabilirsiniz. Ana sayfam http://outofscope.test:<port>/page/out bağlantısını veriyordu; bu, aynı örnekleme işaret eden farklı bir host adıydı. Dolayısıyla o Host header ile gelen bir hit, gerçek internet trafiği olmadan kapsam dışı bir fetch’i kanıtlardı.

İkinci satır, birincinin neden anlamlı olduğunu gösteriyor. any altında bağlantıya iki kez ulaşıldı; yani gerçekten ulaşılabiliyordu — varsayılan prefix kapsamındaki sıfır, crawler’ın bağlantıyı fark edememesinden değil, gerçek kapsam disiplininden kaynaklanıyordu. Diğer konfigürasyonlarda kapsam dışı ziyaretlere dair açık bir rapor var, #788, ancak bunu bu örneklemde varsayılan prefix scope altında yeniden üretemedim. Varlığını bilmek önemli; ben gördüm demek için değil.

Sağlamlık, iyi anlamda kayda değer değildi. HTTP 500 dönen bir rota ve ölü bir bağlantı ikisi de istendi; crawl düzgün şekilde çıktı verdi, geçerli bir WARC ve WACZ üretti ve ölü bağlantı sistemi bozmak yerine deduplikasyona uğramış bir revisit kaydı olarak saklandı.

Artılar ve eksiler

Artılar

• Çalışma anında DOM’a eklenen bağlantıları ve sayfa tarafından başlatılan fetch() çağrılarını yakalar — ikisi de hem arşivde hem sunucu tarafında, düz metin olarak hiçbir yerde bulunmayan yollarda doğrulandı.
• Statik HTML ve derinlik dolaşımı eksiksiz: 4/4 bağlantı, 3/3 derinlik zinciri, kaçırma yok.
• Docker/Colima çalışır hale geldikten sonra tek bir docker run, WARC ve WACZ üretti; Chromium imajın içindeydi.
• Varsayılan prefix scope sıfır kapsam dışı istekle durdu; any ise belgede anlatıldığı gibi genişledi, yani ayar gerçekten dediğini yapıyor.
• Çıktı, tescilli bir blob değil; standart tabanlı bir arşivdir (WARC, CDX indeksi ve sayfa listesi ile WACZ olarak paketlenmiş).
• Neredeyse deterministik arşivler: üç çalışmada yük baytları birebir aynı, diskteki boyut %0.4’ün altında değişiyor.
• Temiz hata davranışı: 500 dönen rota ve bozuk bağlantı crawl’u durdurmadı.

Eksiler

• Çalıştırılmayan JavaScript içindeki URL sabitleri basitçe keşfedilmiyor (0/2); içeren dosya arşivlenmiş olsa bile. Tasarım gereği doğru, ama endpoint keşfi sizin hedefinizse gerçek bir kapsama boşluğu.
• Ağır footprint: yaklaşık 1 GB indirme, 3.51 GB disk, ve hızla büyüyen çıktı dizinleri.
• Küçük sayfalarda bayt yükü kayda değer — istek + pageinfo kayıtları gerçek yükten fazlaydı ve WACZ’in yaklaşık %30’u crawl günlüğüydü.
• AGPL-3.0, ticari gömme için ciddi uyum çalışması gerektiriyor.
• Yapılandırılmış veri aracı değil. Şema yok, alan eşlemesi yok, sonunda temiz satırlar yok.
• Sayfa başına throughput tasarım gereği mütevazı; çünkü her sayfa gerçek bir tarayıcıdan geçiyor.

Kimler kullanmalı, kimler kullanmamalı

Browsertrix, gerekli çıktısı çıkarılmış satırlar değil, tarayıcı tarafından alınmış kaynakların bir arşivi olan ekipler için tasarlanmıştır. Bu örneklemde çalışma anında alınan yanıt gövdeleri WARC içinde mevcuttu ve WACZ’e paketlendi. Kütüphaneler, haber merkezleri ve araştırmacılar mantıklı kullanıcılar olsa da, üretim kullanımı için render edilmiş oynatma, kimlik doğrulama, service worker’lar, onay akışları, gecikmeli davranışlar, akışlı varlıklar, saklama kontrolleri ve varsa delil işleme gereklilikleri ayrıca test edilmelidir.

Eğer aslında ihtiyacınız veri ise, kullanmayın. Hedef “bu 400 sayfadaki her ürün ve fiyatı bana bir tablo olarak ver” ise, arşivciyle oraya gitmek garip bir yoldur — gigabaytlarca veri arşivlersiniz ve sonra yine WARC dosyaları üzerinde çıkarım kodu yazmanız gerekir. Bir uygulamanın API yüzeyini haritalıyorsanız da kullanmayın; çünkü sınıf B sonucu açıkça gösteriyor ki statik bir JavaScript ayrıştırıcısı, Browsertrix’in hiç dokunmadığı uç noktaları bulabilir. Ve Docker’dan hoşlanmıyorsanız ya da 3.5 GB’lık bir imajın sorun olduğu bir yerde çalışıyorsanız, bu sizin için uyum sağlayacak araç değildir.

Yetkilendirme ve saklama

Kapsam kontrolleri yetkilendirme sağlamaz. Tarama öncesinde izin verilen host’ları, saklama süresini ve arşiv erişimini tanımlayın; özellikle kalıcı yakalamalar kişisel veri içerebileceğinden. prefix/any testi, konfigürasyon değişikliklerinin ağ erişimini nasıl değiştirdiğini gösterir; bu, belirli bir koleksiyon için hangi erişimin yasal olduğunu ortaya koymaz.

İlgili inceleme: web scraping ve arşivlemenin hukuki boyutu.

Gerekli çıktıya göre alternatifler

Çıktıya göre seçim yapın. Browsertrix, WARC/WACZ içinde korumayı hedefler. Playwright gibi bir tarayıcı otomasyonu kütüphanesi programlanabilir bir sayfa sunar ama yakalama paketlemesini size bırakır. Uç nokta keşfi yapan crawler’lar URL envanteri çıkarır; çıkarım araçları ise metin ya da yapılandırılmış kayıt döndürür. Bu kategoriler aynı tarayıcıyı paylaşabilir ve yine de farklı işleri çözebilir.

İlgili inceleme: Heritrix incelemesi.

Açıklama: Thunderbit, yayıncının ürünüdür ve bu Browsertrix örnekleminde test edilmemiştir. Yönetilen çıkarım kategorisine aittir; standart tabanlı bir arşiv yerine sayfa metni ya da yapılandırılmış veri üretir. Bu inceleme yalnızca çıktı sınırını destekler; karşılaştırmalı performans veya yetenek iddiası sunmaz.

Web Verisi Çıkarma için Thunderbit’i Deneyin

Karar

Gerekli çıktı bir WARC/WACZ yakalamasıysa ve konteyner içindeki Chromium dağıtımınıza uyuyorsa Browsertrix Crawler’ı kullanın. Bu örneklemde arşiv kayıtları ve sunucu hit’leri, senkron çalışma anı DOM’u ve sayfa başlatmalı fetch’lerde aynı sonuç verdi; varsayılan prefix scope ikinci host’u dışarıda bıraktı ve hata veren rotalar geçerli bir arşivi engellemedi.

Üretim kullanımından önce, oynatmayı, gecikmeli davranışları, kimlik doğrulamalı oturumları, service worker’ları, temsili sayfalardaki depolama bileşimini ve lisans yükümlülüklerini doğrulayın. Test edilen sınır daha dardır: hiç çalıştırılmayan kod referansları, içlerindeki script korunmuş olsa bile, hedefleri için hiçbir istek ve hiçbir arşiv kaydı üretmedi.

Web Verisi Çıkarma için Thunderbit’i Deneyin Get Started Free

SSS

Burada WARC ile WACZ arasındaki fark nedir? WARC, yakalanan istek, yanıt ve ilgili kayıtları içerir. WACZ ise WARC’ı indeksler, sayfa listeleri, metadata ve günlüklerle birlikte dağıtım ve oynatma araçları için paketler. Bu inceleme her iki paketi de kontrol etti, ancak bir oynatma render etmedi.

Depolamayı nasıl tahmin etmeliyim? Temsili sayfaları ölçün ve örnekte günlükler ile indeksler dahil tam WACZ bileşimini saklayın. Bu yazıdaki oranlar alışılmadık derecede küçük yanıt gövdelerinden geliyor; bunları üretim URL sayısıyla çarpmak uygun değildir.

Beni yönlendirdiğim siteden dışarı taşır mı? Benim testimde varsayılan ayarda hayır. --scopeType prefix ile farklı host’taki bir bağlantı sıfır kez istendi; --scopeType any’ye geçince iki kez istendi. Bu da bağlantının erişilebilir olduğunu ve varsayılanın sıfır sonucunun gerçek bir kapsam disiplini olduğunu kanıtlıyor. Diğer konfigürasyonlarda kapsam dışı ziyaretlere dair açık bir upstream raporu var; onu varsayılan altında yeniden üretmedim, bu yüzden kendi kapsam ayarlarınızı kontrol edin, varsaymayın.

Oynatma doğruluğunu iddia etmeden önce neyi test etmeliyim? WACZ’ı amaçlanan oynatma sistemine yükleyin ve render edilmiş sayfaları, etkileşimleri ve gerekli alt kaynakları canlı ya da referans yakalamayla karşılaştırın. WARC içinde gövde bulunması gereklidir; ancak tek başına render edilmiş oynatmayı doğrulamaz.

Browsertrix arşivlenmiş bir sayfayı yapılandırılmış satırlara dönüştürür mü? Hayır. Çıktısı seçilmiş alanlardan oluşan bir tablo değil, bir arşiv paketidir. Teslimat ürünler, fiyatlar, kişiler ya da başka bir şemaysa, yakalamadan sonra hâlâ bir çıkarım aşamasına — ya da birincil çıktısı yapılandırılmış veri olan farklı bir araca — ihtiyacınız vardır.