Ulasan Apache Tika: Ia Membaca Byte, Bukan Nama File — Sampai Bertemu Markdown

Apache Tika adalah toolkit parsing dokumen dari Apache Software Foundation: kamu tinggal kasih file dari hampir semua jenis, lalu dia akan mengembalikan teks polos beserta dictionary metadata yang sudah dinormalisasi. README proyek mengklaim dukungan untuk lebih dari seribu tipe file, dan Tika mencapainya dengan membawa sendiri library spesialisnya — PDFBox untuk PDF, Apache POI untuk dokumen Office, jsoup untuk HTML, reader ODF untuk ODT — jadi semuanya dikemas dalam satu fat jar tanpa perlu menarik dependensi lain saat proses parsing. Dalam pipeline data, Tika biasanya jadi tahap awal yang kurang glamor: komponen di depan search index, kumpulan review e-discovery, atau korpus LLM yang mengubah tumpukan file beragam menjadi format seragam. Sebenarnya ada dua tugas utama: menentukan byte stream itu apa, lalu mengambil teks dan metadata darinya.

Ini adalah alat yang paling tidak merepotkan yang saya siapkan dalam waktu cukup lama. Satu jar, java -jar tika-app-3.3.2.jar --text file.pdf, tanpa file konfigurasi, tanpa model weights, tanpa langkah pasca-instalasi, dan semuanya jalan mulus di JDK bleeding-edge yang pada siang hari yang sama membuat tooling Java lain berhenti total di host yang sama. Tapi klaim katalog itu bukan hal yang ingin saya uji; pertanyaannya bisa dibuat lebih sempit. Saat input mencoba mengecoh kamu, apa yang sebenarnya dilakukan Tika? Jadi saya membuat set fixture terkontrol di mana setiap blok konten membawa token penanda unik, merender dokumen logis yang sama ke dalam sembilan format pembawa, lalu mengujinya dengan ekstensi yang salah, ekstensi yang hilang, tanpa nama file sama sekali, file nol byte, dan biner yang terpotong di tengah jalan.

Deteksi adalah tempat perilaku paling menarik muncul. Saya mengganti nama PDF menjadi .txt dan bertanya ke Tika apa itu; jawabannya application/pdf. Lalu saya menghapus nama filenya sepenuhnya, mengalirkan byte mentah lewat stdin, dan dapat jawaban yang sama. Di lima format yang bisa dideteksi dari konten dalam set saya, perilaku ini bertahan di seluruh 20 kondisi logis unik: tiga kondisi nama file ditambah satu kondisi stream tanpa nama file untuk setiap format. Harness menjalankan kasus stream tiga kali dengan label berbeda, menghasilkan 30 run mentah yang berhasil, tetapi pengulangan itu bukan bukti independen. PDF dan RTF punya byte yang mudah dikenali; DOCX menampilkan containernya; HTML dan XML bisa diidentifikasi dari markup atau root content. Mekanismenya beda-beda, hasilnya sama-sama berguna dalam set fixture ini: ekstensi tidak mengalahkan konten. Lalu ada rezim keluarga teks, di mana Markdown langsung jatuh ke text/plain begitu nama file salah atau hilang. Identitasnya, dalam kasus ini, sepenuhnya bergantung pada .md.

Ada dua batas untuk setiap angka yang muncul setelah ini. Saya menguji Apache Tika 3.3.2 — dicek pada 27 Juli 2026, dan saat itu masih menjadi rilis stabil terbaru; jalur 4.0.0 baru tersedia sebagai build alpha dan beta di Maven Central. Proyek ini berada di sekitar 3.9k bintang GitHub ketika saya cek pada 27 Juli 2026, dan berlisensi Apache-2.0, yang secara komersial sangat bebas repot. Dan saya sama sekali tidak menguji OCR. Tidak satu halaman hasil scan pun, tidak satu PDF image-only pun. Tesseract dan poppler tidak terpasang di mesin yang saya pakai, jadi setiap jalur OCR sudah tertahan bahkan sebelum mulai. Di sini tidak ada angka OCR, titik.

Apa itu Tika, setelah kamu berhenti membaca marketing pada kemasannya

Asumsi umum adalah Apache Tika itu konverter dokumen — masukkan DOCX, lalu keluar Markdown bersih dengan heading dan tabel yang tetap utuh. Sebenarnya bukan itu, dan makin cepat hal ini dipahami, makin baik pula alat ini terlihat.

Jalur yang diuji di sini punya tiga tahap relevan: content-type detector, dispatcher yang meneruskan byte ke parser yang tepat, dan handler output CLI --text yang menghasilkan teks datar bersama metadata yang bisa diakses terpisah. Dalam kontrak output seperti ini tidak ada objek Title, tidak ada ListItem, dan tidak ada grid tabel yang dibangun ulang. Tika juga menyediakan handler dan API lain, termasuk output berorientasi XHTML/SAX; saya tidak menguji itu. Jadi, semua kesimpulan struktur di bawah ini khusus untuk tika-app --text, bukan klaim bahwa toolkit ini tidak punya event stream terstruktur di tempat lain.

Kedengarannya seperti keterbatasan, dan dalam satu dimensi memang begitu. Tapi itu juga berarti Tika tidak punya struktur yang salah untuk ditebak, yang justru merupakan kompromi yang sama dengan yang sering dibuat alat-alat sejenis di arah sebaliknya.

Deteksi sendiri berjalan dalam urutan yang terdokumentasi: signature byte dulu, lalu pemeriksaan root XML, lalu pola nama file, lalu tipe yang kamu berikan sendiri (dokumentasi deteksi Tika menjelaskannya). Setelah tipe dipastikan, dispatcher baru menyerahkan byte ke parser bawaan yang sesuai — PDFBox, POI, jsoup, TextAndCSVParser untuk keluarga teks.

Pemisahan detect-then-parse ini bukan trivia internal. Inilah alasan file yang terlalu rusak untuk diparse masih bisa dikenali tipenya dengan benar, dan itu berubah jadi trik paling praktis yang ditawarkan Tika saat semuanya mulai rusak.

Setup: satu jar, satu command, dan JVM yang tidak rewel

Instalnya tinggal unduh. tika-app-3.3.2.jar dari Maven Central ukurannya sekitar 67 MB — fat jar yang menggabungkan semua parser — lalu cukup jalankan java -jar tika-app-3.3.2.jar --text file.pdf. Tanpa file konfigurasi, tanpa model weights, tanpa langkah pasca-instalasi, tanpa rangkaian brew install yang panjang.

Soal JDK cukup mengejutkan saya. Saya menjalankan semuanya di OpenJDK 26.0.1, sebuah build non-LTS bleeding-edge, dan --version, --text, --metadata, serta --detect semuanya mengembalikan exit 0 tanpa keluhan kompatibilitas. Ini layak disebut, karena di host yang sama pada sesi yang sama saya juga menguji Apache Nutch dan siklus crawl-nya sama sekali tidak mau berjalan di JDK 26 — Nutch butuh LTS 21 atau lebih rendah, akibat penghapusan SecurityManager di JDK yang lebih baru. Tika tidak peduli. Kalau selama ini kamu menghindari tooling JVM karena jenis masalah seperti itu, Tika bukan tempat di mana itu menggigitmu.

Ada dua kesimpulan jujur dari sisi setup. CLI menyalakan JVM baru untuk setiap invocation, jadi cold start memang nyata — menjalankan 131 invocation untuk harness saya memakan waktu sekitar satu menit, sebagian besar untuk pemanasan JVM. Kalau kamu memproses file dalam volume besar, sebaiknya pakai library atau mode server, bukan shell loop di atas jar. Dan cerita “tanpa dependensi” ada batas tegasnya: ekstraksi text layer PDF tidak butuh apa pun di luar, tetapi OCR butuh tesseract dan poppler. PDF dengan text layer, DOCX, ODT, RTF, HTML, XML, TXT, Markdown, CSV semuanya berhasil diparse di host tanpa keduanya terpasang. Dokumen hasil scan tentu tidak, dan saya tidak pura-pura sebaliknya.

Kontrasnya makin terasa kalau dibandingkan dengan library saudara yang saya uji di hari yang sama, unstructured, karena jalur PDF elektroniknya terblokir total: mengimpor modul PDF-nya menarik stack inferensi (torch dan kawan-kawan) saat load time — bahkan sebelum dispatch strategi — jadi strategi “fast” pun tidak bisa diimpor tanpa itu. Tika memproses text layer PDF yang sama hanya dengan java -jar biasa.

Uji ekstensi yang menipu: deteksi mime type yang mengabaikan nama file

Delapan format, masing-masing disajikan dengan ekstensi yang benar, ekstensi yang sengaja salah, atau tanpa ekstensi, ditambah stream byte tanpa nama file di stdin. Itu berarti 32 kondisi logis unik. Harness asli juga menjalankan byte stream yang sama sekali lagi di bawah tiap label nama file, menghasilkan 48 eksekusi mentah; tiga baris stream itu dipadatkan jadi satu kondisi karena stdin tidak membawa nama file.

(Kolom stream merangkum ketiga kondisi ekstensi, karena tanpa nama file tidak ada yang bisa dibaca oleh glob.)

Lima format yang bisa dideteksi dari konten — PDF, DOCX, RTF, HTML, dan XML — mencapai tipe yang benar di 20 dari 20 kondisi logis unik (dan 30 dari 30 eksekusi harness mentah, termasuk pengulangan stream). PDF bernama report.txt tetap terdeteksi sebagai PDF. DOCX bernama photo.jpg tetap terdeteksi sebagai DOCX. Keduanya tidak butuh nama file. Ini bukan berarti kelima format itu semuanya memakai signature byte yang tetap: PDF dan RTF punya header yang mudah dikenali, DOCX adalah container berbasis ZIP, sementara HTML/XML dideteksi dari markup atau root content. Dalam fixture ini, ekstensi yang menipu tidak menang.

Lalu ada rezim keluarga teks. Markdown hanya terdeteksi sebagai text/markdown ketika ekstensi .md ada dan bisa dibaca. Ubah namanya, hilangkan ekstensinya, atau kirim sebagai stream, dan dalam pengujian ini dia turun menjadi text/plain. CSV berperilaku sama pada grid kecil yang sengaja saya buat sederhana: text/csv hanya muncul dari glob .csv. Kalau dihitung berdasarkan kondisi unik, Markdown dan CSV masing-masing hanya berhasil mempertahankan tipe spesifiknya pada satu dari empat kondisi; plain text memang sudah text/plain, jadi tidak ada yang benar-benar bisa “turun” darinya. Harness mentah 48 run tetap berguna sebagai catatan repeatability, tetapi bukan sebagai penyebut yang lebih besar.

Satu detail yang menguntungkan Tika di sini: ekstensi palsu juga tidak menang. Fixture Markdown saya yang diubah menjadi .pdf kembali sebagai text/plain, bukan application/pdf. Tika tidak mempercayai kebohongan itu; dia hanya tidak bisa memastikan kebenarannya. Turun ke tipe induk jauh lebih baik daripada menyatakan tipe yang salah dengan percaya diri, dan fakta bahwa text/markdown adalah subtype yang terdokumentasi dari text/plain membuat fallback ini terasa prinsipil, bukan asal-asalan.

Ada catatan khusus untuk CSV. Tika punya detektor CSV berbasis statistik, dan pada saat parsing — terlihat dari TextAndCSVParser yang muncul dalam rantai X-TIKA:Parsed-By — grid kecil 2 kolom x 3 baris saya terdeteksi sebagai text/plain alih-alih text/csv. Itu hanya satu pengamatan pada fixture yang sengaja minimal. CSV yang lebih besar atau yang dikutip mungkin saja memicu detektornya. Saya tidak sedang mengklaim content-detection CSV rusak; saya mengklaim bahwa pada grid ini, ekstensi-lah yang menghasilkan text/csv.

Kenapa ini penting dalam pipeline upload sungguhan

Skenario konkretnya adalah router upload. Misalnya kamu menerima upload dari pengguna dan merutekannya berdasarkan tipe: PDF ke parser invoice, spreadsheet ke importer ledger, sisanya ke text index. Kalau kamu percaya ekstensi, seseorang yang mengunggah PDF bernama notes.txt akan masuk ke cabang yang salah — dan itu masih kasus yang jinak; versi yang lebih berbahaya adalah file polyglot dengan ekstensi yang tampak ramah.

Untuk fixture biner dan markup yang diuji di sini, Tika merutekan berdasarkan konten bahkan setelah nama file hilang, yang sangat berguna ketika blob store atau HTTP body handler sudah membuangnya. Hasil ini tidak mencakup long tail Tika, file ambigu, atau polyglot. Fixture keluarga teks yang diuji berperilaku berbeda: ketika pipeline menghapus nama file, Markdown dan CSV masuk sebagai text/plain, sehingga rule yang bergantung pada media type spesifik mereka berhenti aktif. Simpan nama file asli sebagai metadata sampingan, jangan berharap content detection bisa menebaknya kembali.

Konten yang saya sisipkan tetap ada. --text yang meratakan strukturnya.

Fidelity adalah sumbu kedua, dan di sini hasilnya terbelah dua dengan jelas. Saya merender satu dokumen kanonik (heading, dua paragraf isi, satu daftar bullet, satu daftar bernomor, satu paragraf penutup) ke dalam HTML, Markdown, plain text, DOCX, PDF, RTF, ODT, dan XML, plus satu dokumen tabel ke dalam HTML, Markdown, text, DOCX, CSV, dan XML. Total empat belas rendering pembawa. Setiap blok membawa token unik — zztitle1, zzitem3, zztblcell_beta, dan seterusnya — jadi status “bertahan” versus “hilang” bisa dicek sebagai substring yang eksak, bukan sekadar penilaian subjektif.

Recall token penanda mencapai 1.000 pada semua empat belas rendering. Tidak satu pun token yang saya sisipkan hilang: setiap sel tabel, item daftar, dan heading yang diberi penanda tetap ada. Tiga pengulangan lokal untuk tiap carrier setelah warmup menghasilkan output --text yang identik byte demi byte. Oracle ini tidak mengatakan apa pun tentang karakter yang tidak ditandai, urutan, whitespace, normalisasi Unicode, konten berulang, tautan, header, catatan kaki, atau objek tertanam. Ini adalah pemeriksaan keberadaan blok, bukan bukti fidelitas dokumen yang lengkap.

Output teks datar mengorbankan sebagian besar struktur sumber.

Inilah hasil dokumen tabel HTML ketika keluar dari --text:

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

Baris-baris digabung dengan tab. Baris header tidak ditandai sebagai header. Tidak ada grid, tidak ada batas sel selain tab, dan tidak ada cara untuk tahu bahwa itu pernah menjadi <table>. Tabel dalam DOCX diratakan dengan cara yang sama.

Daftar lebih halus, dan hasilnya bergantung pada apa yang benar-benar ada di sumber:

Tika tidak pernah menampilkan ulang marker yang tidak diterimanya sebagai teks. Kontennya sama, tapi outputnya terlihat beda.

Kasus Markdown menjelaskan poin ini dengan jelas. Beri Tika file .md dengan tabel pipe, dan tanda pipe itu akan kembali secara verbatim, yang terlihat seperti preservasi struktur. Padahal bukan. Tika memprosesnya sebagai teks dan mengembalikan byte-nya. Tidak ada yang memahami tabel itu.

Jadi kontrak yang terukur lebih sempit: semua token penanda yang saya sisipkan bertahan, sementara --text tidak mempertahankan elemen bertipe atau grid tabel yang bisa dibangun ulang. Menyebut ini cacat parser akan meleset dari inti masalah. Ekstraksi datar memang sengaja menghindari problem klasifikasi elemen; tapi konsekuensinya, ia juga tidak bisa memenuhi kebutuhan konsumen downstream yang butuh tipe elemen itu. Kalau kamu memerlukan blok bertipe atau tabel yang direkonstruksi, --text hanyalah satu komponen stack, bukan keseluruhan stack. Handler Tika lain mungkin menampilkan struktur lebih banyak, tapi itu di luar pengujian ini.

Peringatan standar untuk semua angka fidelity di sini: semuanya berasal dari fixture sintetis terkontrol pada satu mesin, satu versi, satu JDK. Angka-angka ini menunjukkan bahwa blok yang ditandai hadir di output. Mereka tidak membuktikan preservasi karakter demi karakter atau akurasi pada korpus nyata yang berantakan.

Metadata: dinormalisasi, dan dengan senang hati tidak mengarang

Saya menyematkan nilai author, title, dan tanggal pembuatan yang diketahui ke setiap carrier yang punya layer metadata, lalu memeriksa apa yang dikembalikan.

Author dan title berhasil dipulihkan pada 4 dari 4 carrier yang memang punya metadata, dan — ini bagian yang penting — semuanya dinormalisasi. <meta name="author"> di HTML, core property DOCX, entri /Author di PDF, dan elemen dc:creator di ODT semuanya muncul di bawah key dc:creator yang sama. Kamu cukup menulis satu consumer, bukan empat.

created adalah bagian yang paling jujur goyah. DOCX dan ODT mengembalikan timestamp 2021 yang saya sematkan secara persis. PDF menampilkan tanggal pembuatan, tetapi tanggal itu adalah timestamp yang ditempel library generator saat build time, bukan nilai yang saya maksudkan untuk disematkan — jadi saya nilai sebagai hadir, bukan berhasil dipulihkan. Format tanpa layer metadata tidak menampilkan apa pun, dan itu justru jawaban yang benar. Tika tidak mengarang author dari body teks.

Menyengaja merusaknya, dan trik triase yang muncul darinya

Empat input yang hostile. File nol byte. PDF valid dengan body yang dipotong. ZIP DOCX yang terpotong. Dan file UTF-8 yang membawa karakter multibyte tanpa BOM dan tanpa deklarasi encoding. Ini adalah bentuk fixture lokal, bukan ambang batas Tika.

Harness dasar, fixture yang dihasilkan, JSON mentah, checksum jar, dan manifest lingkungan tidak ditautkan secara publik di sini, jadi pembaca luar tidak bisa mereproduksi penyebutnya secara independen. Perlakukan tabel-tabel ini sebagai observasi yang dilaporkan, bukan bukti yang bisa diverifikasi pihak ketiga.

Ekstraksi gagal dengan keras, dan kegagalan-kegagalan ini punya bentuk luar yang sama. File nol byte, PDF terpotong, dan DOCX terpotong semuanya menghasilkan exception, exit 1, dan stdout kosong. CLI tidak menyamarkan kegagalan itu menjadi hasil kosong yang rapi. Aman bagi proses dalam kasus ini — tidak hang, tidak segfault — tapi caller harus memeriksa exit status dan stderr, bukan cuma melihat string kosong.

Deteksi terpisah dari parsing. Pada kedua biner yang terpotong, --detect mengembalikan exit 0 dengan tipe yang diharapkan dari konten awal yang utuh; lalu parser gagal pada body yang rusak. Karena itu, pipeline dapat memakai deteksi sebagai sinyal triase terpisah sebelum atau sesudah parse gagal. Apakah detect-first layak dijadikan default bergantung pada mode deployment: pengujian ini tidak membandingkan detect-first dengan parse-only, dan dua JVM CLI yang baru setiap kali bisa jadi bukan trade terbaik pada volume besar.

Deteksi charset bekerja. File UTF-8 tanpa BOM dan tanpa deklarasi berhasil didekode sebagai UTF-8, dan 日本語テスト lewat dengan utuh. Catatan kecil bagi siapa pun yang membaca dictionary metadata: fixture pure-ASCII saya melaporkan charset=ISO-8859-1, yang tidak bisa dibedakan dari UTF-8 pada byte ASCII. Itu bukan salah baca, itu seri.

Tika dibanding unstructured: tipe file sama, pekerjaan beda

Keduanya diuji dalam sesi riset yang sama, tapi ini adalah taksonomi kontrak output, bukan benchmark yang simetris. Kedua alat dinilai pada hasil yang berbeda.

Ulasan terkait: Ulasan Unstructured.

Output datar yang mempertahankan marker versus elemen bertipe dengan error klasifikasi yang teramati. Pilih sesuai kebutuhan downstream consumer. Kalau yang kamu butuhkan adalah search index atau jendela konteks LLM, teks datar mungkin sudah cukup. Kalau sistemmu bergantung pada tipe elemen, jalur --text Tika tidak bisa menyediakan kontrak itu.

Tak satu pun dari kami punya angka untuk dokumen hasil scan.

Kelebihan dan kekurangan

Kelebihan

• Deteksi content-type mengabaikan nama file yang menipu pada 20/20 kondisi unik untuk lima fixture yang bisa dideteksi dari konten; eksekusi stream yang diduplikasi juga menghasilkan hasil yang sama.
• Semua marker yang disisipkan tetap bertahan pada seluruh 14 rendering, termasuk sel tabel dan item daftar yang diberi penanda.
• Konsisten pada tiga rerun lokal: setiap carrier mengembalikan teks yang identik byte demi byte dalam lingkungan ini.
• Metadata dinormalisasi lintas format — dc:creator / dc:title / dcterms:created terlepas dari format sumber, berhasil dipulihkan pada 4/4 carrier yang punya metadata.
• Benar-benar tanpa dependensi tambahan untuk format yang saya uji: text layer PDF, DOCX, ODT, RTF, HTML semuanya diparse dari satu jar tanpa binary eksternal.
• Berjalan mulus di OpenJDK 26 — tidak terikat LTS saja.
• Deteksi tetap benar (exit 0) pada biner yang terpotong, memberi sinyal triase yang andal saat parsing gagal.
• Apache-2.0, matang, dan masih aktif dipelihara.

Kekurangan

• Identitas Markdown dan CSV sepenuhnya bergantung pada ekstensi file; 10 dari 18 sel tanpa signature jatuh ke text/plain begitu nama file hilang atau salah.
• --text tidak mengembalikan elemen bertipe; grid tabel diratakan menjadi baris yang digabung tab dan marker struktur daftar hilang.
• Ekstraksi melempar exception pada input kosong dan rusak; dua kasus ini terlihat sama dari call ekstraksi saja.
• Jar 67 MB plus cold start JVM per invocation dalam mode CLI.
• OCR dan PDF hasil scan sama sekali tidak diuji di sini — tesseract dan poppler tidak tersedia, jadi tidak ada klaim apa pun tentang jalur itu.
• Semua angka di sini adalah ground truth sintetis pada satu mesin, satu versi. Akurasi korpus nyata, file terenkripsi, dokumen tertanam/rekursif, dan throughput skala besar tidak diukur.

Siapa yang cocok memakainya, dan siapa yang sebaiknya tidak

Tika cocok ketika input kamu adalah file yang sudah kamu miliki dan output yang kamu butuhkan adalah teks plus metadata yang bisa diindeks mesin. Search indexing, e-discovery, pemrosesan arsip, memberi korpus ke LLM, membangun lapisan validasi content-type pada pipeline upload. Tika berguna sebagai tahap triase dan normalisasi awal di depan komponen yang lebih pintar: deteksi tipe yang diuji, ekstrak teks datar, lalu teruskan dengan pemeriksaan eksplisit untuk konten yang tidak boleh hilang.

Lewati saja — atau lebih tepatnya, jangan berhenti di --text — kalau kamu butuh elemen bertipe, tabel yang direkonstruksi, atau layout dokumen. Lewati juga kalau dokumenmu berupa hasil scan, setidaknya sampai kamu memasang tesseract dan menjalankan pengukuran sendiri, karena saya tidak punya angka untuk itu. Untuk kerja volume besar, benchmark mode library atau server dibanding CLI pada dokumen representatif. Startup proses terlihat jelas pada harness file kecil ini, tapi throughput dan biaya resource tidak diukur.

Satu hal yang sering menjebak orang: kalau storage layer kamu menghapus nama file dan kamu menangani Markdown atau CSV, jangan berharap Tika membedakannya dari plain text. Simpan nama aslinya.

Alternatif, dan posisi Thunderbit di dalamnya

Konteks yang adil dulu, karena perbandingan yang jujur di sini adalah soal input, bukan kualitas. Tika adalah toolkit self-hosted gratis berlisensi Apache-2.0 untuk parsing file. File yang sudah ada di disk atau bucket kamu. Dia tidak mengambil halaman web, tidak menjalankan JavaScript, tidak menangani anti-bot, dan tidak berpura-pura bisa.

Itulah batas di mana managed web extraction service, termasuk Thunderbit kami sendiri, bisa masuk ke arsitektur: dia mengambil halaman live, sedangkan Tika mem-parsing file yang sudah ada di tanganmu. Artikel ini tidak membandingkan layanan tersebut dengan Tika, dan keduanya bukan pengganti untuk input yang sama.

Pemisahan yang paling bersih: Tika untuk dokumen yang sudah kamu miliki, managed extraction API untuk halaman web yang perlu kamu ambil. Banyak pipeline menjalankan keduanya — crawl dan ekstraksi di sisi web, Tika untuk lampiran PDF dan DOCX yang kembali.

Kalau kamu membandingkan di ekosistem open-source yang lebih luas, saya juga pernah menulis perbandingan lengkap scraper open-source, survei proyek scraping paling berguna di GitHub, ulasan praktis Crawl4AI yang membahas pendekatan Markdown berbasis browser, serta ringkasan alat scraping yang lebih luas. Untuk jalur tanpa kode, ada juga panduan tentang cara scrape situs menggunakan AI.

Coba Thunderbit untuk Ekstraksi Data Web

Putusan akhir

Haruskah kamu memakai Apache Tika? Ya, kalau pekerjaanmu adalah mengubah file heterogen menjadi teks datar dan metadata yang dinormalisasi, lalu kamu memvalidasi field atau marker yang pipeline kamu sendiri tidak boleh kehilangan.

Detektornya adalah bagian terkuat dari pengujian ini. Dia mengembalikan tipe yang diharapkan pada 20 dari 20 kondisi unik untuk lima fixture yang bisa dideteksi dari konten, termasuk stream tanpa nama file. Semua marker yang disisipkan bertahan di empat belas rendering, dan output-nya berulang byte-per-byte pada tiga rerun lokal. Bukti yang berguna. Tetap saja bukti sintetis. Menjalankannya dari satu jar di JDK ini, tanpa binary eksternal untuk jalur non-OCR yang diuji, membuat deployment terasa menyenangkan karena membosankan.

Namun ukur dengan benar. Setiap tabel yang kamu berikan akan kembali sebagai baris yang digabung tab. Setiap marker daftar struktural akan hilang. Markdown dan CSV kehilangan identitasnya begitu nama file hilang. File kosong dan file rusak melempar bentuk kegagalan yang sama, dan kamu perlu panggilan detect terpisah untuk membedakannya. Dan untuk OCR, pertanyaan yang paling banyak dipedulikan pengguna Tika, saya tidak punya apa-apa untuk ditawarkan: saya tidak bisa menjalankannya, dan saya tidak akan menebak.

Di dalam batas-batas itu, Tika menjalankan pekerjaan yang tidak glamor dengan keandalan yang tidak biasa. Ia membaca byte, bukan label di kotaknya. Hanya saja jangan tanya bentuk byte-nya seperti apa.

Coba Thunderbit untuk Ekstraksi Data Web Get Started Free

FAQ

Apakah Apache Tika bisa mendeteksi tipe file dengan benar jika ekstensi file salah? Untuk lima fixture yang bisa dideteksi dari konten yang diuji di sini, ya. PDF, DOCX, RTF, HTML, dan XML semuanya terdeteksi sebagai media type yang benar pada 20 kondisi logis unik (30 run mentah dengan eksekusi stream yang diduplikasi), termasuk ekstensi yang menyesatkan, tanpa ekstensi, dan stream tanpa nama file. PDF bernama .txt tetap terdeteksi sebagai application/pdf. Markdown dan fixture CSV kecil bergantung pada informasi nama file dan turun ke text/plain ketika informasi itu hilang atau salah.

Apakah Tika mempertahankan tabel dan struktur dokumen? Tidak dalam mode --text yang diuji di sini. Grid tabel kembali sebagai baris yang digabung tab tanpa semantik sel atau header, dan marker struktural daftar (HTML <li>, style DOCX List Bullet) hilang. Semua marker yang disisipkan bertahan di seluruh 14 rendering carrier, tapi itu tidak membuktikan fidelitas konten yang lengkap, dan --text tidak menyediakan typing elemen. Untuk elemen bertipe atau tabel yang direkonstruksi, uji handler output Tika lain atau pakai alat lain berdampingan.

Bisakah Apache Tika melakukan OCR pada PDF hasil scan? Tika mendukung OCR lewat Tesseract, tetapi saya tidak mengujinya, dan semua hasil di sini bukan klaim tentang itu. Tesseract dan poppler tidak tersedia di host pengujian saya, jadi semua jalur OCR dan scanned-image tertahan sebelum berjalan. Di pengujian ini tidak ada angka OCR sama sekali. Kalau OCR adalah use case kamu, instal tesseract dan ukur sendiri — anggap bagian itu belum terverifikasi di sini.

Apa yang dilakukan Tika terhadap file kosong atau rusak? Dia gagal dengan keras, bukan diam-diam. File 0-byte memunculkan ZeroByteFileException; PDF terpotong memunculkan TikaException dari PDFParser; DOCX terpotong memunculkan error XML dari POI. Ketiganya keluar dengan status 1 dan stdout kosong, jadi file kosong dan rusak tidak bisa dibedakan hanya dari call ekstraksi. Namun deteksinya tetap tangguh — --detect mengembalikan exit 0 dengan tipe yang benar pada kedua biner yang terpotong, sehingga cocok dijadikan langkah triase sebelum kamu membuang waktu untuk parsing.

Apa saja yang tidak dicakup oleh pengujian Tika ini? Empat hal, secara eksplisit. OCR dan gambar scan (terblokir, tidak diuji). Akurasi pada korpus nyata — semua hasil adalah fixture sintetis terkontrol dengan token penanda yang disisipkan, jadi yang diukur adalah fidelity terhadap label yang diketahui, bukan akurasi pada dokumen nyata yang berantakan. Biaya resource, throughput, dan peak memory, yang tidak saya ukur. Dan ekor panjang klaim "seribu tipe file" itu: saya menguji sembilan format representatif yang tanpa dependensi eksternal, bukan seluruh katalog. Semua hasil di sini adalah Tika 3.3.2 di OpenJDK 26.0.1, macOS arm64, satu mesin.