html2text ขนาดแค่ 0.2 MiB และมีเพียงแพ็กเกจเดียว แต่ก็อยู่ภายใต้ GPL-3.0 ด้วย

html2text ติดตั้งแค่ 1 แพ็กเกจ ใช้พื้นที่เพียง 0.2 MiB — เล็กกว่าเครื่องมือ Python ที่ใกล้เคียงที่สุดถึง 9 เท่า และเล็กกว่าเวอร์ชันของ Node ถึง 40 เท่า โดยในการทดสอบการแปลงทั้งหมด 4 หน้า มันผ่านครบทุกหน้า และยังคงรักษา body probe ที่ลงทะเบียนไว้ทั้ง 16 รายการได้ทั้งหมด โปรบพวกนี้ใช้เช็กว่าข้อความบางส่วนในเนื้อหายังอยู่ครบไหม แต่ไม่ได้วัดโครงสร้างลำดับชั้น การซ้อนของรายการ ปลายทางของลิงก์ เนื้อหาที่ซ้ำกัน หรือความถูกต้องของตารางแบบเต็ม

นอกจากนี้มันยังอยู่ภายใต้สัญญาอนุญาต GPL-3.0-or-later ซึ่งเป็นคุณสมบัติเดียวในการเปรียบเทียบครั้งนี้ที่ไม่ได้โผล่ใน benchmark ไหนเลย แต่กลับเป็นตัวตัดสินได้จริงว่าจะใช้ไลบรารีนี้ได้หรือไม่

html2text คืออะไร

html2text คือไลบรารี Python สำหรับแปลง HTML ให้กลายเป็นข้อความธรรมดาสไตล์ Markdown ที่อ่านง่าย จุดเริ่มต้นของมันย้อนกลับไปถึงผลงานเดิมของ Aaron Swartz และสายพัฒนาที่ดูแลอยู่ตอนนี้คือเวอร์ชัน 2025.4.15 — รุ่นที่ระบุด้วยวันที่ ออกในเดือนเมษายน 2025 โดยมีดาวบน GitHub 2,168 ดวง, issue ที่ยังเปิดอยู่ 95 รายการ และ push ล่าสุดในเดือนตุลาคม 2025

อ้างอิงทางการ: คลังเก็บทางการของ html2text

import html2text
h = html2text.HTML2Text()
h.body_width = 0          # ดูด้านล่าง; ค่าเริ่มต้นอาจทำให้คุณแปลกใจ
md = h.handle(html)

pip install html2text ดึงมาแค่ 1 แพ็กเกจ และกินพื้นที่ 0.2 MiB โดย cold-import อยู่ที่ 0.077 วินาที ไม่มี dependency ใด ๆ เลย ถ้าจะใช้ใน container image หรือ Lambda layer ความต่างนี้มีนัยมาก เมื่อเทียบกับ markdownify ที่ 1.8 MiB และ turndown ที่ 8.8 MiB

ค่าเริ่มต้นที่เปลี่ยนตัวเลขทุกตัว

body_width มีค่าเริ่มต้นเป็น 78 หมายความว่า html2text จะตัดบรรทัดของผลลัพธ์ทุกบรรทัดที่ 78 ตัวอักษร เว้นแต่คุณจะปิดมัน

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

ผมตั้ง body_width = 0 สำหรับทุกส่วนด้านล่าง และขอบอกไว้ชัด ๆ ไม่ได้ซ่อนมัน: ถ้าเปิด wrapping ตัวเลขจำนวนอักขระและ token ในบทความนี้จะเปลี่ยนหมด หากคุณกำลัง benchmark ตัวแปลงเอง ค่านี้คือจุดที่ทำให้ตัวเลขของคุณเทียบกันไม่ได้แบบเงียบ ๆ

วิธีวัดผล

ผมรัน html2text บนชุดทดสอบการแปลง 4 หน้าแบบมีชื่อกำกับ ซึ่งใช้ร่วมกับการเปรียบเทียบ markitdown ด้วย โดยมี probe strings ที่ลงทะเบียนไว้ล่วงหน้า — เป็นข้อความเฉพาะบางส่วนในเนื้อหาที่ต้องคงอยู่ และข้อความ boilerplate ที่ถ้ายังมีอยู่แปลว่าหน้าเว็บถูกดึงมาครบ ชุดไฟล์เดิม 4 ไฟล์ โปรบชุดเดิม และใช้ตัวให้คะแนนร่วมกันทั้ง 4 ตัวแปลง การรอดของ probe วัดว่าข้อความที่ลงทะเบียนไว้ยังมีอยู่ไหม ไม่ได้วัดความถูกต้องเชิงโครงสร้าง ดังนั้นคอลัมน์ตารางกับคอลัมน์ลิงก์จึงถูกแยกกันคนละส่วนโดยตั้งใจ

fourway-scores.json. มี 4 fixture และนับ token ด้วย o200k_base

ผลลัพธ์สั้นที่สุดในทั้ง 4 ตัว ที่ 76,452 อักขระ และแทบจะสูสีกันด้าน token กับ markdownify และ markitdown — 21,176 เทียบกับ 21,062 และ 21,336 ต่างกันราว 1.3% ซึ่งผมคงไม่เรียกว่าต่างกันแบบมีนัยสำคัญ

32 แถวตาราง เทียบกับ markdownify และ markitdown ที่ได้ 36 แถวในชุด 4 หน้า ช่องว่าง 4 แถวนี้มาจาก fixture Wikipedia ที่มีโครงสร้างไม่ปกติ ไม่ใช่จากความต่างของการจัด outer-pipe ที่จะพูดถึงต่อไป

จำนวนลิงก์น้อยที่สุดที่ 545 เทียบกับ 598 ถึง 611 ของตัวอื่น ถ้าการเก็บลิงก์สำคัญสำหรับงานของคุณ ค่านี้ควรไปเช็กกับหน้าเว็บจริงของคุณเอง — เพราะนี่คือคอลัมน์เดียวที่ html2text ต่ำกว่ากลุ่มอย่างชัดเจน ไม่ได้อยู่ในระดับเดียวกัน

ตารางที่ regex ของผมมองไม่เห็น

เรื่องนี้คุ้มจะเล่า เพราะตอนแรกผมเกือบสรุปผิด

ตัวนับแถวตารางตัวแรกของผมบังคับให้มี pipe ทั้งต้นและท้ายบรรทัด — ^\|.*\|$ ตามกฎนั้น html2text ได้ 1 แถวตารางจาก 5 ไฟล์: ชุดแปลง 4 หน้า บวกกับ fixture ตารางซับซ้อนแบบสังเคราะห์อีก 1 ชุด ตัวนับนั้นจริง ๆ ไปวัด Markdown แบบหนึ่ง ไม่ได้วัดตาราง

มันทำงาน และส่งออกออกมาแบบนี้:

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

ไม่มี pipe ด้านนอก นี่คือ pipe-table syntax แบบมาตรฐาน แต่ระบบทดสอบไม่ได้ตรวจความเข้ากันได้กับ Markdown renderer หลายแบบ มันจึงมองไม่เห็นถ้าใช้ regex ที่รอรูปแบบมี outer pipes อยู่ พอปรับตัวนับให้มองหาบรรทัดที่มี pipe ต่อเนื่องกันและมี separator row อยู่ภายใน html2text ก็ขยับจาก 1 แถวเป็น 32 แถวในชุด 4 หน้า และ 91 แถวเมื่อรวมทั้ง 5 ไฟล์

ดังนั้นข้อสรุปจึงไม่ใช่ html2text ไม่มีตาราง แต่เป็นว่า ตัวแปลง 2 ใน 4 ตัวนี้ใช้ outer pipes และอีก 1 ตัวไม่ใช้ ซึ่งสำคัญมากถ้าคุณเอา Markdown ไป post-process ด้วย pattern matching ของตัวเอง นี่เป็นข้อมูลที่ควรรู้จริง ๆ และผมเองก็คงพลาดไปถ้าเชื่อตัวเลขแรกของตัวเอง

สิ่งที่มันตัดทิ้ง และจุดที่มันเสียแถว

มี 2 ประเด็นที่ดูเหมือนสวนทางกัน

มันตัด <script> และ <style> ออก เมื่อนับจาก marker ที่พบได้เฉพาะในองค์ประกอบเหล่านั้น html2text ให้ผลลัพธ์เป็น script markers 0 และ style markers 0 ตลอดทุก fixture ในขณะที่ turndown มี 10 และ 84 — บน fixture Wikipedia มี JavaScript config แบบ inline ของ MediaWiki 8 บรรทัด และ CSS ที่รวมกันเป็น 14,644 อักขระ (script-style-stripping.json) สำหรับงานที่ output ถูกส่งต่อให้โมเดล นี่คือแหล่งข้อความส่วนเกินที่เลี่ยงได้มากที่สุดใน fixture นี้ และไม่มีต้นทุนปลายทางเพิ่มแบบเปล่าประโยชน์

มันเสียแถวตารางบนหน้าที่ยาก การรวมผลในชุด 4 หน้าออกมาเป็นดังนี้:

fixture ตารางซับซ้อนแบบสังเคราะห์อีกชุดเพิ่ม html2text อีก 59 แถว และ markdownify อีก 62 แถว ทำให้รวม 5 ไฟล์เป็น 91 และ 98 ตามลำดับ ตรงนี้ไม่ได้รวมอยู่ในไฮไลต์เปรียบเทียบ 4 หน้า พวกมันให้ผลตรงกันบนตารางฮอกกี้ที่สะอาด แต่บน Wikipedia ที่ตารางซ้อนและยุ่ง ๆ html2text ได้ 5 แถว ขณะที่ markdownify ได้ 9 แถว

รูปแบบจึงเป็นแบบนี้: ตารางง่าย ๆ ผลเหมือนกัน; ตารางยาก html2text เก็บได้น้อยกว่า ถ้าหน้าเว็บของคุณมีตารางแบบ Wikipedia ควรทดสอบก่อนตัดสินใจใช้ แต่ถ้าเป็นตารางแบบหน้าสถิติทั่วไป ทั้งสองตัวใช้แทนกันได้ในมิตินี้

เรื่องสัญญาอนุญาต

อ้างอิงทางการ: html2text บน PyPI

ยืนยันจาก 3 แหล่ง: metadata บน PyPI, repository บน GitHub และไฟล์ METADATA ของแพ็กเกจที่ติดตั้งไว้ ซึ่งระบุว่า License-Expression: GPL-3.0-or-later

ความหมายของมันขึ้นอยู่กับว่าซอฟต์แวร์ถูกผนวก ส่งต่อ และแจกจ่ายอย่างไร การใช้ภายในองค์กรหรือใช้ผ่านเครือข่ายอย่างเดียวมักเป็นสถานการณ์ GPL คนละแบบกับการส่งมอบซอฟต์แวร์ที่รวมแพ็กเกจนี้ไว้หรือผูกเข้าด้วยกัน แต่บทความนี้ไม่ใช่การวิเคราะห์กฎหมาย ทีมที่ต้องแจกจ่ายซอฟต์แวร์ควรให้ที่ปรึกษากฎหมายตรวจรูปแบบการผนวกและการกระจายจริง

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

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

การดูแลรักษาโครงการ

รุ่นล่าสุด 2025.4.15, push ล่าสุดใน repo คือเดือนตุลาคม 2025 — ราว 10 เดือนก่อนการทดสอบ พร้อมจำนวน release ที่ตามหลังอยู่ 41 รุ่น requires_python >= 3.9 และติดตั้งและรันได้เรียบร้อยบน Python 3.14.2

จังหวะอัปเดตนี้เงียบกว่า markdownify (ปล่อยรุ่นล่าสุดก่อนทดสอบ 6 สัปดาห์) และ turndown (4 เดือน) และถือว่ามีกิจกรรมมากกว่าความเงียบ สำหรับไลบรารีที่แปลง HTML เป็นข้อความ — ซึ่งเป็นปัญหาที่ไม่ค่อยเปลี่ยนเร็วอยู่แล้ว — ช่องว่าง 10 เดือนจึงดูเป็นสัญญาณของความนิ่งมากกว่าการถูกทิ้งร้าง ส่วน issue ที่เปิดอยู่ 95 รายการคือจุดที่น่าจับตากว่า และควรไล่ดูว่ามีอะไรคล้าย use case ของคุณหรือไม่ก่อนตัดสินใจใช้

หน่วยความจำ และ HTML ที่เสียรูปทำอะไรกับมัน

ตรงนี้มี 2 คำถามเชิงการใช้งานที่วัดแยกกัน

บริบทการ stress test แบบกว้างกว่านี้อยู่ใน การเปรียบเทียบหน่วยความจำและ HTML เสียรูปของไลบรารี 10 ตัว

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

memory-results.json. ฐานเปรียบเทียบของ Python กับ Node ใช้เทียบข้ามกันตรง ๆ ไม่ได้ เพราะตัว interpreter อยู่ในทั้งสองฝั่ง

html2text เป็นตัวที่เบาที่สุดในตารางนี้ในทั้งสองมิติที่วัดได้ ค่า import floor 18.7 MiB และ peak 71.2 MiB บน fixture 10 MiB ทำให้มี incremental RSS เท่ากับ 52.5 MiB: (71.2 - 18.7) / 10 = 5.25× ขนาด fixture ให้อ้างอิงเทียบกับแถว absolute และ incremental ในตาราง โดยยังต้องระวังข้อแม้เรื่องฐาน Python/Node ที่กล่าวไว้

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

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

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

จุดแข็ง: มีเพียง 1 แพ็กเกจ ขนาด 0.2 MiB ไม่มี dependency — เล็กที่สุดแบบขาดลอยในการเปรียบเทียบครั้งนี้ ผลลัพธ์สั้นที่สุดในทั้ง 4 ตัว และ token แทบเท่ากับ markdownify และ markitdown ส่งออกเป็น pipe-table ที่อ่านรู้เรื่อง รันบน Python 3.14 ได้ และมีสายพัฒนาที่ยาวและค่อนข้างนิ่ง

จุดอ่อน: GPL-3.0-or-later ซึ่งตัวเลือกอื่นไม่ได้เป็น body_width=78 เป็นค่าเริ่มต้น ทำให้ผลลัพธ์ถูกตัดบรรทัดและตัวเลขต่าง ๆ เปลี่ยนไปถ้าไม่ปิดมัน เก็บลิงก์ได้น้อยที่สุด (545 เทียบกับ 598–611) ตารางใช้รูปแบบไม่มี outer pipe ซึ่งทำให้ regex ปลายทางแบบง่ายพัง มี issue ที่ยังเปิดอยู่ 95 รายการ และรอบการปล่อยรุ่นที่เงียบกว่า markdownify

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

ควรใช้ html2text เมื่อข้อจำกัดเรื่อง dependency เข้มมากจริง ๆ และรูปแบบการนำไปใช้/แจกจ่ายผ่านการตรวจเรื่องลิขสิทธิ์แล้ว แพ็กเกจเดียวและไม่มี dependency ถือเป็นข้อได้เปรียบเชิงปฏิบัติการที่แท้จริง: พื้นผิว dependency ที่ต้องตรวจและ deploy น้อยลง

ตั้ง body_width = 0 ตั้งแต่บรรทัดแรก เว้นแต่คุณตั้งใจอยากได้ข้อความธรรมดาที่ถูกตัดบรรทัด

ควรข้ามมัน ถ้าคุณแจกจ่ายซอฟต์แวร์แล้ว copyleft เป็นปัญหา — markdownify ใช้ MIT, token ใกล้เคียงกัน, และให้ผลตารางพอ ๆ กับ markitdown โดยใช้พื้นที่ดิสก์มากกว่าแค่ 1.6 MiB ข้ามมันถ้าการเก็บลิงก์สำคัญต่อคุณ เพราะมันเก็บได้น้อยที่สุด และข้ามมันถ้าเครื่องมือ downstream ของคุณคาดว่าตารางจะมี outer pipe

บริการแบบ managed API เข้ามาเกี่ยวตรงไหน

html2text แปลง HTML ที่คุณมีอยู่แล้ว มันไม่ได้ไปดึงหน้าเว็บ เรนเดอร์ JavaScript หรือจัดการชั้นป้องกันบอท — ทั้ง 4 ตัวแปลงในบทความนี้ก็ทำไม่ได้ และบนเป้าหมายจริงจำนวนมาก นั่นคือครึ่งที่ยากกว่าของงาน

ถ้าอยากดูผลบนชุด fixture เดียวกันสำหรับตัวแปลงทั้ง 5 ตัว ดูได้ที่ การเปรียบเทียบ HTML-to-Markdown แบบ 5 ทาง

บริการแบบ hosted ที่ดึง/เรนเดอร์/สกัดข้อมูล รวมถึง Thunderbit ของเรา ทำงานคนละชั้น Thunderbit ไม่ได้ถูก benchmark ในบทความนี้ ขอบเขตที่ควรแยกให้ชัดคือการแปลงจาก HTML ที่ป้อนเข้ามา เทียบกับบริการที่ไปดึงและประมวลผลจาก URL เอง บทความนี้จึงไม่ได้ให้การเปรียบเทียบด้านคุณภาพ เวลา latency หรือค่าใช้จ่ายในมาตรวัดเดียวกัน

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

สำหรับภาพรวมที่กว้างกว่า ดูได้ที่ รวม API สำหรับ web scraping ที่ดีที่สุด และ หมวดรวม open-source scraper สำหรับตัวที่ต้องโฮสต์เอง ส่วน แปลง HTML เป็น Markdown ใน Python คือบทแนะนำเชิงปฏิบัติ

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

ควรใช้ html2text ไหม?

มันเป็นตัวเลือกที่แข็งแรงมากเมื่อคุณต้องคุม footprint ให้เล็ก ตั้งใจปิดการ wrapping และผ่านการตรวจเรื่องสัญญาอนุญาตแล้ว

จำนวน token ของมันต่างจาก markdownify และ markitdown ไม่ถึง 1.3% ในชุด 4 หน้า นั่นไม่ได้แปลว่าคุณภาพรวมเท่ากัน: html2text เก็บลิงก์และแถวตารางบน Wikipedia ที่ซับซ้อนได้น้อยกว่า ข้อกำหนดการใช้งาน 2 อย่างที่ต้องทำทันทีคือ body_width = 0 และรูปแบบตารางแบบไม่มี outer pipe

ถ้า GPL review ทำให้ใช้ไม่ได้ markdownify ใช้ MIT, ผลลัพธ์และจำนวน token ใกล้เคียงกันในที่นี้, เก็บลิงก์และแถวของตารางที่ยุ่ง ๆ ได้ดีกว่า และใช้พื้นที่ดิสก์เพิ่มขึ้น 1.6 MiB ในสภาพแวดล้อมนี้

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

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

html2text แปลงตารางได้ไหม? ได้ ตอนแรกตัวนับของผมบอกว่ามันสร้างได้ 1 แถวตารางจาก 5 ไฟล์ แต่ตัวนับนั้นผิด — มันบังคับให้ต้องมี pipe ทั้งต้นและท้ายบรรทัด ในขณะที่ html2text ส่งออก Team Name | Year | Wins โดยไม่มี outer pipe นั่นเป็น Markdown แบบ pipe-table ที่ใช้กันปกติ แม้ harness นี้จะไม่ได้ทดสอบความเข้ากันได้ข้าม renderer ก็ตาม เมื่อแก้ตัวนับแล้ว html2text ให้ 32 แถว เทียบกับ markdownify ที่ 36 แถวในชุด 4 หน้า และ 91 เทียบกับ 98 เมื่อรวม fixture ตารางซับซ้อนแยกต่างหากเข้าไปด้วย

body_width ทำอะไร และทำไมต้องเปลี่ยน? โดยค่าเริ่มต้นมันจะตัดบรรทัดทุก 78 ตัวอักษร ซึ่งเหมาะกับข้อความอ่านบนเทอร์มินัล แต่ไม่ค่อยดีสำหรับงานอื่นเลย การ wrapping ทำให้ขึ้นบรรทัดใหม่กลางประโยค แยก URL ยาว ๆ ออกเป็นหลายบรรทัด และเปลี่ยนวิธีตัด token ตัวเลขทุกตัวในรีวิวนี้ใช้ body_width = 0; ถ้าใช้ค่าเริ่มต้น ตัวเลขทั้งหมดจะเปลี่ยนไป

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

รุ่นที่ออกในเดือนเมษายน 2025 เป็นปัญหาไหม? น่าจะไม่ใช่ในตัวมันเอง การแปลง HTML เป็นข้อความเป็นปัญหาที่ค่อนข้างนิ่ง ไลบรารีนี้ติดตั้งและรันบน Python 3.14.2 ได้เรียบร้อย และมี release อยู่ข้างหลังแล้ว 41 รุ่น สิ่งที่ผมจะเช็กจริง ๆ คือ issue ที่เปิดอยู่ 95 รายการ — ไล่ดูว่ามีอะไรคล้าย input ของคุณหรือไม่ก่อนตัดสินใจ เพราะ repo ที่เงียบอาจหมายความว่าคนที่ต้องไปแก้คือคุณ

อะไรที่ไม่ได้ทดสอบในที่นี้? fixture สำหรับการแปลง 4 หน้า และ fixture ตารางซับซ้อนแยกต่างหากอีก 1 ชุด ยังถือว่าน้อยอยู่ การทดสอบครอบคลุมเอกสาร malformed แบบสังเคราะห์ 12 ชุด พร้อม control 2 ชุด: html2text โยน error 0/14, ไม่คืนค่าว่าง 0/14 และกู้ sentinel ที่ให้คะแนนได้ครบทั้ง 33 รายการ แต่ไม่ได้ครอบคลุมหน้าเว็บเสียหายในโลกจริง รูปแบบ malformed ที่กว้างกว่านี้ list ซ้อน definition list footnotes หรือ math พื้นผิวตัวเลือกทั้งหมด — ignore_links, ignore_images, unicode_snob, single_line_break และตัวอื่น ๆ — ยังใช้ค่าเริ่มต้นทั้งหมด ยกเว้น body_width ส่วนช่องว่างของการเก็บลิงก์พบแล้วแต่ยังไม่ได้วิเคราะห์ และไม่ได้ทดสอบการแปลง Markdown ไปกลับ