ไลบรารี HTML เป็น Markdown ที่ได้รับความนิยมที่สุด แต่กลับแปลงตารางไม่ได้

turndown เป็นไลบรารีที่ได้ดาวมากที่สุดในบรรดา 4 ตัวที่ทดสอบ ณ ตอนที่บันทึกเมตาดาตา โดยมียอดดาวบน GitHub 11,386 ดวง บนชุด HTML ตัวอย่างรวม 4 ชุด มันสร้าง Markdown table เป็นศูนย์ เมื่อใช้ค่าเริ่มต้นหลัก และใช้โทเค็นมากกว่า markdownify อยู่ 24.6% สำหรับข้อมูลชุดเดียวกัน

ทั้ง 4 ตัวสามารถดึง probe ของเนื้อหากลับมาได้ครบทุกตัว ความต่างจึงไปอยู่ที่โครงสร้างที่ถูกแปลงออกมา และต้นทุนของโครงสร้างนั้นในขั้นตอนถัดไป

วัดอะไร และใช้ชุดทดสอบของใคร

ฐานวิจัยนี้มีแพ็กสำหรับ markitdown อยู่ก่อนแล้ว โดยมี HTML fixture 5 ชุด และ probe string ที่ลงทะเบียนไว้ล่วงหน้า — ทั้งสตริงแบบตรงตัวที่ใช้เช็กว่าหายหรือไม่ และสตริง boilerplate ที่ใช้ตรวจจับ chrome ของหน้า การเปรียบเทียบแบบรวมใช้เฉพาะ 4 fixture ที่ทั้ง 4 ตัวแปลงมีร่วมกัน ได้แก่ แคตตาล็อกหนังสือ ร้านคำคม ตารางสถิติฮอกกี้ และบทความวิกิพีเดียเรื่อง web scraping ส่วน fixture ที่ 5 คือ Nothing but tables ใช้แค่เป็นการวินิจฉัยกรณีเน้นตาราง และไม่นำไปรวมในตัวเลข 24.6%

ทั้ง 4 ได้แก่ turndown 7.2.4 (Node), markdownify 1.2.3, html2text 2025.4.15 และ markitdown ซึ่งใช้ค่าที่เผยแพร่มา 그대로 หน้าเว็บคือแคตตาล็อกหนังสือ ร้านคำคม ตารางสถิติฮอกกี้ และบทความวิกิพีเดียเรื่อง web scraping

ชื่อเมตริกทุกตัวด้านล่างตรงกับฟิลด์ artifact ของ markitdown แบบตัวต่อตัว จึงเอามาวางเทียบกันได้เลยโดยไม่ต้องตีความคำเดียวกันคนละนิยาม

ตาราง

4 fixture — ชุดเดียวกับที่ markitdown ใช้ด้วย ตัวเลขแยกตาม fixture ดูได้ใน fiveway-scores.json นับโทเค็นด้วย o200k_base; ส่วนจำนวน table row ของ markitdown นับซ้ำจาก Markdown ที่บันทึกไว้ โดยใช้ตัวนับเดียวกับตัวอื่นๆ

เนื้อหาหลักรอดครบทุกตัว เท่ากันหมด ทั้ง 16 probe ของเนื้อหาบน 4 fixture ผ่านทุกตัวแปลง ถ้าคำถามเดียวของคุณคือ “ข้อความจะรอดไหม” ทั้ง 4 ตัวตอบว่าได้

แต่โครงสร้างไม่เท่ากัน บน 4 fixture ที่ใช้ร่วมกัน markdownify และ markitdown ให้ Markdown table row อย่างละ 36 แถว; html2text ให้ 32 แถว; turndown ให้ 0 แถว ส่วน diagnostic ที่เป็นตารางล้วน markdownify ให้ 62 แถว และ html2text ให้ 59 แถว ตัวเลขนั้นไม่ถูกรวมใน aggregate ข้างบน

ต้นทุนโทเค็นของ turndown สูงกว่า 24.6% และสาเหตุไม่ได้มาจากตารางอย่างเดียว ตอนแรกผมก็คิดแบบนั้น แต่ตัวเลขแยกตาม fixture บอกอีกอย่าง — ดูด้านล่าง

turndown ทำอะไรกับตาราง

นี่คือ fixture สถิติฮอกกี้ ชุดข้อมูลเดียวกัน แต่แสดง 3 แบบ

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 ใน probe แต่สิ่งที่ไม่รอดคือ ค่าว่าตัวเลขแต่ละตัวอยู่ในคอลัมน์ไหน เมื่ออ่านผลลัพธ์ของ turndown แล้ว 44 ก็เป็นแค่ตัวเลขบรรทัดหนึ่ง คุณบอกไม่ได้ว่ามันคือจำนวนชัยชนะของ Boston เว้นแต่จะนับตำแหน่งเองและหวังว่าไม่มี cell ว่าง ซึ่งใน fixture นี้มีบางช่องว่างจริง ทำให้การนับตำแหน่งใช้ไม่ได้อยู่ดี

สำหรับโมเดลที่อ่านผลลัพธ์ นี่คือความต่างระหว่าง “ตารางที่ตอบคำถามได้” กับ “รายการตัวเลขที่ต้องเดาเอา”

นี่ไม่ใช่บั๊กเสียทีเดียว แต่เป็นข้อจำกัดที่เอกสารระบุไว้ — core ของ turndown ไม่รองรับตาราง และมี turndown-plugin-gfm ไว้เพิ่มความสามารถนี้ แต่การติดตั้งแบบปกติไม่ได้รวมปลั๊กอินนั้น และยอดดาว 11,386 ดวงก็บอกว่ามีคนใช้ค่าเริ่มต้นอยู่ไม่น้อย

ช่องว่างของโทเค็นจริงๆ มาจากอะไร

ย่อหน้าด้านบนผมเขียนโดยเชื่อว่าช่องว่างโทเค็น 24.6% มาจากตารางที่ถูกแบนราบกลายเป็นตัวอักษร แต่พอแยกดูทีละ fixture แล้ว มันไม่ใช่

บน fixture ที่เป็น ตารางล้วนๆ turndown กลับ ถูกกว่า 22% — เพราะโครงสร้าง pipe เองก็กินโทเค็น และ turndown ไม่ได้สร้างมันขึ้นมา การแบนตารางเพียงอย่างเดียวจึงไม่ใช่ตัวการเรื่องโทเค็น

fixture Wikipedia คิดเป็น 74% ของทั้งหมด และมี table row แค่ 9 แถว ช่องว่าง 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 ตัดออกทั้งคู่ เมื่อนับจาก marker ที่มีอยู่เฉพาะใน element เหล่านั้น turndown มี script marker 10 จุด และ style marker 84 จุดในทุก fixture รวมกัน ส่วนอีกสองตัวเป็น 0 ทั้งคู่ บนหน้า Wikipedia โค้ด JavaScript และ CSS แบบ inline ของ MediaWiki แค่ 8 บรรทัด ก็กินไป 14,644 อักขระ — 95% ของช่องว่างทั้งหมด (script-style-stripping.json)

นี่แหละคือข้อค้นพบที่ผมจะเอาไปใช้จริง ตารางที่ถูกแบนราบเป็นปัญหาโครงสร้างที่มองเห็นได้ แต่ JavaScript config blob ที่หลุดมาอยู่ใน Markdown คือค่าใช้จ่ายล้วนๆ ไม่มีข้อมูลที่เป็นประโยชน์อยู่เลย และบนหน้าเว็บจริงมันกินหนักกว่าสิ่งอื่นทั้งหมดในการเปรียบเทียบนี้

html2text เขียนตารางในรูปแบบที่คุณอาจไม่คุ้น

html2text ได้ 32 แถว ในขณะที่ markdownify และ markitdown ได้ 36 แถว และเวอร์ชันแรกของตัวนับผมนับมันได้แค่ 1

นั่นเป็นกฎการนับของผม ไม่ใช่ของไลบรารี html2text จะออก Team Name | Year | Wins โดยไม่มี pipe ด้านหน้าและด้านหลัง ซึ่งเป็นรูปแบบ Markdown table ที่ใช้กันบ่อย แต่อยู่รอดพ้น regex ที่บังคับว่า ^\|.*\|$ ไม่ได้ ตอนนั้นผมเขียน regex เอง รันเอง และเกือบจะสรุปว่า html2text ไม่ทำตาราง

แต่จริงๆ แล้วทำได้ ตัวนับที่แก้แล้วใช้ heuristic คือดูชุดบรรทัดที่มีเครื่องหมาย pipe ต่อเนื่องกัน และมีบรรทัด separator อยู่ในกลุ่มนั้น พอใช้กฎนี้ html2text จึงขยับจาก 1 เป็น 32 แถว นี่ไม่ใช่ Markdown parser เต็มรูปแบบ ดังนั้นยอด row ควรอ่านเป็นผลการวัดภายใต้ตัวนับที่ระบุไว้ ไม่ใช่ผลการ render สากล

ถ้าคุณจะ post-process Markdown ด้วย regex ของตัวเอง เรื่องนี้สำคัญมาก เพราะ 2 ใน 4 ไลบรารีจะใส่ outer pipes และอีก 1 ตัวไม่ใส่

ใบอนุญาตที่ไม่มีใครพูดถึง

install-and-import.json แต่ละไลบรารีถูกติดตั้งใน environment ว่างของตัวเอง ตรวจสอบใบอนุญาตจาก 3 แหล่ง: metadata ของ registry, repo บน GitHub และไฟล์ METADATA ของแพ็กเกจที่ติดตั้ง ซึ่งระบุ License-Expression: GPL-3.0-or-later

ไลบรารีที่เบาที่สุดในชุดเปรียบเทียบนี้ — 1 package, 0.2 MiB — เป็น GPL-3.0-or-later จะกระทบโปรเจกต์หรือไม่ขึ้นอยู่กับว่าเอาซอฟต์แวร์ไปประกอบและแจกจ่ายอย่างไร ให้ถือว่าเป็นจุดเช็กสำหรับผู้รับผิดชอบเรื่องไลเซนส์ บทความนี้ไม่ใช่คำปรึกษาทางกฎหมาย ส่วน markitdown แสดงเป็นยังไม่วัด เพราะ artifact ชุดนี้ไม่ได้เก็บข้อมูลการติดตั้งและใบอนุญาตของมันไว้

ดีลแบบนี้มักมองข้าม เพราะไลเซนส์คือคุณสมบัติเดียวที่ไม่โผล่ใน benchmark

ทั้ง 3 ตัวนี้เบากว่าไลบรารีดึงบทความในหมวดเดียวกันอย่างชัดเจน — พวกนั้นอยู่ราว 21 ถึง 70 MiB ตัวแปลงข้อมูลจึงเป็นของที่เล็กกว่าตัวดึงเนื้อหามาก และควรแยกพิจารณาในงบ dependency ของคุณ

สองจุดที่ต้องแก้ก่อนตารางนี้จะเป็นจริง

ตัวเลขข้างบนเป็นเวอร์ชันที่ 3 เวอร์ชันแรกสองอันผิดด้วยเหตุผลที่ควรบอกชื่อ เพราะทั้งคู่ทำซ้ำได้ง่าย

5 fixture เทียบกับ 4 fixture markitdown รันแค่ 4 ไฟล์จาก 5 ไฟล์นี้ ส่วนอีก 3 ตัวรันครบ 5 ถ้าเอาคะแนนแต่ละเครื่องมือไปบวกบนชุดของตัวเอง markdownify จะได้ 98 table row เทียบกับ 36 ของ markitdown และดูเหมือนมีช่องว่างด้านความสามารถ แต่ถ้าเทียบบน 4 ชุดเดียวกัน จะเป็น 36 ต่อ 36 — เสมอกันเป๊ะ fixture ที่ 5 เป็นตัวที่เน้นตารางหนักที่สุด ดังนั้นความคลาดเคลื่อนนี้จึงวิ่งไปในทิศทางที่แย่ที่สุด คือทำให้ตัวใหม่ดูเหนือกว่าตัวเดิมเกือบ 3 เท่า

ตัวนับสองแบบ แต่ใช้คอลัมน์เดียวกัน ค่า md_table_rows ที่ markitdown เผยแพร่มา มาจากโค้ดของตัวเองซึ่งผมยังไม่ได้อ่าน การเอาตัวเลขนั้นมาเทียบกับตัวนับของผมจึงอาจเป็นการเทียบคนละตัวนับ ไม่ใช่คนละตัวแปลง โชคดีที่ Markdown output ของมันถูกเก็บไว้บนดิสก์ วิธีแก้คือเอาตัวนับเดียวไปนับทั้ง 4 ตัวใหม่ทั้งหมด — และเมื่อทำแล้ว markitdown ก็ออกมาตรงกับค่าที่เผยแพร่ไว้ทุก fixture (0, 0, 27, 9) แปลว่านิยามตรงกัน เพียงแต่ผมยังรู้ไม่ได้จนกว่าจะตรวจ

ความผิดพลาดทั้งสองแบบจะไม่โผล่ใน output แต่จะสร้างตารางที่ดูมั่นใจและผิด

ใครควรใช้ตัวไหน

ถ้าจะป้อนให้โมเดล หรือเก็บเนื้อหาเชิงโครงสร้างจากหน้าแบบนี้ เริ่มที่ markdownify ก่อน มันเสมอกับ markitdown ในจำนวน table row ที่สร้างได้ภายใต้ตัวนับนี้ อยู่ในกลุ่มโทเค็นต่ำสุด, เป็น MIT, และติดตั้งแค่ 1.8 MiB แนะนำให้ทดสอบกับรูปแบบหน้าของคุณเองก่อนเอาไปใช้จริง

ถ้างบ dependency วัดเป็นกิโลไบต์ และคุณไม่ได้แจกจ่ายต่อ ใช้ html2text แพ็กเกจเดียว 0.2 MiB ตารางยังอยู่ครบ แต่ต้องเช็กเรื่อง GPL ก่อน และอย่าลืมว่ารุ่นล่าสุดออกเมื่อเมษายน 2025

ถ้าคุณอยู่ในสแตก Node อยู่แล้ว ใช้ turndown คู่กับ turndown-plugin-gfm และควรตัด <script> กับ <style> ออกจาก HTML ก่อนส่งเข้าไป เพราะ turndown ไม่ทำให้อัตโนมัติ ถ้าไม่ทำ 2 อย่างนี้ คุณจะเสียทั้งโทเค็นเพิ่มประมาณหนึ่งในสี่และโครงสร้างตาราง โดยไม่มีอะไรเตือนจนกว่าจะดูผลลัพธ์จริง

ถ้าคุณแปลงเอกสารชนิดอื่นอยู่แล้ว markitdown รองรับ PDF, Office และอื่นๆ และ HTML output ของมันก็แข่งขันได้กับตัวแปลงเฉพาะทาง ตัวเดียวแทนสองตัวก็คุ้มอยู่

managed API เข้ามาอยู่ตรงไหน

ทั้ง 4 ตัวนี้รับ HTML ที่คุณมีอยู่แล้ว ไม่มีตัวไหนดึงหน้าเว็บ, render JavaScript, หรือจัดการ anti-bot layer — และสำหรับเป้าหมายจริงจำนวนมาก นั่นแหละคือครึ่งที่ยากกว่า

developer stack ของเราเองที่ Thunderbit ครอบคลุมฝั่งนั้น POST /distill รับ URL แล้วส่งกลับ Markdown ที่สะอาดและพร้อมใช้กับ LLM โดยจัดการเรื่อง rendering และ fetching ให้แล้ว; ส่วน POST /extract จะส่งกลับ JSON แบบมี schema ตรงกับ AI โดยอิงจาก JSON Schema ที่คุณให้ ซึ่งเป็นรูปแบบผลลัพธ์อีกแบบหนึ่ง — เป็นแถวข้อมูลแทนที่จะเป็น Markdown table ที่ต้องเอาไป parse ต่อ ทั้งสองอย่างเรียกได้ผ่าน MCP server และ CLI (npx @thunderbit/thunderbit-cli) ราคาอยู่ที่ หน้า pricing ของ Thunderbit

พูดแบบตรงไปตรงมา: ถ้าคุณมี HTML อยู่แล้วและอยากได้ Markdown, markdownify ใช้งานฟรีและทำงานได้ดี และตารางนี้ก็บอกแล้วว่าคู่แข่งตัวไหนทำได้ด้วย ถ้าคุณต้องเป็นฝ่ายดึงหน้าเอง หรืออยากได้ข้อมูลเป็นแถวที่มีโครงสร้างแทนข้อความธรรมดา นั่นคือการซื้ออีกแบบหนึ่ง

สำหรับภาพรวมของตลาด web scraping API roundup ของเราครอบคลุมตัวเลือกแบบ hosted และ open-source scraper pillar ครอบคลุมตัวแบบ self-hosted ส่วน การแปลง HTML เป็น Markdown ใน Python คือ walkthrough แบบลงมือทำ และ สิ่งที่ llms.txt พยายามทำให้เป็นมาตรฐาน จะพาไปดูว่าหมวดนี้กำลังมุ่งหน้าไปทางไหน

ลองใช้ Thunderbit เพื่อดึงข้อมูลเว็บ

บทสรุป

สำหรับงาน 4 fixture ชุดนี้ markdownify คือค่าเริ่มต้นที่แข็งแรงที่สุด: มีจำนวน table row ที่สร้างได้เท่ากับ markitdown ภายใต้ตัวนับเดียวกัน, ใช้โทเค็นอยู่ในกลุ่มต่ำที่สุดโดยต่างจากตัวแปลงที่มีประสิทธิภาพตัวอื่นไม่เกิน 1.3%, เป็น MIT และติดตั้งแค่ 1.8 MiB

ช่องว่างระหว่างความนิยมกับพฤติกรรมที่วัดได้คือข้อค้นพบสำคัญ turndown เป็นไลบรารีที่ยอดเยี่ยม แต่คนจำนวนมากติดตั้งมันโดยไม่ได้ใส่ปลั๊กอินที่ทำให้รองรับตาราง และผลที่ตามมาคือโทเค็นเพิ่มขึ้นราวหนึ่งในสี่ กับโครงสร้างตารางที่หายไปเลย ไม่มีตัวเลขเหล่านี้ปรากฏอยู่ที่ไหนจนกว่าจะนับมันจริงๆ

ถ้าจะจำแค่เรื่องเดียว: ตรวจดูว่าตัวแปลงของคุณทำอะไรกับตาราง ก่อนจะเชื่อผลลัพธ์แล้วส่งให้โมเดลใช้ สามในสี่ตัวนี้ทำได้สมเหตุสมผล ส่วนตัวที่ได้รับความนิยมที่สุดทำไม่ได้ เว้นแต่คุณจะสั่งให้มันทำ

ลองใช้ Thunderbit เพื่อดึงข้อมูลเว็บ Get Started Free

คำถามที่พบบ่อย

turndown ไม่รองรับตารางจริงหรือ? core ของมันไม่รองรับ ตารางมาจาก turndown-plugin-gfm ซึ่งเป็นแพ็กเกจแยก และการ npm install turndown แบบปกติไม่ได้รวมมันไว้ ถ้าไม่มีปลั๊กอินนี้ แต่ละ cell จะรอดมาเป็นย่อหน้าของตัวเองหมด — ค่าทั้งหมดยังอยู่ครบ แต่ความสัมพันธ์ระหว่างแถวและคอลัมน์หายไป บน 4 fixture นี้จึงได้ Markdown table row เป็นศูนย์ และใช้โทเค็นมากกว่า markdownify 24.6% สำหรับเนื้อหาเดียวกัน

ทำไมตอนแรก html2text ดูเหมือนไม่มีตาราง? เพราะตัวนับของผมบังคับให้มี pipe ทั้งต้นและท้าย แต่ html2text ไม่ได้ใส่มา Team Name | Year | Wins เป็น Markdown ที่ถูกต้องและ render ได้ปกติ เพียงแต่เป็นสไตล์ต่างจาก | Team Name | Year | ตัวนับที่แก้แล้วจะดูชุดบรรทัดที่มี pipe ต่อเนื่องกันและมีบรรทัด separator อยู่ข้างใน คล้ายวิธีที่ parser ทำ แล้ว html2text จึงขยับจาก 1 แถวเป็น 32 แถว ถ้าคุณ post-process Markdown ด้วย regex ของตัวเอง นี่คือจุดที่มักพลาด

GPL ของ html2text เป็นปัญหาจริงไหม? ขึ้นอยู่กับว่าคุณรวมและแจกจ่ายซอฟต์แวร์อย่างไร GPL-3.0-or-later อาจสร้างข้อผูกพันที่ MIT ไม่มี ดังนั้นควรให้คนที่รับผิดชอบเรื่อง licensing เข้ามาดูก่อนตัดสินใจใช้ในผลิตภัณฑ์ที่ต้องแจกจ่ายต่อ นี่เป็นจุดเช็กด้าน compliance ไม่ใช่คำแนะนำทางกฎหมาย; การยืนยันชนิดใบอนุญาตทำจาก metadata ของ registry, repository และไฟล์ METADATA ของแพ็กเกจที่ติดตั้ง

ตัวเลขโทเค็นพวกนี้ใช้กับหน้าอื่นได้ไหม? ช่องว่าง 24.6% ส่วนใหญ่เกิดจาก turndown ที่เก็บเนื้อหาใน <script> และ <style> เอาไว้ ดังนั้นมันจึงขึ้นกับว่าหน้าเว็บมีของพวกนี้เยอะไหม — ถ้าเป็นหน้า CMS สมัยใหม่จะหนัก ถ้าเป็นหน้า static ก็แทบไม่มี ตารางกลับดันไปคนละทาง: บน fixture ที่เป็นตารางล้วน turndown ถูกกว่า 22% เพราะมันไม่สร้าง pipe scaffolding เลย bytes ต่อโทเค็นอยู่ระหว่าง 3.61 ถึง 3.65 สำหรับทั้ง 4 ตัว ดังนั้นความหนาแน่นของผลลัพธ์แทบเท่ากันหมด ความต่างคือปริมาณล้วนๆ ถ้าตัวเลขนี้สำคัญต่อ budget ก็ควรวัดกับคอร์ปัสของคุณเอง

อะไรที่ไม่ได้ทดสอบในครั้งนี้? ความหลากหลายของโลกจริง — มีแค่ 4 fixture ก็แค่ 4 fixture, รายการซ้อน, definition list, footnote และ math, HTML ที่ผิดรูป ซึ่งเป็นจุดที่ตัวแปลงมัก diverge กันมากที่สุด, การเอา Markdown กลับไปเป็น HTML, docling ซึ่งมี fixture ชุดเดียวกันในดิสก์ แต่รอบที่เผยแพร่ไม่ได้รายงานฟิลด์เหล่านี้ จึงไม่ถูกนำมารวมด้วยการเดา และการตั้งค่า: html2text ถูกรันด้วย body_width=0 เพราะค่าเริ่มต้น 78 จะ hard-wrap ทุกบรรทัด ซึ่งจะเปลี่ยนตัวอักษรและโทเค็นทุกตัวในตารางนี้