مراجعة Scrapy 2.17: يتجاوز المتصفح ويستدعي واجهة الـ API

يُصنَّف Scrapy أحيانًا ضمن الأدوات التي «لا تصلح للمواقع الحديثة» لأنه لا يشغّل JavaScript. لكن هذه السمعة مقلوبة تمامًا. فعدم عرض الصفحة أصلًا هو جوهر الفكرة، وبمجرد ما تشوف هذا الأسلوب عمليًا، يختفي الإحساس بأنه نقص في الميزة.

وقد تأكدت من هذا بنفسي في تجربة واحدة. أنشأت نموذجًا لكتالوج معروض عبر JavaScript، ووجّهت Scrapy إلى الصفحة التي سيعرضها المتصفح، فكانت النتيجة 0 بطاقة منتج. ثم وجّهت العنكبوت نفسه إلى نقطة نهاية JSON التي كانت الصفحة تستدعيها بهدوء في الخلفية، فحصلت على 8/8 عناصر بشكل نظيف. نفس الأداة، نفس الجلسة، ونتيجتان متعاكستان — وهذه الفجوة بين الرقمين هي محور هذه المراجعة كلها.

ما هو Scrapy فعليًا وما ليس هو كذلك

Scrapy هو إطار عمل بلغة Python لزحف المواقع واستخراج البيانات المهيكلة منها. هذا هو الوصف الذي يقدمه المطورون أنفسهم في وثائق النظرة العامة، وبعد استخدامه يتضح أن الوصف دقيق — من دون أي مبالغة تسويقية تحتاج إلى تصحيح. الأداة قديمة بما يكفي، وناضجة بما يكفي، لتكون الجواب التلقائي عندما يسأل مطور Python عمّا يستخدمه المحترفون في عمليات الاستخراج الجادة. كما أن مستودع المشروع يؤكد ذلك: نحو 62,981 نجمة على GitHub حتى 2026-07-07 (scrapy/scrapy)، مع 11,773 نسخة متفرعة و590 مشكلة مفتوحة في اليوم نفسه. الترخيص BSD-3-Clause، ويدعم Python 3.10 أو أحدث، والإصدار الذي اختبرته كان 2.17.0، وقد صدر في صباح اليوم نفسه الذي أجريت فيه هذه الاختبارات — لذا لا توجد هنا ملاحظة من نوع «إصدار قديم».

وهنا السطر الفاصل بينه وبين جيل أدوات الزحف المعتمدة على الذكاء الاصطناعي: Scrapy يعمل عبر HTTP فقط افتراضيًا. لا متصفح، لا محرك عرض. إنه يسحب HTML عبر الشبكة، يمرره إلى المحلل، ثم يتيح لك استخراج الحقول باستخدام محددات CSS أو XPath. وصف هذا بأنه «حد من حدوده» صحيح جزئيًا فقط، لكنه يتجاهل التصميم نفسه. ففكرة Scrapy تقوم على أن تشغيل Chrome بلا واجهة لمجرد استخراج روتيني غالبًا ليس الخيار الذكي؛ الأفضل هو العثور على طلب البيانات الذي تنفذه الصفحة أصلًا والتعامل معه مباشرة.

وهذه ليست فكرة مفروضة على الأداة من الخارج. فوثائق المحتوى الديناميكي الرسمية تقول ذلك صراحة: حدِّد طلب البيانات الأساسي وأعد إنتاجه أولًا، ولا تلجأ إلى متصفح بلا واجهة إلا كخيار أخير عندما يكون تكرار ذلك الطلب غير عملي. معظم أدوات الاستخراج تفتح المتصفح أولًا ولا تفكر في الـ API أبدًا. Scrapy يقلب هذا الافتراض.

أبرز المزايا، وما الذي يفسّر كل قرار في التصميم

في العمق، Scrapy عبارة عن مجموعة مكونات تفترض أمرًا واحدًا عنك: أنك مطور يريد التحكم، لا معالجًا سحريًا بنقرة واحدة.

Spiders. تكتب صنفًا، تحدد له روابط البداية، وتعرّف دالة parse التي ترجع العناصر أو تتبع روابط إضافية. هذا يحتاج كتابة أكثر من أداة استخراج بلا كود — فأنت من يكتب قواعد الاستخراج — لكنك في المقابل تحصل على تحكم دقيق بما يُلتقط وباتجاه الزحف التالي.

Selectors. تعتمد عملية التحليل على parsel، وهو مبني على lxml. وكل من CSS وXPath مدعومان كخيارين أساسيين، لا كإضافات ثانوية. وسبب سرعة الاختيار وبساطة قراءة كود الاستخراج يعود إلى lxml؛ إذ تبدو الشيفرة هنا كأنها نية واضحة لا فوضى قص ولصق نصي.

Feed exports. إذا وجّهت العنكبوت إلى ملف، فإن Scrapy يصدّر العناصر إلى JSON أو JSON Lines أو CSV أو XML من دون أي تجهيزات إضافية. في تجربتي، أخرج أحد العناكب الخاص بالكتالوج الثابت ملفات JSON وCSV في نفس التشغيل، من دون أن أكتب سطرًا واحدًا خاصًا بالتصدير — قصة Feed exports صحيحة فعلًا وتقوم بما تعد به.

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

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

الإعداد: حزمة الاعتماد التي لا يلتقطها أحد في لقطات الشاشة

كان التثبيت أمرًا عاديًا تمامًا، وهو أمر يستحق الذكر بصراحة في إطار عمل بهذا الحجم. انتهى pip install Scrapy==2.17.0 بسلاسة في بيئة افتراضية جديدة على macOS arm64، مع تنزيل حِزم ثنائية جاهزة، من دون أي محاولة ترجمة صعبة تذهب إلى الجدار. لا شيء درامي هنا — وهذه هي النقطة.

لكن تأمل ما تم تنزيله. أظهر scrapy version -v أن Scrapy 2.17.0 يعمل فوق lxml 6.1.1 وTwisted 26.4.0 وpyOpenSSL 26.3.0 وcryptography 49.0.0، مع parsel وcssselect وtldextract لاستكمال المنظومة. هذه بصمة حقيقية — حزمة كاملة لإطار زحف، لا مجرد محلل HTML في ملف واحد. على هذا الجهاز كانت الحِزم الثنائية متاحة لكل شيء، فبقي التثبيت سلسًا. أما في بيئات أخرى، فما زالت الوثائق الرسمية تحذر من بعض الاحتكاك المرتبط بالاعتمادات بحسب المنصة، وغالبًا ما تكون cryptography وTwisted هما موضع التعثر، لذا احسب حساب ذلك إذا كنت تعمل على منصة غير مألوفة. الإعداد هنا كان مريحًا، لكن حجم ما يتم تثبيته يبقى أمرًا مهمًا قبل الالتزام، لأنك في النهاية تستورد إطار عمل كامل، وحجمه بحجم إطار عمل.

تطبيق عملي: ما الذي نجح

بعد التثبيت، كان المسار الثابت سلسًا. استرجاع كامل، من دون أي فقد.

الاختبار	النتيجة	الزمن
كتالوج محلي ثابت + ترقيم صفحات	12/12 منتجًا	0.557 ثانية
تصدير CSV لكتالوج ثابت	كتابة 12 صفًا	(نفس التشغيل)
استخراج مقالة	العنوان + 3/3 فقرات من النص	0.416 ثانية
رسم الزحف، DEPTH_LIMIT=2	11 صفحة عبر الأعماق 0/1/2	0.904 ثانية
صفحة محلية 500	تم التقاط الحالة 500 دون تعطل	0.424 ثانية
Books to Scrape (عام)	20 منتجًا	2.053 ثانية
Quotes to Scrape spider (عام)	12 عنصر اقتباس	3.465 ثانية

زحف العنكبوت الخاص بالكتالوج الثابت انتقل عبر ترقيم الصفحات من الصفحة الأولى إلى الثانية، والتقط 12/12 سجلًا متوقعًا، ثم صدّرها إلى JSON وCSV في نفس المرور. أما نموذج المقالة فهو الأكثر جدارة بالتوقف عنده. لم يحاول Scrapy تحويل الصفحة تلقائيًا إلى Markdown مرتب — بل سمح لي باستهداف حقول article بمحددات واضحة، مع عزل نصوص التنقل والتذييل في حقول منفصلة، فحصلت على 3/3 فقرات من النص، بينما بقيت العناصر العامة معزولة بدل أن تختلط بالمخرجات. هذا هو التبادل: أنت تكتب المحددات، وتحصل على ما طلبته بالضبط لا أكثر ولا أقل.

وضوابط الزحف أثبتت نجاحها على نطاق صغير. مع DEPTH_LIMIT=2، وتأخير تحميل قصير، وتوازي مضبوط لكل نطاق، وrobots.txt مفعّل، شاهد رسم الزحف 11 صفحة عبر الأعماق 0 و1 و2، وعمل العدّ العمقي كما ينبغي. أما التعامل مع الفشل فكان هادئًا بالقدر نفسه. صفحة 500 المتعمدة عادت كعنصر مهيكل مع إظهار الحالة 500 عبر handle_httpstatus_list — من دون استثناء، ومن دون انهيار للتشغيل. يتعامل Scrapy مع رمز الخطأ كشيء تتولاه داخل منطق العنكبوت، لا كمفاجأة تُسقط الزحف.

تطبيق عملي: جدار JavaScript والباب المجاور له

والآن إلى النتيجة التي بُنيت عليها هذه المراجعة.

وجّهت مُستقبل HTTP في Scrapy إلى نموذج كتالوج معروض عبر JavaScript. قام بتنزيل HTML المصدر، ووجد 0 عقدة .product-card، ثم تابع — لأنه لم يشغّل أبدًا السكربت الذي كان سيُنشئ تلك البطاقات. صفحة Quotes to Scrape JS العامة قالت القصة نفسها: 0 عقدة اقتباس معروضة. لو توقفت هنا، لقلت إن Scrapy غير مناسب لأي شيء صُمم في هذا العقد.

لكن لا تتوقف هنا. كان ذلك الكتالوج المعتمد على JavaScript يُملأ من واجهة JSON API في الخلفية، كما تفعل أغلب هذه الصفحات. وجّهت العنكبوت نفسه إلى تلك النقطة، فحصلت على 8/8 منتجات خلال 0.416 ثانية — بلا متصفح، بلا عرض، مجرد طلب إلى الرابط الذي كانت الصفحة تستدعيه أصلًا، ثم تحليل JSON الذي عاد.

هذا العرض المتوازي يلخص فلسفة «إعادة إنتاج الطلب» في صورة مصغرة. الصفحة المعروضة كانت مجرد طُعم؛ البيانات كانت موجودة خلف API طوال الوقت، وتصميم Scrapy يدفعك إلى استدعائها مباشرة بدل دفع تكلفة متصفح بلا واجهة يراقب الصفحة وهي تبني نفسها. إنه أسرع، وأخف، وأقل قابلية للكسر — فالعقد مع API عادةً أكثر ثباتًا من كتلة DOM تُنشأ على جانب العميل. لكن المشكلة أن هذا يحتاج عملًا يدويًا: عليك فتح تبويب الشبكة، والعثور على الطلب، وإعادة إنتاج العناوين والمعلمات بنفسك. Scrapy لن يكتشف الـ API نيابةً عنك؛ كل ما يفعله هو جعل استدعاءه مباشرًا عندما تعرفه.

هناك حدان يجب توضيحهما بوضوح. عندما لا يكون هناك أصلًا طلب يمكن إعادة إنتاجه — أي أن البيانات تُحقن بالكامل عبر العرض من جهة العميل دون أي API خلفها — فحينها يحتاج Scrapy إلى تكامل مع متصفح بلا واجهة تضيفه بنفسك، ولم أختبر هذا المسار في هذه المراجعة. كما أن كل ما سبق جرى على نماذج صغيرة وصفحات تجريبية عامة. لم أشغّل زحفًا من 100 إلى 1000 صفحة، لذلك لا أقدّم أي ادعاء بشأن الذاكرة أو الإنتاجية أو سلوك الإعادة عند النطاق الواسع — النواة غير المتزامنة وضوابط الزحف مؤشرات قوية، لكن المؤشر ليس قياسًا.

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

الإيجابيات:

• التصميم المعتمد على HTTP فقط سريع وخفيف — استرجاع 12/12 من البيانات الثابتة في نحو نصف ثانية، و8/8 من API JSON في 0.416 ثانية، بلا أي عبء متصفح.
• نهج إعادة إنتاج الطلب ينجح فعلًا: صفحة JavaScript التي أعطت 0 سلّمت جميع العناصر الثمانية عبر الـ API الخلفية.
• محددات CSS وXPath المبنية على lxml تجعل كود الاستخراج سريعًا وواضحًا.
• تصدير مباشر إلى JSON وCSV وXML من دون كتابة منطق تصدير إضافي.
• التعامل الواضح مع الأخطاء — حالة 500 تظهر كرمز تتعامل معه، لا كتعطل مفاجئ.
• ضوابط زحف ناضجة: التوازي، التأخير، حدود العمق، AutoThrottle، والالتزام بـ robots.txt.
• ترخيص BSD-3-Clause مرن، والتثبيت كان نظيفًا على جهاز حديث.

السلبيات:

• لا يعرض JavaScript عمدًا — نتيجة 0 عقدة على صفحة معروضة من جهة العميل إلى أن تجد الـ API بنفسك.
• العثور على الطلب الأساسي يدوي؛ Scrapy لن يشير لك إلى نقطة النهاية.
• حزمة الاعتماد كبيرة نسبيًا (Twisted وlxml وcryptography وpyOpenSSL وparsel وtldextract) — كانت سلسة هنا، لكنها تاريخيًا مصدر احتكاك على بعض المنصات غير المعتادة.
• يحتاج كتابة أكثر من أدوات الاستخراج بلا كود أو الأدوات التلقائية؛ العناكب من مسؤوليتك في الكتابة والصيانة.
• اختباري شمل نماذج صغيرة ومواقع تجريبية، لا زحفًا واسعًا؛ لذا فموثوقية الأداء عند النطاق الكبير غير مثبتة في هذه الجولة.

لمن هو مناسب، ومن الأفضل أن يتجاوزه

Scrapy موجه للمطورين الذين يريدون تحكمًا على مستوى الكود ويفكرون بالطلبات لا بالصفحات. إذا كانت استجابتك الغريزية لموقع JavaScript بطيء هي: «لا بد أن هناك API خلفه»، فالأداة مبنية لهذا الحدس تحديدًا. إنها تكافئ من يرتاحون لكتابة المحددات، وقراءة تبويب الشبكة، وتحمل مسؤولية منطق الاستخراج من البداية حتى النهاية. بالنسبة للمواقع الثابتة، وكتالوجات الصفحات المتعددة، وأي مصدر تقف خلفه نقطة نهاية JSON قابلة للاكتشاف، فالأداة سريعة ودقيقة.

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

البدائل، ومكان Thunderbit هنا

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

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

لكن المقايضة الحقيقية تقع في مشكلة العرض والتغيّر، وإجابة Scrapy عليها هي أن أنت تحلها: تبحث عن الـ API، وتعيد إنتاج الطلب، وتعالج حالة عدم وجود API عبر ربط متصفح بنفسك. أما واجهة الاست scraping المدارة بالذكاء الاصطناعي فتسحب هذه الطبقة من على عاتقك بدلًا من ذلك. وهنا يأتي موقع Thunderbit في حزمة المطورين للقراء التقنيين — واجهة scraping بالذكاء الاصطناعي مع MCP server وCLI، وليس إضافة المتصفح التي يستخدمها فريق المبيعات والعمليات. POST /distill يحول الصفحة إلى Markdown نظيف جاهز لنماذج LLM؛ وPOST /extract يعيد JSON مهيكلًا وفق مخطط تحدده أنت؛ وكلاهما يتعامل مع عرض JavaScript، ومكافحة الروبوتات، والمحتوى الديناميكي من جهة الخادم — بما في ذلك الحالة التي تُعرض فيها الصفحة من جانب العميل، وهي الحالة التي يطلب منك Scrapy فيها استخدام متصفح. وهناك MCP server للوكلاء الذكيين ومساعدي البرمجة (مع thunderbit_suggest_fields مجاني لتحديد نطاق الصفحة قبل أن تدفع شيئًا)، بالإضافة إلى CLI عبر npx @thunderbit/thunderbit-cli للعمل داخل الطرفية أو CI أو المهام المجدولة.

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

ولمشهد أوسع، تغطي هذه المراجعات المعيارية الجيران في المجال: المقارنة الكاملة لبرامج استخراج البيانات مفتوحة المصدر، ومراجعة Colly كزاحف Go بلا متصفح، ومراجعة Scrapling للمحددات التكيفية.

الخلاصة

هل يجب أن تستخدم Scrapy؟ نعم — إذا كنت مطورًا يريد التحكم وتتبنّى هذه النظرة: لا تعرض الصفحة، بل ابحث عن الطلب الذي يقف خلفها. في الاختبار، أثبتت هذه الفلسفة جدواها تمامًا كما وعدت. كتالوج JavaScript سلّم مُستقبل HTTP 0 بطاقة، بينما سلّمت الـ JSON API المغذية له جميع العناصر الثمانية للعنكبوت نفسه. الاستخراج الثابت حقق 12/12، ومحددات المقالة أبقت 3/3 فقرات نظيفة من النصوص العامة، ورسم الزحف احترم حد العمق عبر 11 صفحة، وظهرت صفحة 500 كحالة مُعالجة بدلًا من تعطل.

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

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

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

هل يمكن لـ Scrapy استخراج صفحات معروضة عبر JavaScript؟ ليس عبر مُستقبل HTTP الافتراضي لديه — فقد أعاد 0 عقدة سواء في نموذج JS أو في صفحة Quotes JS العامة، لأنه ينزل HTML من دون تشغيل متصفح. المسار المقصود هو العثور على طلب البيانات الأساسي الذي تنفذه الصفحة واستدعاؤه مباشرة؛ وفي تجربتي، أعادت واجهة JSON API خلف كتالوج JavaScript جميع العناصر الثمانية. أما الصفحات التي لا يوجد خلفها طلب قابل لإعادة الإنتاج، فتضيف لها متصفحًا بلا واجهة بنفسك.

ماذا يعني «إعادة إنتاج الطلب» عمليًا؟ معظم الصفحات الديناميكية تجلب بياناتها من JSON API في الخلفية، ثم تعرضها على جانب العميل. بدلًا من تشغيل متصفح لمشاهدة ذلك، تفتح تبويب الشبكة، وتحدد استدعاء الـ API، ثم توجّه Scrapy إليه مباشرة. هذا أسرع وأكثر ثباتًا من العرض — فالعقد مع API أقل عرضة للكسر من DOM — لكنه عمل يدوي، وScrapy لن يكتشف نقطة النهاية بدلًا منك.

هل تثبيت Scrapy صعب؟ كان التثبيت سلسًا بالنسبة لي — فقد انتهى pip install Scrapy==2.17.0 بلا أخطاء ترجمة داخل venv جديدة على macOS باستخدام الحِزم الثنائية الجاهزة. لكنه يسحب معه حزمة اعتماد كبيرة نسبيًا (Twisted وlxml وcryptography وpyOpenSSL وparsel وtldextract)، وما زالت الوثائق الرسمية تحذر من بعض الاحتكاك المرتبط بالاعتمادات على منصات معينة، لذا احسب هذا ضمن خطتك إذا كنت تعمل على بيئة غير مألوفة.

ما صيغ الإخراج التي يدعمها Scrapy؟ يدعم تصدير النتائج إلى JSON وJSON Lines وCSV وXML مباشرةً — فقط وجّه العنكبوت إلى ملف، وسيتكفل بتسلسل العناصر من دون أي كود إضافي. في تجربتي، أنتج أحد العناكب JSON وCSV معًا من نفس التشغيل. لكن تذكر أنه يصدّر الحقول التي اخترتها؛ ولا يحول الصفحة تلقائيًا إلى Markdown.

هل Scrapy مجاني للاستخدام التجاري؟ نعم، فهو مرخّص بموجب BSD-3-Clause، وهو ترخيص مرن ومناسب تجاريًا. وكما هو الحال دائمًا، تأكد من الترخيص الحالي في المستودع قبل البناء عليه، واحرص على أن يكون user-agent وproxy ومعدلات الطلبات لديك مسؤولة — فالقدرة التقنية لا تعني الإذن تلقائيًا.