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

Apache Tika adalah toolkit parsing dokumen dari Apache Software Foundation: kasih dia hampir sembarang file, lalu dia akan mengembalikan teks polos plus kamus metadata yang sudah dinormalisasi. README proyek mengklaim dukungan untuk lebih dari seribu tipe file, dan Tika mencapainya dengan membundel sendiri library spesialisnya — PDFBox untuk PDF, Apache POI untuk dokumen Office, jsoup untuk HTML, pembaca ODF untuk ODT — jadi semuanya hadir sebagai satu fat jar tanpa perlu unduh apa pun saat parsing. Dalam pipeline data, Tika adalah tahap awal yang tidak heboh: komponen di depan indeks pencarian, set review e-discovery, atau korpus LLM yang mengubah tumpukan file heterogen menjadi sesuatu yang seragam. Intinya dua tugas: menebak sebenarnya aliran byte itu apa, lalu mengekstrak teks dan metadata darinya.

Ini alat paling nggak rewel yang saya pasang dalam waktu lama. Satu jar, java -jar tika-app-3.3.2.jar --text file.pdf, tanpa file konfigurasi, tanpa bobot model, tanpa langkah pascainstalasi, dan dia jalan mulus di JDK terbaru yang pada hari yang sama bikin tooling Java lain ngadat di host yang sama. Tapi klaim katalog itu bukan yang ingin saya uji; pertanyaan yang bisa diuji jauh lebih sempit. Saat input membohongi Anda, apa sebenarnya yang dilakukan Tika? Maka saya bikin 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 ditulis setengah jalan.

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

Ada dua batas untuk setiap angka berikut. Saya menguji Apache Tika 3.3.2 — dicek pada 27 Juli 2026, dan saat itu itu masih rilis stabil terbaru; lini 4.0.0 baru ada sebagai build alpha dan beta di Maven Central. Proyek ini punya sekitar 3,9 ribu bintang GitHub ketika saya cek pada 27 Juli 2026, dan berlisensi Apache-2.0, yang secara komersial hampir selega mungkin. Dan saya sama sekali tidak menguji OCR. Tidak ada halaman hasil scan, tidak ada PDF hanya-gambar. Tesseract dan poppler tidak terpasang di mesin yang saya pakai, jadi semua jalur OCR sudah terblokir sebelum dimulai. Tidak ada angka OCR di sini karena memang tidak ada angka OCR, titik.

Apa itu Tika, setelah Anda berhenti membaca materi promosinya

Anggapan yang umum adalah Apache Tika itu konverter dokumen — masukkan DOCX, keluarlah Markdown bersih dengan heading dan tabel tetap utuh. Itu bukan fungsi Tika, dan makin cepat ini dipahami, makin kelihatan bagus alatnya.

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

Itu terdengar seperti keterbatasan, dan dalam satu dimensi memang begitu. Tetapi itu juga berarti Tika tidak punya banyak ruang untuk salah klasifikasi, dan justru itulah kompromi yang diambil oleh alat-alat yang lebih berisik di arah sebaliknya.

Deteksinya sendiri berjalan dalam urutan yang terdokumentasi: byte signature dulu, lalu inspeksi root XML, lalu glob nama file, lalu tipe apa pun yang Anda berikan sendiri (dokumentasi deteksi Tika menjelaskannya). Setelah tipe dipastikan, dispatcher baru menyerahkan byte ke parser bundled yang cocok — PDFBox, POI, jsoup, TextAndCSVParser untuk keluarga teks.

Pemisahan deteksi lalu parsing itu bukan trivia internal. Itulah alasan file yang terlalu rusak untuk diparse tetap bisa ditentukan tipenya dengan benar, dan itu berubah menjadi trik paling praktis yang ditawarkan Tika begitu sesuatu mulai rusak.

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

Instalnya cuma unduh. tika-app-3.3.2.jar dari Maven Central ukurannya sekitar 67 MB — fat jar yang membundel semua parser — lalu cukup jalankan java -jar tika-app-3.3.2.jar --text file.pdf. Tanpa file konfigurasi, tanpa bobot model, tanpa langkah pascainstalasi, tanpa rantai brew install yang panjang.

Cerita JDK-nya lumayan mengejutkan. Saya menjalankan semuanya di OpenJDK 26.0.1, build non-LTS paling mutakhir, dan --version, --text, --metadata, serta --detect semuanya kembali dengan exit 0 tanpa keluhan kompatibilitas. Ini penting disebut, karena saya juga menguji Apache Nutch di host yang sama pada waktu yang sama, dan siklus crawl-nya sama sekali tidak mau jalan di JDK 26 — dia butuh LTS 21 atau di bawahnya, karena penghapusan SecurityManager pada JDK baru. Tika tidak peduli. Kalau selama ini Anda menghindari tooling JVM karena masalah seperti itu, Tika bukan titik di mana masalah itu muncul.

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

Kontras itu makin terasa kalau dibandingkan dengan library saudara yang saya uji di hari yang sama, unstructured, yang jalur PDF elektroniknya terblokir total karena mengimpor modul PDF-nya ikut menarik inference stack (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 berbohong: deteksi mime type yang mengabaikan nama file

Delapan format, masing-masing diberi ekstensi yang benar, ekstensi yang sengaja salah, atau tanpa ekstensi, plus aliran byte tanpa nama file di stdin. Itu adalah 32 kondisi logis unik. Harness asli juga menjalankan byte stream yang identik satu kali di bawah setiap label nama file, menghasilkan 48 eksekusi mentah; tiga baris stream itu menyatu menjadi satu kondisi karena stdin tidak membawa nama file.

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

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

Lalu rezim keluarga teks. Markdown hanya teridentifikasi sebagai text/markdown ketika ekstensi .md ada dan bisa dibaca. Begitu namanya diubah, ekstensi dihapus, atau dikirim sebagai stream, hasilnya turun menjadi text/plain pada pengujian ini. CSV berperilaku sama pada grid kecil yang sengaja dibatasi ini: text/csv hanya muncul dari glob .csv. Kalau dihitung per kondisi unik, Markdown dan CSV masing-masing hanya berhasil sebagai tipe spesifiknya pada satu dari empat kondisi; teks polos memang sudah text/plain, jadi tidak ada yang bisa “jatuh” darinya. Harness mentah 48 kali tetap berguna sebagai catatan repeatability, tetapi bukan sebagai penyebut yang lebih besar.

Satu detail justru menguntungkan Tika: ekstensi yang bohong juga tidak menang. Fixture Markdown saya yang diubah menjadi .pdf kembali sebagai text/plain, bukan application/pdf. Tika tidak percaya bohongnya; dia hanya tidak bisa memastikan kebenarannya. Turun ke tipe induk adalah kegagalan yang jauh lebih baik daripada mengklaim tipe yang salah dengan yakin, dan fakta bahwa text/markdown adalah subtype terdokumentasi dari text/plain membuat fallback itu masuk akal, bukan asal.

Ada catatan khusus untuk CSV. Tika punya detektor CSV berbasis statistik, dan saat parse — terbukti dari TextAndCSVParser yang muncul di rantai X-TIKA:Parsed-By — grid kecil saya yang cuma 2 kolom dan 3 baris malah terdeteksi sebagai text/plain, bukan text/csv. Ini hanya satu observasi pada fixture yang sengaja minimal. CSV yang lebih besar atau yang pakai kutipan mungkin saja memicu detektor. Saya tidak bilang deteksi konten CSV rusak; saya bilang bahwa pada grid ini, ekstensi-lah yang menghasilkan text/csv.

Mengapa ini penting dalam pipeline upload nyata

Skenario konkretnya adalah router upload. Misalnya Anda menerima unggahan pengguna dan mengarahkannya berdasarkan tipe: PDF ke parser invoice, spreadsheet ke importer ledger, sisanya ke indeks teks. Kalau Anda percaya ekstensi, seseorang yang mengunggah PDF bernama notes.txt akan masuk cabang yang salah — dan itu kasus yang paling jinak; versi yang berniat buruk adalah file polyglot dengan ekstensi yang kelihatan aman.

Untuk fixture biner dan markup yang diuji di sini, Tika mengarahkan berdasarkan konten bahkan setelah nama file hilang, yang berguna ketika blob store atau handler body HTTP sudah membuangnya. Hasil itu tidak mencakup ekor panjang Tika, file ambigu, atau polyglot. Fixture keluarga teks yang diuji berperilaku berbeda: ketika pipeline menghapus nama file, Markdown dan CSV tiba sebagai text/plain, sehingga aturan yang bergantung pada media type spesifik mereka berhenti jalan. Simpan nama asli sebagai metadata sidecar, jangan berharap content detection bisa menebaknya kembali.

Konten yang ditanam tetap selamat. --text meratakan strukturnya.

Fidelity adalah sumbu kedua, dan di sini hasilnya terbagi jelas menjadi dua. Saya merender satu dokumen kanonik (heading, dua paragraf isi, satu daftar berpoin, satu daftar bernomor, satu paragraf penutup) ke HTML, Markdown, teks polos, DOCX, PDF, RTF, ODT, dan XML, plus satu dokumen tabel ke HTML, Markdown, teks, DOCX, CSV, dan XML. Total empat belas rendering pembawa. Setiap blok membawa token unik — zztitle1, zzitem3, zztblcell_beta dan seterusnya — sehingga “selamat” versus “hilang” adalah pengecekan substring yang tepat, bukan penilaian subjektif.

Recall token penanda kembali 1.000 pada seluruh empat belas rendering. Tidak satu pun token yang ditanam hilang: setiap sel tabel, item daftar, dan heading yang diberi penanda muncul semua. Tiga pengulangan lokal per carrier setelah warmup menghasilkan output --text yang identik byte per byte. Oracle ini tidak mengatakan apa-apa tentang karakter yang tidak diberi penanda, urutan, spasi, normalisasi Unicode, konten berulang, link, header, footnote, atau objek tertanam. Ini hanya pengecekan keberadaan blok, bukan bukti fidelitas dokumen penuh.

Output teks polos melepaskan sebagian besar struktur sumbernya.

Inilah dokumen tabel HTML yang keluar dari --text:

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

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

Daftar lebih halus, dan pecah tergantung pada isi sumber aslinya:

Tika tidak pernah merender ulang marker yang tidak diterimanya sebagai teks. Kontennya sama, tetapi tampilannya beda.

Kasus Markdown menjelaskan poin ini dengan sangat bersih. Beri Tika file .md dengan tabel berbasis pipe, lalu tanda | akan kembali apa adanya, yang kelihatan seperti pelestarian struktur. Padahal tidak. Tika cuma memprosesnya sebagai teks dan mengembalikan byte apa adanya. Tidak ada yang memahami tabel itu.

Jadi kontrak yang terukur memang lebih sempit: semua token penanda yang ditanam selamat, tetapi --text tidak mempertahankan elemen bertipe atau grid tabel yang bisa direkonstruksi. Menyebutnya sebagai cacat parser akan melewatkan inti persoalannya. Ekstraksi datar memang sengaja menghindari masalah klasifikasi elemen; tetapi juga tidak bisa memenuhi kebutuhan konsumen downstream yang memerlukan tipe elemen tersebut. Kalau Anda butuh blok bertipe atau tabel yang direkonstruksi, --text hanya salah satu komponen dari stack, bukan stack itu sendiri. Handler Tika lain mungkin menampilkan struktur lebih banyak, tetapi itu di luar pengujian ini.

Catatan standar untuk semua angka fidelitas di sini: semuanya berasal dari fixture sintetis terkontrol pada satu mesin, satu versi, satu JDK. Hasil ini menunjukkan bahwa blok yang diberi penanda memang ada di output. Hasil ini tidak membuktikan pelestarian karakter demi karakter atau akurasi pada korpus dunia nyata yang berantakan.

Metadata: dinormalisasi, dan untungnya tidak sok mengarang

Saya menanam nilai author, title, dan creation-date yang sudah diketahui ke setiap carrier yang punya lapisan metadata, lalu memeriksa apa yang kembali.

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

created memang agak bergeser. DOCX dan ODT mengembalikan timestamp 2021 yang saya sematkan persis. PDF mengembalikan tanggal pembuatan, tetapi itu tanggal yang ditempel library generator saya saat build, bukan nilai yang ingin saya tanam — jadi saya skor sebagai ada, bukan dipulihkan. Dan format tanpa lapisan metadata tidak menampilkan apa pun, yang memang jawaban yang benar. Tika tidak menebak author dari isi teks.

Merusaknya dengan sengaja, dan trik triase yang muncul karenanya

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

Harness dasar, fixture yang dihasilkan, JSON mentah, checksum jar, dan manifest lingkungan tidak ditautkan dari draf ini. Karena itu, pembaca dari luar belum bisa mereproduksi denominator yang persis sama secara independen. Perlakukan tabel ini sebagai observasi yang dilaporkan; publikasi seharusnya menyertakan bundel stabil sebelum angka-angka ini dipakai sebagai bukti pihak ketiga.

Ekstraksi gagal dengan keras, dan kegagalan ini punya bentuk luar yang sama. File nol byte, PDF terpotong, dan DOCX terpotong masing-masing menghasilkan exception, exit 1, dan stdout kosong. CLI tidak menyamarkan kegagalan itu jadi hasil kosong yang rapi. Aman secara proses dalam kasus ini — tidak hang, tidak segfault — tetapi caller harus memeriksa exit status dan stderr, bukan hanya mencari string kosong.

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

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

Tika dibandingkan dengan unstructured: tipe file sama, tugasnya berbeda

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

Ulasan terkait: Ulasan Unstructured.

Output datar yang mempertahankan marker versus elemen bertipe dengan kesalahan klasifikasi yang teramati. Pilih sesuai kebutuhan konsumen downstream. Kalau yang dibutuhkan adalah search index atau window konteks LLM, teks datar mungkin sudah cukup. Kalau alurnya bergantung pada tipe elemen, jalur --text Tika tidak bisa menyediakan kontrak itu.

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

Kelebihan dan kekurangan

Kelebihan

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

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 tipe elemen; grid tabel diratakan menjadi baris-baris yang dipisahkan tab dan marker struktural daftar dihapus.
• Ekstraksi melempar exception pada input kosong dan korup; dua kasus ini terlihat identik dari panggilan ekstraksi saja.
• Jar 67 MB ditambah cold start JVM untuk setiap invokasi pada mode CLI.
• OCR dan PDF hasil scan sama sekali tidak diuji di sini — tesseract dan poppler tidak ada, 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 saat input Anda adalah file yang sudah Anda miliki dan output yang dibutuhkan 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. Dia berguna sebagai langkah triase dan normalisasi tahap awal di depan sesuatu yang lebih pintar: deteksi tipe yang diuji, ekstrak teks datar, lalu teruskan dengan pemeriksaan eksplisit untuk konten yang tidak boleh hilang dari pipeline Anda sendiri.

Lewati — atau lebih tepatnya, jangan berhenti di --text — kalau Anda butuh elemen bertipe, tabel yang direkonstruksi, atau layout dokumen. Lewati juga kalau dokumen Anda berupa hasil scan, setidaknya sampai Anda memasang tesseract dan mengukur sendiri, karena saya tidak punya data itu. Untuk pekerjaan volume besar, benchmark library atau mode server melawan CLI pada dokumen yang representatif. Startup proses terlihat jelas pada harness file kecil ini, tetapi throughput dan biaya resource tidak diukur.

Yang sering menjebak orang: jika storage layer Anda menghapus nama file dan Anda menangani Markdown atau CSV, jangan berharap Tika membedakan keduanya dari teks polos. Simpan nama asli.

Alternatif, dan posisi Thunderbit

Pemetaan yang adil dulu, karena perbandingan jujur di sini tentang input, bukan kualitas. Tika adalah toolkit gratis, Apache-2.0, dan self-hosted untuk parsing file. File yang sudah ada di disk atau di bucket. Dia tidak mengambil halaman, tidak menjalankan JavaScript, tidak berurusan dengan anti-bot, dan tidak pura-pura bisa.

Itulah batas ketika layanan ekstraksi web terkelola, termasuk Thunderbit milik kami, bisa masuk ke arsitektur: layanan itu mengambil halaman langsung, sementara Tika mem-parsing file yang sudah ada di tangan Anda. Artikel ini tidak membandingkan layanan-layanan itu dengan Tika, dan keduanya bukan pengganti untuk input yang sama.

Pembagian yang bersih: Tika untuk dokumen yang sudah Anda miliki, API ekstraksi terkelola untuk halaman web yang perlu Anda ambil. Banyak pipeline menjalankan keduanya — crawl dan ekstraksi di sisi web, Tika pada lampiran PDF dan DOCX yang kembali.

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

Coba Thunderbit untuk Ekstraksi Data Web

Putusan

Perlukah memakai Apache Tika? Ya, kalau tugas Anda mengubah file heterogen menjadi teks datar dan metadata yang dinormalisasi, dan Anda memvalidasi field atau marker yang tidak boleh hilang dari pipeline Anda sendiri.

Bagian terkuat dari pengujian ini adalah detektornya. 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 ditanam selamat di empat belas rendering, dan outputnya berulang identik byte demi byte dalam tiga pengulangan lokal. Bukti yang berguna. Tetap saja, bukti sintetis. Menjalankannya dari satu jar di JDK ini, tanpa binary eksternal untuk jalur non-OCR yang diuji, bikin deployment terasa menyenangkan karena membosankan.

Tetapi ukur dengan benar. Setiap tabel yang Anda berikan akan kembali sebagai baris-baris yang dipisahkan tab. Setiap marker struktur daftar akan hilang. Markdown dan CSV kehilangan identitas begitu nama file hilang. File kosong dan file korup melempar bentuk kegagalan yang sama, dan Anda perlu panggilan detect terpisah untuk membedakannya. Dan pada OCR, pertanyaan yang paling sering penting bagi pengguna Tika, saya tidak punya apa-apa untuk ditawarkan: saya tidak bisa menjalankannya, dan saya tidak akan menebak.

Di dalam batas itu, Tika melakukan pekerjaan yang tidak glamor dengan keandalan yang tidak biasa. Ia membaca byte, bukan label di kotaknya. Hanya saja jangan minta dia menebak bentuk asli dari byte tersebut.

Coba Thunderbit untuk Ekstraksi Data Web Get Started Free

FAQ

Apakah Apache Tika mendeteksi tipe file dengan benar kalau ekstensinya salah? Untuk lima fixture yang bisa dideteksi dari kontennya dalam pengujian ini, ya. PDF, DOCX, RTF, HTML, dan XML terdeteksi ke media type yang diharapkan pada seluruh 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 menjadi text/plain ketika informasi itu hilang atau salah.

Apakah Tika mempertahankan tabel dan struktur dokumen? Tidak pada mode --text yang diuji di sini. Grid tabel kembali sebagai baris-baris yang dipisahkan tab tanpa semantik sel atau header, dan marker struktural daftar (HTML <li>, gaya DOCX List Bullet) hilang. Semua marker yang ditanam selamat di semua 14 rendering carrier, tetapi itu tidak membuktikan fidelitas konten penuh, dan --text tidak menyediakan tipifikasi elemen. Untuk elemen bertipe atau tabel yang direkonstruksi, uji handler output Tika lain atau pakai alat lain bersamanya.

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 ada di host uji saya, jadi semua jalur OCR dan scanned-image terblokir sebelum berjalan. Tidak ada angka OCR di mana pun dalam pengujian ini. Kalau OCR adalah kasus penggunaan Anda, pasang tesseract dan benchmark sendiri — anggap bagian Tika itu belum diverifikasi di sini.

Apa yang dilakukan Tika pada file kosong atau rusak? Dia gagal dengan keras, bukan diam-diam. File 0-byte melempar ZeroByteFileException; PDF terpotong melempar TikaException dari PDFParser; DOCX terpotong melempar error XML dari POI. Ketiganya keluar dengan status 1 dan stdout kosong, jadi file kosong dan rusak tak bisa dibedakan hanya dari panggilan ekstraksi. Namun deteksinya tetap kuat — --detect kembali exit 0 dengan tipe yang benar pada kedua biner yang terpotong, sehingga cocok sebagai langkah triase yang andal sebelum Anda membuang waktu untuk parse.

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