- Công cụ CLI mã nguồn mở dựa trên Python do nhóm py-pdf phát triển để thao tác với tệp PDF
- Cung cấp nhiều tính năng chỉnh sửa PDF như hiển thị metadata, trích xuất và gộp trang, xóa trang, chuyển ảnh thành PDF, nén tài liệu, tạo booklet, v.v.
- Cũng hỗ trợ các tính năng chuyên sâu như trích xuất hình ảnh và văn bản chú thích từ PDF hoặc khôi phục xref của PDF bị hỏng do chỉnh sửa thủ công
- Trong phiên bản 0.5.0 phát hành gần đây, đã bổ sung các tính năng mới như ký và xác minh tài liệu PDF, chỉ trích xuất các trang có chú thích, xoay các trang cụ thể
Công cụ PDF CLI mã nguồn mở pdfly
- pdfly là dự án mới nhất của tổ chức py-pdf, một công cụ dòng lệnh để thao tác với tệp PDF chạy trong môi trường Python
- Được phát triển dựa trên các thư viện fpdf2 và pypdf, dễ cài đặt và sử dụng nên có thể áp dụng trên nhiều nền tảng
- Điểm mạnh lớn nhất của pdfly là hỗ trợ tính năng rất rộng so với các dự án mã nguồn mở cạnh tranh, cùng giao diện trực quan mà cả lập trình viên mới cũng dễ dùng
- So với các dự án khác, công cụ này có thể xử lý dễ dàng phần lớn tác vụ PDF chỉ bằng một công cụ, nên hiệu quả rất cao
Các tính năng chính
-
Hiển thị metadata
- Hỗ trợ hiển thị metadata PDF thông qua các lệnh
pdfly meta và pdfly pagemeta
- Cung cấp dữ liệu hệ điều hành như tên tệp, quyền, kích thước, thời gian tạo/sửa/truy cập
- Hiển thị dữ liệu nội bộ của PDF như phiên bản PDF, số trang, trạng thái mã hóa, thông tin phông chữ, tệp đính kèm, số lượng hình ảnh
-
Kết hợp và chỉnh sửa tài liệu
pdfly cat: tính năng trích xuất các trang cụ thể và gộp tài liệupdfly rm: tính năng xóa trang có chọn lọcpdfly x2pdf: chuyển ảnh thành tài liệu PDFpdfly compress: tính năng nén tài liệupdfly 2-up và pdfly booklet: tính năng tạo booklet
-
Trích xuất nội dung
pdfly extract-images: trích xuất hình ảnh từ PDFpdfly extract-annotated-text: trích xuất văn bản có chú thích
-
Khôi phục PDF
pdfly update-offsets: sửa bảng xref của PDF đã bị chỉnh sửa thủ công bằng trình soạn thảo văn bản để có thể mở lại- Bảng xref là chỉ mục byte offset trong tài liệu và có thể bị hỏng khi chỉnh sửa thủ công
- Phiên bản pdfly 0.5.0 được phát hành vào ngày 13 tháng 10 năm 2025
pdfly sign: có thể thêm chữ ký điện tử vào tài liệu PDF một cách dễ dàngpdfly check-sign: tính năng xác minh chữ ký của tài liệu PDFpdfly extract-annotated-pages: chỉ trích xuất các trang có chú thích để hỗ trợ rà soát lặp lại và làm lại trên các tài liệu lớnpdfly rotate: tính năng xoay các trang cụ thể của tài liệu
Kế hoạch sắp tới
- Nhiều ý tưởng tính năng đa dạng đang được chuẩn bị trong các issue
up-for-grabs trên GitHub
- Các issue gắn nhãn
good first issues dành cho người đóng góp mới cũng đã sẵn sàng, nhằm khuyến khích cả người mới bắt đầu với mã nguồn mở tham gia
- Dự kiến sẽ tập trung phát triển mở rộng các tính năng liên quan đến chữ ký điện tử như
pdfly sign và check-sign
- Rất hoan nghênh phản hồi từ người dùng, báo cáo lỗi và đề xuất tính năng
https://github.com/py-pdf/pdfly
2 bình luận
Tôi từng dùng Moduui PDF, nhưng rồi đã tự làm một công cụ PDF chỉ hỗ trợ một số tính năng (trích xuất, gộp, xóa, xoay, đổi thứ tự) để tiện cho nhu cầu cá nhân và đang dùng nó. Tôi dùng
pdf.js/pdf-lib.jsđể chạy trên trình duyệt. Trước khi tự làm công cụ riêng, tôi cũng đã tìm thử và thấy có vô số công cụ lẫn website liên quan đến PDF.Ý kiến trên Hacker News
Đây là ý kiến từ 10 năm trước nhưng tôi nghĩ đến giờ vẫn còn đúng. Chỉ riêng các thư viện Python thôi cũng đã có cực nhiều thư viện cung cấp các chức năng liên quan đến PDF theo kiểu chồng lấn từng phần. Các ngôn ngữ khác cũng tương tự, có vô số thư viện. Xét cho cùng, mỗi thư viện chỉ là một gói gồm nhiều chức năng để biến đổi các cấu trúc dữ liệu tương tự nhau. Vì vậy, để xử lý các tác vụ PDF phức tạp thì thường phải kết hợp hai ba thư viện với nhau, điều này kém hiệu quả cả từ góc độ lập trình viên lẫn tài nguyên tính toán. Nếu có ai đó tạo ra các struct đọc/ghi PDF cấp thấp, được thiết kế tốt trong bộ nhớ bằng Rust, tôi nghĩ toàn bộ hệ sinh thái sẽ cải thiện rất nhiều. Bất kỳ ngôn ngữ hay thư viện PDF nào cũng có thể tận dụng các struct đó, và khi áp dụng thì mã nguồn có thể ngắn hơn, nhanh hơn và an toàn hơn. Và nếu chỉ cần cung cấp
get_structure_pointer()vàset_structure_pointer()thì các thư viện cũng có thể tự do liên kết với nhau. Với kiểu cấu trúc này, các thư viện nhỏ có thể dễ dàng bổ sung tính năng và được chấp nhận nhanh hơn. Thực tế thì tôi không biết ai sẽ làm việc này, nhưng tôi thật sự nghĩ là rất cần thiếtKhi xây dựng thư viện PDF thì luôn tồn tại các đánh đổi thiết kế bất tận tùy theo mục đích sử dụng. Bản thân “trong bộ nhớ” đã là một lựa chọn lớn rồi. Vì định dạng PDF vốn được thiết kế để không cần phải tải toàn bộ PDF lên bộ nhớ cùng lúc. Và nếu bạn là người ưa thích các mô-đun sâu với giao diện tối thiểu, thì chắc chắn bạn sẽ không coi việc tạo ra một mô-đun nông nhưng có bề mặt chức năng rộng là câu trả lời. Cuối cùng, trong các môi trường được quản lý như JVM, thư viện làm bằng giao diện C còn tạo thêm độ phức tạp và overhead. Liên kết liên quan
Tôi đồng ý với ý kiến “nếu có một struct PDF trong bộ nhớ được làm tốt bằng Rust thì hệ sinh thái sẽ được cách mạng hóa”. Nhưng chỉ riêng việc tạo ra một thư viện tốt hơn hẳn mọi thư viện hiện có đã không hề dễ, chưa nói đến việc liên tục cập nhật, sửa lỗi và bảo trì thì còn khó hơn nhiều. Ngay cả khi có đủ tài chính, bạn vẫn phải tìm được người có đủ nhiệt huyết để làm việc đó năm này qua năm khác; nếu người đó mất hứng thú thì lại phải tìm người kế nhiệm, và trong khoảng chuyển giao ấy thì chắc chắn cũng phải chấp nhận những sự bất mãn. Tóm lại, tôi muốn gửi lời cảm ơn trước tới người tình nguyện sẽ dành cả đời để xây dựng và duy trì thứ này
Khi thấy câu chuyện “sẽ tuyệt nếu có một struct PDF trong bộ nhớ xuất sắc viết bằng Rust”, tôi muốn chia sẻ dự án mã nguồn mở thực sự đang tồn tại là lopdf
Ngay lúc này tôi cũng đang debug vấn đề phân tích PDF, và cuối cùng lại đi đến chỗ tự viết parser. Tôi đã cố gắng hiểu các parser hiện có, nhưng mã nguồn quá cẩu thả nên rốt cuộc phải tự triển khai. Thành thật mà nói, định dạng PDF đã trở nên khá phức tạp do trong quá trình mở rộng nó bị trộn lẫn đủ loại giải pháp chắp vá và các tính năng bị nhồi nhét quá mức. Ý tưởng ban đầu thì hay, nhưng trong PDF có quá nhiều loại đối tượng và thuộc tính đặc biệt, nên mỗi lần binding thứ này thì rốt cuộc lại lặp lại sự phức tạp của FFI. Có khi nên tạo một ánh xạ chính thức giữa PDF và JSON, để miễn là không vướng vấn đề bộ nhớ thì các thư viện lớn có thể trao đổi dữ liệu với nhau. Dù sao mô hình đối tượng cũng không khác nhau hoàn toàn
Có người đùa rằng toàn bộ cuộc thảo luận này có thể được tóm gọn bằng một trang XKCD, rồi chia sẻ liên kết tới truyện tranh đó
Poppler không được mô tả kỹ trên trang chủ chính thức, nhưng thực tế là một thư viện đi kèm bộ công cụ rất đa dạng và cũng dễ dùng trên các bản phân phối Linux. Đây là bộ công cụ tôi đã dùng rất tốt nhiều lần. Liên kết wiki liên quan
Tôi đã dùng các công cụ này để phân tích hàng trăm nghìn phiếu lương PDF và đưa dữ liệu lên một hệ thống tài chính mới. Tôi chấm 10/10, rất hài lòng
Bình thường tôi cũng hay dùng các công cụ poppler. Tôi nghĩ chúng thực sự xuất sắc
Với các tác vụ cấp thấp thì qpdf khá hữu ích
Còn có pdfcpu.io. Tuy vậy, nếu chỉ cần chỉnh sửa PDF đơn giản thì việc tìm một ứng dụng GUI mã nguồn mở, đa nền tảng là cực kỳ khó. Thực ra đến giờ tôi vẫn chưa tìm được
Tôi từng dùng tốt PDF SAM basic (“split and merge”). Liên kết trang web Nó là mã nguồn mở, đa nền tảng, và cũng có thêm các tính năng chỉ có ở bản trả phí
Nếu có thể tự host thì Signature PDF cũng khá ổn. Liên kết dự án
Có lẽ pdf24 tools cũng ổn. Nó còn hỗ trợ cài đặt ngoại tuyến
Tôi đã thử
pdfcpu images list, và giật mình khi thấy nó bắt đầu tải một phông chữ nào đó từ bên ngoài về máy cục bộ. Mới tháng 10 thôi mà đã thấy quá đáng sợ nên tôi bỏ qua luônSau một hồi đắn đo, cuối cùng tôi quyết định dùng giấy phép trả phí Creative Cloud. Acrobat đơn giản là hoạt động tốt nên đành chịu. Tôi thực sự muốn có phương án thay thế, nhưng trên thực tế không có lựa chọn nào thật sự tương xứng
Tôi muốn giới thiệu PDFgear. Nó chưa phải loại cao cấp hoàn toàn, nhưng đối với việc chỉnh sửa PDF tầm trung như một lựa chọn thay Adobe thì gần như là thứ duy nhất dùng được, lại còn miễn phí và có mặt trên mọi nền tảng trừ Linux
Nghe nói hỗ trợ mọi thứ trừ Linux, vậy bản nhị phân cho OpenVMS, Apple II và DEC Alpha ở đâu thế, có người đùa như vậy
Còn có Master PDF, và cái này có cả bản cho Linux, nên có người chia sẻ liên kết
Dù nhìn có vẻ ổn, tôi vẫn thấy khó tin với lập luận kiểu “miễn phí, không quảng cáo, không bán dữ liệu, vận hành minh bạch chỉ bằng vốn đầu tư”. Người này còn trích nguyên phần giải thích trên trang chủ, rằng PDFgear vận hành nhờ vốn đầu tư và tối ưu công nghệ chứ không kiếm tiền từ quảng cáo hay dữ liệu
Tôi có chút nghi ngờ với PDFgear. Trước đây nó từng tải dữ liệu lên cloud mà người dùng không biết, và có dấu hiệu công ty tự quản lý cả subreddit của mình
Điều tôi học được hôm nay: đã có cực kỳ nhiều công cụ đa năng cho file PDF rồi
Tôi rất muốn có tính năng tự động tạo mục lục (metadata). Các file PDF sách cũ không có thứ này nên việc điều hướng rất bất tiện. Kybook3 cũng có một phiên bản tính năng đó nhưng không hoạt động chuẩn. Với công nghệ LLM hiện nay, có lẽ chuyện này đã khả thi rồi chăng
Tôi tự hỏi liệu một tiện ích tự động hóa việc ký PDF có thật sự có ý nghĩa không. Bản chất của chữ ký là con người đã đọc và đồng ý, nên việc tự động hóa nó có đúng không cũng đáng nghi ngờ
Tôi nghĩ không có lý do gì để một công ty lại không tự động ký lên các tài liệu do chính họ tạo ra. Chữ ký ở đây không phải là chữ ký hiển thị bằng hình ảnh trong PDF, mà là chữ ký mật mã để bất kỳ ai cũng có thể xác minh bên phát hành. Tức là một tính năng cho phép người dùng xác nhận sao kê ngân hàng thực sự đến từ ngân hàng
CEO thì không có thời gian để ký vô số hợp đồng nhân viên. Ngay từ thời analog, thư ký đã làm vai trò đóng dấu thay rồi, nên việc tự động hóa ký là điều có ý nghĩa trong thực tế
Giấy xác nhận tài khoản ngân hàng có thể được phát hành và ký tự động bất cứ khi nào cần. Tôi không nghĩ ai lại mong giám đốc chi nhánh phải ngồi ký từng đơn một
Ví dụ nếu phải ký 25 file PDF, thì thay vì thao tác thủ công từng cái trong trình xem, sẽ tiện hơn nếu xem xét trên màn hình rồi ký hàng loạt một lần
Ngoài những thứ đã được nhắc đến ở trên, còn có pdfcpu, một “Go PDF processor and CLI”. GitHub của pdfcpu
Với tôi, công cụ PDF vạn năng mà tôi từng nghĩ đến chính là bộ công cụ PDF của Didier Stevens. Liên kết chương trình