รีวิว Apache Tika: อ่านจากไบต์ ไม่ใช่จากชื่อไฟล์ — จนกระทั่งเจอ Markdown

Apache Tika คือชุดเครื่องมือสำหรับแยกวิเคราะห์เอกสารจาก Apache Software Foundation: คุณส่งไฟล์แทบทุกชนิดเข้าไป แล้วมันจะส่งกลับมาเป็นข้อความล้วนพร้อมพจนานุกรมเมตาดาต้าที่ถูกทำให้อยู่ในรูปแบบมาตรฐานแล้ว README ของโปรเจกต์ ระบุว่ารองรับไฟล์มากกว่าพันประเภท และ Tika ก็ทำได้ด้วยการแพ็กไลบรารีเฉพาะทางไว้ในตัวเอง — PDFBox สำหรับ PDF, Apache POI สำหรับเอกสาร Office, jsoup สำหรับ HTML, ตัวอ่าน ODF สำหรับ ODT — ทำให้ทั้งหมดถูกส่งมาเป็น fat jar ไฟล์เดียว โดยไม่ต้องดึงอะไรเพิ่มตอน parse ใน data pipeline มันคือด่านแรกที่ไม่หวือหวา: ชิ้นส่วนที่อยู่หน้าดัชนีค้นหา ชุดเอกสารสำหรับ e-discovery หรือคลังข้อมูลสำหรับ LLM ซึ่งแปลงกองไฟล์ที่หลากหลายให้กลายเป็นรูปแบบเดียวกัน งานจริง ๆ ก็มีแค่สองอย่าง — ตีความว่า byte stream นี้คืออะไร แล้วดึงข้อความกับเมตาดาต้าออกมา

นี่เป็นเครื่องมือที่จุกจิกน้อยที่สุดตัวหนึ่งที่ผมตั้งค่ามาในรอบนานมาก jar เดียว java -jar tika-app-3.3.2.jar --text file.pdf ไม่ต้องมีไฟล์คอนฟิก ไม่ต้องมี model weights ไม่ต้องมีขั้นตอนหลังติดตั้ง และมันยังรันผ่านอย่างสบายบน JDK รุ่นล่าสุดที่ตัวอื่น ๆ บนเครื่องเดียวกันล้มตั้งแต่บ่ายวันเดียวกัน แม้คำเคลมเรื่องรองรับไฟล์เยอะจะน่าสนใจ แต่สิ่งที่ผมอยากทดสอบจริง ๆ แคบกว่านั้น เมื่ออินพุตโกหก Tika จะทำอะไรจริง ๆ? ผมจึงสร้างชุดทดสอบแบบควบคุม โดยให้แต่ละบล็อกของเนื้อหามี marker เฉพาะตัว เรนเดอร์เอกสารเชิงตรรกะเดียวกันออกมาเป็นเก้ารูปแบบ แล้วโจมตีทั้งหมดด้วยนามสกุลที่ผิด ไฟล์ไม่มีนามสกุล ไม่มีชื่อไฟล์เลย ไฟล์ว่างเปล่า และไบนารีที่ถูกเขียนไม่ครบ

จุดที่พฤติกรรมของมันน่าสนใจจริง ๆ คือการตรวจจับประเภทไฟล์ ผมเปลี่ยนชื่อ PDF เป็น .txt แล้วถาม Tika ว่านี่คืออะไร มันตอบว่า application/pdf จากนั้นผมลบชื่อไฟล์ทิ้ง ส่งไบต์ดิบผ่าน stdin แล้วได้คำตอบเดียวกัน ตลอดทั้งห้ารูปแบบที่ตรวจจับได้จากเนื้อหาในชุดทดสอบนี้ ผลแบบนั้นเกิดขึ้นครบใน 20 เงื่อนไขเชิงตรรกะที่ไม่ซ้ำกัน: สามเงื่อนไขของชื่อไฟล์ บวกอีกหนึ่งเงื่อนไขแบบไม่มีชื่อไฟล์ต่อหนึ่งรูปแบบ ชุดทดสอบสตรีมถูกเรียกซ้ำสามครั้งภายใต้ป้ายกำกับต่างกัน ทำให้เกิดการรันดิบที่สำเร็จ 30 ครั้ง แต่การซ้ำเหล่านั้นไม่นับเป็นหลักฐานอิสระ PDF และ RTF มีไบต์ที่จำแนกได้ชัด DOCX เปิดเผยคอนเทนเนอร์ของมัน HTML และ XML จำแนกได้จาก markup หรือ root content กลไกต่างกัน แต่ผลลัพธ์ที่มีประโยชน์เหมือนกันในชุดทดสอบนี้: นามสกุลไฟล์ไม่ได้เอาชนะเนื้อหา แล้วก็มีฝั่งตระกูลข้อความที่ Markdown จะถูกลดเหลือ text/plain ทันทีเมื่อชื่อไฟล์ผิดหรือหายไป ตัวตนของมันในที่นี้ขึ้นอยู่กับ .md ล้วน ๆ

ตัวเลขทุกตัวจากตรงนี้มีขอบเขตสองชั้น ผมทดสอบ Apache Tika 3.3.2 — ตรวจสอบเมื่อ 27 กรกฎาคม 2026 แล้วยังเป็นเวอร์ชันเสถียรล่าสุดอยู่; สาย 4.0.0 มีแค่บิลด์ alpha และ beta บน Maven Central เท่านั้น โปรเจกต์มีดาว GitHub ราว ๆ 3.9k ตอนที่ผมเช็กเมื่อ 27 กรกฎาคม 2026 และใช้ไลเซนส์ Apache-2.0 ซึ่งถือว่าเป็นมิตรกับเชิงพาณิชย์มากที่สุดแบบหนึ่ง และ ผมไม่ได้ทดสอบ OCR เลยสักนิด ไม่มีกระดาษสแกนสักหน้า ไม่มี PDF ที่เป็นรูปภาพล้วน Tesseract และ poppler ไม่ได้ติดตั้งอยู่บนเครื่องที่ใช้รัน ดังนั้นทุกเส้นทาง OCR ถูกปิดตั้งแต่ยังไม่เริ่ม ไม่มีตัวเลข OCR อยู่ในนี้ เพราะไม่มีตัวเลข OCR จริง ๆ เลย

Tika คืออะไร เมื่อเลิกอ่านคำโฆษณาบนกล่อง

ความเข้าใจผิดที่พบบ่อยคือ Apache Tika เป็นตัวแปลงเอกสาร — ป้อน DOCX แล้วได้ Markdown สะอาด ๆ ที่คงหัวข้อกับตารางไว้ครบ มันไม่ใช่แบบนั้น และยิ่งเข้าใจส่วนนี้เร็วเท่าไร เครื่องมือนี้ยิ่งดูดีขึ้นเท่านั้น

เส้นทางที่ทดสอบที่นี่มีสามช่วงที่เกี่ยวข้อง: content-type detector, dispatcher ที่ส่งไบต์ไปยัง parser ที่ถูกต้อง และตัวจัดการ output ของ CLI ที่ใช้ --text ซึ่งส่งออกเป็นข้อความแบน ๆ พร้อมเมตาดาต้าที่เรียกใช้แยกต่างหาก ในสัญญาของ output แบบนี้ไม่มีอ็อบเจ็กต์ Title ไม่มี ListItem และไม่มีการสร้างตารางกลับมาใหม่ Tika ยังมี handler และ API แบบอื่น รวมถึง output แนว XHTML/SAX ด้วย แต่ผมไม่ได้ทดสอบส่วนนั้น ดังนั้นข้อสรุปเรื่องโครงสร้างทั้งหมดด้านล่างจึงอ้างอิงเฉพาะ tika-app --text ไม่ใช่การบอกว่า toolkit นี้ไม่มี event stream แบบมีโครงสร้างอยู่ที่ไหนเลย

ฟังดูเหมือนข้อจำกัด และในอีกมุมมันก็ใช่ แต่ในขณะเดียวกันนั่นหมายความว่า Tika ไม่มีอะไรให้จำแนกผิดพลาด ซึ่งก็คือการแลกเปลี่ยนที่เครื่องมือฝั่งที่ noisy กว่ามักเลือกไปทางตรงข้าม

ตัวการตรวจจับเองทำงานตามลำดับที่มีเอกสารกำกับไว้: ดู signature bytes ก่อน แล้วค่อยตรวจ root ของ XML จากนั้นถึง glob ของชื่อไฟล์ และสุดท้ายจึงใช้ชนิดที่คุณระบุเอง (เอกสาร detection ของ Tika อธิบายไว้แบบนี้) เมื่อชนิดถูกระบุเสร็จแล้ว dispatcher จึงส่งไบต์ไปยัง parser ที่ bundle มาและตรงกัน เช่น PDFBox, POI, jsoup, TextAndCSVParser สำหรับตระกูลข้อความ

การแยก detection ออกจาก parse ไม่ใช่แค่เรื่องภายในที่น่าสนใจ แต่มันคือเหตุผลที่ไฟล์ที่เสียหายจน parse ไม่ได้ยังถูกระบุชนิดได้อย่างถูกต้อง และนั่นกลายเป็นทริกที่ใช้งานได้จริงที่สุดของ Tika เมื่อทุกอย่างเริ่มพัง

การตั้งค่า: jar เดียว คำสั่งเดียว และ JVM ที่ไม่เรื่องมาก

การติดตั้งคือการดาวน์โหลด tika-app-3.3.2.jar จาก Maven Central ขนาดประมาณ 67 MB — เป็น fat jar ที่รวม parser ทุกตัวไว้แล้ว — จากนั้นก็แค่ java -jar tika-app-3.3.2.jar --text file.pdf ไม่มีไฟล์คอนฟิก ไม่มี model weights ไม่มีขั้นตอนหลังติดตั้ง ไม่ต้องไล่ brew install เป็นทอด ๆ

เรื่อง JDK ทำให้ผมประหลาดใจ ผมรันทั้งหมดบน OpenJDK 26.0.1 ซึ่งเป็นบิลด์ non-LTS ที่ค่อนข้างใหม่มาก และ --version, --text, --metadata, --detect ก็คืน exit 0 ทุกคำสั่งโดยไม่มีปัญหาเรื่องความเข้ากันได้ น่าสนใจเพราะผมทดสอบ Apache Nutch บนเครื่องเดียวกันในช่วงเวลาเดียวกัน และรอบ crawl ของมันรันบน JDK 26 ไม่ได้เลย — มันต้องเป็น LTS ที่ 21 หรือต่ำกว่า เพราะการถอด SecurityManager ออกใน JDK รุ่นใหม่ ๆ Tika ไม่แคร์ ถ้าคุณเคยเลี่ยงเครื่องมือสาย JVM เพราะเจอความเจ็บปวดแบบนี้ Tika ไม่ใช่จุดที่ทำให้คุณสะดุด

มีข้อสรุปที่ตรงไปตรงมาสองข้อในฝั่งการตั้งค่า CLI จะสร้าง JVM ใหม่ทุกครั้งที่เรียกใช้งาน ดังนั้น cold start จึงมีผลจริง — การรัน 131 invocation สำหรับ harness ของผมใช้เวลาประมาณหนึ่งนาที โดยส่วนใหญ่หมดไปกับ JVM warmup ถ้าคุณต้องประมวลผลไฟล์จำนวนมาก ควรใช้ library หรือ server mode ไม่ใช่ shell loop ที่วนเรียก jar และเรื่อง dependency-free ก็มีขอบเขตชัดเจน: การดึงข้อความจาก PDF ชั้น text-layer ไม่ต้องพึ่งของภายนอก แต่ OCR ต้องมี tesseract และ poppler PDF ที่มี text-layer, DOCX, ODT, RTF, HTML, XML, TXT, Markdown, CSV ทั้งหมด parse ได้บนเครื่องที่ไม่มีสองตัวนั้นติดตั้งอยู่เลย ส่วนเอกสารสแกนจะไม่ได้เป็นแบบนั้น และผมก็ไม่ได้พยายามทำเป็นว่าได้

ความต่างนี้ยิ่งชัดเมื่อเทียบกับไลบรารีพี่น้องที่ผมทดสอบในวันเดียวกันอย่าง unstructured ซึ่งเส้นทาง PDF แบบอิเล็กทรอนิกส์ถูกบล็อกทั้งหมด เพราะการ import โมดูล PDF ของมันดึง inference stack (torch และตัวอื่น ๆ) มาตั้งแต่ตอนโหลด — ก่อนถึง dispatch ของ strategy ดังนั้นแม้จะใช้ strategy แบบ "fast" ก็ยัง import ไม่ได้ถ้าไม่มีของพวกนั้น Tika แค่ parse text layer ของ PDF เดียวกันด้วย java -jar ธรรมดา

การทดสอบนามสกุลที่โกหก: การตรวจจับ mime type ที่ไม่สนใจชื่อไฟล์

แปดรูปแบบ แต่ละแบบถูกนำเสนอพร้อมนามสกุลที่ถูกต้อง นามสกุลที่ตั้งใจผิด หรือไม่มีนามสกุล พร้อมกับ byte stream ที่ไม่มีชื่อไฟล์ผ่าน stdin นั่นคือ 32 เงื่อนไขเชิงตรรกะที่ไม่ซ้ำกัน ชุดทดสอบดั้งเดิมยังรัน byte stream เดิมซ้ำอีกหนึ่งครั้งภายใต้ป้ายชื่อของแต่ละ filename ทำให้มีการรันดิบ 48 ครั้ง; แถว stream สามแถวนี้ยุบเหลือเงื่อนไขเดียว เพราะ stdin ไม่มีชื่อไฟล์ให้ glob อ่าน

(คอลัมน์ stream รวมเงื่อนไขนามสกุลทั้งสามแบบเข้าด้วยกัน เพราะเมื่อไม่มีชื่อไฟล์ ก็ไม่มีอะไรให้ glob อ่าน)

ห้ารูปแบบที่ตรวจจับได้จากเนื้อหา — PDF, DOCX, RTF, HTML และ XML — ตรงกับชนิดจริงใน 20 จาก 20 เงื่อนไขเชิงตรรกะที่ไม่ซ้ำกัน (และ 30 จาก 30 การรันดิบของ harness รวมทั้งรอบ stream ที่ซ้ำกัน) PDF ที่ตั้งชื่อว่า report.txt ก็ยังเป็น PDF DOCX ที่ตั้งชื่อว่า photo.jpg ก็ยังเป็น DOCX ไม่จำเป็นต้องมีชื่อไฟล์เพื่อให้ถูกต้อง นี่ไม่ได้หมายความว่าทั้งห้ารูปแบบใช้แค่ signature bytes แบบตายตัว: PDF กับ RTF มี header ที่จำแนกได้ชัด DOCX เป็นคอนเทนเนอร์แบบ ZIP ส่วน HTML/XML ถูกตรวจจาก markup หรือ root content กลไกต่างกัน แต่ผลลัพธ์ที่มีประโยชน์ในชุดทดสอบนี้เหมือนกัน: นามสกุลที่โกหกไม่ชนะ

จากนั้นคือฝั่งตระกูลข้อความ Markdown จะถูกระบุเป็น text/markdown ก็ต่อเมื่อมี .md และอ่านได้จริงเท่านั้น เปลี่ยนชื่อ ลบนามสกุล หรือส่งเป็นสตรีม มันจะถูกลดลงเหลือ text/plain ในการทดสอบนี้ CSV ก็เป็นแบบเดียวกันบนกริดเล็ก ๆ ที่ตั้งใจทำให้เรียบง่าย: text/csv จะได้จาก glob ของ .csv เท่านั้น ถ้านับเป็นเงื่อนไขเชิงตรรกะ Markdown และ CSV ต่างก็ถูกระบุเป็นชนิดเฉพาะของตัวเองเพียงหนึ่งจากสี่เงื่อนไข ส่วน plain text อยู่ใน text/plain อยู่แล้ว จึงไม่มีอะไรให้มัน “collapse” ลงมาจากตรงไหน การรันดิบ 48 ครั้งยังมีประโยชน์ในฐานะบันทึกความทำซ้ำได้ แต่ไม่ควรถูกใช้เป็นตัวหารที่ใหญ่กว่าเดิม

มีรายละเอียดหนึ่งที่เข้าข้าง Tika ตรงนี้: นามสกุลที่โกหกก็ไม่ชนะเช่นกัน ไฟล์ Markdown ของผมที่เปลี่ยนชื่อเป็น .pdf ถูกส่งกลับมาเป็น text/plain ไม่ใช่ application/pdf Tika ไม่ได้เชื่อคำโกหก มันแค่ยืนยันความจริงไม่ได้ การลดระดับลงเป็น parent type เป็นความล้มเหลวที่ดีกว่าการยืนยันผิดอย่างมั่นใจมาก และการที่ text/markdown เป็น subtype ของ text/plain ตามเอกสารก็ทำให้ fallback นี้มีเหตุผล ไม่ใช่การเดาสุ่ม

มีข้อสังเกตสำหรับ CSV โดยเฉพาะ Tika มี statistical CSV detector และในเวลาพาร์ส — ยืนยันได้จาก TextAndCSVParser ที่ปรากฏใน chain ของ X-TIKA:Parsed-By — ตาราง 2 คอลัมน์ 3 แถวที่ผมใช้กลับถูกระบุเป็น text/plain แทน text/csv นี่เป็นเพียงการสังเกตจาก fixture เล็ก ๆ ที่ตั้งใจทำให้เรียบง่ายกว่าเดิม CSV ที่ใหญ่กว่าหรือมี quote อาจกระตุ้น detector ได้ ผมไม่ได้บอกว่าการตรวจจับ CSV จากเนื้อหาเสียหาย ผมบอกว่าในกริดนี้ สิ่งที่ทำให้ได้ text/csv คือ extension

ทำไมเรื่องนี้ถึงสำคัญใน pipeline รับไฟล์จริง

สถานการณ์ที่เป็นรูปธรรมคือ upload router สมมติว่าคุณรับไฟล์จากผู้ใช้แล้วส่งต่อไปตามชนิด: PDF ไปยัง invoice parser, spreadsheet ไปยัง ledger importer, ส่วนที่เหลือไปยัง text index ถ้าคุณเชื่อ extension คนที่อัปโหลด PDF ชื่อ notes.txt จะถูกส่งเข้า branch ที่ผิด — และนั่นยังเป็นกรณีที่อ่อนโยน; เวอร์ชันที่เป็นภัยคือ polyglot file ที่ตั้งชื่อด้วย extension ดูดีแต่ภายในแฝงของอีกแบบ

สำหรับ fixture แบบไบนารีและ markup ที่ทดสอบตรงนี้ Tika เลือกทางตามเนื้อหาแม้ชื่อไฟล์จะหายไปแล้ว ซึ่งมีประโยชน์มากเมื่อ blob store หรือ HTTP body handler ตัดชื่อไฟล์ทิ้ง ผลลัพธ์นี้ไม่ได้ครอบคลุม long tail, ไฟล์กำกวม หรือ polyglots ของ Tika ฝั่งตระกูลข้อความที่ทดสอบทำงานต่างออกไป: เมื่อ pipeline ตัดชื่อไฟล์ออก Markdown และ CSV จะมาถึงเป็น text/plain ทำให้กฎที่อิง media type เฉพาะไม่ทำงานอีกต่อไป ควรเก็บชื่อไฟล์เดิมไว้เป็น sidecar metadata แทนที่จะหวังว่าการตรวจจับจากเนื้อหาจะสร้างมันกลับมาได้

เนื้อหาที่ฝังไว้รอดมาได้ แต่ --text ทำให้โครงสร้างแบนราบ

ความเที่ยงตรงเป็นอีกแกนหนึ่ง และมันแยกออกเป็นสองส่วนอย่างชัดเจน ผมเรนเดอร์เอกสารต้นแบบหนึ่งฉบับ (หัวข้อ ย่อหน้าหลักสองย่อหน้า รายการ bullet รายการตัวเลข และย่อหน้าปิดท้าย) ออกมาเป็น HTML, Markdown, plain text, DOCX, PDF, RTF, ODT และ XML รวมถึงเอกสารตารางเป็น HTML, Markdown, text, DOCX, CSV และ XML รวมทั้งหมดสิบสี่รูปแบบ แต่ละบล็อกมี token เฉพาะของตัวเอง — zztitle1, zzitem3, zztblcell_beta และอื่น ๆ — ดังนั้นคำว่า "รอด" กับ "หาย" จึงตรวจได้ด้วย substring ตรง ๆ ไม่ใช่การตีความ

marker-token recall กลับมาเป็น 1.000 สำหรับทั้งสิบสี่ rendering ไม่มี token ที่ฝังไว้หายไปแม้แต่ตัวเดียว: ทุก cell ของตาราง รายการใน list และ heading ที่ติดป้ายไว้ยังอยู่ครบ การรันซ้ำในเครื่องสามครั้งต่อ carrier หลัง warmup ให้ผล --text ที่เหมือนกันทุกไบต์ Oracle นี้ไม่ได้บอกอะไรเกี่ยวกับอักขระที่ไม่ได้ติดแท็ก ลำดับ ช่องว่าง Unicode normalization เนื้อหาที่ซ้ำกัน ลิงก์ headers footnotes หรือ object ที่ฝังอยู่ มันเป็นแค่การเช็กว่าบล็อกยังอยู่ ไม่ใช่การพิสูจน์ว่าเอกสารคงสภาพครบถ้วน

output แบบข้อความแบน ๆ ยอมสละโครงสร้างต้นฉบับไปส่วนใหญ่

นี่คือเอกสารตาราง HTML ที่ออกมาจาก --text:

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

บรรทัดถูกเชื่อมด้วยแท็บ แถวหัวตารางไม่ได้ถูกทำเครื่องหมายว่าเป็น header ไม่มีกริด ไม่มีขอบเขตของเซลล์นอกจากแท็บ และไม่มีทางรู้ได้เลยว่านี่เคยเป็น <table> มาก่อน ตารางใน DOCX ก็แบนในลักษณะเดียวกัน

ส่วน list นั้นละเอียดกว่า และแยกตามสิ่งที่แหล่งข้อมูลจริง ๆ มี:

Tika ไม่เคยสร้าง marker ขึ้นมาใหม่ถ้ามันไม่ได้รับมาเป็นข้อความตั้งแต่แรก เนื้อหาเดียวกัน แต่หน้าตา output ต่างกัน

กรณี Markdown แสดงประเด็นนี้ชัดเจน ถ้าป้อน .md ที่มี pipe table เข้าไปใน Tika ตัว pipe จะถูกส่งกลับมาตามเดิม ซึ่ง ดูเหมือน ว่าเก็บโครงสร้างไว้ แต่มันไม่ใช่ Tika แค่ parse เป็นข้อความแล้วส่งไบต์กลับมา ไม่มีอะไรเข้าใจตารางนั้นเลย

ดังนั้นสัญญาที่วัดได้จึงแคบกว่า: marker ที่ฝังไว้ทั้งหมดรอดมาได้ ในขณะที่ --text ไม่ได้เก็บ typed elements หรือ grid ของตารางที่นำไปสร้างใหม่ได้ การเรียกสิ่งนี้ว่า parser defect จะพลาดประเด็นไป เพราะ flat extraction ตั้งใจหลีกเลี่ยงปัญหาการจำแนกองค์ประกอบอยู่แล้ว แต่มันก็ไม่อาจตอบสนองผู้ใช้ downstream ที่ต้องการชนิดของ element เหล่านั้นได้ ถ้าคุณต้องการ typed blocks หรือตารางที่สร้างใหม่ --text เป็นเพียงหนึ่งชิ้นของ stack ไม่ใช่ทั้ง stack ทั้งก้อน handler อื่นของ Tika อาจเปิดเผยโครงสร้างมากกว่านี้ แต่ไม่ได้อยู่ในรอบทดสอบนี้

คำเตือนแบบเดิมยังใช้กับตัวเลข fidelity ทุกตัวตรงนี้: มันมาจาก synthetic fixture ที่ควบคุมได้บนเครื่องเดียว เวอร์ชันเดียว JDK เดียว มันบอกว่าบล็อกที่ติดแท็กยังอยู่ใน output ไม่ได้พิสูจน์ความถูกต้องแบบอักขระต่ออักขระใน corpus จริงที่สกปรกและหลากหลาย

เมตาดาต้า: ทำให้เป็นมาตรฐาน และน่ายินดีตรงที่ไม่ชอบเดาเอาเอง

ผมฝังค่า author, title และวันที่สร้างที่รู้แน่นอนไว้ในทุก carrier ที่มีชั้นเมตาดาต้า แล้วดูว่ามันถูกดึงกลับมาอย่างไร

author และ title ถูกดึงกลับมาได้บน 4 จาก 4 carrier ที่มีเมตาดาต้า และส่วนที่น่าชื่นใจคือมันถูกทำให้เป็นมาตรฐานแล้ว <meta name="author"> ของ HTML, core property ของ DOCX, entry /Author ของ PDF และ element dc:creator ของ ODT ถูกยุบมาอยู่ใต้ key เดียวกันคือ dc:creator คุณจึงเขียน consumer แค่ตัวเดียว ไม่ใช่สี่ตัว

created คือส่วนที่ไม่เสถียรอย่างซื่อสัตย์ DOCX และ ODT คืน timestamp 2021 ที่ฝังไว้แบบตรงตัว ส่วน PDF คืนวันที่สร้างกลับมาจริง แต่เป็นวันที่ไลบรารี generator ของผมประทับไว้ตอน build ไม่ใช่ค่าที่ผมตั้งใจฝัง ดังนั้นผมจึงนับว่า "มีอยู่" แต่ไม่ใช่ "ดึงค่าที่ฝังไว้กลับมาได้" และฟอร์แมตที่ไม่มีชั้น metadata ก็ไม่ส่งอะไรกลับมาเลย ซึ่งนั่นคือคำตอบที่ถูกต้อง Tika ไม่ได้เดา author จากเนื้อหาหลัก

ลองทำให้มันพังโดยตั้งใจ และทริกคัดแยกที่ได้ผลตามมา

อินพุตอันตรายสี่แบบ ไฟล์ว่างเปล่า ไฟล์ PDF ที่มี header ถูกต้องแต่ body ที่ถูกตัดทิ้ง ZIP ของ DOCX ที่ถูกตัดให้ไม่ครบ และไฟล์ UTF-8 ที่มีอักขระหลายไบต์โดยไม่มี BOM และไม่มีประกาศ encoding เหล่านี้เป็นหน้าตาของ fixture ภายใน ไม่ใช่ threshold ของ Tika

harness พื้นฐานที่สร้าง fixture, raw JSON, checksum ของ jar และ environment manifest ไม่ได้ถูกลิงก์ไว้จาก draft นี้ ดังนั้นผู้อ่านภายนอกจึงยังไม่สามารถ reproduce ตัวหารที่แน่นอนเหล่านี้ได้ด้วยตนเองในตอนนี้ ควรอ่านตารางเหล่านี้ในฐานะ observation ที่รายงานไว้; การเผยแพร่ควรแนบ bundle ที่เก็บถาวรได้ก่อนที่จะนำตัวเลขเหล่านี้ไปใช้อ้างอิงต่อบุคคลที่สาม

การดึงข้อมูลล้มเหลวแบบเสียงดัง และความล้มเหลวเหล่านี้มีรูปแบบภายนอกเหมือนกัน ไฟล์ 0-byte, PDF ที่ถูกตัด, และ DOCX ที่ถูกตัด ต่างก็โยน exception, exit 1 และ stdout ว่างเปล่า CLI ไม่ได้กลืนความผิดพลาดให้กลายเป็นผลลัพธ์ว่างเรียบร้อย ๆ มันปลอดภัยในเชิง process สำหรับกรณีเหล่านี้ — ไม่ค้าง ไม่ segfault — แต่ caller ต้องเช็ก exit status และ stderr ไม่ใช่ดูแค่สตริงว่าง

การตรวจจับแยกจากการ parse บนไบนารีที่ถูกตัดทั้งสองแบบ --detect คืน exit 0 พร้อมชนิดที่ถูกต้องจาก content ส่วนต้นที่ยังครบอยู่ แล้ว parser ค่อยล้มตอนเจอ body ที่พัง ดังนั้น pipeline จึงใช้ detection เป็นสัญญาณ triage แยกต่างหากได้ก่อนหรือหลัง parse ที่ล้มเหลว ส่วนจะตั้ง detect-first เป็นค่าเริ่มต้นดีไหม ขึ้นอยู่กับโหมดการใช้งาน: การทดสอบนี้ไม่ได้ benchmark detect-first เทียบกับ parse-only และการสร้าง JVM CLI ใหม่สองครั้งอาจไม่ใช่การแลกเปลี่ยนที่ดีเมื่อใช้งานปริมาณมาก

การตรวจ charset ใช้งานได้ ไฟล์ UTF-8 ที่ไม่มี BOM และไม่ได้ประกาศ encoding ถูกถอดรหัสเป็น UTF-8 และ 日本語テスト ออกมาครบถ้วน ข้อควรระวังเล็กน้อยสำหรับคนที่อ่าน metadata dict: fixture ที่เป็น ASCII ล้วนของผมรายงาน charset=ISO-8859-1 ซึ่งแยกไม่ออกจาก UTF-8 บนไบต์ ASCII นั่นไม่ใช่การพลาด แต่มันคือเสมอกัน

Tika เทียบกับ unstructured: ไฟล์ชนิดเดียวกัน แต่งานต่างกัน

ทั้งสองตัวถูกทดสอบในเซสชันวิจัยเดียวกัน แต่ที่นี่เป็น taxonomy ของสัญญา output ไม่ใช่ benchmark แบบสมมาตร เครื่องมือถูกให้คะแนนตามผลลัพธ์คนละแบบ

รีวิวที่เกี่ยวข้อง: รีวิว Unstructured.

output แบบแบนที่รักษา marker ไว้ เทียบกับ typed elements ที่มี error ในการจัดประเภทจริง เลือกตามสิ่งที่ downstream consumer ต้องการ ถ้าเป็น search index หรือ context window ของ LLM ข้อความแบนอาจพอแล้ว แต่ถ้ามันยึดกับชนิดของ element Tika ในเส้นทาง --text ไม่สามารถส่งมอบสัญญานั้นได้

พวกเราทั้งคู่ไม่มีตัวเลขสำหรับเอกสารสแกน

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

ข้อดี

• การตรวจจับประเภทไฟล์ไม่สนใจชื่อไฟล์ที่โกหกใน 20/20 เงื่อนไขเชิงตรรกะที่ไม่ซ้ำกันสำหรับ fixture ที่ตรวจจับจากเนื้อหาได้ทั้งห้าแบบ; การรัน stream ที่ซ้ำกันก็ให้ผลตรงกัน
• marker ที่ฝังไว้รอดทุกตัวใน rendering ทั้ง 14 แบบ รวมถึงเซลล์ตารางและรายการ bullet ที่มี tag
• ทำซ้ำได้ในการรันซ้ำในเครื่องสามครั้ง: แต่ละ carrier คืนข้อความที่เหมือนกันแบบ byte-identical ภายในสภาพแวดล้อมนี้
• เมตาดาต้าถูกทำให้เป็นมาตรฐานข้ามฟอร์แมต — dc:creator / dc:title / dcterms:created ไม่ว่ามาจากฟอร์แมตใด โดยดึงกลับมาได้ 4/4 ของ carrier ที่มีเมตาดาต้า
• แทบไม่ต้องพึ่ง dependency จริง ๆ สำหรับฟอร์แมตที่ผมทดสอบ: PDF text layer, DOCX, ODT, RTF, HTML แยกวิเคราะห์ได้จาก jar เดียวโดยไม่ต้องใช้ binary ภายนอก
• รันได้เรียบร้อยบน OpenJDK 26 — ไม่ได้บังคับว่าเป็น LTS เท่านั้น
• การตรวจจับยังคงถูกต้อง (exit 0) บนไบนารีที่ถูกตัด ทำให้คุณมีสัญญาณ triage ที่เชื่อถือได้เมื่อ parse ล้มเหลว
• Apache-2.0, เก่าพอสมควร, และยังดูแลต่อเนื่อง

ข้อเสีย

• การระบุ Markdown และ CSV ขึ้นอยู่กับนามสกุลไฟล์ทั้งหมด; 10 จาก 18 ช่องที่ไม่มี signature จะถูกลดลงเป็น text/plain ทันทีที่ชื่อไฟล์หายหรือผิด
• --text ไม่ได้คืน typed elements; ตารางแบนเป็นบรรทัดที่เชื่อมด้วยแท็บ และ marker ของ list ที่เป็นโครงสร้างหายไป
• การดึงข้อมูลจะโยน exception เมื่อเจออินพุตว่างหรือเสียหาย; สองกรณีนี้จากมุมมองของการเรียก extraction ล้วน ๆ ดูเหมือนกัน
• jar ขนาด 67 MB บวกกับ cold start ของ JVM ทุกครั้งในโหมด CLI
• OCR และ PDF จากภาพสแกนยังไม่ได้ทดสอบเลย — ไม่มี tesseract และ poppler จึงไม่มีการอ้างอะไรเกี่ยวกับเส้นทางนั้น
• ทุกตัวเลขในที่นี้มาจาก synthetic ground truth บนเครื่องเดียว เวอร์ชันเดียว ยังไม่ได้วัดความแม่นยำกับ corpus จริง ตลอดจนไฟล์เข้ารหัส เอกสารที่ฝัง/recursive หรือ throughput เมื่อใช้งานที่สเกลใหญ่

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

Tika เหมาะเมื่ออินพุตของคุณคือ ไฟล์ที่คุณมีอยู่แล้ว และ output ที่ต้องการคือ ข้อความพร้อมเมตาดาต้าที่เครื่องจักรสามารถ index ได้ การทำ search indexing, e-discovery, ประมวลผล archive, ป้อน corpus ให้ LLM, สร้างชั้นตรวจสอบ content-type สำหรับ upload pipeline มันมีประโยชน์เป็นด่านคัดกรองและ normalization ชั้นแรกก่อนส่งต่อให้ของที่ฉลาดกว่า: ตรวจชนิดที่ทดสอบไว้, ดึงข้อความแบน ๆ, แล้วส่งต่อพร้อมเช็กอย่างชัดเจนสำหรับเนื้อหาที่ pipeline ของคุณยอมสูญเสียไม่ได้

ควรข้ามมัน — หรือพูดให้แม่นยำกว่านั้น อย่าหยุดแค่ --text — ถ้าคุณต้องการ typed elements, ตารางที่สร้างกลับมาใหม่ หรือ layout ของเอกสาร ข้ามมันถ้าเอกสารของคุณเป็นไฟล์สแกน อย่างน้อยจนกว่าคุณจะติดตั้ง tesseract แล้วรันตัวเลขของคุณเอง เพราะผมไม่มีตัวเลขนั้นให้ และสำหรับงานปริมาณมาก ควร benchmark library หรือ server mode เทียบกับ CLI บนเอกสารตัวแทน การเริ่ม process เห็นผลชัดใน harness ที่ไฟล์เล็กนี้ แต่ throughput และ resource cost ไม่ได้ถูกวัด

จุดที่มักทำให้คนพลาดคือ ถ้าชั้นเก็บข้อมูลของคุณตัดชื่อไฟล์ทิ้ง และคุณจัดการ Markdown หรือ CSV อย่าไปหวังให้ Tika แยกมันจาก plain text ได้ เก็บชื่อเดิมไว้ด้วย

ทางเลือกอื่น และ Thunderbit อยู่ตรงไหน

ขอวางกรอบให้ยุติธรรมก่อน เพราะการเทียบที่ซื่อสัตย์ในที่นี้คือเรื่อง inputs ไม่ใช่คุณภาพ Tika คือ toolkit แบบฟรี โอเพนซอร์ส Apache-2.0 สำหรับ parse ไฟล์ที่โฮสต์เอง ไฟล์ที่คุณมีอยู่บนดิสก์หรือใน bucket มันไม่ดึงหน้าเว็บ ไม่รัน JavaScript ไม่จัดการ anti-bot และก็ไม่ได้แกล้งทำว่าได้

นั่นคือเส้นแบ่งที่บริการสกัดข้อมูลเว็บแบบ managed รวมถึง Thunderbit ของเราเอง อาจเข้ามาอยู่ในสถาปัตยกรรม: มันดึงหน้าเว็บสด ในขณะที่ Tika parse ไฟล์ที่คุณถือครองอยู่แล้ว บทความนี้ไม่ได้ benchmark บริการเหล่านั้นเทียบกับ Tika และมันก็ไม่ใช่ตัวแทนกันสำหรับอินพุตเดียวกัน

การแบ่งหน้าที่ที่ชัดเจนคือ: ใช้ Tika กับเอกสารที่อยู่ในมือคุณอยู่แล้ว ใช้ managed extraction API กับหน้าเว็บที่คุณต้องไปเก็บมาเอง หลาย pipeline ใช้ทั้งสองอย่าง — crawl และ extract ฝั่งเว็บ แล้วใช้ Tika กับ PDF และ DOCX ที่ถูกส่งกลับมา

ถ้าคุณกำลังเทียบในสนามโอเพนซอร์สที่กว้างขึ้น ผมเขียน บทความเปรียบเทียบ open-source scraper แบบเต็ม, สำรวจ โปรเจกต์ scraping บน GitHub ที่มีประโยชน์ที่สุด, รีวิว Crawl4AI แบบลงมือใช้จริง ที่ครอบคลุมแนวทาง Markdown ผ่าน browser และบทสรุป เครื่องมือ scraping ที่น่าสนใจ สำหรับทาง no-code ก็มีคู่มือสอน scrape เว็บไซต์ด้วย AI ด้วย

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

บทสรุป

ควรใช้ Apache Tika ไหม? ควร ถ้างานของคุณคือแปลงไฟล์หลากหลายชนิดให้เป็นข้อความแบน ๆ และเมตาดาต้ามาตรฐาน และคุณตรวจสอบฟิลด์หรือ marker ที่ pipeline ของคุณยอมเสียไม่ได้

ส่วนที่แข็งที่สุดของรอบทดสอบนี้คือ detector มันคืนชนิดที่คาดไว้ใน 20 จาก 20 เงื่อนไขเชิงตรรกะที่ไม่ซ้ำกันสำหรับ fixture ห้าชนิดที่ตรวจจับจากเนื้อหาได้ รวมถึงสตรีมที่ไม่มีชื่อไฟล์ด้วย marker ที่ฝังไว้รอดครบทั้งสิบสี่ rendering และ output ซ้ำได้ byte-to-byte ในการรันซ้ำในเครื่องสามครั้ง หลักฐานมีประโยชน์ แต่ก็ยังเป็นหลักฐานแบบ synthetic การทำทั้งหมดจาก jar เดียวบน JDK นี้ โดยไม่ต้องพึ่ง binary ภายนอกในเส้นทางที่ไม่ใช่ OCR ทำให้การ deploy น่าเบื่อในทางที่ดี

แต่ต้องประเมินขนาดให้ถูก ทุกตารางที่ป้อนเข้าไปจะกลับมาเป็นบรรทัดที่เชื่อมด้วยแท็บ เครื่องหมายโครงสร้างของ list จะหายไป Markdown และ CSV สูญเสียตัวตนทันทีที่ชื่อไฟล์หาย ไฟล์ว่างและไฟล์เสียหายจะโยนความล้มเหลวในรูปแบบเดียวกัน และคุณจะต้องใช้การเรียก detect แยกต่างหากเพื่อแยกมันออกจากกัน และสำหรับ OCR ซึ่งเป็นคำถามที่ผู้ใช้ Tika หลายคนสนใจมากที่สุด ผมไม่มีอะไรจะให้: ผมรันไม่ได้ และก็จะไม่เดา

ภายในเส้นเหล่านั้น Tika ทำงานที่ไม่หวือหวาแต่ไว้ใจได้อย่างผิดคาด มันอ่านจากไบต์ ไม่ใช่ป้ายบนกล่อง แต่อย่าไปถามมันว่าไบต์พวกนั้นเดิมอยู่ในรูปทรงอะไร

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

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

Apache Tika ตรวจจับชนิดไฟล์ถูกไหมถ้านามสกุลผิด? สำหรับไฟล์ห้าชนิดที่ตรวจจับจากเนื้อหาได้ในการทดสอบนี้ — ใช่ PDF, DOCX, RTF, HTML และ XML ถูกระบุเป็น media type ที่คาดไว้ครบทั้ง 20 เงื่อนไขเชิงตรรกะที่ไม่ซ้ำกัน (30 การรันดิบเมื่อรวม stream ที่ซ้ำกัน) รวมถึงนามสกุลที่หลอก ไม่มีนามสกุล และสตรีมที่ไม่มีชื่อไฟล์ PDF ที่ตั้งชื่อเป็น .txt ก็ยังตรวจได้เป็น application/pdf ส่วน Markdown และ fixture CSV ขนาดเล็กพึ่งพาชื่อไฟล์ และจะถูกลดลงเป็น text/plain เมื่อชื่อหายหรือผิด

Tika เก็บตารางและโครงสร้างเอกสารไว้ไหม? ไม่ใช่ในโหมด --text ที่ทดสอบที่นี่ ตารางจะกลับมาเป็นบรรทัดที่เชื่อมด้วยแท็บ โดยไม่มี semantics ของ cell หรือ header และเครื่องหมายโครงสร้างของ list (เช่น HTML <li> หรือสไตล์ List Bullet ใน DOCX) จะหายไป marker ที่ฝังไว้รอดครบทั้ง 14 rendering จริง แต่ไม่ได้พิสูจน์ว่าเนื้อหาครบถ้วนสมบูรณ์ และ --text ก็ไม่ให้ typed elements ถ้าคุณต้องการ typed elements หรือตารางที่สร้างกลับมาได้ ควรทดสอบ output handler อื่นของ Tika หรือใช้เครื่องมืออื่นร่วมด้วย

Apache Tika ทำ OCR กับ PDF สแกนได้ไหม? Tika รองรับ OCR ผ่าน Tesseract แต่ ผมไม่ได้ทดสอบ และผลลัพธ์ทั้งหมดนี้ไม่ได้อ้างถึงส่วนนั้น Tesseract และ poppler ไม่มีอยู่บนเครื่องทดสอบของผม ดังนั้นทุกเส้นทาง OCR และ scanned-image ถูกบล็อกตั้งแต่ยังไม่รัน ไม่มีตัวเลข OCR ใด ๆ ในการทดสอบนี้ หาก use case ของคุณคือ OCR ให้ติดตั้ง tesseract แล้ว benchmark เอง — ให้มองส่วนนั้นของ Tika ว่ายังไม่ได้ยืนยันในที่นี้

Tika ทำอะไรกับไฟล์ว่างหรือไฟล์เสียหาย? มันล้มเหลวแบบเสียงดัง ไม่ใช่เงียบ ๆ ไฟล์ 0-byte จะโยน ZeroByteFileException; PDF ที่ถูกตัดจะโยน TikaException จาก PDFParser; DOCX ที่ถูกตัดจะโยน error ของ XML จาก POI ทั้งสามกรณี exit 1 และ stdout ว่าง ดังนั้นจากการเรียก extraction อย่างเดียวจะแยกไฟล์ว่างกับไฟล์เสียหายไม่ออก อย่างไรก็ตาม detection ยังแข็งแรง — --detect คืน exit 0 พร้อมชนิดที่ถูกต้องบนไบนารีที่ถูกตัดทั้งสองแบบ ทำให้มันเป็นขั้น triage ที่เชื่อถือได้ก่อนเสียเวลา parse

การทดสอบ Tika นี้ไม่ได้ครอบคลุมอะไรบ้าง? สี่อย่างแบบระบุชัด: OCR และภาพสแกน (ถูกบล็อก ไม่ได้ทดสอบ), ความแม่นยำบน corpus จริง — ผลทั้งหมดมาจาก synthetic fixture ที่ควบคุมได้พร้อม marker ที่ฝังไว้ ซึ่งวัด fidelity เทียบกับ label ที่รู้แน่ ไม่ใช่ความแม่นยำบนเอกสารจริงที่สกปรก, ค่าใช้จ่ายของ resource, throughput และ peak memory ซึ่งผมไม่ได้วัด และ long tail ของคำเคลม "ไฟล์มากกว่าพันชนิด" — ผมทดสอบเพียง 9 รูปแบบตัวแทนที่ไม่ต้องพึ่ง dependency ไม่ใช่แคตตาล็อกทั้งหมด ทุกอย่างในที่นี้คือ Tika 3.3.2 บน OpenJDK 26.0.1, macOS arm64, เครื่องเดียว