Scrapling: إطار عمل بايثون للـWeb Scraping التكيفي والزحف والتعامل مع أنظمة مكافحة البوتات

مشاركة

Scrapling هو إطار عمل مفتوح المصدر بلغة Python لجمع البيانات من الويب، لكنه لا يقتصر على إرسال طلب HTTP ثم تحليل HTML. الفكرة الأساسية للمشروع هي جمع عدة طبقات يحتاجها مشروع Web Scraping حقيقي داخل مكتبة واحدة: تحليل DOM، وتتبع العناصر بصورة تكيفية عندما تتغير الصفحة، وجلب المواقع الثابتة والديناميكية، وتشغيل متصفح عند الحاجة، والتعامل مع بعض أنظمة مكافحة البوتات، وبناء زواحف متزامنة، وإدارة الجلسات والبروكسي، إضافة إلى خادم MCP يسمح لوكلاء الذكاء الاصطناعي باستخدام هذه القدرات مباشرة.

حاسوب مطور يشغّل Scrapling بلغة Python لجمع بيانات من صفحات ويب ثابتة وديناميكية

حتى أغسطس 2026، وصل Scrapling إلى الإصدار 0.4.13 المنشور في 9 أغسطس 2026، وأصبح يتطلب Python 3.10 أو أحدث. ويمكن التحقق من الإصدار الحالي والمتطلبات مباشرة عبر صفحة Scrapling الرسمية على PyPI.

الميزة التي تميزه أكثر من مجرد الجمع بين Requests وBeautifulSoup هي ما يسميه المشروع Adaptive Scraping: إمكانية حفظ خصائص عنصر في الصفحة ثم محاولة العثور على العنصر المكافئ لاحقًا حتى إذا تغير CSS selector أو أعيد ترتيب بنية HTML. ومع ذلك، لا تعني هذه الميزة أن الكود أصبح غير قابل للكسر، كما أن قدرات التخفي ومواجهة Anti-Bot ليست ضمانًا بأن كل موقع محمي سيصبح قابلًا للجمع تلقائيًا.

ما هو Scrapling بالضبط؟

تصف الوثائق الرسمية Scrapling بأنه إطار Web Scraping تكيفي يستطيع التعامل مع حالات تبدأ من طلب واحد وتنتهي بزحف واسع النطاق. ويمكن النظر إلى معماريته على أنها أربع طبقات مترابطة:

  • Selector وParser: تحليل HTML والبحث باستخدام CSS وXPath والنصوص وRegular Expressions وطرق أخرى.
  • Fetchers: جلب صفحات الويب عبر HTTP أو متصفح كامل حسب طبيعة الموقع.
  • Spiders: تشغيل عمليات Crawling متزامنة مع التحكم في الجلسات والتأخير وإعادة المحاولة والبروكسي.
  • MCP Server: إتاحة جمع صفحات الويب واستخراج البيانات كأدوات يمكن لعملاء ووكلاء الذكاء الاصطناعي استدعاؤها.

هذا الفصل مهم لأن Scrapling ليس مجرد بديل مباشر لـBeautifulSoup، ولا هو مجرد Wrapper حول Playwright. يمكن استخدام جزء التحليل وحده، أو إضافة Fetchers، أو بناء Spider كامل، أو تشغيل خادم MCP بحسب المشروع.

مخطط يوضح معمارية Scrapling من Fetchers وتحليل Response إلى Spiders وAdaptive Storage وخادم MCP

كيف يعمل Adaptive Scraping؟

في Web Scraping التقليدي قد يعتمد السكربت على محدد مثل:

page.css('#product-price')

إذا غيّر الموقع المعرف id أو نقل العنصر إلى مكان آخر، قد يعود المحدد بلا نتيجة ويتوقف استخراج البيانات. هنا تأتي ميزة Adaptive Scraping.

وفق شرح Adaptive Scraping الرسمي، تمر العملية عمليًا بمرحلتين: حفظ خصائص العنصر في البداية، ثم استخدام تلك الخصائص لاحقًا للبحث عن أقرب عنصر مشابه عند فشل المحدد الأصلي.

يمكن مثلًا تفعيل الخاصية ثم حفظ العنصر في أول تشغيل:

from scrapling import Fetcher

Fetcher.adaptive = True

page = Fetcher.get("https://example.com")
element = page.css("#product-price", auto_save=True)

إذا تغيرت بنية الصفحة في تشغيل لاحق:

page = Fetcher.get("https://example.com")
element = page.css("#product-price", adaptive=True)

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

مخطط يشرح كيف يحفظ Scrapling خصائص عنصر DOM ثم يعثر عليه مجددًا بعد تغير تصميم الصفحة

ما الخصائص التي يستخدمها للمقارنة؟

لا تعتمد المطابقة على Class أو ID واحد فقط. توضح الوثائق أن النظام يأخذ في الاعتبار مجموعة من المعلومات، مثل اسم العنصر، والنص، والخصائص Attributes، وبعض معلومات العناصر المجاورة والمسار والأب Parent، ثم يحسب درجة تشابه للعثور على أفضل تطابق.

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

هل Adaptive Scraping يمنع تعطل الزاحف نهائيًا؟

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

الأفضل التعامل مع Adaptive Scraping كوسيلة لتقليل صيانة Selectors، وليس كبديل عن المراقبة والتحقق من جودة البيانات.

ثلاثة Fetchers لثلاثة أنواع من المواقع

يوفر Scrapling عدة طرق لجلب الصفحة بدل إجبار كل موقع على استخدام متصفح Headless كامل. وتوضح وثائق Fetchers ثلاثة مسارات رئيسية.

Fetcher للطلبات العادية

إذا كانت البيانات موجودة مباشرة في استجابة HTTP ولا يحتاج الموقع إلى JavaScript، فهذا هو المسار الأبسط والأخف.

from scrapling.fetchers import Fetcher

page = Fetcher.get("https://example.com")
print(page.status)

titles = page.css("h2::text").getall()

يمكن للـFetcher أيضًا محاكاة بعض بصمات TLS والمتصفحات وإدارة Headers، لكن تشغيل متصفح ليس ضروريًا في هذا الوضع.

DynamicFetcher للصفحات التي تعتمد على JavaScript

عندما لا تظهر البيانات إلا بعد تنفيذ JavaScript، يمكن استخدام DynamicFetcher الذي يعتمد على أتمتة المتصفح عبر Playwright.

from scrapling.fetchers import DynamicFetcher

page = DynamicFetcher.fetch(
    "https://example.com",
    headless=True,
    network_idle=True
)

data = page.css(".product::text").getall()

هذا مناسب لتطبيقات الويب الديناميكية أو الصفحات التي تحتاج إلى تصيير DOM داخل متصفح حقيقي قبل الاستخراج.

StealthyFetcher للمواقع ذات الحماية الأعلى

يضيف StealthyFetcher طبقات تخفٍّ وإدارة لبصمة المتصفح، ويمكنه تشغيل JavaScript والتعامل مع بعض تحديات Anti-Bot. وتعرض الوثائق الرسمية لـStealthyFetcher خيارات مخصصة للتعامل مع Cloudflare Turnstile وInterstitial challenges.

from scrapling.fetchers import StealthyFetcher

page = StealthyFetcher.fetch(
    "https://example.com",
    headless=True
)

يوفر Scrapling أيضًا الخيار solve_cloudflare=True في StealthyFetcher للتعرف على أنواع من تحديات Cloudflare ومحاولة إكمالها آليًا.

لكن كلمة "تجاوز" تحتاج إلى تفسير دقيق هنا. أنظمة Anti-Bot الحديثة لا تعتمد على CAPTCHA واحد فقط؛ قد تدخل في القرار عوامل مثل عنوان IP، وسلوك الجلسة، والسرعة، وبصمات الشبكة والمتصفح، والكوكيز، وتاريخ الطلبات وقواعد خاصة بالموقع. لذلك لا توجد مكتبة تضمن عمليًا أن كل حماية ستُتجاوز في كل الظروف.

الجلسات أهم من فتح متصفح جديد لكل صفحة

يوفر Scrapling Session classes مقابلة لطرق الجلب المختلفة، مثل FetcherSession وDynamicSession وStealthySession.

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

from scrapling.fetchers import StealthySession

with StealthySession(headless=True) as session:
    first = session.fetch("https://example.com/page1")
    second = session.fetch("https://example.com/page2")

هذا النموذج أنسب خصوصًا عند التنقل داخل موقع واحد أو عندما تتطلب الصفحة تسجيل دخول أو Cookie تم الحصول عليها في خطوة سابقة.

من سكربت لجلب صفحة إلى Spider متزامن

إحدى أكبر الإضافات التي أصبحت جزءًا محوريًا من Scrapling 0.4 هي إطار Spiders. أسلوبه قريب من Scrapy: تحدد عناوين البداية ثم تعالج كل Response داخل دالة parse غير متزامنة.

from scrapling.spiders import Spider, Response

class ProductSpider(Spider):
    name = "products"
    start_urls = ["https://example.com/"]

    async def parse(self, response: Response):
        for product in response.css(".product"):
            yield {
                "title": product.css("h2::text").get()
            }

ProductSpider().start()

ولا يقتصر Spider على تنفيذ الطلبات بالتوازي؛ توضح وثائق Spiders أنه يدعم التحكم في عدد الطلبات المتزامنة، والحدود لكل نطاق، والتأخير بين الطلبات، وAutoThrottle، واستئناف الزحف، إضافة إلى Streaming للنتائج أثناء وصولها.

Pause وResume

في عمليات الزحف الطويلة، يمكن حفظ حالة الزاحف في Checkpoint ثم استكمال العمل بدل إعادة آلاف الطلبات من البداية بعد إيقاف العملية.

AutoThrottle

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

التعامل مع robots.txt

يدعم Spider خيار robots_txt_obey لقراءة توجيهات مثل Disallow وCrawl-delay وRequest-rate. لكن هذا الخيار غير مفعّل افتراضيًا، لذلك إذا كان الالتزام بـrobots.txt جزءًا من سياسة المشروع فيجب تفعيله صراحة.

إدارة البروكسي داخل Scrapling

عند الحاجة إلى بنية Proxy مشروعة لمشروع موزع، يوفر Scrapling فئة ProxyRotator التي يمكن ربطها بأنواع الجلسات المختلفة. وتشرح وثائق Proxy Management التدوير الدوري أو تطبيق استراتيجية مخصصة.

وجود Proxy Rotation داخل الإطار يقلل الحاجة إلى بناء طبقة مستقلة لإسناد Proxy لكل طلب، لكنه لا يجعل البروكسي نفسه جيدًا تلقائيًا. جودة عنوان IP وسمعته وموقعه وسياسة الموقع المستهدف عوامل منفصلة عن Scrapling.

استخراج استجابات XHR وFetch من الصفحة

من القدرات المفيدة في الإصدارات الحديثة خيار capture_xhr في Fetchers المعتمدة على المتصفح. يمكن تحديد نمط URL، ثم يجمع Scrapling استجابات XHR أو Fetch المطابقة التي تنفذها الصفحة أثناء التحميل ويضعها داخل response.captured_xhr.

تكون هذه الطريقة مفيدة عندما تعرض الصفحة بيانات جلبتها من Backend API بعد تحميل HTML، لأنك قد تحصل على الاستجابة المنظمة مباشرة بدل محاولة استخراج كل قيمة من DOM المرئي.

خادم MCP: عندما يستخدم وكيل الذكاء الاصطناعي Scrapling

يحتوي Scrapling على MCP Server مدمج يتيح لوكلاء وتطبيقات الذكاء الاصطناعي المتوافقة مع Model Context Protocol استخدام قدراته كأدوات. ووفق دليل Scrapling MCP الرسمي، يستطيع الخادم تنفيذ جلب HTTP، وجلب صفحات ديناميكية ومحمية، وتشغيل طلبات Bulk، وفتح جلسات متصفح مستمرة، والتقاط Screenshots وإغلاق الجلسات وإدارتها.

هذا يعني أن Agent متوافقًا مع MCP لا يحتاج بالضرورة إلى توليد سكربت Python مستقل لكل عملية استخراج. يمكنه استدعاء Scrapling Server واختيار أداة الجلب المناسبة ثم استلام المحتوى المستهدف.

تثبيت MCP

pip install "scrapling[ai]"

ومنذ Scrapling 0.4.13 أضيف الأمر المختصر:

scrapling-mcp

وهو اختصار مباشر للأمر الأقدم:

scrapling mcp

يمكن استخدامه مع Claude Desktop وClaude Code وCursor وأي عميل آخر يدعم بروتوكول MCP بالطريقة المناسبة لذلك العميل.

جلسة متصفح مستمرة لوكيل AI

يوفر MCP أدوات open_session وclose_session وlist_sessions. لذلك يستطيع الوكيل فتح Browser Session مرة واحدة، ثم استخدام session_id في عدة عمليات بدلاً من تشغيل Browser جديد مع كل Tool Call.

كما يمكن لـopen_session الاتصال بمتصفح موجود محليًا أو على جهاز آخر عبر Chrome DevTools Protocol (CDP) بدل تشغيل Chromium جديد داخل نفس الجهاز.

حماية Prompt Injection داخل MCP

إدخال صفحات ويب غير موثوقة مباشرة إلى سياق نموذج لغوي يفتح مشكلة إضافية لا تظهر في Web Scraping التقليدي: قد يضع الموقع تعليمات مخفية صممت كي يقرأها Agent ويتعامل معها كأوامر.

لذلك يتضمن Scrapling MCP طبقة لتنظيف أنواع من المحتوى المخفي عندما يكون main_content_only مفعّلًا، وهو الوضع الافتراضي. وتشمل الأمثلة التي تذكرها الوثائق عناصر CSS المخفية، وaria-hidden، وتعليقات HTML، وعناصر template وبعض المحارف غير المرئية.

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

انتبه عند تشغيل MCP عبر HTTP

يدعم Scrapling تشغيل MCP عبر Streamable HTTP بدل stdio:

scrapling-mcp --http --host 127.0.0.1 --port 8000

لكن إذا أصبح الخادم قابلًا للوصول عبر الشبكة، فالمسألة أمنية وليست مجرد إعداد اتصال. توصي وثائق Scrapling باستخدام Authentication Token عند الاستماع خارج localhost، وتوفير TLS عند تعريض الخدمة للإنترنت، كما توفر إعداد allowed-host للمساعدة في الحماية من DNS rebinding.

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

كيفية تثبيت Scrapling بالطريقة الصحيحة

من التغييرات التي قد تربك من يتبع شرحًا قديمًا أن:

pip install scrapling

يثبت حاليًا محرك Parser واعتماداته، لكنه لا يثبت كل مكونات Fetchers وSpiders.

إذا كان هدفك استخدام Fetchers أو Spiders فالتثبيت الموصى به هو:

pip install "scrapling[fetchers]"
scrapling install

الأمر الثاني ينزل متطلبات المتصفحات والمكونات اللازمة لها.

أما للحصول على جميع الإضافات:

pip install "scrapling[all]"
scrapling install

ويشمل المشروع كذلك Docker image جاهزة تحتوي على المتصفحات والإضافات.

مثال عملي بسيط لجلب صفحة واستخراج بيانات

بعد تثبيت Fetchers يمكن تنفيذ عملية أساسية كالتالي:

from scrapling.fetchers import Fetcher

page = Fetcher.get("https://example.com")

print("Status:", page.status)

title = page.css("h1::text").get()
print(title)

الكائن الذي تعيده Fetchers هو Response، ويجمع خصائص التحليل مع معلومات الشبكة مثل HTTP status والـHeaders والCookies وسجل Redirects ومحتوى الاستجابة الخام.

Scrapling أم Requests وBeautifulSoup أم Playwright أم Scrapy؟

الخيار يناسب أكثر أبرز ما يميزه ما قد تحتاج إلى إضافته بنفسك
Requests + BeautifulSoup صفحات HTML بسيطة ومشروعات صغيرة بساطة ومنظومة Python ناضجة JavaScript، Crawling واسع، Adaptive Tracking، وإدارة متقدمة للجلسات والحماية
Playwright Browser Automation والصفحات الديناميكية تحكم تفصيلي جدًا في المتصفح طبقة استخراج وزحف وتخزين وإدارة مشروع كاملة حسب حاجتك
Scrapy مشروعات Crawling منظمة وكبيرة إطار Crawling ناضج وواسع المنظومة Browser/Stealth integrations حسب المواقع المستهدفة
Scrapling مشروعات تريد Parser وHTTP وBrowser وAdaptive Scraping وSpiders ضمن واجهة واحدة تكامل هذه الطبقات إضافة إلى MCP يبقى عليك تصميم Schema للبيانات، التخزين، الجودة، المراقبة وسياسة الاستخدام

لا توجد إجابة واحدة صحيحة لكل مشروع. إذا كنت تحتاج فقط إلى قراءة جدول من عشر صفحات HTML ثابتة، فقد تكون مكتبة HTTP ومحلل HTML أبسط. أما إذا كان المشروع يجمع بين مواقع ديناميكية، وتغيرات DOM، وجلسات، وزحف متزامن، فقد يقلل Scrapling عدد المكونات المنفصلة التي تحتاج إلى ربطها معًا.

وإذا كان هدفك التعليمي هو فهم كيفية بناء Crawlers ومحركات البحث والمكونات البرمجية بنفسك بدل استخدام إطار جاهز، يجمع دليل بناء البرمجيات من الصفر مجموعة من مشاريع Python وغيرها التي تشرح هذه الطبقات من الداخل.

متى يكون Scrapling خيارًا منطقيًا؟

يصبح Scrapling مثيرًا للاهتمام خصوصًا عندما يجتمع أكثر من مطلب في المشروع، مثل:

  • صفحات تتغير بنيتها بمرور الوقت وتسبب كسر Selectors بصورة متكررة.
  • الحاجة إلى التعامل مع HTML ثابت وصفحات JavaScript ضمن المشروع نفسه.
  • استخدام جلسات Browser مستمرة والحفاظ على Cookies والحالة.
  • الانتقال من جلب صفحات منفردة إلى Spider متزامن.
  • الحاجة إلى Proxy Rotation وAutoThrottle واستئناف الزحف.
  • إدخال Web Scraping في Workflow يعتمد على MCP وAI Agents.

ومتى قد يكون أكبر من حاجتك؟

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

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

ماذا عن الجوانب القانونية والأخلاقية؟

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

ويضع مشروع Scrapling نفسه تنبيهًا واضحًا في مستودعه الرسمي بأن المكتبة مخصصة للأغراض التعليمية والبحثية، وأن على المستخدم الالتزام بقوانين جمع البيانات والخصوصية وشروط المواقع واحترام robots.txt.

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

هل Scrapling مجرد أداة لتجاوز Anti-Bot؟

لا، واختزاله في هذه النقطة يفوّت أهم ما يقدمه. StealthyFetcher جزء واحد فقط من الإطار. القوة الحقيقية تأتي من إمكانية بناء المسار الكامل باستخدام واجهات مترابطة:

  1. جلب الصفحة بالطريقة الأنسب.
  2. تحليل المحتوى باستخدام Selector API.
  3. حفظ خصائص العناصر المهمة للتتبع التكيفي.
  4. الحفاظ على Sessions عند الحاجة.
  5. الانتقال إلى Spider عند نمو عدد الصفحات.
  6. استخدام Proxy Rotation وAutoThrottle في البيئات المناسبة.
  7. تصدير النتائج أو تمريرها إلى Pipeline خاص بك.
  8. إتاحة نفس القدرات لوكيل AI عبر MCP إذا كان ذلك جزءًا من التطبيق.

لذلك فإن المقارنة الأقرب ليست "Scrapling مقابل BeautifulSoup" فقط، بل "Scrapling مقابل تجميع عدة مكتبات منفصلة لتغطية دورة Web Scraping كاملة".

الخلاصة

Scrapling تطور من Parser سريع إلى إطار Web Scraping متعدد الطبقات. وفي الإصدار 0.4.13 الحالي أصبح يجمع Adaptive Scraping، وHTTP وBrowser Fetchers، وStealthyFetcher، والجلسات، وSpiders المتزامنة، وProxy Rotation، وAutoThrottle، وXHR capture، إضافة إلى MCP Server يمكن لوكلاء الذكاء الاصطناعي استخدامه.

الميزة الأكثر تميزًا هي Adaptive Scraping، لأنها تعالج مشكلة عملية يواجهها أي مشروع طويل العمر: تغير DOM وكسر Selectors. أما قدرات Anti-Bot فهي قوية لكنها ليست ضمانًا عامًا لتجاوز كل حماية، ويجب استخدامها ضمن سياسات وصول مشروعة وبمعدلات مناسبة.

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

شارك برأيك

لديك إضافة، سؤال أو تجربة مرتبطة بالموضوع؟ اكتبها وشارك بها القراء.