pdfly - มีดพกสวิสอาร์มีสำหรับไฟล์ PDF

 (chezsoi.org)
30 คะแนน โดย GN⁺ 2025-10-14 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครื่องมือ CLI แบบโอเพนซอร์สสำหรับจัดการไฟล์ PDF ที่พัฒนาโดยทีม py-pdf และทำงานบน Python
  • รองรับความสามารถในการแก้ไข PDF ที่หลากหลาย เช่น แสดงเมตาดาตา, แยกและรวมหน้า, ลบหน้า, แปลงรูปภาพเป็น PDF, บีบอัดเอกสาร, สร้างบุ๊กเลต เป็นต้น
  • ยังรองรับความสามารถระดับมืออาชีพ เช่น การดึงรูปภาพและข้อความคำอธิบายประกอบจาก PDF หรือ การกู้คืน xref ของ PDF ที่เสียหายจากการแก้ไขด้วยตนเอง
  • ในเวอร์ชัน 0.5.0 ที่เพิ่งเปิดตัวล่าสุด ได้มีการเพิ่มฟีเจอร์ใหม่ เช่น การลงลายเซ็นและตรวจสอบลายเซ็นเอกสาร PDF, การดึงเฉพาะหน้าที่มีคำอธิบายประกอบ, การหมุนหน้าเฉพาะที่ต้องการ เป็นต้น

เครื่องมือ PDF CLI แบบโอเพนซอร์ส pdfly

  • pdfly เป็นโปรเจ็กต์ล่าสุดขององค์กร py-pdf และเป็นเครื่องมือบรรทัดคำสั่งสำหรับจัดการไฟล์ PDF ที่ทำงานในสภาพแวดล้อม Python
  • พัฒนาบนพื้นฐานของไลบรารี fpdf2 และ pypdf ติดตั้งและใช้งานง่าย จึงนำไปใช้ได้บนหลากหลายแพลตฟอร์ม
  • จุดแข็งที่สุดของ pdfly คือ การรองรับฟีเจอร์ที่ครอบคลุมกว่าโอเพนซอร์สคู่แข่ง พร้อมอินเทอร์เฟซที่ใช้งานง่ายแม้สำหรับนักพัฒนามือใหม่
  • เมื่อเทียบกับโปรเจ็กต์อื่น ๆ เครื่องมือนี้ช่วยให้จัดการงาน PDF ส่วนใหญ่ได้สะดวกด้วยเครื่องมือเดียว จึงมีประสิทธิภาพสูงมาก

ความสามารถหลัก

  • การแสดงเมตาดาตา

    • รองรับการแสดงเมตาดาตาของ PDF ผ่านคำสั่ง pdfly meta และ pdfly pagemeta
    • แสดงข้อมูลจากระบบปฏิบัติการ เช่น ชื่อไฟล์, สิทธิ์การเข้าถึง, ขนาด, เวลาในการสร้าง/แก้ไข/เข้าถึง
    • แสดงข้อมูลภายใน PDF เช่น เวอร์ชัน PDF, จำนวนหน้า, มีการเข้ารหัสหรือไม่, ข้อมูลฟอนต์, ไฟล์แนบ, จำนวนรูปภาพ

  • การรวมและแก้ไขเอกสาร

    • pdfly cat: ฟังก์ชันแยกหน้าที่ต้องการและรวมเอกสาร
    • pdfly rm: ฟังก์ชันลบหน้าแบบเลือกได้
    • pdfly x2pdf: แปลงรูปภาพเป็นเอกสาร PDF
    • pdfly compress: ฟังก์ชันบีบอัดเอกสาร
    • pdfly 2-up และ pdfly booklet: ฟังก์ชันสร้างบุ๊กเลต

  • การดึงเนื้อหา

    • pdfly extract-images: ดึงรูปภาพจาก PDF
    • pdfly extract-annotated-text: ดึงข้อความที่มีคำอธิบายประกอบ

  • การกู้คืน PDF

    • pdfly update-offsets: แก้ไขตาราง xref ของ PDF ที่ถูกแก้ไขด้วยตนเองผ่านโปรแกรมแก้ไขข้อความ เพื่อให้สามารถเปิดได้อีกครั้ง
    • ตาราง xref คือดัชนี byte offset ภายในเอกสาร ซึ่งอาจเสียหายได้เมื่อมีการแก้ไขด้วยตนเอง

การเปิดตัวเวอร์ชัน 0.5.0 และฟีเจอร์ใหม่

  • เปิดตัวpdfly เวอร์ชัน 0.5.0 เมื่อวันที่ 13 ตุลาคม 2025
  • pdfly sign: สามารถเพิ่มลายเซ็นอิเล็กทรอนิกส์ลงในเอกสาร PDF ได้อย่างง่ายดาย
  • pdfly check-sign: ฟังก์ชันตรวจสอบลายเซ็นของเอกสาร PDF
  • pdfly extract-annotated-pages: ดึงเฉพาะหน้าที่มีคำอธิบายประกอบ เพื่อรองรับการทบทวนและทำงานซ้ำในเอกสารขนาดใหญ่
  • pdfly rotate: ฟังก์ชันหมุนหน้าเฉพาะของเอกสาร

แผนในอนาคต

  • มีการเตรียมไอเดียฟีเจอร์หลากหลายไว้ใน issue ที่ติดป้าย up-for-grabs บน GitHub
  • มี issue ที่ติดป้าย good first issues สำหรับผู้ร่วมพัฒนาใหม่ เพื่อเปิดทางให้ผู้เริ่มต้นในโลกโอเพนซอร์สเข้ามามีส่วนร่วม
  • มีแผนจะพัฒนาต่อยอดโดยเน้น การขยายฟีเจอร์ด้านลายเซ็นอิเล็กทรอนิกส์ เช่น pdfly sign และ check-sign
  • ยินดีรับฟังฟีดแบ็กจากผู้ใช้ รายงานบั๊ก และข้อเสนอฟีเจอร์ใหม่อย่างเต็มที่

https://github.com/py-pdf/pdfly

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
ifmkl 2025-10-14

ผมเคยใช้ Moduui PDF อยู่ แล้วก็เลยทำเครื่องมือ PDF ใช้เองที่รองรับเฉพาะฟีเจอร์บางอย่างที่สะดวกกับการใช้งานส่วนตัวของผม เช่น การแยก การรวม การลบ การหมุน และการเปลี่ยนลำดับ โดยใช้ pdf.js /pdf-lib.js บนเบราว์เซอร์ครับ ก่อนจะทำเครื่องมือส่วนตัวของตัวเอง ผมก็ลองหาดูเหมือนกัน แล้วพบว่ามีเครื่องมือหรือเว็บไซต์เกี่ยวกับ PDF เยอะมากจริง ๆ
 
GN⁺ 2025-10-14
ความคิดเห็นบน Hacker News

  • แม้จะเป็นความเห็นเมื่อ 10 ปีก่อน แต่ผมคิดว่ายังใช้ได้อยู่ จนแค่ในฝั่งไลบรารี Python ก็มีของที่ให้ความสามารถเกี่ยวกับ PDF แบบทับซ้อนกันอยู่เยอะมาก ภาษาอื่นก็เช่นกัน มีไลบรารีนับไม่ถ้วน สุดท้ายแล้วแต่ละไลบรารีก็เป็นการรวมฟังก์ชันหลายอย่างที่ใช้แปลงโครงสร้างข้อมูลคล้าย ๆ กันไว้ด้วยกัน เพราะแบบนี้ ถ้าจะทำงาน PDF ที่ซับซ้อน ก็มักต้องเอาไลบรารี 2-3 ตัวมาประกอบกัน ซึ่งไม่มีประสิทธิภาพทั้งในมุมของนักพัฒนาและทรัพยากรคอมพิวต์ ถ้ามีใครสักคนทำโครงสร้างอ่าน/เขียน PDF ระดับล่างที่ออกแบบมาดีแบบ in-memory ด้วย Rust ได้ ผมคิดว่าทั้ง ecosystem จะดีขึ้นมาก ภาษาไหนหรือไลบรารี PDF ตัวไหนก็เอาโครงสร้างนั้นไปใช้ได้ และถ้านำมาใช้ก็มีโอกาสที่โค้ดจะสั้นลง ความเร็วและความปลอดภัยก็ดีขึ้นด้วย แล้วถ้าแค่มี get_structure_pointer() กับ set_structure_pointer() ให้ ไลบรารีต่าง ๆ ก็จะเชื่อมต่อกันได้อย่างอิสระ โครงสร้างแบบนี้จะทำให้ไลบรารีขนาดเล็กเพิ่มความสามารถใหม่ ๆ และถูกนำไปใช้ได้เร็วขึ้น ในทางปฏิบัติผมไม่รู้ว่าใครจะอยากทำสิ่งนี้ แต่คิดว่ามันจำเป็นมาก

    • ตอนสร้างไลบรารี PDF จะมี trade-off ด้านการออกแบบไม่รู้จบ ขึ้นอยู่กับจุดประสงค์การใช้งาน คำว่า "in-memory" เองก็เป็นตัวเลือกใหญ่แล้ว เพราะตัวฟอร์แมต PDF ถูกออกแบบมาให้ไม่จำเป็นต้องโหลดทั้งไฟล์เข้าเมมโมรีพร้อมกัน และถ้าคุณชอบโมดูลที่ลึกแต่มีอินเทอร์เฟซเล็กที่สุด ก็ย่อมไม่มองว่าโมดูลที่ตื้นแต่กว้างและมีฟังก์ชันมาก ๆ คือคำตอบ สุดท้าย ในสภาพแวดล้อมแบบ managed อย่าง JVM ก็ต้องคิดด้วยว่าไลบรารีที่ทำผ่าน C interface จะเพิ่มทั้งความซับซ้อนและ overhead ลิงก์ที่เกี่ยวข้อง

    • เห็นด้วยกับความเห็นที่ว่า "ถ้ามีโครงสร้าง PDF แบบ in-memory ที่ทำมาดีด้วย Rust ecosystem คงเปลี่ยนไปมาก" แต่แค่การสร้างไลบรารีที่ดีกว่าทุกตัวที่มีอยู่ตอนนี้ก็ยากมากแล้ว การอัปเดต แก้บั๊ก และดูแลรักษาต่อเนื่องยิ่งยากกว่าอีก ต่อให้มีเงินทุนพอ ก็ยังต้องหาคนที่มีแพสชันจะทำต่อทุกปี และถ้าคนนั้นหมดความสนใจ ก็ต้องหาคนใหม่มารับช่วง ระหว่างนั้นก็ต้องยอมรับเสียงบ่นต่าง ๆ อยู่ดี สรุปคืออยากขอขอบคุณล่วงหน้าสำหรับอาสาสมัครที่จะสร้างและดูแลสิ่งนี้ไปตลอดชีวิต

    • พอเห็นคนพูดว่า "ถ้ามีโครงสร้าง PDF แบบ in-memory ที่ยอดเยี่ยมจาก Rust ก็คงดี" เลยอยากแชร์โอเพนซอร์ส lopdf ที่มีอยู่จริง

    • ตอนนี้ผมก็กำลังดีบั๊กปัญหาเรื่องการ parse PDF อยู่ และสุดท้ายก็ลงเอยด้วยการเขียน parser เอง ผมพยายามทำความเข้าใจ parser ที่มีอยู่แล้ว แต่โค้ดมันเละจนสุดท้ายต้องลงมือทำเอง ฟอร์แมต PDF พูดตรง ๆ ว่าซับซ้อนมาก เพราะระหว่างการขยายความสามารถมีทั้งการแก้ขัดเฉพาะหน้าและการยัดฟีเจอร์เกินจำเป็นเข้าไปปนกัน ไอเดียตั้งต้นมันดี แต่ใน PDF มีทั้งชนิดอ็อบเจ็กต์และพร็อพเพอร์ตีพิเศษหลากหลายมาก จนพอจะทำ binding กับมันทีไร ความซับซ้อนของ FFI ก็วนกลับมาอีกอยู่ดี บางทีถ้ามีการทำ mapping อย่างเป็นทางการระหว่าง PDF กับ JSON แล้วไม่มีปัญหาเรื่องหน่วยความจำ ไลบรารีหลัก ๆ อาจเอาไว้แลกเปลี่ยนข้อมูลกันได้ เพราะ object model ของมันก็ไม่ได้ต่างกันแบบสุดขั้ว

    • มีคนแซวว่าการถกเถียงทั้งหมดนี้สรุปได้ด้วยการ์ตูน XKCD แผ่นเดียว พร้อมแชร์ลิงก์

  • Poppler แม้ในหน้าเว็บทางการจะไม่ได้อธิบายละเอียดนัก แต่จริง ๆ แล้วเป็นไลบรารีที่มาพร้อมชุดเครื่องมือหลายอย่าง และใช้งานได้ง่ายบนลินุกซ์ดิสโทรต่าง ๆ เป็นเครื่องมือที่ผมใช้แล้วดีหลายครั้ง ลิงก์วิกิที่เกี่ยวข้อง

    • ผมใช้เครื่องมือพวกนี้วิเคราะห์สลิปเงินเดือน PDF หลายแสนไฟล์แล้วอัปโหลดข้อมูลขึ้นระบบการเงินใหม่ ให้คะแนน 10 เต็ม 10 ได้เลย

    • ปกติผมก็ใช้เครื่องมือของ poppler บ่อยมาก คิดว่าเยี่ยมจริง ๆ

  • สำหรับงานระดับล่าง qpdf มีประโยชน์มากทีเดียว

    • ผมก็มาจะพูดเรื่องนี้เหมือนกัน Qpdf คือสิ่งที่ใช้บ่อยที่สุดเวลาจัดการไฟล์ PDF จาก command line ใช้ได้ทั้งเข้ารหัส ถอดรหัส ดึงหน้า รวมไฟล์ และอีกหลายอย่าง อยู่ภายใต้ Apache license และเขียนด้วย C++

  • มี pdfcpu.io ด้วย แต่ถ้าต้องการแค่แก้ไข PDF แบบง่าย ๆ การหาแอป GUI โอเพนซอร์สข้ามแพลตฟอร์มที่ใช้ได้จริงนั้นยากมาก ซึ่งผมเองก็ยังหาไม่เจอ

    • ผมเคยใช้ PDF SAM basic ("split and merge") แล้วดีมาก ลิงก์เว็บไซต์ เป็นโอเพนซอร์ส รองรับหลายแพลตฟอร์ม และมีฟีเจอร์เสริมบางอย่างที่มีเฉพาะแบบเสียเงิน

    • ถ้าโฮสต์เองได้ Signature PDF ก็ค่อนข้างดีเหมือนกัน ลิงก์โปรเจกต์

    • ผมว่า pdf24 tools ก็น่าจะใช้ได้ และรองรับการติดตั้งแบบออฟไลน์ด้วย

    • ผมลองใช้ pdfcpu images list แล้วตกใจมาก เพราะมันเริ่มดาวน์โหลดฟอนต์บางตัวจากภายนอกลงเครื่อง ตอนนี้ก็เดือนตุลาคมแล้ว น่ากลัวเกิน ขอผ่าน

    • สุดท้ายหลังจากคิดไปคิดมา ผมก็ตัดสินใจใช้ไลเซนส์ Creative Cloud แบบเสียเงิน เพราะ Acrobat มันใช้งานได้ดีจริง ๆ เลยเลี่ยงไม่ได้ ผมอยากได้ทางเลือกอื่นมาก แต่ในโลกความจริงก็ยังไม่มีตัวแทนที่เหมาะสม

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

    • พอเห็นว่ารองรับทุกอย่างยกเว้นลินุกซ์ ก็มีคนแซวถามว่าแล้วไบนารีสำหรับ OpenVMS, Apple II, DEC Alpha อยู่ไหน

    • ยังมี Master PDF ด้วย และตัวนี้มีเวอร์ชันสำหรับลินุกซ์ด้วย ลิงก์

    • ถึงหน้าตาจะดูดี แต่ผมเชื่อได้ยากกับตรรกะว่า "ฟรี ไม่มีโฆษณา ไม่ขายข้อมูล และดำเนินงานได้อย่างโปร่งใสด้วยเงินลงทุนอย่างเดียว" พร้อมยกข้อความจากหน้าเว็บจริงที่บอกว่า PDFgear ดำเนินงานได้โดยไม่ต้องพึ่งรายได้จากโฆษณาหรือข้อมูลผู้ใช้ เพราะมีเงินลงทุนและการเพิ่มประสิทธิภาพทางเทคโนโลยี

    • ผมค่อนข้างระแวง PDFgear เพราะก่อนหน้านี้เคยมีการอัปโหลดขึ้นคลาวด์โดยผู้ใช้ไม่รู้ตัว และดูเหมือนว่าบริษัทจะดูแล subreddit ของตัวเองด้วย

  • วันนี้เพิ่งรู้ว่ามีเครื่องมืออเนกประสงค์สำหรับไฟล์ PDF อยู่เยอะมากแล้ว

  • อยากให้มีฟีเจอร์สร้างสารบัญ (metadata) อัตโนมัติจริง ๆ หนังสือ PDF เก่า ๆ มักไม่มี ทำให้การนำทางลำบากมาก Kybook3 ก็มีเวอร์ชันหนึ่ง แต่ทำงานไม่ค่อยตรงนัก ด้วยเทคโนโลยี LLM สมัยนี้น่าจะเป็นไปได้แล้วหรือเปล่า

    • ผมใช้ pdf.tocgen อยู่ มันไม่อัตโนมัติเต็มร้อย แต่ก็ประหยัดเวลากว่าทำมือทั้งหมดมาก

  • ผมสงสัยว่ายูทิลิตีสำหรับทำ PDF signature แบบอัตโนมัติมีความหมายจริงหรือไม่ เพราะแก่นของการเซ็นคือการที่มนุษย์อ่านและยินยอม แล้วการทำให้มันอัตโนมัติจะถูกต้องหรือ

    • ผมคิดว่าไม่มีเหตุผลเลยที่บริษัทจะไม่เซ็นเอกสารที่ตัวเองสร้างขึ้นแบบอัตโนมัติ และสิ่งที่พูดถึงตรงนี้ไม่ใช่ลายเซ็นที่มองเห็นใน PDF แต่เป็นลายเซ็นเชิงเข้ารหัสที่ทุกคนตรวจสอบผู้ออกเอกสารได้ หรือก็คือช่วยให้ผู้ใช้ตรวจสอบได้ว่าเอกสารยอดเงินของธนาคารมาจากธนาคารจริง

    • CEO ไม่มีเวลามานั่งเซ็นสัญญาพนักงานจำนวนมากอยู่แล้ว แม้แต่ในยุคแอนะล็อกก็ยังมีเลขานุการช่วยประทับตราแทน ดังนั้นการทำลายเซ็นอัตโนมัติก็มีความหมายในทางปฏิบัติ

    • ระบบออกหนังสือรับรองบัญชีธนาคารแบบเซ็นรับรองอัตโนมัติได้ทุกเมื่อที่ต้องการ ผมไม่คิดว่าจะมีใครคาดหวังให้ผู้จัดการสาขานั่งเซ็นคำขอทุกฉบับด้วยตัวเอง

    • ตัวอย่างเช่น ถ้าคุณต้องเซ็น PDF 25 ไฟล์ การตรวจบนหน้าจอแล้ว batch sign ทีเดียว ย่อมสะดวกกว่าการเปิด viewer มาเซ็นทีละไฟล์ด้วยมือ

  • นอกจากที่กล่าวมาข้างต้น ยังมี pdfcpu ที่เป็น "Go PDF processor and CLI" ด้วย GitHub ของ pdfcpu

  • สำหรับผม เครื่องมือ PDF สารพัดประโยชน์ที่นึกถึงคือชุดเครื่องมือ PDF ของ Didier Stevens ลิงก์โปรแกรม