مراجعة Browsertrix Crawler: يَحفظ ما فعله المتصفح، لا ما يقوله الكود

Browsertrix Crawler هو أداة الأرشفة الخاصة بـ Webrecorder: صورة Docker واحدة تُشغّل Chromium حقيقيًا عبر Puppeteer، وتلتقط كل ما يجلبه المتصفح، ثم تكتبه إلى WARC — وهو تنسيق الأرشيف القياسي للويب — مع إمكانية تجميعه داخل حزمة WACZ تتضمن فهرسًا وقائمة صفحات وسجلات. وهذه الغاية بالذات هي ما يميّزه عن أدوات الاستخراج التي يشبهها ظاهريًا. فمُستخرج البيانات يذهب ليحصد الحقول ثم يتخلص من الصفحة، بينما الأداة الأرشيفية تحتفظ بالزيارة نفسها — البايتات، والرؤوس، وترتيب وصولها — حتى يمكن فتح الصفحة لاحقًا بعد أن يتغير الموقع أو يختفي. وتُواصل Webrecorder صيانة هذا الجزء من بنية الويب، بما في ذلك الصيغ وآلية الإعادة والتشغيل، منذ وقتٍ سابق بكثير من تحوّل الأرشفة إلى فئة منتجات، وتعتمد عليه المكتبات وغرف الأخبار والباحثون.

شغّلت الإصدار v1.14.0 داخل Docker على بيئة محلية تحتوي على أربع فئات مختلفة عمدًا من نقاط النهاية، وراقبت جانبي عملية الزحف: سجلات WARC لمحتوى الأرشيف، وعدّادًا على الخادم لاحتساب الطلبات الفعلية. والفرق المهم لم يكن بين الثابت والديناميكي فحسب. فقد التقط Browsertrix رابطًا جرى إنشاؤه وقت التشغيل وطلب fetch() صادرًا من الصفحة، لكنه لم يطلب عبارتي URL حرفيتين داخل دالة JavaScript لم تُستدعَ.

تمت أرشفة الملف app.js المرتبط بالكامل، بما في ذلك كلا المسارين الحرفيين، لكن لم ينتج أيٌّ من الطرفين سجل استجابة أو سجل طلب أو حتى ضربة على الخادم. والسبب أن الدالة التي تحتويهما لم تعمل أصلًا. لذلك تقوّم هذه المقالة Browsertrix بوصفه أرشيفًا لجلسة متصفح، لا كفهرس لكل عنوان URL ورد في شفرة المصدر.

ما هو Browsertrix Crawler فعلًا

يدخل كثيرون وهم يتوقعون أداة استخراج، ثم يخرجون بخيبة أمل. فلا شيء في المسار الافتراضي يسلّمك ملف CSV بأسعار المنتجات، وتوقع ذلك يشبه انتظار كاميرا السيارة أن تكتب لك تقريرًا مروريًا. الناتج هنا هو سجل قابل لإعادة التشغيل لجلسة تصفح، وكل قرار تصميم لاحق ينبني على هذه الفكرة.

اختبرت v1.14.0 في 27 يوليو 2026: الصورة webrecorder/browsertrix-crawler:latest عند digest sha256:9d6800a8…، مع تأكيد البناء عبر crawl --version. المشروع مرخّص تحت AGPL-3.0. وقد جرت كل القياسات داخل Docker عبر Colima على macOS arm64، ضد بيئة محلية مضبوطة؛ كما قدّم عدّاد الخادم دليلاً مستقلًا عن سجلات Browsertrix وتحليل الأرشيف.

وتستحق AGPL-3.0 وقفة خاصة. فهي ترخيص copyleft قوي مع شروط للاستخدام عبر الشبكة. فإذا كان Browsertrix Crawler سيُدمج داخل منتج تجاري بدل تشغيله كأداة مستقلة، فليقرأ أحدهم الترخيص جيدًا قبل الإطلاق. هذا تنبيه، وليس استشارة قانونية.

الأرشيف يسجّل الجلسة، لا الشفرة المصدرية

كانت بيئتي الاختبارية تخدم أربعة أنواع من نقاط النهاية، وفصلتها عمدًا لأن الأرشيف يتعامل معها بطرق مختلفة تمامًا:

• الفئة A — وسم <a href> عادي داخل HTML. أربع صفحات مع سلسلة عمق من ثلاث مستويات. أي زاحف تقريبًا سيجدها.
• الفئة B — عناوين URL حرفية داخل دالة لا تُنفَّذ أبدًا. مساران هما /api/js-endpoint-7 و/api/js-endpoint-8، موضوعان كنصين داخل loadData() غير المستدعاة في app.js المرتبط.
• الفئة C — رابط يُبنى وقت التشغيل. وسم <a href> يُركّب من أجزاء في JavaScript ('endpoint' + (6 * 7)) ثم يُضاف إلى DOM. المسار المتصل /runtime-only/endpoint42 لا يظهر حرفيًا في أي بايت من الملف المقدم.
• الفئة D — طلب fetch() تنفّذه الصفحة فعلًا. المسار يُركّب بالطريقة نفسها ('runtime-xhr-' + (33 * 3))، ثم يُطلب فعليًا عند التحميل.

في الفئتين C وD، كانت المسارات الكاملة غائبة كنصوص متصلة داخل الملفات المقدمة. لذلك فوجودها في سجلات الخادم وسجلات الاستجابة دليل على أن إنشاءها وقت التشغيل ومسارات الطلب قد استُخدمت فعلًا في هذه البيئة.

ما الذي التُقط، وما الذي لم يُلتقط

أداتان، تمت مطابقة نتائجهما في كل خلية: سجلات استجابة WARC (ما يوجد داخل الأرشيف) وعدّاد ضربات الخادم في البيئة الاختبارية وفق (Host header, path) (ما طُلِب فعلًا). واتفقا في كل المواضع.

الفئة C هي التي تفرّق بين متصفح حقيقي وزحف ثابت. فالاستخراج الافتراضي للروابط يقرأ DOM المعروض (a[href]->href، وفق وثائق الخيارات الشائعة)، لذا فإن الرابط الذي لا يظهر إلا بعد تشغيل JavaScript سيُضاف إلى قائمة الانتظار ثم يُجلب ويُؤرشف. أما الفئة D فتصل لسبب مختلف: فالصفحة نفسها هي التي أرسلت الطلب، والأداة الأرشيفية تقف على خط الشبكة وتُسجّل كل ما يمرّ.

وهناك حدٌّ صريح للفئة C: فقد أُدرج الرابط عندي بشكل متزامن أثناء تحميل الصفحة. أما الروابط التي تظهر لاحقًا أثناء سلوكيات Browsertrix فهي حالة مختلفة، وهناك مشكلة مفتوحة خصيصًا لهذا الشأن — #723، "Links on pages that are discovered during behaviors are not extracted". لم أختبر هذا السيناريو، لذلك لا أزعم فيه شيئًا.

الملف أُرشف. أما نقاط النهاية فلم تُرشف.

تأكيد خطأ الفئة B احتاج مرورًا سجلًا سجلًا عبر WARC بدل الاكتفاء بعدٍّ إجمالي.

الملف app.js موجود في الأرشيف — سجل استجابة واحد، ونص JavaScript بحجم 222 بايت — وكلا العنوانين الحرفيين من الفئة B يظهران فيه كما هما. وفي المقابل، لا يظهر /api/js-endpoint-7 ولا /api/js-endpoint-8 كـ URI مستهدف في أي سجل داخل الملف كله: صفر سجلات استجابة، صفر سجلات طلب. وكل نص حرفي منهما يظهر مرة واحدة فقط عبر الأرشيف بأكمله، وكلتا المرتين داخل جسم app.js المحفوظ.

وهذا يستبعد التفسير الممل (“app.js لم يُجلب أصلًا”). فقد خزّن الأرشيف الملف الذي يشير إلى تلك النهايات ولم يرسل أي طلب لها، لأن loadData() لم تُستدعَ قط. وكانت سلوكيات Browsertrix الافتراضية مفعّلة — autoplay وautofetch وautoscroll وsiteSpecific — لكن autofetch لم يُنقذ الموقف أيضًا، وهو أمر منطقي إذا قرأت ما يفعله autofetch: فهو يتتبع قيم srcset الخاصة بالصور، وأوراق الأنماط، وروابط data-*، لا النصوص الحرفية المخبأة داخل أجسام الدوال.

ولإظهار الفرق داخل نفس البيئة، شغّلت أيضًا Katana v1.6.1 بالأمر katana -u <seed> -jc -silent -nc -d 4. ويُظهر ملخص الاكتشاف الخام نتيجة معاكسة على فئتي JavaScript المصممتين عمدًا:

استخدم كلا الأمرين البيئة نفسها وأسماء النهايات نفسها. والجدول ليس ترتيبًا عامًا بين المتصفحات والزواحف الثابتة؛ بل يوضح لماذا يحتاج جرد النهايات والحفاظ على الجلسة إلى اختبارات تغطية مختلفة.

عبارة “متصفح حقيقي، إذًا يلتقط كل ما يفعله JavaScript” ستراها تتكرر كثيرًا. لكنها مبالغ فيها. فهو يلتقط الحركة المنفَّذة فعلًا. أما الكود الذي يذكر عنوان URL من دون استدعائه أبدًا فلا ينتج حركة، ولا حركة تعني لا سجل.

أجسام الإعادة موجودة، مع شيء لم أتحقق منه

بالنسبة للنهايتين المنتجتين وقت التشغيل، استخرجت أجسام استجابة HTTP المؤرشفة من WARC وتأكدت أنها تحتوي JSON المخدَّم: 206 بايت لهدف الرابط المُدرج وقت التشغيل، و201 بايت لهدف fetch() وقت التشغيل. إذن فهذه ليست مجرد فهارس فارغة تشير إلى لا شيء — المحتوى نفسه موجود داخل الأرشيف، وهو الشرط المسبق لكي يقدّمها نظام الإعادة لاحقًا.

لكن ما لم أفعله هو تشغيل pywb أو replayweb.page وعرض الأرشيف. وجود الجسم داخل الأرشيف وعرضه بشكل صحيح في إعادة التشغيل هما ادعاءان مختلفان، وهذه التجربة تغطي الأول فقط. أما سلوك الإعادة، وضوابط الأصالة، وسلسلة الحيازة، وقابلية القبول كدليل، فتتطلب جميعها تحققًا منفصلًا.

تحتاج عملية الالتقاط الإنتاجية إلى اختبار قبول أوسع

تجيب البيئة الاختبارية عن سؤال ضيق بوضوح: هل أصبح الرابط المتولد وقت التشغيل بشكل متزامن والطلب الصادر من الصفحة حركة مرور شبكية وسجلات أرشيفية؟ أما مهمة الحفظ الإنتاجية فعادةً ما تمتلك عدة طرق أخرى للفشل، رغم أنها ما تزال تُنتج WACZ صحيحًا.

ابدأ بالإعادة. افتح الحزمة في نظام الإعادة الذي ستستخدمه المجموعة فعلًا، وقارن مجموعة ثابتة من الصفحات مع مرجع وقت الالتقاط. افحص النص المعروض والصور والأنماط والتنقل وأي تفاعلات مهمة للسجل. ثم راقب لوحة الشبكة في متصفح الإعادة بحثًا عن الموارد الفرعية الناقصة. قد يوجد جسم استجابة في WARC بينما تفشل الإعادة لأن إعادة الكتابة أو الفهارس أو التوقيت أو المصادر أو الاعتماديات لا تتطابق. هذه المراجعة لم تتجاوز هذه الحدود.

السلوك الديناميكي يستحق بيئة اختبار خاصة به. الرابط من الفئة C هنا ظهر متزامنًا أثناء تحميل الصفحة. أما التطبيقات الحقيقية فقد تكشف المحتوى بعد المؤقتات أو التمرير أو إغلاق نوافذ الموافقة أو تغييرات المسار أو العناصر المخصصة أو سلاسل API طويلة. ضع هدفًا معروفًا خلف كل سلوك تعتمد عليه، وتحقق من كلٍّ من ضربة الخادم والجسم المؤرشف. سلوكيات Browsertrix الافتراضية مفيدة في هذا الاختبار، لكنها ليست دليلًا على أن كل حالة متأخرة قد تم الوصول إليها. وتكتسب المشكلة #723 أهمية خاصة إذا كانت الروابط تظهر أثناء السلوكيات لا أثناء التنفيذ الأولي للصفحة.

الالتقاطات التي تتطلب تسجيل دخول تفتح أسئلة جلسة. تأكد من أن حالة الدخول تدخل ملف المتصفح، وتستمر عبر التنقلات المطلوبة، ولا تتسرب إلى مجموعات ينبغي عزلها. اختبر تحديث الرموز ومسارات تسجيل الخروج. وإذا كان الأرشيف يحتوي على مواد خاصة أو شخصية، فاختبر ضوابط الوصول والاحتفاظ للملفات الناتجة ضمن خطة القبول نفسها. فالالتقاط المكتمل تقنيًا قد يُساء التعامل معه بعد الجمع.

أما service workers، ووسائط البث، وWebSockets، والتنزيلات، والإطارات عبر المصادر، وعناوين URL الموقعة، فكلٌّ منها يستحق صفحة تمثيلية إذا كان مهمًا لهدفك. فالبيئة المؤلفة من إحدى عشرة صفحة لا تقول شيئًا عنها. ولا تثبت أيضًا كيف يتصرف الزاحف حين تبقى الصفحة نشطة لدقائق، أو تُصدر طلبات بعد نافذة الاستقرار المعتادة، أو تحتاج إلى إيماءات المستخدم. لا تجعل عبارة “Chromium حقيقي” مرادفًا لتغطية شاملة؛ بل حدّد سلوكيات المتصفح التي يجب أن يحتفظ بها الجمع، واجعل كل واحدة منها قابلة للملاحظة.

وأخيرًا، احتفِظ بالأدلة اللازمة لتشخيص الإخفاقات. احفظ digest الدقيق للصورة والأمر المستخدم، وسجلات Browsertrix، وقوائم الصفحات، والفهارس، وchecksums الخاصة بـ WARC/WACZ، وأدلة الطلبات على الخادم حين تكون متاحة، وملفًا صغيرًا للحقيقة المرجعية. وفي عمليات الالتقاط المتكررة، سجّل الوقت والإعدادات والبيئة إلى جانب المخرجات. هذه السجلات لا تصنع حجية قانونية، لكنها تجعل الادعاء التقني قابلاً لإعادة الإنتاج وتُظهر ما إذا كان الاختلاف اللاحق ناتجًا عن الهدف أم الزاحف أم طبقة الإعادة.

ما كلفته هذه البيئة صغيرة الحمولة من بايتات

لا تقدّم هذه البيئة سوى بضع مئات من البايتات لكل صفحة، لذا لا ينبغي إسقاط نسبها على مواقع كثيفة الأصول. وضمن هذا النطاق الضيق، قستُ تركيب الأرشيف بدلًا من الاكتفاء بحجمه النهائي:

أعداد الأنواع وإجماليات البايتات منشورة في ملف capture-summary.json العام؛ أما النِّسب فحُسبت على أساس إجمالي 17,024 بايتًا من محتوى السجلات.

في هذه التجربة صغيرة الحمولة، تفوقت سجلات الطلب على محتوى الاستجابة، وكانت بايتات الطلب مع urn:pageinfo: تعادل تقريبًا 2.1× من حمولة الاستجابة. وهذا يصف مزيج السجلات في هذه البيئة فقط، لا نسبة عامة في WARC.

وعلى القرص، عبر ثلاث تشغيلات معزولة:

وباستخدام الوسيطات، تظهر أربع نسب:

وداخل WACZ نفسه:

الصف الأخير هو ما فاجأني. فقرابة ثلث حزمة الأرشيف، في زحف صغير، هو سجل الزحف نفسه لا الويب.

كانت القياسات مستقرة: حمولة الاستجابة عادت متطابقة بالبايت في التشغيلات الثلاث (5,339 بايتًا كل مرة)، مع تباين WARC.gz وWACZ بأقل من 0.4%.

ولا يمكن نقل هذه النِّسب إلى صفحات حقيقية تحتوي صورًا وخطوطًا وحِزم JavaScript كبيرة. لكن النقطة البنيوية تظل قائمة: سجلات الطلب وurn:pageinfo: تخلق حمولة إضافية مستقلة عن حجم المحتوى. قِس عينة ممثلة قبل التخطيط للتخزين الإنتاجي؛ ولا تضرب نسبة 10× الخاصة بهذه البيئة في تقديرٍ شامل لمجموعة صفحات.

الإعداد، والمساحة التي يجب أن تخطط لها على القرص

بعد تثبيت Docker أو Colima وتشغيلهما، يكون الإعداد الخاص بـ Browsertrix هو docker pull webrecorder/browsertrix-crawler:latest ثم docker run … crawl --url … --generateWACZ. وتضم الصورة Chromium، لذا لم تكن هناك حاجة إلى متصفح منفصل أو بيئة Python.

وهذه هي كلفة هذه السهولة، وفق التشغيلات المقاسة هنا:

الحاوية هي موضع الاحتكاك هنا، وسطر التنزيل والفك هو ثمن تجميع متصفح داخل الصورة. وقد شغلته مع --shm-size 1g، وبما أن البيئة كانت على المضيف بينما الزحف يجري داخل الحاوية، فقد احتجت إلى --add-host=host.docker.internal:host-gateway وإلى ربط البيئة على 0.0.0.0 بدل loopback. إذا كنت تزحف إلى الإنترنت العام فستتجاوز خطوة الشبكة هذه تمامًا، أما إذا كنت تؤرشف شيئًا على جهازك أو على مضيف staging داخلي، فخصص لها فترة بعد الظهر.

أما مجلد الإخراج فهو السطر الأسهل في التقليل من شأنه. اسقط هذا النمو على زحف حقيقي، وخطط للسعة قبل البدء، لا بعد أن يمتلئ القرص عند الثالثة صباحًا.

ويرجّح أن بدء المتصفح يساهم بشكل ملحوظ في زمن زحف يتراوح بين 28 و30 ثانية لعدد لا يتجاوز إحدى عشرة صفحة، لكنني لم أفصل زمن البدء عن زمن التنقل أو التغليف. لذلك لا يترتب على هذه التجربة أي استنتاج عن الإنتاجية لكل صفحة.

التخطيط للتخزين من دون إساءة استخدام نسب هذه البيئة

الطريقة المفيدة لتقدير حجم مجموعة هي الطريقة التجريبية. اختر صفحات تمثل التوزيع الفعلي للهدف: أُطر تطبيقية خفيفة، صفحات هبوط غنية بالصور، تنزيلات مستندات، مقالات طويلة، وواجهات تتطلب تسجيل دخول إذا كانت ضمن النطاق. التقط كل فئة بالسلوكيات والتغليف المقصودين. قِس حمولة الاستجابة، وWARC، وWACZ، والفهارس، والسجلات، وبقايا ملف المتصفح، وأي مساحة عمل مؤقتة تبقى أثناء التشغيل. فالاستهلاك الأقصى على القرص لا يقل أهمية عن الحزمة النهائية إذا كان التغليف يحتفظ بعدة نسخ مؤقتًا.

افصل بين المكوّنات الثابتة والمتغيرة. فصورة الحاوية بحجم 3.51 GB هي عبء نشر يمكن مشاركته بين عدة عمليات التقاط على عامل واحد. أما سجلات الطلب، وسجلات page-info، والفهارس، وقوائم الصفحات، فتزداد مع نشاط الزحف. وتعتمد أجسام الاستجابة بدرجة كبيرة على الهدف، بينما تعتمد السجلات على مدة التشغيل ومستوى التفصيل. ثم يأتي الاحتفاظ والنسخ المكرّر ليضاعفا المجموعة النهائية بمعزل عن سلوك الزحف. لذا فإن نموذج السعة الذي يختزل كل ذلك في “بايت لكل صفحة” سيكون هشًا.

كما أن الضغط وإزالة التكرار يحتاجان إلى محتوى ممثل. فقد كانت حمولة الاستجابة في هذه البيئة متطابقة بالبايت عبر ثلاث تشغيلات، لكن ذلك لا يصف صفحات فيها إعلانات متغيرة أو طوابع زمنية أو استجابات مخصّصة أو عناوين أصول تتغير لكسر التخزين المؤقت. وإذا كانت عمليات الالتقاط المتكررة جزءًا من البرنامج، فقِس عمليات التقاط متتابعة للصفحات نفسها وافحص سجلات revisit بدل افتراض أن الصفحات المتشابهة ظاهريًا ستُزال تكراراتها جيدًا. وبالمثل، اختبر ما إذا كانت السجلات والفهارس تُحتفظ بمستوى النسخ نفسه الذي تحتفظ به حمولة الحفظ.

تشغيليًا، ضع عتبات تحذير قبل بدء المجموعة. راقب المساحة الحرة، ونمو كل مجموعة على حدة، وفشل التغليف، وحجم ملفات تعريف المتصفح أو الأدلة المؤقتة. ونفّذ تمرين استعادة من WACZ المخزّن، لا مجرد تمرير checksums. فالنِّسب أعلاه مفيدة لأنها تكشف المكوّنات الموجودة أصلًا؛ لكن العينة الممثلة هي ما يخبرك بمدى حجمها الفعلي لموقعك.

وثّق تلك الافتراضات إلى جانب تقدير السعة، ثم راجعها بعد الزحف التجريبي.

الانضباط في النطاق، تم اختباره بضابطين

الزواحف الأرشيفية التي تخرج عن المسار خطر تشغيلي حقيقي — فقد تنتهي بك الحال إلى مشكلة قانونية وفاتورة تخزين في الوقت نفسه. كانت صفحتي الرئيسية ترتبط بـ http://outofscope.test:<port>/page/out، وهو اسم مضيف مختلف يشير إلى البيئة نفسها، لذا فإن ضربة تحمل هذا الـ Host header ستثبت جلبًا خارج النطاق من دون أي حركة إنترنت حقيقية.

الصف الثاني هو ما يجعل الصف الأول ذا معنى. فعند any وصل الرابط مرتين، ما يعني أنه كان قابلًا للوصول — بينما الصفر تحت نطاق prefix الافتراضي يعني انضباطًا حقيقيًا في النطاق، لا رابطًا فشل الزاحف في ملاحظته. وهناك تقرير مفتوح عن زيارات خارج النطاق في إعدادات أخرى، #788، ولم أستطع إعادة إنتاجه تحت نطاق prefix الافتراضي في هذه البيئة. من الجيد معرفة أنه موجود؛ لكن ليس من الجيد أن أدّعي أنني رأيته.

أما المتانة فكانت جيدة على نحو غير لافت. فقد طُلِب كلٌّ من مسار يعيد HTTP 500 ورابط ميت، وانتهى الزحف بشكل سليم مع WARC وWACZ صالحين، وحُفظ الرابط الميت كسجل revisit مُزالة التكرار بدل أن يسبب أي انهيار.

الإيجابيات والسلبيات

الإيجابيات

• يلتقط روابط DOM المُدرجة وقت التشغيل وطلبات fetch() الصادرة من الصفحة — وقد تأكد ذلك في الأرشيف وعلى الخادم، لمسارات لا تظهر كنصوص حرفية في أي مكان.
• الاستخراج من HTML الثابت وتتبع العمق كاملان: 4/4 للروابط، 3/3 في سلسلة العمق، بلا أخطاء.
• بعد تشغيل Docker/Colima، أنتج أمر docker run واحد WARC وWACZ؛ وChromium موجود داخل الصورة.
• نطاق prefix الافتراضي صمد دون أي جلب خارج النطاق؛ وany وسّع النطاق كما هو موثّق، لذا فإن الإعداد يفعل ما يعد به.
• الناتج أرشيف قائم على المعايير (WARC، مُجمّع كـ WACZ مع فهرس CDX وقائمة صفحات) وليس ملفًا مغلقًا خاصًا.
• الأرشيفات شبه حتمية: الحمولة كانت متطابقة بالبايت عبر ثلاث تشغيلات، والحجم على القرص تباين بأقل من 0.4%.
• سلوك الفشل نظيف: مسار 500 ورابط معطوب لم يُفشلا الزحف.

السلبيات

• عناوين URL الحرفية داخل JavaScript غير المنفذ لا تُكتشف ببساطة (0/2)، حتى عندما يُؤرشف الملف الذي يحتويها. وهذا صحيح تصميميًا، لكنه يظل فجوة حقيقية في التغطية إذا كان هدفك اكتشاف النهايات.
• البصمة كبيرة: تنزيل يقارب 1 GB، و3.51 GB على القرص، ومجلدات إخراج تنمو بسرعة.
• الحمولة البايتية مرتفعة في الصفحات الصغيرة — فالطلبات مع سجلات pageinfo تجاوزت الحمولة الفعلية، وحوالي 30% من WACZ كان سجل الزحف.
• ترخيص AGPL-3.0 يعني أعمال امتثال حقيقية إذا كنت ستضمّه تجاريًا.
• ليس أداة بيانات مهيكلة. لا توجد مخططات، ولا تعيين حقول، ولا صفوف نظيفة في النهاية.
• الإنتاجية لكل صفحة متواضعة بطبيعتها، لأن كل صفحة تمر عبر متصفح حقيقي.

من ينبغي أن يستخدمه، ومن ينبغي ألا يستخدمه

Browsertrix موجّه للفرق التي تحتاج في النهاية إلى أرشيف لموارد جرى جلبها بواسطة متصفح، لا إلى صفوف مستخرجة. وفي هذه البيئة الاختبارية، كانت أجسام الاستجابة التي جرى جلبها وقت التشغيل موجودة في WARC ومُجمعة داخل WACZ. وتبدو المكتبات وغرف الأخبار والباحثون مستخدمين محتملين، لكن التبني في الإنتاج يجب أن يختبر بشكل منفصل إعادة الإعادة، والسلوك المؤجل، والجلسات المصادَق عليها، وservice workers، ومسارات الموافقة، والسلوكيات المتأخرة، والأصول المتدفقة، وضوابط الاحتفاظ، وأي متطلبات خاصة بالتعامل مع الأدلة.

تجاوزه إذا كان ما تريده فعليًا هو البيانات. فإذا كان الهدف هو “أعطني كل المنتجات والأسعار من هذه الـ 400 صفحة في جدول”، فالأرشيف طريق غريب للوصول إلى هذا المخرج — ستؤرشف جيجابايتات ثم تضطر مع ذلك إلى كتابة كود استخراج فوق ملفات WARC. وتجاوزه أيضًا إذا كنت ترسم سطح API لتطبيق ما، لأن نتيجة الفئة B تقول بوضوح إن محلل JavaScript الثابت سيعثر على نهايات لا تلمسها Browsertrix. وإذا كنت لا تحب Docker أو تعمل في مكان يمثل فيه ملف 3.5 GB مشكلة، فهذه ليست الأداة التي ستلين لك.

التفويض والاحتفاظ

التحكم في النطاق لا يمنح تفويضًا. حدّد المضيفين المسموحين، وفترات الاحتفاظ، وإمكانية الوصول إلى الأرشيف قبل الزحف، خاصة إذا كانت الالتقاطات الدائمة قد تتضمن بيانات شخصية. ويُظهر اختبار prefix/any أن تغيير الإعدادات يغيّر مدى الوصول الشبكي؛ لكنه لا يثبت أي مدى يكون قانونيًا لمجموعة بعينها.

مراجعة ذات صلة: الجانب القانوني من web scraping والأرشفة.

بدائل بحسب المخرج المطلوب

اختر وفقًا للمخرج. فـ Browsertrix يستهدف الحفظ داخل WARC/WACZ. أما مكتبة أتمتة متصفح مثل Playwright فتمنحك صفحة قابلة للبرمجة لكنها تترك لك تغليف الالتقاط. وزواحف اكتشاف النهايات تسرد العناوين، بينما أدوات الاستخراج تعيد نصًا أو سجلات منظمة. وهذه الفئات قد تشترك في متصفح واحد ومع ذلك تحل مهامًا مختلفة.

مراجعة ذات صلة: مراجعة Heritrix.

إفصاح: Thunderbit هو منتج الجهة الناشرة، ولم يُختبر داخل بيئة Browsertrix هذه. وهو ينتمي إلى فئة الاستخراج المُدار، إذ ينتج نصوص الصفحات أو البيانات المهيكلة بدل الأرشيف القياسي. وتدعم هذه المراجعة حدّ المخرجات فقط، لا أي ادعاء مقارن حول الأداء أو القدرات.

جرّب Thunderbit لاستخراج بيانات الويب

الحكم النهائي

استخدم Browsertrix Crawler عندما يكون المخرج المطلوب هو التقاط WARC/WACZ، وعندما يناسبك Chromium داخل حاوية. وفي هذه البيئة، اتفقت سجلات الأرشيف وضربات الخادم على روابط DOM المتولدة وقت التشغيل وطلبات fetch() الصادرة من الصفحة، كما أن نطاق prefix الافتراضي منع المضيف الثاني، ولم تمنع مسارات الفشل من تكوين أرشيف صالح.

قبل الاستخدام الإنتاجي، تحقّق من الإعادة، والسلوك المؤجل، والجلسات المصادَق عليها، وservice workers، وتركيب التخزين على صفحات ممثلة، والتزامات الترخيص. أما الحد المختبَر فهو أضيق: فالمراجع البرمجية التي لم تُنفَّذ قط لم تُنتج طلبًا ولا سجل أرشيفًا لأهدافها، رغم أن السكربت المحتوي عليها حُفظ بالفعل.

جرّب Thunderbit لاستخراج بيانات الويب Get Started Free

الأسئلة الشائعة

ما الفرق بين WARC وWACZ هنا؟ يحتوي WARC على الطلبات والاستجابات والسجلات المرتبطة التي جرى التقاطها. أما WACZ فيجمع WARC مع الفهارس وقوائم الصفحات والميتاداتا والسجلات لأغراض التوزيع وأدوات الإعادة. وقد راجعت هذه المقالة الحزمتين معًا، لكنها لم تُشغّل إعادة عرض فعلية.

كيف أقدّر مساحة التخزين؟ قِس صفحات ممثلة واحتفظ بالتركيب الكامل لـ WACZ، بما في ذلك السجلات والفهارس، ضمن العينة. النسب في هذه المقالة مأخوذة من أجسام استجابة صغيرة جدًا، ولا تصلح للضرب في عدد عناوين URL إنتاجي.

هل سيبتعد عن الموقع الذي وجّهته إليه؟ ليس في الإعداد الافتراضي، بحسب اختباري. فمع --scopeType prefix جرى جلب رابط إلى مضيف مختلف صفر مرة؛ وعند التبديل إلى --scopeType any جرى جلبه مرتين، ما يثبت أن الرابط كان قابلًا للوصول وأن الصفر في النطاق الافتراضي كان انضباطًا حقيقيًا في النطاق. وهناك تقرير مفتوح في المنبع عن زيارات خارج النطاق في إعدادات أخرى لم أستطع إعادة إنتاجه تحت الإعداد الافتراضي، لذا افحص إعدادات النطاق لديك بدل الافتراض.

ما الذي يجب أن أختبره قبل الادعاء بدقة الإعادة؟ حمّل WACZ في نظام الإعادة المقصود وقارن الصفحات المعروضة والتفاعلات والموارد الفرعية المطلوبة مع الالتقاط الحي أو المرجعي. وجود الجسم داخل WARC ضروري، لكنه لا يثبت الإعادة المعروضة وحده.

هل يحوّل Browsertrix الصفحة المؤرشفة إلى صفوف مهيكلة؟ لا. فمخرجه حزمة أرشيف، لا جدولًا بحقول مختارة. وإذا كان المطلوب منتجات أو أسعارًا أو جهات اتصال أو أي مخطط آخر، فستحتاج إلى مرحلة استخراج بعد الالتقاط — أو إلى أداة أخرى يكون مخرجها الأساسي بيانات مهيكلة.