html2text Sadece 0.2 MiB ve Tek Paket. Üstelik GPL-3.0 Lisanslı.

html2text, tek bir paket olarak kurulur ve yalnızca 0.2 MiB yer kaplar — en yakın Python alternatifinden dokuz kat, Node alternatifinden ise kırk kat daha küçüktür. Dönüştürme test paketindeki dört sayfanın tamamını başarıyla geçti ve kayıtlı 16 gövde probunun hepsini korudu. Bu prob’lar, seçilen gövde metinlerinin korunup korunmadığını kontrol eder; hiyerarşi, liste iç içeliği, bağlantı hedefleri, tekrar eden içerik ya da tablo bütünlüğünü puanlamaz.

Ayrıca GPL-3.0-or-later lisansına sahiptir; bu da karşılaştırmadaki, hiçbir benchmark’ta görünmeyen ama bir kütüphaneyi tamamen elendirebilecek tek özelliktir.

html2text nedir?

html2text, HTML’i Markdown benzeri düz metne dönüştüren bir Python kütüphanesidir. Kökeni Aaron Swartz’ın ilk sürümüne dayanır ve güncel bakım hattı 2025.4.15 sürümünde devam eder — Nisan 2025 tarihli sürüm numaralı bir yayın; GitHub’da 2.168 yıldız, 95 açık sorun ve Ekim 2025’te yapılmış son bir push bulunuyor.

Resmî kaynak: html2text’in resmî deposu.

import html2text
h = html2text.HTML2Text()
h.body_width = 0          # aşağıda göreceksiniz; varsayılan değer sizi şaşırtabilir
md = h.handle(html)

pip install html2text, 1 paket ve 0.2 MiB indirir; soğuk import süresi 0.077 s’dir. Sıfır bağımlılık. Bir container imajında ya da Lambda layer’da bu, markdownify’ın 1.8 MiB’ine ve turndown’ın 8.8 MiB’ine kıyasla kayda değer bir farktır.

Her sayıyı değiştiren varsayılan değer

body_width varsayılan olarak 78’dir. html2text, siz kapatmadığınız sürece çıktının her satırını 78 karakterde otomatik sarar.

Bu, asıl görevi terminal ve e-posta için okunabilir düz metin üretmek olan bir kütüphane için makul bir varsayılandır. Ancak model besleyen ya da diff üreten işler için yanlış varsayılandır; çünkü eklenen satır sonları tokenizasyonu değiştirir, uzun bağlantıları bölerek kırar ve çıktıyı karşılaştırılamaz hale getirir.

Aşağıdaki her şey için body_width = 0 kullandım ve bunu özellikle belirtiyorum: sarma açık olsaydı, bu makaledeki tüm karakter ve token sayıları farklı olurdu. Dönüştürücüleri kendiniz benchmark ederken, sayıların sessizce kıyaslanamaz hale gelmesine neden olan ayar budur.

Ölçüm yöntemi

html2text’i, markitdown karşılaştırmasında da kullanılan, isimlendirilmiş dört sayfalık bir dönüşüm setinde çalıştırdım. Bu sette önceden kaydedilmiş prob dizeleri bulunuyor — korunması gereken seçili gövde metinleri ve sayfanın çerçeve kısmının da geçtiğini gösteren yardımcı metinler. Aynı dört dosya, aynı prob’lar, dört dönüştürücü için tek bir puanlayıcı. Prob kalımı, kayıtlı dizelerin görünmesini ölçer; yapısal doğruluğu değil. Tablo ve bağlantı sütunlarının ayrı tutulmasının sebebi de tam olarak budur.

fourway-scores.json. Dört örnek dosya, token sayımı o200k_base ile yapıldı.

Dördü arasında en küçük çıktı 76.452 karakterle html2text’e ait; token sayısında ise markdownify ve markitdown ile neredeyse başa baş — 21.176, 21.062 ve 21.336 karşısında; %1,3’lük bir farkı ben fark saymazdım.

Dört sayfalık sette markdownify ve markitdown’ın 36’sına karşılık 32 tablo satırı üretti. Bu dört satırlık fark, bir sonraki bölümde anlatılan dış boru biçimi farkından ziyade düzensiz Wikipedia örneğinde ortaya çıkıyor.

545 bağlantı ile en az bağlantıyı koruyan yine html2text. Bağlantı korunumu sizin için kritikse kendi sayfalarınızda ayrıca test etmeye değer; çünkü bu sütunda grup içinde değil, açıkça altında kalıyor.

Regex’imin göremediği tablolar

Bunu anlatmaya değer, çünkü neredeyse yanlış sonucu yayımlıyordum.

İlk tablo satırı sayacım, satırların başında ve sonunda pipe gerektiriyordu — ^\|.*\|$. Bu kurala göre html2text, beş dosya boyunca yalnızca 1 tablo satırı üretti: dört sayfalık dönüşüm seti ve ayrıca sentetik, karmaşık bir tablo örneği. Yani sayaç tabloları değil, yalnızca tek bir Markdown biçimini ölçüyordu.

Yine de tablo üretiyor. Şöyle yazıyor:

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

Dış borular yok. Bu, yaygın bir pipe-table söz dizimidir; ancak test düzeni bunu Markdown render’ları arasında doğrulamadı. Dış borulu biçimi bekleyen bir regex için görünmez kalıyor. Sayacı, içinde ayırıcı satır bulunan ve pipe içeren satır kümelerini arayacak şekilde yeniden yazınca html2text, 1 satırdan dört sayfalık sette 32 satıra ve beş dosyanın tamamında 91 satıra çıktı.

Dolayısıyla sonuç, html2text’in tablo üretmediği değil. Asıl sonuç şu: bu dört dönüştürücünün ikisi dış boru ekliyor, biri eklemiyor. Markdown’ı kendi desen eşlemenizle sonradan işliyorsanız bu önemlidir. İlk sayıya güvenseydim bunu tamamen kaçıracaktım.

Ne çıkarıyor, nerede satır kaybediyor?

Zıt yönlere işaret eden iki bulgu.

<script> ve <style> etiketlerini temizliyor. Yalnızca bu öğelerin içinde görülen işaretleyicilerle sayıldığında, html2text’in tüm örneklerdeki çıktısında sıfır script işaretleyici ve sıfır style işaretleyici var. turndown’ın çıktısında ise 10 ve 84 var — Wikipedia örneğinde MediaWiki’nin satır içi JavaScript yapılandırması ve CSS’ine ait 14.644 karakter değerinde sekiz satır (script-style-stripping.json). Model çıktısı açısından bu, o örnekte görülen en büyük gereksiz metin kaynağıydı. Aşağı yönlü bir maliyet modeli ölçülmedi.

Zor sayfada tablo satırı kaybediyor. Dört sayfalık set şu şekilde netleşiyor:

Ayrı sentetik karmaşık tablo örneği, html2text’e 59 satır ve markdownify’a 62 satır ekleyerek beş dosyalık toplamı 91 ve 98’e çıkarıyor. Bu, dört sayfalık başlık karşılaştırmasının parçası değil. Temiz hockey tablosunda ikisi birebir aynı. Wikipedia gibi iç içe ve düzensiz tablolarda ise html2text, markdownify’ın ürettiği dokuz satıra karşılık beş satır veriyor.

Özetle: basit tablolar söz konusuysa aynı; zor tablolar söz konusuysa html2text daha azını koruyor. Sayfalarınız Wikipedia’daki türde tablolar içeriyorsa, karar vermeden önce bunu test edin. İstatistik sayfalarındaki türde tablolar içeriyorsa, bu eksende birbirlerinin yerine kullanılabilirler.

Lisans

Resmî kaynak: html2text on PyPI.

Bu bilgi üç yerde doğrulandı: PyPI metadatasında, GitHub deposunda ve kurulu paketinin kendi METADATA dosyasında; bu dosyada License-Expression: GPL-3.0-or-later yazıyor.

Bunun ne anlama geldiği, yazılımın nasıl entegre edildiğine, aktarıldığına ve dağıtıldığına bağlıdır. Yalnızca dahili ya da ağ üzerinden kullanım ile paketi içeren veya onunla birleşen yazılım dağıtımı, GPL açısından genellikle farklı durumlar olarak değerlendirilir; ancak bu yazı bir hukuk analizi değildir. Yazılım dağıtan ekipler, tam entegrasyon ve dağıtım modelini hukuk müşavirine inceletmelidir.

Rahatsız edici nokta korelasyondur. En küçük ayak izine sahip kütüphane — tam da dağıtılabilir paketi küçük tutmaya çalıştığınız için seçeceğiniz seçenek — lisans açısından dağıtımı en fazla kısıtlayandır. Her iki alternatif de MIT lisanslıdır.

Avukat değilim ve bu bir hukuki tavsiye değil; sadece, en çok önem taşıması ve karşılaştırma tablosunda en az görünmesi muhtemel özellik olduğu için kaynaklarıyla birlikte aktardığım bir gerçektir.

Bakım durumu

Son yayın 2025.4.15, son depo push’u Ekim 2025 — teste göre yaklaşık on ay önce, arkada 41 sürüm bırakmış durumda. requires_python >= 3.9 ve Python 3.14.2 üzerinde temiz biçimde kurulup çalıştı.

Bu, markdownify’a göre daha sakin bir tempo (testten altı hafta önceki son sürüm) ve turndown’a göre de daha eski (dört ay); yine de ortada bırakılmış bir proje olmaktan ziyade istikrarlı görünen bir tablo var. HTML’den metne dönüşüm, çok sık değişmeyen bir problem; bu yüzden on aylık boşluk terk edilmişlikten çok olgunluk gibi okunuyor. Yine de 95 açık sorun, gözden geçirilmeye en çok değer veren sinyal; kendi kullanım senaryonuza benzeyen bir şey var mı diye bakmaya değer.

Bellek ve bozuk HTML’nin etkisi

Burada iki operasyonel soru ayrı ayrı ölçülüyor.

Daha geniş stres testi bağlamı için on kütüphanelik bellek ve bozuk HTML karşılaştırmasına bakın.

Zirve çalışan bellek kullanımı, /usr/bin/time -l ile, her hücre için yeni bir süreç üzerinden ölçüldü — import tabanı, kütüphanenin yüklenmiş ve boşta iken maliyetini; tepe değerler ise belgeyi de kapsar.

memory-results.json. Python ve Node tabanları birbirleriyle karşılaştırılabilir değildir; yorumlayıcı her ikisinin de içindedir.

Burada iki ölçekte de en hafif giriş html2text. 18.7 MiB’lik import tabanı ve 10 MB’lik örnekte 71.2 MiB tepe değeri, 52.5 MiB’lik artı RSS verir: (71.2 - 18.7) / 10 = 5.25× örnek boyutu. Tablodaki mutlak ve artımsal satırlarla karşılaştırırken, belirtilen Python/Node taban uyarısını akılda tutun.

Bozuk HTML. Her biri tek bir şeyi bozan on iki belge — kapatılmamış etiketler, yanlış iç içe geçmiş satır içi öğeler, içinde boşluk olan tırnaksız öznitelikler, fazladan kapanışlar, hiç <html> olmaması, yinelenen öznitelikler, ortasında kesilmiş bir belge, hatalı entity’ler, kapatılmamış bir <script>, yanıltıcı bir charset bildirimi, içinde markup bulunan bir yorum ve 600 katmanlı iç içelik — ayrıca eş boyutlarda iki düzgün örnek, çünkü “hiç çıktı vermedi” ifadesi, kütüphane aynı boyutta temiz bir belgede de susuyorsa bozukluk hakkında hiçbir şey söylemez.

html2text 14’ün 0’ında hata verdi ve 0 kez boş döndü; bozuk örneklerdeki 33 işaretleyicinin tamamını kurtardı (malformed-results.json). Bu sayımdan bir örnek hariç tutuldu: HTML5’e göre kapatılmamış bir <script> sonrasındaki her şey script içeriği sayılır; bu durumda onu kaybetmek doğrudur, geri almak ise sapma olur.

Artılar ve eksiler

Lehine. Tek paket, 0.2 MiB, sıfır bağımlılık — karşılaştırmadaki açık ara en küçük seçenek. Dördü arasında en küçük çıktı ve token sayısında markdownify ile markitdown’a neredeyse eşit. Tanınabilir pipe-table sözdizimi üretiyor. Python 3.14’te çalışıyor. Köklü ve istikrarlı bir geçmişi var.

Aleyhine. GPL-3.0-or-later; alternatiflerde bu yok. Varsayılan body_width=78; bu, çıktıyı zorla sarıyor ve devre dışı bırakılmazsa ölçümleri ya da diff’leri değiştiriyor. Korunan bağlantı sayısı en az (545; diğerleri 598–611). Tablolar dış boru olmadan yazılıyor; bu da kaba downstream regex’leri bozuyor. 95 açık sorun ve markdownify’a kıyasla daha yavaş bir sürüm temposu var.

Kim kullanmalı, kim kullanmamalı?

html2text’i kullanın eğer bağımlılık bütçesi gerçekten çok kısıtlıysa ve planlanan entegrasyon ile dağıtım modeli lisans incelemesinden geçtiyse. Sıfır bağımlılıkla tek paket olması, operasyonel açıdan gerçek bir avantajdır: denetlenecek ve dağıtılacak daha küçük bir bağımlılık yüzeyi.

İlk satırda body_width = 0 ayarlayın — özellikle sarılmış düz metin istemiyorsanız.

Atlayın eğer yazılım dağıtıyorsanız ve copyleft sizin için sorun teşkil ediyorsa — markdownify MIT lisanslıdır, burada token sayısında onunla beraberdir ve markitdown’la tablolarda eşleşir; üstelik yalnızca 1.6 MiB daha fazla disk kullanır. Bağlantı korunumu sizin için önemliyse de atlayın, çünkü en az bağlantıyı korudu. Ve aşağı yönlü araçlarınız tablo satırlarında dış boru bekliyorsa yine atlayın.

Yönetilen bir API nerede devreye girer?

html2text, elinizde zaten bulunan HTML’i dönüştürür. JavaScript çalıştırmaz, sayfayı yüklemez ve anti-bot katmanını aşmaz — dört dönüştürücünün hiçbiri bunu yapmaz; birçok gerçek hedefte işin zor yarısı da zaten budur.

Tüm beş dönüştürücü için aynı örnekleri görmek isterseniz, beş yönlü HTML’den Markdown’a karşılaştırmaya bakın.

Kendi Thunderbit hizmetimiz de dahil olmak üzere barındırılan bir fetch/render/extraction hizmeti, farklı bir katmanda çalışır. Thunderbit burada benchmark edilmedi. Buradaki ayrım, size verilmiş HTML’i dönüştürmek ile bir URL’yi alıp işleyen bir hizmet arasındadır; bu yazı aynı ölçekte kalite, gecikme ya da maliyet karşılaştırması sunmaz.

Adil özet şu: HTML sizdeyse, Markdown istiyorsanız ve GPL dağıtım şekliniz için sorun değilse html2text ücretsiz ve olağanüstü küçüktür. Sayfaları çekmeniz gerekiyorsa ya da düz metin yerine satırlar istiyorsanız, bu başka bir üründür.

Daha geniş alan için, web scraping API derlememiz barındırılan seçenekleri; açık kaynak scraper rehberimiz ise kendi kendine barındırılan alternatifleri kapsıyor. Python’da HTML’i Markdown’a dönüştürme yazısı da pratik bir uygulama rehberidir.

Web Veri Çıkarma için Thunderbit’i Deneyin

html2text kullanılmalı mı?

Ayak izi önemliyse, sarma bilinçli olarak kapatılıyorsa ve dağıtım modeli lisans incelemesinden geçiyorsa güçlü bir adaydır.

Dört sayfalık sette token sayısı markdownify ve markitdown’a göre %1,3 içinde kaldı. Bu, genel kalite eşit demek değildir: html2text daha az bağlantı ve düzensiz Wikipedia örneğinde daha az satır korudu. İki operasyonel ayrıntı hemen önem kazanıyor: body_width = 0 ve dış borusuz tablo stili.

Eğer GPL incelemesi onu elerse, markdownify MIT lisanslıdır; burada benzer çıktı boyutuna ve token sayısına sahipti, daha fazla bağlantı ve düzensiz tablo satırı korudu, ayrıca bu ortamda 1.6 MiB daha fazla disk kullandı.

Web Veri Çıkarma için Thunderbit’i Deneyin Get Started Free

SSS

html2text tablo dönüştürüyor mu? Evet. İlk sayacım, beş dosya boyunca tek bir tablo satırı ürettiğini söyledi ama bu sayaç yanlıştı — satırların başında ve sonunda pipe istiyordu, oysa html2text Team Name | Year | Wins biçiminde bunlar olmadan yazıyor. Bu, yaygın bir pipe-table Markdown’ıdır; ancak bu test düzeneği farklı render’lar arasında uyumluluk testi yapmadı. Düzeltilmiş sayaca göre html2text, dört sayfalık sette markdownify’ın 36 satırına karşı 32 satır; ayrı karmaşık tablo örneği eklendiğinde ise 98’e karşı 91 satır üretti.

body_width ne yapar, neden değiştirilir? Varsayılan olarak çıktıyı 78 karakterde zorla sarar; terminalde okunabilir düz metin için mantıklı, diğer her şey için zayıf bir seçimdir. Sarma, cümle ortasında satır sonları ekler, uzun URL’leri böler ve tokenizasyonu değiştirir. Bu incelemedeki her sayı body_width = 0 ile alındı; varsayılanla hepsi farklı olurdu.

GPL lisansı gerçekten kısıtlayıcı mı? Bu, tam entegrasyon ve dağıtım modeline bağlıdır. Dahili kullanım, yalnızca ağ üzerinden kullanım ve yazılımı dağıtma senaryoları farklı değerlendirme alanlarıdır; ancak bu yazı bunların hukuki sonucunu belirlemez. Yazılım dağıtan ekipler, GPL-3.0-or-later şartlarını hukuk müşavirine inceletmelidir; markdownify ve turndown MIT lisanslıdır. html2text’in lisans ifadesi PyPI metadatasında, GitHub’da ve kurulu paketin METADATA dosyasında doğrulanmıştır.

Nisan 2025 tarihli bir sürüm sorun mu? Tek başına muhtemelen değil. HTML’den metne dönüşüm olgun bir problemdir; kütüphane Python 3.14.2 üzerinde temiz biçimde kuruldu ve çalıştı, ayrıca arkasında 41 sürüm var. Benim asıl kontrol edeceğim sayı 95 açık sorudur — kendi girdinize benzeyen bir şey var mı diye bunlara bakın, çünkü sessiz bir depo, sonunda sorunu sizin çözeceğiniz anlamına gelebilir.

Burada ne test edilmedi? Dört dönüşüm örneği ve ayrı bir karmaşık tablo örneği hâlâ küçük bir test setidir. Test, on iki sentetik bozuk belgeyi ve iki kontrolü kapsadı: html2text 14/14’te hata vermedi, 14/14’te boş dönmedi ve puanlanan 33 işaretleyicinin hepsini kurtardı. Gerçek dünyadaki hasarlı sayfalar, daha geniş bozukluk desenleri, iç içe listeler, tanım listeleri, dipnotlar veya matematik içerikleri kapsanmadı. ignore_links, ignore_images, unicode_snob, single_line_break ve diğer tüm seçenekler, body_width hariç varsayılanlarda bırakıldı. Bağlantı farkı gözlendi ama nedeni araştırılmadı; Markdown round-trip testi yapılmadı.