markdownify ทำสถิติเทียบเท่า markitdown ในจำนวนแถวตาราง Markdown ที่สร้างได้ ภายในขนาด 1.8 MiB

จาก HTML ตัวอย่างทั้ง 4 ชุดที่ใช้ร่วมกับ markitdown, markdownify สร้าง จำนวนแถวตาราง Markdown ที่ตรวจนับได้เท่ากัน — 36 เท่ากับ 36 — และกู้คืนสตริงเนื้อหาที่ตรวจสอบทั้ง 16 รายการได้ครบถ้วน เอาต์พุตขนาด 21,062 โทเคนของมันถือว่าต่ำที่สุดในเชิงตัวเลข แม้ว่า 3 ตัวแปลงแรกจะต่างกันไม่เกิน 1.3% ก็ตาม ตัวโปรแกรมติดตั้งใช้พื้นที่ 1.8 MiB, ใช้สัญญาอนุญาต MIT และในช่วงที่เก็บสถิติ มีดาวบน GitHub 2,235 ดวง

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

markdownify คืออะไร

markdownify คือเครื่องมือแปลง HTML เป็น Markdown สำหรับ Python ที่สร้างบน BeautifulSoup โครงสร้างของมันมีเพียงเท่านี้: parse ด้วย BeautifulSoup, ไล่โครงสร้าง DOM แล้วปล่อยเป็น Markdown เวอร์ชันที่ทดสอบคือ 1.2.3, ใช้ MIT, มี 2,235 ดาว, เปิด issue อยู่ 42 รายการ, และปล่อยเวอร์ชันล่าสุดเมื่อ 2026-06-30 — ยังดูแลต่อเนื่องอยู่ รวมทั้งหมด 44 releases

เอกสารอ้างอิงอย่างเป็นทางการ: python-markdownify's official repository

API มีเพียงฟังก์ชันเดียว:

from markdownify import markdownify
md = markdownify(html)

ถ้าต้องการปรับการจัดการ element ละเอียดขึ้น ก็มีแบบ class (MarkdownConverter) ให้ใช้ และยังมีตัวเลือกที่ดีพอสมควร เช่น รูปแบบหัวข้อ, ตัวอักษร bullet, การตรวจจับภาษาในโค้ด, และการตัด element บางชนิดออก แต่กรณีใช้งานที่พบบ่อยที่สุดคือเรียกแบบบรรทัดเดียว และมันก็ทำงานได้ดี

pip install markdownify ดึงมา 5 แพ็กเกจ และกินพื้นที่ 1.8 MiB, พร้อม cold import ที่ 0.046 วินาที — เร็วที่สุดในบรรดา 3 ตัวแปลงที่ทดสอบร่วมกัน ต้นตอของ dependency คือ BeautifulSoup และชุดประกอบตามปกติ ซึ่งโปรเจกต์ Python จำนวนมากมีอยู่แล้ว ดังนั้นต้นทุนส่วนเพิ่มมักแทบเป็นศูนย์

วิธีวัดผล

ผมทดสอบกับ HTML ตัวอย่าง 4 ชุดเดียวกับที่อีกชุดในฐานข้อมูลนี้เคยใช้กับ markitdown โดยใช้ probe strings ที่ลงทะเบียนไว้ล่วงหน้า ของชุดนั้น — ตรวจ 16 สตริงในเนื้อหาว่ายังรอดอยู่ครบไหม พร้อมเช็กข้อความมาตรฐานของส่วนโครงหน้าเว็บด้วย ส่วนตัวอย่างที่ 5 คือ Nothing but tables เป็นชุดวินิจฉัยที่เน้นตารางโดยเฉพาะ และไม่นับรวมในผลรวมของ 4 ชุดด้านล่าง

fourway-scores.json. วัดจาก 4 fixtures, นับโทเคนด้วย o200k_base, และนับแถวตารางด้วยกฎเดียวกันทั้ง 4 ตัว — รวมถึงการนับซ้ำจาก output ที่บันทึกไว้ของ markitdown ซึ่งตรงกับตัวเลขที่เผยแพร่ไว้ทุกประการ

มี 3 ประเด็นที่เด่นชัด

มันเสมอกับ markitdown ในจำนวนแถวตารางที่สร้างออกมาได้ 36 แถวเท่ากันใน 4 fixtures ที่ใช้ร่วมกัน โดยนับด้วย heuristic เดียวกัน นี่ไม่ได้พิสูจน์ว่า cell ต่อ cell เหมือนกัน แต่แปลว่าเอาต์พุตของทั้งคู่เปิดเผยจำนวนแถวตาราง Markdown ที่เครื่องมือนี้นับได้เท่ากัน

มันมีจำนวนโทเคนต่ำที่สุด 21,062 ต่ำกว่า html2text ที่ 21,176 และ markitdown ที่ 21,336 เล็กน้อย และต่ำกว่า turndown ที่ 26,236 อยู่ 19.7% ตัวเลขของ 3 ตัวแรกต่างกันไม่เกิน 1.3% ซึ่งผมมองว่าเป็นผลเสมอมากกว่าชนะ ข้อแตกต่างที่มีนัยสำคัญจริง ๆ คือเมื่อเทียบกับ turndown

probe ด้านเนื้อหาผ่านทั้งหมด ครบทั้ง 16 รายการ เช่นเดียวกับอีก 3 ตัวที่เหลือ — เรื่องการคงอยู่ของเนื้อหาไม่ใช่จุดที่ไลบรารีเหล่านี้ต่างกัน

ตารางที่มันทำได้ถูกต้อง

ชุดข้อมูลสถิติฮอกกี้เป็นจุดที่ตัวแปลงหลายตัวแยกกันชัด markdownify:

| Team Name | Year | Wins | Losses | OT Losses | Win % | ... |
| --- | --- | --- | --- | --- | --- | --- |
| Boston Bruins | 1990 | 44 | 24 |  | 0.55 | ... |

เป็นตาราง GFM แบบมาตรฐาน มี pipe ทั้งหน้าและท้าย มีแถวตัวคั่น และ — สังเกตช่องว่างที่ว่างอยู่ระหว่าง 24 กับ 0.55 — มันคงช่องว่างนั้นไว้ แทนที่จะข้ามทิ้ง ฟังดูเหมือนไม่สำคัญ แต่จริง ๆ สำคัญมาก: ถ้าตัวแปลงลบ cell ว่างออก ค่าอื่น ๆ ถัดจากนั้นจะเลื่อนไปอยู่ผิดคอลัมน์ แม้ผลลัพธ์ยังดูเหมือนตารางที่ถูกต้องก็ตาม

turndown กับ input เดียวกันจะปล่อยค่าทุกตัวออกมาเป็นย่อหน้าคนละบล็อก โดยไม่มีโครงสร้างคอลัมน์เลย ส่วน html2text สร้างตารางได้ถูกต้องในรูปแบบที่ต่างออกไป โดยไม่ใช้ pipe ด้านนอก

ถ้า Markdown นี้จะถูกส่งให้โมเดล ตัว pipe และการเก็บ cell ว่างไว้คือสิ่งที่ทำให้มันตอบคำถามอย่าง “Boston แพ้กี่เกม” ได้ แทนที่จะเดา

2 สิ่งที่มันลบทิ้ง แต่ turndown ไม่ทำ

ความแม่นยำของตารางคือความต่างที่เห็นได้ชัด แต่สิ่งนี้ใหญ่กว่านั้น และแทบไม่มีใครพูดถึง

markdownify ตัดเนื้อหาใน <script> และ <style> ออก ในขณะที่ turndown ไม่ทำ เมื่อนับจาก marker ที่เกิดขึ้นเฉพาะภายใน element เหล่านี้ เอาต์พุตของ markdownify ตลอดทั้ง fixtures มี script marker 0 และ style marker 0 ส่วน turndown มี 10 และ 84 ตามลำดับ บน fixture ของ Wikipedia นี่คือความต่างระหว่าง 59,561 ตัวอักษรกับ 74,939 ตัวอักษร — และ 8 บรรทัด ของ JavaScript config และ CSS แบบ inline ของ MediaWiki คิดเป็น 14,644 ตัวอักษร หรือ 95% ของช่องว่างนั้น (script-style-stripping.json)

สำหรับงานใดก็ตามที่ส่งต่อให้โมเดล นี่คือสิ่งที่แพงที่สุดในบทเปรียบเทียบทั้งหมด: ก้อน JavaScript config หนึ่งก้อนกินโทเคน แต่ไม่ให้ข้อมูลที่มีประโยชน์เลย markdownify ลบทิ้งให้เองโดยไม่ต้องสั่ง html2text ก็ทำเช่นเดียวกัน

เมื่อดูราย fixture, markdownify และ html2text จะตรงกันอย่างแม่นยำเมื่อ table เรียบง่าย และเริ่มต่างกันเมื่อโครงสร้างซับซ้อน:

markdownify สร้างแถวที่เครื่องมือนี้ยอมรับได้มากกว่าทั้งสองชุดการวินิจฉัย โดยเฉพาะบน Wikipedia มันเก็บได้ 9 แถว ขณะที่ html2text เก็บได้ 5 แถวภายใต้กฎนับนี้ นี่เป็นสัญญาณให้ตรวจสอบ table ที่ซ้อนกันและ table ที่ไม่เป็นระเบียบก่อนตัดสินใจเลือก ไม่ใช่ข้อพิสูจน์ว่า cell ที่ปล่อยออกมาทุกตัวถูกต้องทางความหมาย

การติดตั้งและสัญญาอนุญาต เทียบกับตัวเลือกอื่น

เอกสารอ้างอิงอย่างเป็นทางการ: markdownify on PyPI

install-and-import.json และ metadata-snapshot.json. ไลบรารีแต่ละตัวถูกติดตั้งลงใน environment ว่างของตัวเอง

html2text เล็กกว่าบนดิสก์ถึง 9 เท่า และใช้สัญญาอนุญาตแบบ GPL-3.0-or-later ถ้าเป็นโปรดักต์ที่ต้องแจกจ่าย ให้ถือจุดนี้เป็นจุดตรวจสอบของผู้รับผิดชอบเรื่องไลเซนส์ บทความนี้ไม่ใช่คำปรึกษากฎหมาย ส่วน markdownify ใช้ MIT ซึ่งโดยทั่วไปยืดหยุ่นกว่า แต่ก็ยังควรผ่านการตรวจ compliance ตามปกติ

ขนาด 1.8 MiB ก็เป็นเพียงตัวเลขประมาณการในบางแง่ หากโปรเจกต์ของคุณใช้ BeautifulSoup อยู่แล้ว ซึ่งโปรเจกต์ scraping สำหรับ Python จำนวนมากก็เป็นแบบนั้น — ในกรณีนั้น markdownify แทบไม่มีต้นทุนเพิ่ม

รอบการออกเวอร์ชันของ markdownify สุขภาพดีที่สุดใน 3 ตัวนี้: มี 44 releases และมีการส่งโค้ดครั้งล่าสุดก่อนทดสอบ 6 สัปดาห์ เทียบกับ html2text ที่ปล่อยล่าสุดเมื่อเมษายน 2025

โค้ด Python บรรทัดเดียวให้อะไรคุณได้จริง

ทั้งไลบรารีคือ markdownify(html) และควรพูดให้ชัดว่าการเรียกฟังก์ชันนี้ตัดสินอะไรแทนคุณบ้าง เพราะ 3 ใน 4 เรื่องที่เปรียบเทียบกันอยู่ในบทความนี้ ล้วนขึ้นกับการตัดสินใจเหล่านั้น

มัน parse ด้วย BeautifulSoup, ลบ <script> และ <style> โดยไม่ต้องสั่ง และปล่อยตารางแบบ pipe ของ GFM พร้อม pipe ด้านนอกและการคง cell ว่างไว้ Parser ที่ใช้ดีอย่างเดียวไม่ได้รับประกันพฤติกรรมกับ input ที่เสียรูป ดังนั้นประเด็นนั้นจึงถูกวัดแยกไว้ด้านล่าง

สิ่งเหล่านี้ไม่ใช่ตัวเลือกที่คุณต้องตั้งเอง มันคือพฤติกรรมเริ่มต้น และในหมวดที่ค่าเริ่มต้นของ turndown เก็บ JavaScript ไว้ และค่าเริ่มต้นของ html2text hard-wrap ที่ 78 ตัวอักษร ไลบรารีที่ใช้งานได้ถูกต้องตั้งแต่ติดตั้งมาก็นับว่ามีคุณค่าในตัวเอง

ถ้าต้องการ ตัวเลือกก็มีให้ใช้ เช่น heading_style, bullets, code_language, strip และ convert สำหรับ allowlist และ denylist ของ element รวมถึง MarkdownConverter สำหรับ override ราย element ทั้งหมดที่วัดในที่นี้ไม่ได้ใช้ตัวเลือกเหล่านี้เลย

หน่วยความจำ และ HTML ที่พังส่งผลอย่างไร

บริบทการทดสอบความทนทานที่กว้างกว่านี้อยู่ใน ten-library memory and malformed-HTML comparison

มี 2 เรื่องที่การรีวิวในชุดนี้ระบุว่า “ยังไม่ได้ทดสอบ” แต่ตอนนี้วัดได้แล้ว

หน่วยความจำ resident สูงสุด, วัดด้วย /usr/bin/time -l, แยก process ใหม่ทุกช่อง — import floor คือสิ่งที่ไลบรารีใช้เมื่อโหลดแล้วอยู่นิ่ง ๆ ส่วนค่า peak รวม document เข้าไปด้วย

memory-results.json. baseline ของ Python และ Node ไม่ควรเอามาเทียบกันโดยตรง เพราะตัว interpreter ถูกนับรวมอยู่ในทั้งสองฝั่ง

markdownify อยู่ตรงกลาง: ค่า floor 23.9 MiB และ 278.5 MiB บน document ขนาด 10 MB นั่นคือ peak สูงกว่า html2text 3.9 เท่า และต่ำกว่าของ turndown ราวหนึ่งในสิบ ซึ่งเป็นต้นทุนที่ต้องแลกกับการมี BeautifulSoup อยู่เบื้องหลัง

HTML ที่พัง เอกสาร 12 ชุด แต่ละชุดทำให้เสียหายเพียงอย่างละ 1 อย่าง — เช่น tag ปิดไม่ครบ, inline element ซ้อนผิด, attribute ที่ไม่ใส่เครื่องหมายคำพูดแต่มีช่องว่าง, closing tag โผล่มาเกิน, ไม่มี <html> เลย, attribute ซ้ำ, เอกสารถูกตัดกลาง tag, entity ผิดรูป, <script> ที่ไม่ปิด, การประกาศ charset ที่โกหก, comment ที่มี markup อยู่ข้างใน, และการซ้อนลึก 600 ชั้น — พร้อม control ที่ถูกต้องตามรูปแบบอีก 2 ชุดในขนาดที่ตรงกัน เพราะคำว่า “มันไม่คืนค่าอะไรเลย” จะบอกเรื่อง malformed ได้ก็ต่อเมื่อไลบรารีไม่ได้เงียบกับ document ที่ถูกต้องและมีขนาดเท่ากันด้วย

markdownify โยน exception ใน 1 จาก 14 กรณี และไม่คืนค่าอะไรเลยใน 0 กรณี กู้คืน sentinel ได้ 30/33 รายการในชุด broken fixtures (malformed-results.json). มี 1 fixture ที่ไม่นับรวมในตัวเลขนี้: ตาม HTML5 ทุกอย่างหลัง <script> ที่ยังไม่ปิดถือว่าเป็น script content ดังนั้นการหายไปของเนื้อหาตรงนั้นจึงถูกต้อง ส่วนการกู้คืนกลับมาถือเป็นความคลาดเคลื่อน

ข้อดีและข้อเสีย

ข้อดี ความแม่นยำของตารางเท่ากับ markitdown โดยนับด้วยกฎเดียวกัน โทเคนต่ำที่สุดในกลุ่ม 4 ตัว ใช้ MIT ขนาด 1.8 MiB และถ้าคุณมี BeautifulSoup อยู่แล้ว ต้นทุนส่วนเพิ่มแทบเป็นศูนย์ cold import เร็วที่สุดที่ 0.046 วินาที ยังมีการอัปเดตอย่างต่อเนื่อง เก็บ cell ตารางว่างไว้ได้ ปรับ conversion ราย element ผ่าน MarkdownConverter ได้ และการเรียกแบบบรรทัดเดียวคือวิธีที่ควรใช้

ข้อเสีย พึ่งพา BeautifulSoup ดังนั้นถ้าไม่ได้มีอยู่แล้ว จะกินพื้นที่ดิสก์มากกว่า html2text ถึง 9 เท่า ดาว 2,235 ดวงหมายถึงชุมชนเล็กกว่า turndown — ตัวอย่างแก้ปัญหาเวลาพบเคสแปลก ๆ น้อยกว่า เป็น Python เท่านั้น จึงช่วยไม่ได้ในสแตก Node และยังมี issue เปิดค้างอยู่ 42 รายการ

ใครควรใช้ และใครไม่ควรใช้

เริ่มต้นด้วย markdownify ถ้างานของคุณเป็น Python และ input คล้ายกับ fixtures ชุดนี้ มันเสมอกับ markitdown ในจำนวนแถวที่สร้างได้ภายใต้ตัวนับนี้ อยู่ในกลุ่มโทเคนต่ำสุด และใช้ MIT ถ้าคุณพึ่งพา BeautifulSoup อยู่แล้ว ต้นทุนส่วนเพิ่มอาจเล็กมาก ควรตรวจสอบส่วนต่างของ dependency จริงใน environment ของคุณเอง

ลองพิจารณา html2text แทน ถ้างบ dependency วัดกันเป็นเพียงไม่กี่ร้อยกิโลไบต์ และรูปแบบ output ของมันเหมาะกับหน้าเว็บของคุณ แต่อย่าลืมให้ผู้รับผิดชอบเรื่องไลเซนส์ตรวจ GPL-3.0-or-later ก่อนแจกจ่าย

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

ข้ามตัวนี้ไปใน Node แล้วใช้ turndown ซึ่งเป็นคำตอบตามธรรมชาติของฝั่งนั้น — และติดตั้ง turndown-plugin-gfm ควบคู่ไปด้วย เพราะแกนหลักของ turndown ไม่สร้างตารางเลย

บริการแบบจัดการเหมาะตรงไหน

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

ถ้าต้องการดูผลลัพธ์ของทั้ง 5 ตัวแปลงบน fixtures ชุดเดียวกัน ดูได้ใน five-way HTML-to-Markdown comparison

สแตกสำหรับนักพัฒนาของเราที่ Thunderbit จัดการงานต้นทางตรงนั้น: POST /distill ดึง URL แล้วส่ง Markdown กลับมา ส่วน POST /extract ส่ง JSON ตาม schema ทั้งคู่ใช้งานได้ผ่าน MCP server และ CLI ส่วนราคาอยู่ที่ Thunderbit pricing page จุดให้บริการเหล่านี้ไม่ได้ถูก benchmark เทียบกับตัวแปลงในเครื่อง จึงเป็นการแยกประเภท ไม่ใช่การเปรียบเทียบประสิทธิภาพ

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

สำหรับภาพรวมตลาดที่กว้างกว่า ดู web scraping API roundup สำหรับตัวเลือกแบบ hosted และ open-source scraper pillar สำหรับตัวที่ self-hosted ส่วน Converting HTML to Markdown in Python คือคู่มือเชิงปฏิบัติ

ลองใช้ Thunderbit สำหรับดึงข้อมูลเว็บ

ควรใช้ markdownify ไหม?

ถ้าเป็นงาน Python มันเป็นตัวเลือกที่แข็งแรงมากเมื่อ input ของคุณคล้ายกับ fixtures เหล่านี้; ควรลองกับตารางและหน้า HTML ที่เสียรูปของคุณเองก่อนจะตั้งให้เป็นค่าเริ่มต้น

มันเสมอกับ markitdown ในจำนวนแถวตาราง Markdown ที่สร้างออกมา อยู่ในกลุ่มโทเคนต่ำสุดในชุดทดสอบนี้ import ได้เร็วที่สุด, และใช้ MIT แต่ก็แลกมาด้วยการใช้หน่วยความจำมากกว่า html2text, ใช้ได้เฉพาะ Python, และมีการโยน error ในหนึ่ง fixture ที่ malformed ขนาดดิสก์และสัญญาอนุญาตเป็นปัจจัยคัดเลือกเพิ่มเติม ไม่ใช่เหตุผลทั้งหมด

สิ่งที่สะดุดตาผมคือจำนวนดาว turndown มีคนสนใจมากกว่าถึง 5 เท่า แต่เมื่อใช้งานแบบค่าเริ่มต้นกลับแปลงตารางที่ markdownify จัดการได้อย่างถูกต้องไม่ได้เลย ในหมวดนี้ ความนิยมไม่ได้วิ่งตามพฤติกรรมที่วัดได้ ซึ่งนั่นเองคือเหตุผลหลักที่ทำให้การเปรียบเทียบนี้คุ้มค่าที่จะทำ

ลองใช้ Thunderbit สำหรับดึงข้อมูลเว็บ Get Started Free

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

markdownify ดีเท่า markitdown สำหรับ HTML จริงไหม? ใน fixtures 4 ชุดนี้ ทั้งคู่สร้างแถวตาราง Markdown ที่ตรวจนับได้ 36 แถวเท่ากัน กู้คืนสตริงที่ตรวจสอบทั้ง 16 รายการได้ครบ และมีขนาด output ต่างกันเพียง 0.2% ในเชิงตัวอักษร นี่ไม่ใช่การทดสอบระดับ cell หรือเทียบการเรนเดอร์แบบสมบูรณ์ และ markitdown ยังรองรับ PDF กับ Office formats ด้วย ดังนั้นการเปรียบเทียบนี้จึงพูดเฉพาะผลลัพธ์ HTML ที่วัดได้เท่านั้น

ต้องใช้ BeautifulSoup ไหม? ใช่ — นั่นคือ parser ของมัน และเป็นส่วนใหญ่ของ 1.8 MiB หากโปรเจกต์ของคุณใช้ BeautifulSoup อยู่แล้ว ต้นทุนส่วนเพิ่มของ markdownify จะเล็กมาก ถ้าไม่ใช่ และคุณซีเรียสเรื่องพื้นที่ดิสก์จริง ๆ html2text มีขนาด 0.2 MiB ใช้เพียง 1 แพ็กเกจ แต่ต้องแลกกับไลเซนส์ GPL-3.0-or-later

มันจัดการช่องตารางว่างยังไง? มันคงช่องว่างไว้ ใน fixture ที่มีช่องข้อมูลขาดหาย เอาต์พุตจะรักษาช่องว่างนั้นไว้ในตำแหน่งเดิม ทำให้ค่าถัดไปยังอยู่คอลัมน์ที่ถูกต้อง ตัวแปลงที่ข้าม cell ว่างจะสร้างตารางที่ยังดูถูกต้อง แต่ทำให้ค่าทุกตัวเลื่อนไปหนึ่งคอลัมน์ทางซ้าย ซึ่งเป็นความล้มเหลวที่แย่กว่า เพราะไม่มีอะไรบอกว่าพลาด

ควรใช้ฟังก์ชันหรือคลาส? ใช้ฟังก์ชัน markdownify() สำหรับกรณีทั่วไป ใช้ MarkdownConverter เมื่อคุณต้องการ override วิธีแปลงของ element เฉพาะบางชนิด — การวัดทั้งหมดในที่นี้ใช้ฟังก์ชันปกติกับค่าเริ่มต้น

ที่นี่ไม่ได้ทดสอบอะไรบ้าง? fixtures ที่แชร์กัน 4 ชุดบวกชุดวินิจฉัยตารางล้วนอีก 1 ชุดยังไม่ใช่คอร์ปัสตัวแทนทั้งหมด ชุด malformed แยกต่างหากครอบคลุมการพัง 12 แบบที่ระบุชื่อไว้และ control อีก 2 ชุด แต่ก็ยังไม่ครอบคลุม HTML ที่เสียรูปทุกแบบ, ไม่มีการเทียบ nested lists, definition lists, footnotes, math, การ round trip จาก Markdown ไป HTML, ความเท่ากันระดับ cell ของตาราง, และ variant ของการตั้งค่า รวมถึงไม่ได้เปรียบเทียบความเร็วในการแปลงด้วย