Apache Tika İncelemesi: Dosya Adına Değil Baytlara Bakar — Markdown’la Karşılaşana Kadar

Apache Tika, Apache Software Foundation’ın belge ayrıştırma aracıdır: Neredeyse her türden bir dosyayı verirsiniz, size düz metin ve normalize edilmiş bir metadata sözlüğü döndürür. proje README’si binin üzerinde desteklenen dosya türü sunduğunu iddia ediyor; Tika bunu, uzman kütüphaneleri kendi içine paketleyerek başarıyor — PDF’ler için PDFBox, Office belgeleri için Apache POI, HTML için jsoup, ODT için bir ODF okuyucu — böylece parse anında dışarıdan bir şey çekmeden tek bir şişkin jar olarak dağıtılıyor. Bir veri hattında genelde parıltısız ama kritik ilk adımdır: bir arama indeksinin, e-discovery inceleme setinin ya da bir LLM korpusunun önünde durur ve heterojen bir dosya yığınını tek biçimli hale getirir. Aslında iki iş yapar: bayt akışının ne olduğunu anlamak ve ardından metin ile metadata’yı dışarı çıkarmak.

Uzun zamandır kurduğum en zahmetsiz araçlardan biri. Tek jar, java -jar tika-app-3.3.2.jar --text file.pdf, konfigürasyon yok, model ağırlığı yok, kurulum sonrası ek adım yok; üstelik aynı gün aynı makinede diğer Java araçlarını durduran en güncel JDK üzerinde de sorunsuz çalıştı. Yine de katalog iddiasını test etmek istemedim; asıl test edilebilir soru daha dar: Girdi sizi yanıltıyorsa, Tika gerçekte ne yapıyor? Bunun için her blokta benzersiz bir işaretleyici token taşıyan kontrollü bir fixture seti hazırladım, aynı mantıksal belgeyi dokuz farklı taşıyıcı formata dönüştürdüm, ardından tümünü yanlış uzantılarla, eksik uzantılarla, hiç dosya adı olmadan, sıfır baytlık dosyalarla ve yarım yazılmış ikililerle sınadım.

İlginç davranışın olduğu yer tespittir. Bir PDF’i .txt olarak yeniden adlandırıp Tika’ya ne olduğunu sordum; application/pdf dedi. Sonra dosya adını tamamen sildim, ham baytları stdin üzerinden verdim, yine aynı yanıtı aldım. Setimdeki içerik ile tespit edilebilen beş formatın tamamında, bu durum 20 benzersiz mantıksal koşulun hepsinde geçerliydi: her format için üç dosya adı koşulu ve bir de dosya adı olmayan akış koşulu. Harness, akış senaryosunu farklı etiketlerle üç kez çalıştırdı ve 30 başarılı ham çalıştırma üretti; ancak bu tekrarlar birbirinden bağımsız kanıt sayılmaz. PDF ve RTF tanınabilir baytlar sunar; DOCX kendi kapsayıcısıyla tanınır; HTML ve XML markup ya da kök içerikten ayırt edilebilir. Farklı mekanizmalar, aynı faydalı sonuç: bu fixture setinde uzantı içeriği geçersiz kılamadı. Sonra metin ailesi rejimi geliyor; burada Markdown, dosya adı yanlış ya da yok olur olmaz text/plain’e düşüyor. Bu testte kimliği tamamen .md uzantısına bağlıydı.

Bundan sonra gelecek her sayı için iki sınır notu. Apache Tika 3.3.2 sürümünü test ettim — 27 Temmuz 2026’da kontrol ettiğimde hâlâ en güncel kararlı sürüm buydu; 4.0.0 hattı Maven Central’da yalnızca alpha ve beta derlemeleri olarak vardı. Proje yine 27 Temmuz 2026’da yaklaşık 3,9 bin GitHub yıldızına sahipti ve Apache-2.0 lisansı kullanıyordu; yani ticari açıdan lisans tarafında neredeyse hiç sürtünme yok. Ve OCR’yi hiç test etmedim. Tek bir taranmış sayfa bile yok, görüntü tabanlı tek bir PDF bile yok. Bu makinede Tesseract ve poppler kurulu değildi; bu yüzden OCR yollarının tamamı daha başlamadan engellendi. Burada OCR sayısı yok çünkü OCR sayısı yok, nokta.

Kutunun üzerindeki pazarlamayı okumayı bıraktığınızda Tika gerçekte nedir?

Yaygın varsayım, Apache Tika’nın bir belge dönüştürücü olduğu yönündedir — bir DOCX verirsiniz, karşılığında başlıkları ve tabloları bozulmadan kalmış temiz Markdown alırsınız. Oysa bu değildir; bunu erken fark etmek aracı daha iyi gösterir.

Burada test edilen yolun üç ilgili aşaması var: bir içerik türü algılayıcı, baytları doğru ayrıştırıcıya veren bir yönlendirici, ve CLI’nin --text çıktı işleyicisi; bu işleyici, ayrı olarak erişilebilen metadata ile birlikte düz metin üretir. Bu çıktı sözleşmesinde Title nesneleri, ListItem’lar ya da yeniden oluşturulmuş bir tablo ızgarası yoktur. Tika başka işleyiciler ve API’ler de sunar; XHTML/SAX odaklı çıktı da bunlardan biridir. Bunları test etmedim. Dolayısıyla aşağıdaki tüm yapı sonuçları tika-app --text hakkındadır; aracın hiçbir yerinde yapılandırılmış olay akışı olmadığını iddia etmiyorum.

Bu bir sınırlama gibi duruyor ve tek bir açıdan öyle de. Ama aynı zamanda Tika’nın yanlış sınıflandırabileceği bir şey bırakmaması anlamına gelir; daha gürültülü rakiplerinin diğer yönde yaptığı takas tam da budur.

Algılama kendisi belgelenmiş bir sırayla çalışır: önce imza baytları, sonra XML kök denetimi, ardından dosya adı kalıbı, son olarak da sizin verdiğiniz tür (Tika’nın kendi algılama dokümantasyonu bunu açıklar). Tür çözülünceye kadar yönlendirici baytları uygun gömülü ayrıştırıcıya gönderir — PDFBox, POI, jsoup, metin ailesi için TextAndCSVParser.

Bu algılama-sonra-ayrıştırma ayrımı iç işleyişe dair önemsiz bir ayrıntı değildir. Bu sayede ayrıştırılamayacak kadar bozuk bir dosya yine de doğru tür olarak tanınabilir; işler bozulmaya başladığında Tika’nın sunduğu en pratik numara da budur.

Kurulum: tek jar, tek komut ve nazlı olmayan bir JVM

Kurulum bir indirmeden ibaret. Maven Central’daki tika-app-3.3.2.jar yaklaşık 67 MB — tüm ayrıştırıcıları içeren şişkin bir jar — ve sonrasında java -jar tika-app-3.3.2.jar --text file.pdf komutunu çalıştırıyorsunuz. Konfigürasyon yok, model ağırlığı yok, kurulum sonrası adım yok, brew install zinciri yok.

JDK tarafı beni şaşırttı. Tüm denemeyi OpenJDK 26.0.1 üzerinde, en güncel LTS olmayan derleme ile yaptım; --version, --text, --metadata ve --detect komutlarının hepsi uyumluluk şikâyeti olmadan exit 0 döndü. Bunu özellikle söylemeye değer; çünkü aynı gün aynı makinede Apache Nutch’i de test ettim ve onun tarama döngüsü JDK 26 üzerinde hiç çalışmadı — yeni JDK’lerde SecurityManager kaldırıldığı için 21 veya altı bir LTS istiyor. Tika umursamadı. JVM araçlarından sırf bu tür bir acı yüzünden kaçınıyorsanız, Tika sizi orada vurmaz.

Kurulum tarafında iki dürüst not. CLI her çağrıda yeni bir JVM başlatıyor; yani soğuk başlangıç gerçek — harness’ım için 131 çağrı yaklaşık bir dakika sürdü, bunun çoğu JVM ısınmasıydı. Dosyaları yüksek hacimde işliyorsanız, jar üzerinde kabuk döngüsü yerine kütüphane ya da sunucu modunu tercih edersiniz. Ve “bağımlılıksız” hikâyesinin sert bir sınırı var: PDF metin katmanı çıkarımı için dışarıdan hiçbir şey gerekmez, fakat OCR için tesseract ve poppler gerekir. Metin katmanlı PDF’ler, DOCX, ODT, RTF, HTML, XML, TXT, Markdown ve CSV, bu ikisi kurulu olmayan bir makinede sorunsuz ayrıştırıldı. Taranmış belgeler ise ayrışmazdı; bunu iddia etmeye de çalışmadım.

Bu karşıtlık, aynı gün test ettiğim kardeş kütüphane unstructured ile daha da belirginleşti; onun elektronik PDF yolu, PDF modülünü içe aktarmak yükleme anında çıkarım yığınını (torch ve benzerleri) getirdiği için tamamen engellendi — strateji dağıtımından önce, yani “hızlı” strateji bile bunu içe aktarmadan çalışmıyor. Tika aynı PDF’in metin katmanını düz bir java -jar ile ayrıştırdı.

Yalan uzantı testi: dosyaya ne ad verdiğinizi umursamayan mime türü tespiti

Sekiz format; her biri doğru uzantıyla, kasıtlı olarak yanlış uzantıyla ya da uzantısız sunuldu; buna ek olarak stdin üzerinden dosya adı olmayan bir bayt akışı da var. Bu 32 benzersiz mantıksal koşul demek. Orijinal harness aynı akış baytlarını her dosya adı etiketi altında bir kez daha çalıştırdı; böylece 48 ham yürütme oluştu. Ancak dosya adı olmadığında stdin tarafında okunacak bir ad olmadığı için bu üç akış satırı tek bir koşula indirgenir.

(Akış sütunu tüm üç uzantı koşulunu birleştirir; çünkü dosya adı yoksa kalıbın okuyacağı bir şey de yoktur.)

İçerik ile tespit edilebilen beş format — PDF, DOCX, RTF, HTML ve XML — 20’de 20 benzersiz koşulda gerçek türlerine ulaştı (ve tekrar edilen akış çalıştırmaları da dahil edilirse 30’da 30 ham harness yürütmesinde). report.txt adı verilen bir PDF yine PDF olarak kaldı. photo.jpg adı verilen bir DOCX yine DOCX olarak kaldı. Bunun için dosya adına ihtiyaç duymadılar. Bu, beşinin de sabit bayt imzaları kullandığı anlamına gelmez: PDF ve RTF tanınabilir başlıklara sahiptir, DOCX ZIP tabanlı bir kapsayıcıdır, HTML ve XML ise markup ya da kök içerikten ayırt edilir. Bu fixture setinde yalan uzantı kazanmadı.

Sonra metin ailesi rejimi. Markdown, yalnızca .md uzantısı mevcut ve okunabilir olduğunda text/markdown olarak çözüldü. Uzantıyı değiştirin, kaldırın ya da akış olarak gönderin; bu testte text/plain’e düştü. CSV de bu özellikle küçük ızgarada aynı davrandı: text/csv yalnızca .csv kalıbından geldi. Benzersiz koşulları sayarsak, Markdown ve CSV dört koşulun birinde kendi türlerine çözüldü; düz metin zaten text/plain idi, yani “çökecek” bir şey yoktu. Ham 48 çalıştırmalı harness ise tekrar edilebilirlik kaydı olarak yararlı kalır, ama daha büyük bir payda oluşturmaz.

Burada Tika lehine bir ayrıntı var: yalan uzantı da kazanamıyor. Markdown fixture’ım .pdf olarak yeniden adlandırıldığında application/pdf değil, text/plain döndü. Tika yalana inanmadı; sadece gerçeği doğrulayamamış oldu. Üst türe düşmek, yanlış bir şeyi güvenle iddia etmekten çok daha iyi bir başarısızlıktır ve text/markdown’un belgelenmiş bir text/plain alt türü olması bu geri dönüşü rastgele değil, ilkesel hale getirir.

CSV konusunda bir not düşmek gerekir. Tika’nın istatistiksel bir CSV algılayıcısı var ve ayrıştırma sırasında — X-TIKA:Parsed-By zincirinde TextAndCSVParser göründüğü için doğrulandı — benim küçük 2 sütun × 3 satırlık ızgaram text/csv yerine text/plain olarak çözüldü. Bu, bilerek minimal tutulmuş bir fixture üzerinde tek bir gözlemdir. Daha büyük ya da tırnaklı bir CSV algılayıcıyı tetikleyebilir. CSV içerik tespitinin bozuk olduğunu söylemiyorum; bu ızgarada text/csv sonucunu uzantının ürettiğini söylüyorum.

Bunun gerçek bir yükleme hattında önemi ne

Somut senaryo bir upload yönlendiricisidir. Diyelim ki kullanıcı yüklemelerini kabul ediyor ve onları türe göre ayırıyorsunuz: PDF’ler fatura ayrıştırıcısına, elektronik tablolar defter içe aktarıcısına, geri kalan her şey metin indeksine. Uzantıya güvenirsiniz, notes.txt adıyla yüklenen bir PDF yanlış dala gider — bu zararsız senaryodur; düşmanca versiyon ise dostça uzantıya sahip bir polyglot dosyadır.

Burada test edilen ikili ve işaretleme fixture’larında Tika, dosya adı ortadan kalksa bile içeriğe göre yönlendirme yaptı; bu, bir blob deposu ya da HTTP body işleyicisi dosya adını düşürdüğünde çok işe yarar. Ancak bu sonuç Tika’nın uzun kuyruk tiplerini, belirsiz dosyalarını ya da polyglot’larını kapsamaz. Test edilen metin ailesi fixture’ları farklı davrandı: hat borusu dosya adlarını kaldırdığında Markdown ve CSV text/plain olarak geldi; dolayısıyla onların özel medya türlerine bağlı kurallar çalışmayı bıraktı. İçeriğin dosya adını yeniden üretmesini beklemek yerine, özgün adı yan metadata olarak saklayın.

Gömülen içerik hayatta kaldı. --text yapıyı düzleştirdi.

İkinci eksen sadakattir ve ikiye ayrılır. Bir kanonik belgeyi (başlıklar, iki gövde paragrafı, madde işaretli liste, numaralı liste, kapanış paragrafı) HTML, Markdown, düz metin, DOCX, PDF, RTF, ODT ve XML’e; ayrıca bir tablo belgesini HTML, Markdown, metin, DOCX, CSV ve XML’e dönüştürdüm. Toplam on dört taşıyıcı işleme. Her blok benzersiz bir token taşıyor — zztitle1, zzitem3, zztblcell_beta gibi — dolayısıyla “hayatta kaldı” ile “kayboldu” ayrımı tam bir alt dize kontrolü; yoruma açık değil.

İşaretleyici token geri çağırımı, on dört işleme tamamında 1.000 çıktı. Yerleştirilen tek bir token bile kaybolmadı: etiketlenmiş her tablo hücresi, liste öğesi ve başlık oradaydı. Isınma sonrası taşıyıcı başına yapılan üç yerel tekrar, byte-identical --text çıktısı verdi. Bu ölçüm, etiketlenmemiş karakterler, sıralama, boşluk, Unicode normalizasyonu, tekrar eden içerik, bağlantılar, başlıklar, dipnotlar veya gömülü nesneler hakkında hiçbir şey söylemez. Bu bir blok varlık kontrolüdür; eksiksiz belge sadakatinin kanıtı değil.

Düz metin çıktısı kaynak yapının çoğunu feda eder.

İşte HTML tablo belgesinin --text çıktısı:

	Araç	Verim

	zztblcell_alpha	120

	zztblcell_beta	95

Sekmeyle birleştirilmiş satırlar. Başlık satırı başlık olarak işaretlenmemiştir. Izgara yok, sekmeden başka hücre sınırı yok, bunun hiç <table> olduğunu anlamanın bir yolu yok. DOCX tablosu da aynı şekilde düzleşir.

Listeler daha inceliklidir ve kaynakta gerçekten ne olduğuna göre ayrılır:

Tika, metin olarak almadığı bir işaretçiyi asla yeniden biçimlendirmez. Aynı içerik, farklı görünen çıktı.

Markdown örneği bunu çok net gösterir. Tika’ya bir pipe tablo içeren .md dosyası verin; pipe karakterleri aynen geri gelir, bu da yapı korunuyormuş gibi görünür. Oysa korunmaz. Tika onu metin olarak ayrıştırmış ve baytları geri vermiştir. O tabloyu anlayan hiçbir şey yoktur.

Dolayısıyla ölçülen sözleşme daha dardır: yerleştirilen tüm işaretleyiciler hayatta kaldı, ama --text yazılan öğeleri ya da yeniden oluşturulabilir bir tablo ızgarasını korumadı. Buna ayrıştırıcı kusuru demek noktayı kaçırmak olur. Düz çıkarım, öğe sınıflandırma sorunundan bilerek kaçar; ama aynı zamanda bu öğe türlerine ihtiyaç duyan bir aşağı akış tüketicisini de tatmin edemez. Etiketli bloklara ya da yeniden oluşturulmuş tablolara ihtiyacınız varsa, --text yığının bir parçasıdır, yığının kendisi değil. Diğer Tika işleyicileri daha fazla yapı sunabilir, ama bu çalışmanın dışında kaldılar.

Buradaki her sadakat sayısı için standart uyarı: kontrollü sentetik fixture’lardan, tek bir makinede ve tek bir sürümde geliyorlar. Etiketli blokların çıktıda bulunduğunu gösterirler. Karakter karakter koruma ya da gerçek dünyadaki karmaşık bir korpusta doğruluk kanıtlamazlar.

Metadata: normalize edilmiş ve uydurma yapmaya gönülsüz

Yazar, başlık ve oluşturulma tarihi gibi bilinen değerleri metadata katmanı olan her taşıyıcıya gömdüm, sonra ne döndüğüne baktım.

Yazar ve başlık, metadata taşıyan 4’te 4 taşıyıcıda geri kazanıldı ve — burada değerli olan kısım bu — normalize edilmiş durumda geldiler. Bir HTML <meta name="author">, bir DOCX çekirdek özelliği, bir PDF /Author girdisi ve bir ODT dc:creator öğesi aynı dc:creator anahtarı altında birleşiyor. Dört farklı tüketici yazmıyorsunuz; tek bir tüketici yazıyorsunuz.

created ise dürüst dalgalanmadır. DOCX ve ODT, gömdüğüm tam 2021 zaman damgasını döndürdü. PDF bir oluşturulma tarihi döndürdü; ancak bu, gömmek istediğim değer değil, üretici kütüphanenin derleme sırasında damgaladığı tarihti — bu yüzden onu geri kazanılmış değil, mevcut olarak puanlıyorum. Metadata katmanı olmayan formatlar ise hiçbir şey göstermedi; bu da doğru cevap. Tika, metin gövdesinden yazar uydurmaz.

Kasten bozmak ve bunun içinden çıkan triage hilesi

Dört düşmanca girdi. Sıfır baytlık dosya. Gövdesi kesilmiş geçerli bir PDF başlığı. Bölünmüş bir DOCX ZIP’i. Ve BOM ya da encoding bildirimi olmayan, çok baytlı karakterler taşıyan bir UTF-8 dosyası. Bunlar Tika eşiği değil, yerel fixture şekilleridir.

Bu taslakta bağlantılandırılmayan temel harness, üretilmiş fixture’lar, ham JSON, jar checksum’u ve ortam manifesti bulunmuyor. Dışarıdan biri bu yüzden tam paydaları bağımsız olarak henüz yeniden üretemez. Tabloları raporlanan gözlemler olarak değerlendirin; yayına geçmeden önce bu sayıların üçüncü taraf kanıt olarak kullanılabilmesi için sabit bir paket eklenmelidir.

Çıkarma başarısız olduğunda bunu yüksek sesle yapıyor ve bu hatalar aynı dış forma sahip. Sıfır baytlık dosya, kesilmiş PDF ve kesilmiş DOCX’in her biri istisna, exit 1 ve boş stdout üretti. CLI, hatayı tertemiz boş bir sonuca dönüştürmüyor. Bu durumlarda işlem açısından güvenli — takılma yok, segfault yok — ama çağıranın yalnızca boş dizeye bakmak yerine exit durumunu ve stderr’i kontrol etmesi gerekir.

Algılama, ayrıştırmadan bağımsız çalışıyor. Her iki kesilmiş ikilide de --detect, sağlam kalan başlangıç içeriğinden beklenen türü vererek exit 0 döndürdü; ardından ayrıştırıcı bozuk gövdede başarısız oldu. Bir hatadan önce ya da sonra bir pipeline, algılamayı ayrı bir triage sinyali olarak kullanabilir. Detect-first’in iyi bir varsayılan olup olmadığı dağıtım moduna bağlıdır: bu test detect-first’i parse-only ile benchmark etmedi ve iki taze CLI JVM’i hacimde yanlış takas olabilir.

Karakter kodlaması algılanıyor. BOM’suz ve bildirimsiz UTF-8 dosyası UTF-8 olarak çözüldü ve 日本語テスト olduğu gibi geçti. Metadata sözlüklerine bakanlar için küçük bir not: saf ASCII fixture’larım charset=ISO-8859-1 raporluyor; bu, ASCII baytlarında UTF-8’den ayırt edilemez. Bu bir hata değil, beraberlik.

Tika ve unstructured yan yana: aynı dosya türleri, farklı işler

İkisi de aynı araştırma oturumunda çalıştırıldı; ancak bu bir çıktı sözleşmeleri taksonomisi, simetrik bir benchmark değil. Araçlar farklı sonuçlar üzerinden puanlandı.

İlgili inceleme: Unstructured incelemesi.

İşaretleyiciyi koruyan düz çıktı ile gözlenen sınıflandırma hataları olan yazılı öğeler. Aşağı akış tüketicisinin neye ihtiyaç duyduğuna göre seçim yapın. Bir arama indeksi ya da bir LLM bağlam penceresi ise, düz metin yeterli olabilir. Eğer öğe türüne göre anahtar alıyorsa, Tika’nın --text yolu bu sözleşmeyi sağlayamaz.

İkimizde de taranmış belge sayısı yok.

Artılar ve eksiler

Artılar

• İçerik türü tespiti, beş içerik ile tespit edilebilen fixture boyunca yalan dosya adlarını 20/20 benzersiz koşulda yok saydı; tekrar eden akış çalıştırmaları da aynı fikirdeydi.
• Etiketli tablo hücreleri ve liste öğeleri dahil olmak üzere, on dört taşıyıcı işlemenin hepsinde yerleştirilen tüm işaretleyiciler hayatta kaldı.
• Üç yerel tekrar ile tekrar üretilebilir: bu ortamda her taşıyıcı byte-identical metin döndürdü.
• Formatlar arasında normalize edilmiş metadata — kaynak formattan bağımsız olarak dc:creator / dc:title / dcterms:created, metadata taşıyan 4/4 taşıyıcıda geri kazanıldı.
• Test ettiğim formatlar için gerçekten bağımlılıksız: PDF metin katmanı, DOCX, ODT, RTF, HTML tek bir jar ile ve dış ikililer olmadan ayrıştırılıyor.
• OpenJDK 26 üzerinde temiz çalışıyor — yalnızca LTS zorunluluğu yok.
• Ayrıştırma başarısız olduğunda bile algılama doğru kalıyor (exit 0), bu da size güvenilir bir triage sinyali veriyor.
• Apache-2.0, olgun, aktif olarak bakımı yapılan bir proje.

Eksiler

• Markdown ve CSV kimliği tamamen dosya adına bağlı; imzasız 18 hücreden 10’u dosya adı kaybolduğunda ya da yanlış olduğunda text/plain’e düştü.
• --text öğe türlerini döndürmüyor; tablo ızgaraları sekmeyle birleştirilmiş satırlara düzleşiyor ve yapısal liste işaretleri kayboluyor.
• Çıkarma, boş ve bozuk girdilerde yakalanmamış hata fırlatıyor; yalnızca çıkarma çağrısına bakıldığında iki durum aynı görünüyor.
• CLI modunda 67 MB jar ve her çağrıda JVM soğuk başlangıcı.
• OCR ve taranmış görüntü PDF’leri burada tamamen test edilmedi — tesseract ve poppler yoktu, bu yüzden o yol hakkında hiçbir iddia yok.
• Buradaki her sayı tek bir makinede, tek bir sürümde sentetik ground truth. Gerçek korpus doğruluğu, şifreli dosyalar, gömülü/özyinelemeli belgeler ve ölçekteki performans ölçülmedi.

Kim kullanmalı, kim kullanmamalı

Tika, girdiğiniz şey zaten elinizde olan dosyalar ve çıktı ihtiyacınız bir makinenin indeksleyebileceği metin artı metadata ise uygundur. Arama indeksleme, e-discovery, arşiv işleme, bir korpusu LLM’e besleme, bir upload hattının içerik türü doğrulama katmanını kurma. Test edilen türleri algılayan, düz metni çıkaran ve hattınızın kaybetmeyi göze alamadığı içerikler için açık kontrollerle bunu bir sonraki adıma ileten daha akıllı bir sistemin önünde ilk aşama triage ve normalizasyon adımı olarak faydalıdır.

Şunu atlayın — ya da daha doğrusu --text’te durmayın — eğer yazılan öğelere, yeniden oluşturulmuş tablolara ya da belge yerleşimine ihtiyacınız varsa. Belgeleriniz taranmışsa da atlayın; en azından tesseract kurup kendi sayılarınızı çıkarana kadar, çünkü benim elimde yok. Yüksek hacim için, kütüphane ya da sunucu modunu CLI’ye karşı temsilî belgelerde benchmark edin. Bu küçük dosya harness’inde süreç başlangıcı görünür durumdaydı, fakat throughput ve kaynak maliyeti ölçülmedi.

İnsanların gözden kaçırdığı nokta şu: depolama katmanınız dosya adlarını siliyorsa ve Markdown ya da CSV işliyorsanız, Tika’nın bunları düz metinden ayırmasını beklemeyin. Orijinal adı saklayın.

Alternatifler ve Thunderbit’in konumu

Önce dürüst çerçeve: Buradaki doğru karşılaştırma girdiler üzerinedir, kalite değil. Tika, dosyaları ayrıştırmak için ücretsiz, Apache-2.0 lisanslı, kendi üzerinde barındırılan bir araçtır. Diskinizde ya da bucket’ınızda duran dosyalar. Sayfa çekmez, JavaScript çalıştırmaz, bot korumasıyla uğraşmaz ve bunu iddia etmez.

İşte yönetilen bir web çıkarım hizmetinin — kendi Thunderbit ürünümüz de dahil — mimariye girebileceği sınır burasıdır: canlı sayfaları çeker, Tika ise zaten sahip olduğunuz dosyaları ayrıştırır. Bu makale bu hizmetleri Tika’ya karşı benchmark etmedi ve aynı giriş için birbirinin yerine geçmezler.

Temiz ayrım şu: Tika, zaten elinizde olan belgeler için; yönetilen bir çıkarım API’si, gidip almanız gereken web sayfaları için. Pek çok hat ikisini birden kullanır — web tarafında crawl ve extraction, geri dönen PDF ve DOCX eklerinde Tika.

Daha geniş açık kaynak alanını karşılaştırıyorsanız, tam açık kaynak scraper karşılaştırmasını, GitHub’daki en kullanışlı scraping projeleri derlemesini, tarayıcı destekli Markdown yaklaşımını ele alan uygulamalı bir Crawl4AI incelemesini ve daha geniş bir scraping araçları özetini yazdım. No-code yol için, bir siteyi AI kullanarak nasıl scrape edeceğinize dair bir rehber de var.

Web Veri Çıkarımı için Thunderbit’i Deneyin

Karar

Apache Tika’yı kullanmalı mısınız? Evet, işiniz heterojen dosyaları düz metin ve normalize metadata’ya çevirmekse ve kendi hattınızın kaybetmeyi göze alamayacağı alanları ya da işaretleyicileri doğruluyorsanız.

Bu çalışmada en güçlü taraf algılayıcıydı. Beş içerik ile tespit edilebilen fixture için, dosya adı olmayan akışlar dahil 20 benzersiz koşulun 20’sinde beklenen türü döndürdü. Yerleştirilen her işaretleyici on dört işleme boyunca hayatta kaldı ve çıktı üç yerel tekrarda birebir aynı kaldı. Faydalı kanıt. Yine de sentetik kanıt. Bu JDK’de, test edilen OCR dışı yollar için dış ikililere ihtiyaç duymayan tek jar üzerinden bunu yapmak dağıtımı hoş biçimde sıkıcı tuttu.

Ama doğru boyutlandırın. Verdiğiniz her tablo sekmeyle birleştirilmiş satırlar olarak geri gelir. Her yapısal liste işaretçisi kaybolur. Markdown ve CSV, dosya adı kaybolur kaybolmaz kimliğini yitirir. Boş dosyalar ve bozuk dosyalar aynı türden hata fırlatır; bunları ayırt etmek için ayrı bir detect çağrısına ihtiyaç duyarsınız. Ve birçok Tika kullanıcısının en çok önem verdiği konu olan OCR tarafında sunabileceğim hiçbir şey yok: Çalıştıramadım ve tahmin de etmeyeceğim.

Bu sınırlar içinde Tika, alışılmadık derecede güvenilir, gösterişsiz bir iş yapıyor. Baytları okur, kutunun üzerindeki etiketi değil. Sadece baytların hangi biçimde olduğunu sormayın.

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

SSS

Apache Tika, uzantı yanlışsa dosya türünü doğru algılar mı? Burada test edilen beş içerik ile tespit edilebilen fixture için evet. PDF, DOCX, RTF, HTML ve XML, yanlış yönlendirici uzantılar, uzantısız durum ve dosya adı olmayan akışlar dahil olmak üzere 20 benzersiz mantıksal koşulun tamamında beklenen medya türüne çözüldü (tekrarlanan akış yürütmeleriyle 30 ham çalıştırma). .txt adı verilen bir PDF yine de application/pdf olarak algılandı. Markdown ve küçük CSV fixture’ı ise dosya adı bilgisine bağlıydı; bu bilgi eksik ya da yanlış olduğunda text/plain’e düştüler.

Tika tabloları ve belge yapısını korur mu? Burada test edilen --text modunda hayır. Tablo ızgaraları hücre ya da başlık semantiği olmadan sekmeyle birleştirilmiş satırlara döndü ve yapısal liste işaretleri (bir HTML <li>, bir DOCX List Bullet stili) kayboldu. Yerleştirilen tüm işaretleyiciler on dört işleme boyunca hayatta kaldı, ancak bu eksiksiz içerik sadakati kanıtı değildir; --text de öğe türü vermez. Yazılan öğeler veya yeniden oluşturulmuş tablolar için başka bir Tika çıktı işleyicisini test edin ya da yanına başka bir araç koyun.

Apache Tika, taranmış PDF’lerde OCR yapabilir mi? Tika, Tesseract üzerinden OCR destekler; ancak bunu test etmedim ve buradaki sonuçların hiçbiri bu konuda bir iddia değildir. Test makinemde Tesseract ve poppler yoktu; bu yüzden tüm OCR ve taranmış-görüntü yolları daha çalışmadan engellendi. Bu testte OCR’ye dair hiçbir sayı yok. Kullanım alanınız OCR ise, tesseract kurun ve kendiniz benchmark edin — Tika’nın o kısmını burada doğrulanmamış kabul edin.

Tika boş ya da bozuk dosyalara ne yapıyor? Sessizce değil, yüksek sesle başarısız olur. 0 baytlık dosya ZeroByteFileException fırlatır; kesilmiş PDF, PDFParser’dan bir TikaException fırlatır; kesilmiş DOCX ise bir POI XML hatası üretir. Üçü de exit 1 ve boş stdout ile biter; dolayısıyla boş ve bozuk, yalnızca çıkarma çağrısına bakıldığında ayırt edilemez. Ancak algılama sağlam kalır — --detect, her iki kesilmiş ikilide de doğru türle exit 0 döndürdü; bu da ayrıştırmaya zaman harcamadan önce güvenilir bir triage adımı sağlar.

Tika testinde neler kapsam dışı kaldı? Dört şey, açıkça. OCR ve taranmış görüntüler (engellendi, test edilmedi). Gerçek korpus doğruluğu — tüm sonuçlar, bilinen etiketlere karşı sadakati ölçen, karmaşık gerçek belgelerdeki doğruluktan ziyade yerleştirilmiş işaretleyici token’lara sahip kontrollü sentetik fixture’lardır. Kaynak kullanımı, throughput ve tepe bellek; bunları ölçmedim. Ve “bin dosya türü” iddiasının uzun kuyruğu: tüm kataloğu değil, dokuz temsili ve bağımlılıksız formatı test ettim. Buradaki her şey Tika 3.3.2, OpenJDK 26.0.1, macOS arm64, tek makinede çalıştırıldı.