ספריית HTML ל-Markdown הפופולרית ביותר לא ממירה טבלאות

turndown הייתה הספרייה מבין הארבע שנבדקו עם הכי הרבה כוכבים בזמן צילום המטא־דאטה, עם 11,386 כוכבים ב-GitHub. בארבעת קובצי ה-HTML המשותפים היא יצרה אפס טבלאות Markdown עם ברירות המחדל שלה, והשתמשה ב-24.6% יותר טוקנים מ-markdownify עבור אותם קלטים.

כל ארבעת הכלים עברו את כל בדיקות התוכן. ההבדלים הם לגמרי במה שקורה למבנה — ובכמה המבנה הזה עולה בהמשך.

מה נמדד, ועל אילו קבצים

בסיס המחקר כבר כלל חבילה עבור markitdown עם חמישה קובצי HTML ומחרוזות בדיקה מוגדרות מראש — מחרוזות מדויקות שנבדקו להישרדות, לצד מחרוזות boilerplate שנועדו לזהות רכיבי chrome של הדף. ההשוואה המצטברת משתמשת ב-ארבעת הקבצים המשותפים לכל ארבעת הממירים: קטלוג חנות ספרים, אתר ציטוטים, טבלת סטטיסטיקות הוקי ומאמר ויקיפדיה על web scraping. קובץ חמישי, Nothing but tables, משמש רק כאבחון עתיר טבלאות ואינו נכלל במצטבר של 24.6%.

ארבעת הכלים: turndown 7.2.4 (Node), markdownify 1.2.3, html2text 2025.4.15, ו-markitdown, שהשורות שפורסמו עבורו משמשות כפי שהן. הדפים: קטלוג חנות הספרים, אתר הציטוטים, טבלת הסטטיסטיקות של ההוקי ומאמר ויקיפדיה על web scraping.

כל שם מדד למטה תואם אחד-לאחד לשדה בממצא של markitdown עצמו, כך שהשורות יושבות זו לצד זו בלי שאף אחד יצטרך ליישב בין שתי הגדרות לאותה מילה.

הטבלה

ארבעה קבצים — אלה שגם markitdown רץ עליהם. מספרים מלאים לכל קובץ נמצאים ב-fiveway-scores.json. הטוקנים נספרו באמצעות o200k_base; שורות הטבלה של markitdown נספרו מחדש מתוך ה-Markdown השמור שלו, עם אותו מונה ששימש את האחרים.

שימור התוכן מסתיים בתיקו. כל שש-עשרה בדיקות התוכן בארבעת הקבצים שרדו בכל אחד מהממירים. אם השאלה היחידה שלך היא "האם הטקסט יעבור", כל אחת מארבע התשובות היא כן.

המבנה אינו תיקו. בארבעת הקבצים המשותפים, markdownify ו-markitdown מפיקים שניהם 36 שורות טבלת Markdown; html2text מפיק 32; turndown לא מפיק אף אחת. באבחון הנפרד של "רק טבלאות", markdownify הפיקה 62 שורות ו-html2text 59; השורות האלה לא נכללות במצטבר למעלה.

עלות הטוקנים גבוהה ב-24.6% עבור turndown, והסיבה אינה הטבלאות. הנחתי שזה המקור, אבל המספרים לפי כל קובץ אומרים אחרת — ראו בהמשך.

מה turndown עושה לטבלה

הנה קובץ בדיקות הוקי, אותם נתונים, בשלוש דרכים.

turndown:

Team Name

Year

Wins

Losses

Boston Bruins

1990

44

24

markdownify:

| Team Name | Year | Wins | Losses | ... |
| --- | --- | --- | --- | --- |
| Boston Bruins | 1990 | 44 | 24 | ... |

html2text:

Team Name  |  Year  |  Wins  |  Losses  | ...
---|---|---|---|---
Boston Bruins  |  1990  |  44  |  24  | ...

כל ערך שורד את ההמרה של turndown, ולכן הוא מקבל 16/16 בבדיקות. מה שלא שורד הוא איזה ערך שייך לאיזו עמודה. קרא את הפלט של turndown, ו-44 הוא רק מספר בשורה; אי אפשר לשחזר שהוא מספר הניצחונות של Boston בלי לספור מיקומים ולקוות שאף תא לא היה ריק. בקובץ הזה יש תאים ריקים, כך שספירת מיקומים לא עובדת גם כך.

עבור מודל שקורא את הפלט, זה ההבדל בין טבלה שאפשר לענות עליה לבין רשימת מספרים שהוא ינחש לגביה.

זו לא ממש תקלה אלא גבול מתועד — המערכת הבסיסית של turndown לא מטפלת בטבלאות, ו-turndown-plugin-gfm קיים כדי להוסיף אותן. אבל ההתקנה הרגילה לא כוללת אותו, ו-11,386 כוכבים מרמזים שהרבה אנשים משתמשים בברירת המחדל.

מאיפה באמת מגיע פער הטוקנים

כתבתי את הפסקה למעלה מתוך הנחה שפער הטוקנים של 24.6% נובע מהטבלאות ש״השתטחו״ לטקסט. ואז בחנתי את זה לפי קובץ, וזה לא כך.

בקובץ שהוא רק טבלאות, turndown דווקא זול ב-22% — כי גם שלד ה-pipeים עולה טוקנים, ו-turndown לא מפיק ממנו דבר. השטחת טבלה לבדה אינה עונש טוקנים.

קובץ ויקיפדיה מהווה 74% מהסה״כ, ויש בו תשע שורות טבלה. הפער של 15,378 תווים לא יכול להגיע מהטבלאות. הוא מגיע מאלה:

(function(){var className="client-js vector-feature-language-in-header-enabled…
.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}…
(RLQ=window.RLQ||[]).push(function(){mw.config.set({"wgHostname":"mw-web…

turndown לא מסיר תוכן מתוך <script> ו-<style>. markdownify ו-html2text כן מסירים. אם סופרים לפי סמנים שמופיעים רק בתוך האלמנטים האלה: הפלט של turndown מכיל 10 סמני script ו-84 סמני style לאורך הקבצים; שני האחרים מכילים אפס מכל סוג. בדף ויקיפדיה, שמונה שורות של קוד JavaScript פנימי ו-CSS של MediaWiki אחראיות ל-14,644 תווים — 95% מהפער כולו (script-style-stripping.json).

זה הממצא שהייתי באמת פועל לפיו. טבלה שטוחה היא בעיית מבנה שרואים. בלוק JavaScript של קונפיגורציה בתוך ה-Markdown שלך הוא עלות נטו בלי מידע בכלל, ובדף אמיתי הוא גובר על כל דבר אחר בהשוואה הזו.

html2text כותב טבלאות שאולי לא תזהו

html2text קיבל 32 שורות במקום 36 כמו markdownify ו-markitdown, ובגרסה הראשונה של המונה שלי הוא קיבל 1.

זו הייתה שיטת הספירה שלי, לא של הספרייה. html2text מפיק Team Name | Year | Wins בלי pipes מובילים ומסיימים — צורת Markdown נפוצה לטבלאות, אבל בלתי נראית ל-regex שדורש ^\|.*\|$. כתבתי את ה-regex הזה, הרצתי אותו, וכמעט דיווחתי ש-html2text לא יודע לייצר טבלאות.

הוא כן. המונה המתוקן משתמש בהיוריסטיקה: רצף של שורות עוקבות שמכילות pipes, עם שורת מפריד בתוכן. לפי הכלל הזה, html2text עולה מ-1 ל-32. זה לא מנתח Markdown מלא, ולכן יש לקרוא את סך השורות כמדידה לפי מונה מתועד, לא כתוצאה אוניברסלית של רינדור.

חשוב לדעת אם אתם מעבדים את ה-Markdown אחר כך עם regex משלכם: שתיים מתוך ארבע הספריות האלה מפיקות pipes חיצוניים, ואחת לא.

הרישיון שאף אחד לא מזכיר

install-and-import.json. כל ספרייה הותקנה בסביבה ריקה משלה. הרישיונות אושרו בשלושה מקורות: מטא־הדאטה של הרג׳יסטרי, מאגר ה-GitHub, וקובץ METADATA של החבילה המותקנת עצמה, שבו מופיע License-Expression: GPL-3.0-or-later.

הספרייה הקלה ביותר בהשוואת ההתקנה הזו — חבילה אחת, 0.2 MiB — היא GPL-3.0-or-later. האם זה משפיע על פרויקט תלוי באופן שבו התוכנה משולבת ומופצת. התייחסו לזה כאל נקודת בדיקה למי שאחראי על רישוי; המאמר הזה אינו ייעוץ משפטי. markitdown מוצג כאן כלא נמדד, משום שההתקנה והרישיון שלו לא נלכדו בממצא הספציפי הזה.

את הפער הזה קל לפספס, כי הרישיון הוא המאפיין היחיד שלא מופיע בבנצ'מרק.

כל שלוש הספריות קלות משמעותית מספריות חילוץ המאמרים באותה קטגוריה — אלה נעות בין 21 ל-70 MiB. ממיר הוא דבר קטן בהרבה מאקסטרקטור, וכדאי להפריד ביניהם בתקציב התלויות.

שתי הטיות שהייתי צריך לתקן לפני שהטבלה הזו הייתה נכונה

המספרים למעלה הם הגרסה השלישית. שתי הקודמות היו שגויות בדרכים שכדאי לציין, כי קל לשחזר את שתיהן.

חמישה קבצים מול ארבעה. markitdown רץ על ארבעה מתוך חמשת הקבצים האלה; שלושת האחרים רצו על כולם. סכימה של כל כלי על סט הקבצים שלו נתנה ל-markdownify 98 שורות טבלה מול 36 של markitdown, וזה גרם להיראות כמו פער יכולת. על פני אותם ארבעה, זה 36 מול 36 — תיקו מוחלט. הקובץ החמישי הוא זה העמוס בטבלאות, כך שההטיה פעלה בכיוון הגרוע ביותר, וניפחה את החדשים מול הוותיק כמעט פי שלושה.

שני מונים, עמודה אחת. ה-md_table_rows שפורסם של markitdown הגיע מהקוד שלו עצמו, שלא קראתי. השוואה של המספר הזה למספר שלי הייתה עלולה להשוות בין שני מונים ולא בין שני ממירים. פלט ה-Markdown שלו שמור על הדיסק, ולכן התיקון היה להריץ מונה אחד על כל הארבעה — וכשעשיתי זאת, המונה החוזר של markitdown יצא בדיוק לפי המספר שפורסם לכל קובץ (0, 0, 27, 9). ההגדרות הסכימו; פשוט לא יכולתי לדעת זאת בלי לבדוק.

אף אחת מהשגיאות לא הייתה נראית בפלט. שתיהן היו מייצרות טבלה סמוכה ובטוחה — אבל שגויה.

מי צריך להשתמש במה

מאכילים מודל, או שומרים תוכן מובנה מדפים כמו אלה? התחילו עם markdownify. הוא שווה ל-markitdown במספר שורות הטבלה המופקות לפי המונה הזה, נמצא באשכול הטוקנים הנמוך ביותר, הוא MIT, ומתקין ב-1.8 MiB. כדאי לאמת אותו על מבני דפים משלכם לפני שמתקבעים עליו.

תקציב התלויות נמדד בקילובייטים, ואתם לא מפיצים את התוכנה? html2text. חבילה אחת, 0.2 MiB, טבלאות נשמרות. בדקו קודם את שאלת ה-GPL, ושימו לב שהגרסה האחרונה יצאה באפריל 2025.

כבר עובדים בסטאק של Node? turndown, יחד עם turndown-plugin-gfm מותקן לצידו — וחשוב להסיר מ-HTML את <script> ו-<style> לפני שמעבירים אליו, כי turndown לא יעשה זאת. שתי ההשמטות האלה עולות רבע יותר טוקנים וגם את מבנה הטבלה, ושום דבר מזה לא נראה אם לא מביטים בפלט.

כבר ממירים פורמטים אחרים של מסמכים? markitdown מטפל ב-PDF, Office ועוד, ופלט ה-HTML שלו תחרותי מול הממירים הייעודיים. תלות אחת במקום שתיים היא יתרון משמעותי.

איפה API מנוהל משתלב

כל ארבעת הכלים האלה מקבלים HTML שכבר יש לכם. אף אחד מהם לא מביא דף, לא מרנדר JavaScript, ולא מתמודד עם שכבת anti-bot — ועבור הרבה יעדים אמיתיים, זה החלק הקשה יותר.

ערימת המפתחים שלנו ב-Thunderbit מכסה את הצד הזה. POST /distill מקבל URL ומחזיר Markdown נקי ומוכן ל-LLM, כשהרינדור והבאת התוכן כבר מטופלים; POST /extract מחזיר JSON מובנה תואם-סכמה באמצעות JSON Schema שאתם מספקים, שזה כבר צורת פלט אחרת לגמרי — שורות במקום טבלת Markdown שתצטרכו אחר כך לנתח. שניהם זמינים גם דרך שרת MCP וגם דרך CLI (npx @thunderbit/thunderbit-cli). המחיר מופיע ב-דף התמחור של Thunderbit.

ההשוואה הכנה: אם יש לכם את ה-HTML ואתם רוצים Markdown, markdownify הוא חינמי ועושה את העבודה היטב, והטבלה הזו מראה אילו מהמתחרים שלו עושים זאת גם כן. אם אתם מביאים את הדפים, או רוצים שורות מובנות במקום פרוזה, זו כבר רכישה אחרת.

לעולם הרחב יותר, הסיכום שלנו של ממשקי API ל-web scraping מכסה אפשרויות מתארחות, ו-המדריך ל-open-source scrapers מכסה את אלה שמתארחים אצלכם. המרת HTML ל-Markdown ב-Python הוא המדריך המעשי, ו-מה ש-llms.txt מנסה לתקנן מסביר לאן כל הקטגוריה הזו הולכת.

נסו את Thunderbit לחילוץ נתוני רשת

פסק דין

עבור עומס העבודה של ארבעת הקבצים האלה, markdownify הוא ברירת המחדל החזקה ביותר: אותו מספר שורות טבלת פלט כמו markitdown תחת אותו מונה משותף, ספירת טוקנים שנמצאת בטווח של 1.3% מהממירים היעילים האחרים, רישיון MIT והתקנה של 1.8 MiB.

הפער בין הפופולריות להתנהגות שנמדדה הוא הממצא כאן. turndown היא ספרייה מצוינת שהרבה מאוד אנשים התקינו בלי התוסף שהופך אותה ליכולה להתמודד עם טבלאות, והעלות של זה מופיעה כרבע יותר טוקנים ומבנה טבלה שכבר לא קיים. אף אחד מהמספרים האלה לא מופיע בשום מקום עד שסופרים אותם.

אם לוקחים דבר אחד: בדקו מה הממיר שלכם עושה לטבלה לפני שאתם סומכים על הפלט שלו מול מודל. שלושה מתוך ארבעת הכלים כאן עושים משהו סביר. הפופולרי ביותר — לא, אלא אם ביקשתם זאת במפורש.

נסו את Thunderbit לחילוץ נתוני רשת Get Started Free

שאלות נפוצות

האם turndown באמת לא תומך בטבלאות? הגרעין שלו לא. טבלאות מגיעות מ-turndown-plugin-gfm, חבילה נפרדת, ו-npm install turndown הרגיל לא כולל אותה. בלי התוסף, כל תא נשמר כפסקה נפרדת — כל הערכים נשארים, אבל היחסים בין שורות לעמודות לא. לאורך ארבעת הקבצים זה יצר אפס שורות טבלת Markdown ו-24.6% יותר טוקנים מאשר markdownify עבור אותו תוכן.

למה html2text נראה בהתחלה כאילו אין לו טבלאות? כי המונה שלי דרש pipes בתחילה ובסוף, ו-html2text לא מפיק אותם. Team Name | Year | Wins הוא Markdown תקין ומרונדר נכון; זו פשוט צורת כתיבה שונה מ-| Team Name | Year |. המונה המתוקן מחפש רצף של שורות עם pipes ושורת מפריד, כמו מנתח, ו-html2text עובר מ-1 שורה ל-32. אם אתם מעבדים Markdown אחר כך עם regex משלכם, זה ההבדל שיכבול אתכם.

האם ה-GPL ב-html2text הוא בעיה אמיתית? זה תלוי איך משלבים ומפיצים את התוכנה. GPL-3.0-or-later יכולה ליצור חובות שאין ב-MIT, לכן כדאי לערב את מי שאחראי על הרישוי לפני שבוחרים בו למוצר שמופץ. זו נקודת בדיקת תאימות, לא ייעוץ משפטי; זהות הרישיון אומתה במטא־דאטה של הרג׳יסטרי, במאגר ובקובץ METADATA של החבילה המותקנת.

האם ספירת הטוקנים הזו משמעותית גם לדפים אחרים? פער ה-24.6% נובע בעיקר מכך ש-turndown שומר על תוכן <script> ו-<style>, כך שהוא גדל או קטן לפי כמה מזה יש בדף — כבד בדפי CMS מודרניים, כמעט אפסי בדפים סטטיים. טבלאות מושכות את זה לכיוון ההפוך: בקובץ שהוא רק טבלאות turndown יצא 22% זול יותר, כי הוא לא מפיק שום שלד pipes. בתים לטוקן נשארו בין 3.61 ל-3.65 בכל הארבעה, כך שצפיפות הפלט זהה בכל מקום וההבדל הוא בכמות. כדאי למדוד את הקורפוס שלך אם המספר חשוב לתקציב.

מה לא נבדק כאן? מגוון אמיתי מהעולם — ארבעה קבצים הם ארבעה קבצים. רשימות מקוננות, רשימות הגדרה, הערות שוליים ומתמטיקה. HTML פגום, שבו הממירים נוטים להיפרד הכי הרבה זה מזה. החזרת ה-Markdown חזרה ל-HTML. docling, שיש לו אותם קבצים על הדיסק אבל הריצה שפורסמה שלו לא מדווחת על השדות האלה, ולכן הוא נעדר ולא מוערך. וגם קונפיגורציה: html2text הורץ עם body_width=0 כי ברירת המחדל שלו, 78, שוברת אוטומטית כל שורה, מה שהיה משנה כל תו וכל טוקן בטבלה הזו.