ל-Selectors אדפטיביים לא פעם מייחסים יכולות שלא באמת שייכות להם. בחצי מההשוואות של סקרייפרים שקראתי, התווית "שורד רידיזיין של אתר" נדבקה לאיזה crawler גדול מבוסס AI — שבפועל בכלל לא עושה את זה. ספריית ה-Python שבאמת שמה את היכולת הזו בחזית היא Scrapling, פרויקט בצמיחה מהירה עם כ-68.7 אלף כוכבים ב-GitHub נכון ל-2026-07-09.
אז עשיתי את הבדיקה שבאמת משנה כשמדובר בטענה כזו. בניתי עמוד בדיקה, שמרתי selector, ואז שיניתי את שם ה-class של אלמנט היעד מתחתיו — בדיוק אותו סוג שינוי שמרוקן בשקט סקרייפר מתוכן בבוקר שאחרי שהאתר עולה עם רידיזיין. selector רגיל החזיר תוצאה ריקה. ההתאמה האדפטיבית של Scrapling מצאה את האלמנט בכל זאת. זה אמיתי, ואציג גם את המספרים. מה שכמעט אף אחד לא מודד הוא איפה ההחלמה נעצרת — והגבול הזה מתברר כעיקר הסקירה.
מה Scrapling בעצם הוא
Scrapling מציג את עצמו כ-framework אדפטיבי ל-web scraping שמטפל ב"הכול — מבקשה אחת ועד crawl בקנה מידה מלא". אם מורידים את הסלוגן, מקבלים שני רכיבים מונחים זה על זה: Fetcher מבוסס HTTP שמוריד עמודים, ו-Selector מבוסס lxml שמנתח אותם, עם CSS/XPath תקינים ועם pseudo-selectors נוחים כמו ::text ו-::attr(). הרישיון שלו הוא BSD-3-Clause, כלומר די מקל כמו שרישיונות קוד פתוח מגיעים. בדקתי את גרסה 0.4.10, שהייתה הגרסה העדכנית בזמן הבדיקה — כך שלא צריך כוכבית של "בדקתם משהו מיושן".
השכבה המעניינת היא השכבה האדפטיבית שמעל ה-parser הזה. תחשבו איך selector רגיל עובד: זו כתובת קשיחה. "תפוס את האלמנט עם class בשם product-name." תנו לבניין מספר חדש — כלומר תשנו את שם ה-class — והכתובת מצביעה על מגרש ריק. Scrapling, לעומת זאת, יכול לשמור טביעת אצבע של אלמנט בריצה אחת, ובריצה מאוחרת יותר, אחרי שה-markup השתנה, לאתר מחדש את אותו אלמנט לפי טביעת האצבע שלו במקום לפי הכתובת הישנה שכבר לא קיימת. לפי תיעוד ה-adaptive scraping של Scrapling, שלב ההתאמה מדרג דמיון בין ה-tag, הטקסט, המאפיינים, השכנים והמיקום של האלמנט — בלי מודל AI בלופ, רק השוואה מבנית למה שנשמר קודם.
כדאי להיות מדויקים לגבי המקור של היכולת הזו, כי זה משנה איך קוראים את הפיצ'ר. relocation אדפטיבי הוא יכולת אמיתית ומתועדת, לא משהו שגיליתי במקרה — תיעוד המוצר מסביר במפורש את כל המנגנון של שמירה ל-SQLite והתאמה לפי דמיון, וגם כתבות צד שלישי עצמאיות מפרטות אותו. הרעיון של selectors שמרפאים את עצמם הופיע עוד לפני Scrapling בעולם של בדיקות אוטומציה. מה שמייחד את Scrapling הוא שהוא שולח את זה כחלק מובנה מהספרייה: parsers רגילים כמו lxml, parsel ו-BeautifulSoup נותנים selectors סטטיים — ולא משהו שמאתר את עצמו מחדש. אז זה פיצ'ר ייחודי אבל מתועד, ששחזרתי ובחנתי תחת לחץ — לא יכולת שאף אחד אחר לא מציע.
הבדיקה האדפטיבית, בפירוט
כך הוקמה סביבת הבדיקה. הרמתי קטלוג בדיקה ועקבתי אחרי אלמנט מוצר כשה-class שלו היה product-name. ואז שיניתי את ה-class ל-product-title והרצתי שוב את אותו הקוד. selector רגיל מסוג .product-name החזיר 0 אלמנטים — בדיוק התוצאה הריקה שהייתם מצפים לה כשמצביעים על class שכבר לא קיים. ההתאמה האדפטיבית של Scrapling שיחזרה את האלמנט שהיה במעקב באמצעות טביעת האצבע שנשמרה בגרסה הקודמת. התוצאה הגולמית שמורה בריפו של הבנצ'מרק ב-local_adaptive_selector.json.
נסו את Thunderbit לחילוץ נתוני רשת
ועכשיו לחלק שרוב הסקירות מדלגות עליו. המשכתי לבדיקה סינתטית עם כמה אלמנטים — שלושה אלמנטים במעקב במקום אחד. Scrapling איתר מחדש את האלמנט הראשון שנשמר, ולא את שלושתם. זו לא כשלון וזה גם לא באג; התיעוד מגדיר auto-match כמעקב אחרי אלמנט, טביעת אצבע אחת לכל אלמנט שנשמר, כך שתוצאה של 1 מתוך 3 בהגדרות ברירת המחדל היא בדיוק ההתנהגות המתוכננת. אבל זה כן אומר שהתיאור המדויק הוא "מעקב עמיד אחר אלמנט", ולא "שחזור אוטומטי של עמוד שלם אחרי רידיזיין". auto-match עוקב אחרי האלמנט שביקשתם לעקוב אחריו. עמידות לריבוי אלמנטים היא כבר כוונון שאתם עושים לבד.
ההבחנה הזו חשובה יותר ממה שנראה במבט ראשון. "שורד שינויי markup" הוא כותרת. "ממשיך לעקוב אחרי האלמנט המסומן בטביעת אצבע גם כש-markup משתנה, ואת השאר אתם מטפלים לבד" — זו היכולת האמיתית שאתם קונים. אם תגיעו עם הציפייה הראשונה, תתאכזבו. אם תבואו עם הציפייה השנייה, הוא עושה את העבודה יפה.
ההתקנה: החיכוך שאף אחד לא מזהיר מפניו
זה עלה לי בזמן אמת, אז עדיף שתדעו לפני שתיתקלו בזה בעצמכם. pip install scrapling מתקין את ה-parser — ורק את ה-parser. ברגע שכתבתי from scrapling.fetchers import Fetcher, הכול נשבר בגלל שרשרת תלויות חסרות: קודם curl_cffi, אחר כך playwright, ואז browserforge, כל אחת צצה רק אחרי שפתרתי את הקודמת.
הפתרון הוא להתקין את התוספת: pip install "scrapling[fetchers]", או להריץ את פקודת ה-CLI scrapling install, שמורידה את כל סט ה-fetcher המלא — גם HTTP וגם דפדפן. אחרי זה הכול עבד. אבל הרצף של "התקנה בסיסית נראית בסדר ואז מתפוצצת ב-fetch הראשון" הוא אמיתי, ושום דבר לא דוחף את זה לכם לפרצוף מראש. אם תכניסו לתכנון כבר מהפקודה הראשונה את ה-[fetchers] extra ואת שרשרת התלויות הכבדה שלו, תדלגו על כל הסיבוב המיותר הזה.
מה כן עבד בחילוץ רגיל ב-HTTP
אחרי שה-fetchers היו במקום, מסלול החילוץ הרגיל היה יציב — recall של 1.0 בכל הבדיקות:
| בדיקה | תוצאה |
|---|---|
| קטלוג סטטי + pagination | 12/12 מוצרים |
| חילוץ מאמר | כותרת + 3/3 פסקאות |
| JSON API דינמי | 8/8 פריטים |
| Books to Scrape (ציבורי) | 20 מוצרים |
| טיפול ב-HTTP 500 | הסטטוס הוצג בבירור, בלי קריסה |
כאן רואים את ה-lxml בפעולה. גם CSS וגם XPath מתנהגים כמו שהייתם רוצים, וה-pseudo-selectors של ::text ו-::attr() שומרים על קוד קצר וקריא במקום להפוך אותו לערימה של קריאות מקוננות. מקרה ה-500 הוא קטן אבל משמעותי — ה-Fetcher הציג את קוד הסטטוס במקום להטיל עליי stack trace, וזה בדיוק ההבדל בין סקרייפר שאפשר לשים בלו״ז לבין אחד שצריך להשגיח עליו ידנית. כל המספרים המלאים נמצאים ב-scrapling-test-summary.json.
שום דבר מזה לא נוצץ. זה פשוט נכון — ודיוק הוא תכונה שמעריכים פחות מדי.
מה הוא לא עושה (בכוונה)
ה-Fetcher של HTTP לא מרנדר JavaScript. הפניתי אותו לעמוד בדיקה שמורנדר ב-JS וקיבלתי 0 כרטיסים חזרה; גם ב-Quotes to Scrape JS page הציבורי התקבלה אותה תוצאה של 0. זו לא תקלה — Fetcher של HTTP מוריד HTML, הוא לא מפעיל דפדפן, ולכן תוכן שנבנה בצד הלקוח פשוט לא שם כשהוא מצפה לו. Scrapling כולל DynamicFetcher נפרד, מבוסס דפדפן, עבור עמודי JS. לא בדקתי אותו בסיבוב הזה, אז לא אגיד לכם איך הוא מתפקד. פשוט אל תפנו את מסלול ה-HTTP לאפליקציה שמסתמכת על client-side rendering ותצפו לראות את התוכן.
יש גם StealthyFetcher שמכוון להתמודדות עם מנגנוני זיהוי. אני מתייחס לזה כשיקול של ציות ורגולציה, נקודה — לא כפיצ'ר להתהדר בו. איפה ואיך מותר לכם לגרד נתונים זו האחריות שלכם והעמדה המשפטית שלכם, והסקירה הזו בדקה יכולת חילוץ, לא עקיפה של זיהוי. לא הרצתי אותו, ולא נתתי לו ניקוד.
יתרונות וחסרונות
יתרונות:
- selectors אדפטיביים באמת שיחזרו אלמנט במעקב אחרי שינוי class, במקום לקבל 0 כמו selector רגיל — וזה בדיוק הסיבה הייחודית לבחור ב-Scrapling.
- חילוץ HTTP עם recall של 1.0 בעמודים סטטיים, מאמרים ו-JSON APIs.
- CSS/XPath נקיים מבוססי lxml, עם pseudo-selectors קריאים כמו
::textו-::attr(). - טיפול אלגנטי ב-HTTP 500 — הסטטוס מוצג, בלי קריסה.
- הגרסה שנבדקה היא גם הגרסה העדכנית, כך שאין פער גרסאות.
- רישיון BSD-3-Clause מקל, מתאים גם לשימוש מסחרי.
חסרונות:
- auto-match עוקב אחרי אלמנט שמור אחד, לא אחרי עמוד שלם — בבדיקה עם שלושה אלמנטים התקבל שחזור של אחד בלבד. צריך לנסח את הטענה בהתאם.
pip install scraplingמתקין רק את ה-parser; ל-fetchers צריך את ה-[fetchers] extra ואת שרשרת התלויות הכבדה שלו, וזה משהו שלמדתי בדרך הקשה.- ה-HTTP Fetcher לא מרנדר JavaScript; לתוכן בצד הלקוח צריך את
DynamicFetcherמבוסס הדפדפן, שלא נבדק כאן. - פיצ'ר העמידות בכותרת דורש כוונון ידני במקרים של כמה אלמנטים.
למי זה מתאים — ולמי עדיף לוותר
Scrapling מצדיק את המקום שלו אם אתם מתחזקים סקרייפרים מול אתרים שמשנים עיצוב לעיתים קרובות, ונמאס לכם משינוי class אחד שמפיל בשקט את החילוץ שלכם בלילה. אם הכאב הקבוע שלכם הוא "ה-selectors שלי נשברים כל כמה שבועות, ואני רק רוצה שהאלמנט היחיד שמעניין אותי יימצא שוב", זה בדיוק בשבילכם. הוא גם משמש כ-extractor נקי וקליל מבוסס lxml לעמודים סטטיים ו-JSON APIs, גם אם לעולם לא תפעילו את השכבה האדפטיבית.
כדאי לאפס ציפיות — או לפנות לפתרון אחר — בשני מקרים. אם ציפיתם שה-selectors האדפטיביים ירפאו אוטומטית עמוד שלם שעבר רידיזיין, זה לא המודל כאן: הם עוקבים אחרי אלמנטים, לא בונים מחדש פריסות. ואם היעדים שלכם כבדים ב-JavaScript ואתם לא רוצים להרים את DynamicFetcher מבוסס הדפדפן, מסלול ה-HTTP לבדו לא יפתור אתכם. בכל מקרה, כשאתם מתקינים — הוסיפו את ה-[fetchers] extra כבר מהפקודה הראשונה.
איפה נכנס API מנוהל ל-AI scraping
Scrapling הוא ספרייה חינמית וקוד פתוח שאתם מריצים ומתחזקים בעצמכם. אתם מחזיקים את הקוד, את שרשרת התלויות ואת הכיוונון — ובתמורה לא משלמים פר בקשה ושומרים הכול בתוך הארגון. זו בחירה אמיתית, מוצדקת, ולצוותים רבים זו גם הבחירה הנכונה.
השאלה הראויה היא מי נושא באחריות לבעיית ה-resilience. Scrapling אומר שאתם: אתם מייצרים fingerprints לאלמנטים וכווננים את המעקב. API מנוהל ל-AI scraping עונה אחרת — הוא מעביר את טיפול ה-drift לשרת. זה בדיוק המקום שבו Thunderbit ממלאת את ה-slot הזה לצוותים טכניים. POST /extract מחזיר JSON מובנה לפי JSON Schema שאתם מגדירים, כשה-rendering, האנטי-בוט ו-drift של ה-markup נבלעים בצד השרת; דגל renderMode קובע כמה מהעמוד יופעל לפני החילוץ. ל-Thunderbit יש גם שרת MCP עבור סוכני AI ועוזרי קוד — thunderbit_suggest_fields הוא חינמי ורץ ראשון כדי לתכנן את החילוץ — וגם CLI דרך npx @thunderbit/thunderbit-cli לשימוש בטרמינל, בסקריפטים וב-CI. אותו מנוע AI מאחורי כל שלושת הממשקים.
הפשרה האמיתית היא לא "טוב יותר" מול "גרוע יותר" — אלא איפה אתם רוצים שלוגיקת העמידות תחיה. עם Scrapling אתם משאירים אותה בקוד שלכם, עם fingerprints וכוונון שאתם מנהלים, בלי עלות לכל קריאה, ומקבלים על עצמכם את התחזוקה שנלווית לזה. עם API מנוהל אתם מעבירים את טיפול ה-drift ומשלמים פר בקשה. צוות קטן, הוסט-עצמי, ואוהב לשלוט בכיוונון בעצמו? השליטה של Scrapling היא התשובה הנכונה. מנהלים מאה אתרים ולא רוצים לטפל ידנית ב-fingerprints של selectors בכל אחד מהם? המסלול המנוהל מוחק את כל קטגוריית התחזוקה הזו.
אם אתם משווים בין כלים, הבנצ'מרק המלא של סקרייפרים בקוד פתוח מציב את Scrapling מול אחרים על אותם fixtures, וה-סקירה של Scrapy ו-סקירה של Colly מכסות עוד שני frameworks שמבוססים HTTP ושווה להכיר.
פסק דין
האם כדאי להשתמש ב-Scrapling? כן — אם אתם רוצים extractor מבוסס Python בקוד פתוח, שהטריק הבולט שלו הוא להמשיך למצוא אלמנט במעקב גם כשה-markup שמתחתיו זז, ואתם מבינים בדיוק את גבולות הטריק הזה. הוא החזיר אלמנט שסלקטור שבור לא הצליח למצוא, בעקבות שינוי שם שהיה עולה בשקט ל-scraper רגיל בנתונים שלו. חילוץ ה-HTTP הרגיל נקי, והגיע ל-recall מלא בכל fixture. הרישיון מקל, והגרסה שבדקתי הייתה עדכנית.
רק תנסחו נכון את ההבטחה — ותהיו מרוצים. הוא עוקב אחרי אלמנטים, הוא לא בונה מחדש עמודים אוטומטית — בבדיקה עם שלושה אלמנטים התקבל שחזור של אחד בלבד. התקינו את ה-[fetchers] extra מההתחלה, אחרת תיתקלו בקיר התלויות כמוני. ואם העמודים שלכם צריכים JavaScript, זה התפקיד של ה-fetcher מבוסס הדפדפן, לא של ה-HTTP. בתוך הגבולות האלה, Scrapling עושה בדיוק את מה שהוא מוכר עליו — ובין ספריות ה-scraping ב-Python, הוא זה שבאמת מספק את הפיצ'ר שכולם מייחסים בטעות לאחרים.
נסו את Thunderbit לחילוץ נתוני רשת Get Started Free
שאלות נפוצות
האם ה-selectors האדפטיביים של Scrapling באמת שורדים רידיזיין של אתר?
הם שורדים שינוי class עבור אלמנט במעקב — וזה אומת בבדיקה. אחרי ששיניתי את product-name ל-product-title, selector רגיל החזיר 0, בעוד שההתאמה האדפטיבית שיחזרה את האלמנט שהיה במעקב. אבל הוא עוקב אחרי אלמנטים שנשמרו, לא בונה מחדש עמוד שלם: בבדיקה סינתטית עם שלושה אלמנטים, רק אחד שוחזר. תתייחסו לזה כמעקב עמיד אחר אלמנט, לא כשחזור אוטומטי של עמוד שלם.
למה pip install scrapling נכשל כשאני מייבא fetcher?
כי ההתקנה הבסיסית כוללת רק את ה-parser. ייבוא scrapling.fetchers מפעיל שרשרת של תלויות חסרות — curl_cffi, אחר כך playwright, ואז browserforge. הריצו pip install "scrapling[fetchers]" (או את פקודת ה-CLI scrapling install) כדי למשוך את כל סט ה-fetchers, ואז הייבוא יעבוד.
האם Scrapling יכול לגרד עמודים שמורנדרים ב-JavaScript?
לא עם ה-Fetcher של HTTP — הוא החזיר 0 גם על עמוד בדיקה ב-JS וגם על עמוד ה-JS הציבורי של Quotes to Scrape, כי הוא מוריד HTML בלי להריץ דפדפן. ל-Scrapling יש DynamicFetcher נפרד, מבוסס דפדפן, לעמודי JS, אבל הבדיקה הזו לא כיסתה אותו, אז עדיין אי אפשר להסיק על הביצועים שלו כאן.
האם Scrapling מהיר ומדויק לחילוץ רגיל? בבדיקה הוא היה מדויק — recall של 1.0 על קטלוגים סטטיים, עמודי מאמר ו-JSON APIs, עם CSS/XPath נקיים מבוססי lxml. הוא גם טיפל ב-HTTP 500 על ידי הצגת הסטטוס במקום קריסה. אם לעולם לא תיגעו בשכבה האדפטיבית, הוא עדיין extractor חזק וקליל לתוכן סטטי.
האם Scrapling חינמי לשימוש מסחרי? כן, הוא ברישיון BSD-3-Clause, שהוא מקל וידידותי לשימוש מסחרי. כמו תמיד, כדאי לאמת את הרישיון הנוכחי ב-repo לפני שבונים עליו מוצר.
