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

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

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

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

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

Tika คืออะไร เมื่อหยุดอ่านคำโฆษณาหน้ากล่อง

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

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

ฟังดูเหมือนข้อจำกัด และในมิติหนึ่งมันก็ใช่ แต่ก็หมายความว่า Tika ไม่มีอะไรให้จำแนกผิด ซึ่งเป็นข้อตกลงแลกเปลี่ยนแบบเดียวกับที่เครื่องมือที่ “ฉลาดกว่า” แต่เสียงดังหลายตัวทำในอีกทางหนึ่ง

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

การแยก “ตรวจจับก่อน แล้วค่อย 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 ไม่มีไฟล์คอนฟิก ไม่มีโมเดลเวต ไม่มีขั้นตอนหลังติดตั้ง และไม่ต้องไล่ brew install เป็นทอด ๆ

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

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

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

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

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

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

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

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

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

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

ทำไมสิ่งนี้ถึงสำคัญในสายงานอัปโหลดจริง

สถานการณ์จริงคือมีตัว router สำหรับไฟล์อัปโหลด สมมติว่าคุณรับไฟล์จากผู้ใช้แล้วแยกเส้นทางตามชนิด: PDF ไปยังตัวแยกบิล สเปรดชีตไปยังตัวนำเข้าบัญชี ที่เหลือส่งไปดัชนีข้อความ หากคุณเชื่อนามสกุลไฟล์ ใครบางคนที่อัปโหลด PDF แต่ตั้งชื่อว่า notes.txt จะถูกส่งเข้ากิ่งผิด — และนั่นยังเป็นกรณีที่ไม่ร้ายแรงนัก; แบบที่อันตรายกว่าคือไฟล์ polyglot ที่ใส่นามสกุลดูดี

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

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

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

อัตราการคืนค่าของ marker-token เท่ากับ 1.000 ในการเรนเดอร์ทั้ง 14 แบบ ไม่มีโทเคนที่ผมใส่ไว้หายไปเลย: ทุกเซลล์ตารางที่ติดแท็ก รายการในลิสต์ และหัวข้อ ถูกพบครบ การรันซ้ำในเครื่องเดียวกันสามครั้งต่อ carrier หลังวอร์มอัปให้เอาต์พุต --text เหมือนเดิมทุกไบต์ Oracle นี้ไม่ได้บอกอะไรเกี่ยวกับตัวอักษรที่ไม่ได้ติดแท็ก ลำดับ ช่องว่าง การทำ normalization ของ Unicode เนื้อหาที่ซ้ำ ลิงก์ ส่วนหัว footnote หรืออ็อบเจ็กต์ฝัง มันเป็นแค่การเช็กว่าบล็อกยังอยู่ ไม่ใช่หลักฐานของความเที่ยงตรงทั้งเอกสาร

เอาต์พุตแบบข้อความล้วนยอมสละโครงสร้างต้นทางไปเกือบทั้งหมด

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

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

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

ลิสต์ละเอียดกว่านั้น และมันแยกตามสิ่งที่ต้นฉบับมีจริง:

Tika จะไม่สร้าง marker กลับมาถ้ามันไม่ได้รับมาเป็นข้อความตั้งแต่ต้น ไม่ว่าจะเป็นเนื้อหาเดียวกัน แต่เอาต์พุตที่เห็นต่างกัน

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

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

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

เมตาดาทา: ถูกทำให้เป็นมาตรฐาน และไม่ค่อยยอมเดาสุ่ม

ผมฝังค่าผู้เขียน ชื่อเรื่อง และวันที่สร้างที่รู้แน่ไว้ในทุก carrier ที่มีชั้นเมตาดาทา แล้วดูว่าสิ่งที่คืนมากลับมาอย่างไร

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

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

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

อินพุตที่ออกแบบมาเพื่อทำร้ายสี่แบบ: ไฟล์ขนาดศูนย์ไบต์ ไฟล์ PDF ที่มีหัวไฟล์ถูกต้องแต่ตัดเนื้อหาทิ้ง ไฟล์ ZIP ของ DOCX ที่ถูกตัด และไฟล์ UTF-8 ที่มีตัวอักษรหลายไบต์แต่ไม่มี BOM และไม่มีการประกาศ encoding ทั้งหมดนี้เป็นรูปร่างของฟิกซ์เจอร์ในเครื่อง ไม่ใช่เกณฑ์จำกัดของ Tika

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

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

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

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

Tika เทียบกับ unstructured: ชนิดไฟล์เหมือนกัน แต่คนละงาน

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

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

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

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

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

ข้อดี

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

ข้อเสีย

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

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

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

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

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

ทางเลือกอื่น และตำแหน่งของ Thunderbit

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

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

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

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

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

บทสรุป

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

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

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

ภายใต้ขอบเขตเหล่านี้ Tika ทำงานที่ไม่หรูหราแต่เชื่อถือได้อย่างน่าประหลาด มันอ่านไบต์ ไม่ได้อ่านฉลากบนกล่อง แต่อย่าให้มันบอกคุณว่ารูปร่างของไบต์เป็นอย่างไร

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

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

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

Tika เก็บตารางและโครงสร้างเอกสารไว้ไหม? ไม่ใช่ในโหมด --text ที่ทดสอบที่นี่ ตารางถูกส่งกลับมาเป็นบรรทัดที่คั่นด้วยแท็บ โดยไม่มี semantics ของเซลล์หรือหัวตาราง และ marker ของลิสต์แบบโครงสร้างจริง ๆ (เช่น <li> ใน HTML หรือสไตล์ List Bullet ใน DOCX) หายไป marker ที่ฝังไว้ยังอยู่ครบทุกการเรนเดอร์ทั้ง 14 แบบ แต่สิ่งนั้นไม่ได้พิสูจน์ความเที่ยงตรงครบถ้วน และ --text ไม่ได้ให้ typed elements ถ้าคุณต้องการ typed elements หรือตารางที่สร้างกลับมาได้ ลอง 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 อย่างเดียว แต่การตรวจจับยังแข็งแรงอยู่ — --detect คืน exit 0 พร้อมชนิดที่ถูกต้องบนไบนารีที่ถูกตัดทั้งสองแบบ ซึ่งทำให้มันเป็นขั้นตอน triage ที่เชื่อถือได้ก่อนคุณจะเสียเวลารัน parse

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