Bộ chuyển đổi PDF sang HTML miễn phí

Trích xuất văn bản từ tài liệu PDF và chuyển nó thành HTML ngữ nghĩa sạch. Xem trước tức thì và tải xuống hoặc sao chép mã.

Dữ liệu của bạn không bao giờ rời khỏi thiết bị
Thả PDF tại đây hoặc nhấp để duyệt (tối đa 10 MB)

Đang xử lý…

Về chuyển đổi PDF → HTML

Công cụ này sử dụng PDF.js để trích xuất văn bản từ tệp PDF và xuất ra HTML ngữ nghĩa. Lý tưởng để chuyển đổi tài liệu sang định dạng tương thích web, lưu trữ nội dung hoặc chuẩn bị văn bản cho xử lý tiếp theo.

Trường hợp sử dụng phổ biến

Câu hỏi thường gặp

Kích thước PDF nào được hỗ trợ?

Công cụ này có thể xử lý PDF lên đến khoảng 10 MB tùy thuộc vào trình duyệt của bạn. Các PDF rất lớn hoặc phức tạp có thể mất nhiều thời gian xử lý hơn.

Nó có giữ định dạng PDF không?

Công cụ trích xuất nội dung văn bản và xuất ra dưới dạng đoạn văn. Bố cục phức tạp, hình ảnh và kiểu được đơn giản hóa thành HTML sạch.

Tôi có thể tải xuống HTML không?

Có. Nhấp « Tải xuống HTML » để lưu nội dung đã chuyển đổi thành tệp .html, có thể mở trong bất kỳ trình duyệt hoặc trình soạn thảo nào.

Lịch sử ngắn về PDF, từ PostScript đến tài liệu di động

Định dạng Tài liệu Di động là ý tưởng của John Warnock, đồng sáng lập Adobe Systems, người trước đó đã đồng phát minh PostScript, ngôn ngữ mô tả trang vốn từ năm 1985 với Apple LaserWriter đã làm cho xuất bản để bàn trở nên khả thi. PostScript cực kỳ mạnh mẽ nhưng là ngôn ngữ lập trình, không phải định dạng tài liệu: một tệp PostScript mô tả cách hiển thị trang khi đưa vào trình thông dịch, nhưng không thực sự được dùng để đọc, chỉnh sửa hay hiển thị nhất quán trên các máy thiếu phông chữ phù hợp.

Năm 1991, Warnock lưu hành một bản ghi nhớ nội bộ Adobe được gọi là Dự án Camelot. Tiền đề: Adobe sẽ xây dựng một định dạng tệp duy nhất có thể lưu bất kỳ tài liệu nào (bao gồm phông chữ, bố cục, đồ họa vector và hình ảnh) và tái tạo nó giống hệt trên mọi máy tính, mọi hệ điều hành, bất kể ứng dụng nào đã tạo ra nó. Khi đề xuất được tinh chỉnh, dự án có tên sản phẩm: Adobe Acrobat.

Acrobat 1.0 và PDF 1.0 được trình diễn tại triển lãm thương mại Comdex Fall ở Las Vegas vào tháng 11 năm 1992 và chính thức bán ra vào tháng 6 năm 1993. Quyết định thương mại then chốt của Adobe đến vào năm 1994 khi họ bắt đầu phát hành miễn phí Acrobat Reader, động thái phản chiếu những gì đã xảy ra với trình duyệt HTML và gieo mầm hàng triệu lượt cài đặt. Định dạng trải qua nhiều phiên bản, PDF 1.1 (1996, liên kết ngoài và bảo mật), 1.2 (1996, AcroForms), 1.3 (2000, chữ ký số), 1.4 (2001, trong suốt), 1.5 (2003, luồng đối tượng và JPEG 2000), 1.6 (2004, OpenType và 3D), 1.7 (2006). Năm 2008, PDF 1.7 được xuất bản theo ISO 32000-1:2008; PDF 2.0 tiếp theo theo ISO 32000-2:2017, với ấn bản thứ hai được sửa đổi đáng kể (ISO 32000-2:2020) tích hợp các lỗi đính chính và là tài liệu tham chiếu có thẩm quyền hiện tại.

Nhiều hồ sơ PDF chuyên biệt tồn tại bên cạnh tiêu chuẩn chính: PDF/A (ISO 19005-1:2005, với -2 năm 2011 và -3 năm 2012) là hồ sơ lưu trữ ngăn các tính năng phụ thuộc vào tài nguyên ngoài hoặc phần mềm tương lai (không JavaScript, không âm thanh, không mã hóa, phông chữ phải nhúng vào); PDF/X là hồ sơ in ấn trước được ngành in sử dụng; PDF/E là hồ sơ kỹ thuật cho bản vẽ kỹ thuật; PDF/UA (ISO 14289-1:2014) là hồ sơ tiếp cận phổ quát yêu cầu cấu trúc logic và gắn thẻ để trình đọc màn hình có thể trình bày nội dung theo thứ tự đọc; PDF/VT là hồ sơ biến đổi và giao dịch được dùng trong trộn thư cá nhân hóa.

Tại sao chuyển đổi PDF sang HTML khó về mặt cấu trúc

PDF ở cấp độ thấp nhất là tập hợp các đối tượng được đánh số (từ điển, mảng, chuỗi, số, tên và luồng nhị phân) được bố trí với bảng tham chiếu chéo ở cuối cho phép trình đọc nhảy đến bất kỳ đối tượng nào mà không cần phân tích cú pháp toàn bộ tệp. Các đối tượng tạo thành cây có gốc trong đối tượng Catalog trỏ đến cây Pages, chứa các đối tượng Page. Mỗi Page tham chiếu đến một luồng nội dung: các lệnh thực tế vẽ trang.

Luồng nội dung là một chuỗi các toán tử đồ họa nhỏ gọn trong ngôn ngữ nhỏ liên quan đến PostScript nhưng không Turing-đầy đủ. Đối với văn bản, nó sử dụng Tf (đặt phông và cỡ chữ), Td (di chuyển vị trí văn bản), Tm (đặt ma trận văn bản), Tj (hiển thị một chuỗi), TJ (hiển thị mảng chuỗi với độ lệch ký tự tùy chọn để kerning) và ET (kết thúc văn bản). Điểm mấu chốt là mọi thứ đều là vị trí. Một đoạn văn bản không được lưu trữ như một đoạn. Nó được lưu trữ như một loạt lệnh Tj hoặc TJ, mỗi lệnh vẽ một glyph hoặc chuỗi ngắn các glyph tại tọa độ x và y cụ thể trên trang. Không có khái niệm về câu, đoạn, tiêu đề, danh sách hay cột, chỉ có câu hỏi mỗi ký tự nằm ở đâu về mặt vật lý.

HTML là nghịch đảo: cây phần tử ngữ nghĩa linh hoạt trong đó bố cục là trách nhiệm của trình hiển thị và cùng một HTML có thể sắp xếp lại phù hợp với điện thoại, máy để bàn hay trình đọc màn hình. Do đó, chuyển đổi PDF sang HTML đòi hỏi phải kỹ thuật ngược một cấu trúc mà PDF không bao giờ cần ghi lại. Bộ chuyển đổi phải nhìn vào sự phân bố không gian của văn bản trên mỗi trang và suy ra:

Không có gì trong số này được giải quyết bằng cách đọc luồng nội dung theo thứ tự, vì thứ tự trong luồng không nhất thiết là thứ tự đọc. Một công cụ bố cục tạo ra PDF có thể đã vẽ các phần tử theo thứ tự hiệu quả nhất cho việc hiển thị, có thể là từ trên xuống theo kiểu zig-zag, hoặc theo phông chữ, hoặc theo màu sắc. Văn bản của một đoạn đơn lẻ có thể xen kẽ với văn bản từ các đoạn lân cận trong luồng cơ bản. Đó là lý do tại sao các bộ trích xuất PDF chỉ đơn giản nối chuỗi theo thứ tự luồng tạo ra kết quả bị xáo trộn cho bất kỳ thứ gì phức tạp hơn một cuốn tiểu thuyết một cột.

Nếu PDF đã được gắn thẻ: tức là tác giả đã bao gồm cây cấu trúc bên cạnh nội dung trực quan, công việc trở nên dễ dàng hơn nhiều. PDF được gắn thẻ bao gồm một phân cấp các phần tử cấu trúc (P cho đoạn, H1 đến H6 cho tiêu đề, L cho danh sách, LI cho mục danh sách, Table, TR, TD, Figure, Caption) phản ánh từ vựng ngữ nghĩa của HTML. PDF/UA bắt buộc gắn thẻ cho khả năng tiếp cận chính xác vì PDF không gắn thẻ về cơ bản là mờ đục với công nghệ hỗ trợ. Tuy nhiên, trên thực tế, phần lớn PDF ngoài thực tế không được gắn thẻ, hoặc được gắn thẻ kém bởi công cụ tạo tác, vì vậy bộ chuyển đổi mạnh mẽ phải quay lại phân tích bố cục ngay cả khi có thẻ.

Các thư viện hiển thị PDF mã nguồn mở lớn

PDF.js là thư viện JavaScript được Mozilla viết, ban đầu ra mắt vào tháng 6 năm 2011 như một dự án thử nghiệm do Andreas Gal dẫn dắt. Nó phân tích cú pháp và hiển thị PDF hoàn toàn trong trình duyệt bằng HTML5 canvas và JavaScript, không cần plugin gốc. PDF.js được tích hợp vào Firefox làm trình xem PDF mặc định từ Firefox 19 vào tháng 3 năm 2013, thay thế plugin Adobe Reader. Nó cung cấp API JavaScript cho phép trang trích xuất nội dung văn bản với siêu dữ liệu vị trí (mỗi đoạn văn bản trả về với tọa độ x, y, chiều rộng, chiều cao, tên phông và cỡ phông). Công cụ này được xây dựng trên PDF.js.

Poppler là thư viện C++ được fork từ xpdf, trình xem PDF lâu đời do Glyph and Cog duy trì từ cuối những năm 1990. Poppler cung cấp tính năng hiển thị PDF cho môi trường máy tính để bàn Linux (Evince trong GNOME, Okular trong KDE), các tiện ích dòng lệnh pdftotext và pdftohtml, và nhiều quy trình xử lý PDF phía máy chủ. MuPDF, của Artifex Software (công ty cũng duy trì Ghostscript), là thư viện C nhỏ hơn và nhanh hơn hướng đến sử dụng nhúng. PDFium là công cụ tích hợp trong Google Chrome và Microsoft Edge để xem PDF tích hợp sẵn; nó là fork của Foxit PDF SDK độc quyền mà Google và Foxit cùng mở mã nguồn vào tháng 5 năm 2015. qpdf là thư viện C++ và công cụ dòng lệnh tập trung vào thao tác cấu trúc hơn là hiển thị, có thể giải nén, mã hóa, giải mã, tuyến tính hóa và viết lại PDF mà không thay đổi nội dung trực quan.

Đối với việc tạo đầu ra HTML cụ thể, dự án mục đích đặc biệt quan trọng nhất là pdf2htmlEX, ban đầu được viết bởi Lu Wang năm 2012 và hiện được duy trì bởi một nhóm cộng đồng. pdf2htmlEX áp dụng cách tiếp cận khác với hầu hết bộ chuyển đổi: thay vì cố gắng tái tạo HTML ngữ nghĩa, nó tái tạo bố cục trực quan của PDF trung thực nhất có thể bằng cách phát ra các phần tử div định vị tuyệt đối cho mỗi đoạn văn bản, nhúng phông gốc dưới dạng tệp Web Open Font Format (WOFF) và sử dụng CSS transform khi cần. Kết quả là trang web trông không phân biệt được với PDF gốc, nhưng HTML cơ bản là bức tường các span position: absolute không có ý nghĩa ngữ nghĩa.

Độ trung thực bố cục so với luồng ngữ nghĩa, sự đánh đổi trung tâm

Đây là sự đánh đổi trung tâm trong chuyển đổi PDF sang HTML: bạn có thể có độ trung thực bố cục hoặc có luồng ngữ nghĩa, nhưng khó có cả hai. Bộ chuyển đổi ưu tiên trung thực như pdf2htmlEX tạo ra đầu ra in và trông giống bản gốc nhưng mờ đục với trình đọc màn hình và cứng nhắc trên màn hình điện thoại. Bộ chuyển đổi ưu tiên luồng như pdftotext hoặc getTextContent của PDF.js theo sau bởi tái tạo đoạn đơn giản tạo ra HTML sạch, dễ đọc, có thể tiếp cận, nhưng mất đi sự phong phú trực quan của nguồn, màu sắc, phông chính xác, vị trí hình ảnh, lưới bảng và bất kỳ cảm giác nào về trang gốc.

Công cụ Absolutool đứng vững ở phía ưu tiên luồng. Nó trích xuất nội dung văn bản bằng PDF.js và phát ra dưới dạng đoạn văn, ưu tiên khả năng đọc, tiếp cận và kích thước tệp nhỏ hơn so với tái tạo pixel hoàn hảo. Nếu bạn cần tuyến đường tái tạo trực quan (mọi glyph ở vị trí gốc, phông nhúng, phân trang chính xác) pdf2htmlEX là công cụ cần xem; nếu bạn cần tuyến đường đoạn có thể đọc (tái sử dụng nội dung, xuất bản web, HTML có thể lập chỉ mục tìm kiếm, đầu ra có thể tiếp cận bởi trình đọc màn hình) công cụ này phù hợp.

Phông nhúng, hình ảnh và nội dung vector bên dưới

PDF có thể nhúng bất kỳ phông nào, và bộ chuyển đổi muốn giữ nguyên giao diện gốc có ba lựa chọn. Nhúng và phục vụ: bộ chuyển đổi trích xuất từng phông nhúng từ PDF, đóng gói lại thành phông web ở định dạng trình duyệt hiểu (WOFF hoặc, từ năm 2018, WOFF2 với nén Brotli tích cực hơn) và liên kết từ HTML được tạo. Điều này giữ nguyên giao diện gốc nhưng tăng kích thước tệp và có thể gặp vấn đề bản quyền nếu quyền nhúng phông không bao gồm phân phối lại web. Thay thế: ánh xạ mỗi phông nhúng thành phông hệ thống tương tự (phông có chân của PDF có thể thành Times New Roman hoặc Georgia), chấp nhận một số sai lệch trực quan để đổi lấy đầu ra nhỏ hơn, gọn hơn. Bỏ qua: loại bỏ hoàn toàn thông tin phông và để trình duyệt áp dụng phông nội dung mặc định, đây là lựa chọn của hầu hết bộ chuyển đổi ưu tiên luồng vì người dùng đọc HTML với kiểu dáng bình thường của trình duyệt.

Hình ảnh đặt ra lựa chọn tương tự. Bộ chuyển đổi có thể trích xuất hình ảnh nhúng thành các tệp riêng và tham chiếu từ HTML; raster hóa toàn bộ trang thành hình ảnh và nhúng nội tuyến (biến PDF thành thư viện ảnh đơn giản); hoặc bỏ hoàn toàn hình ảnh và chỉ phát văn bản, đây là lựa chọn của công cụ này, phù hợp cho tái sử dụng nội dung hơn là tái tạo trực quan. Nội dung vector (đường, hình dạng, đường dẫn do toán tử đồ họa PDF vẽ) còn phức tạp hơn, vì không có cách sạch để biểu diễn nó trong HTML ngữ nghĩa; các bộ chuyển đổi muốn giữ nó thường chuyển sang SVG nội tuyến hoặc raster hóa PNG.

Khi PDF là hình ảnh: OCR dự phòng cho tài liệu quét

Một tỷ lệ đáng kể PDF ngoài thực tế không thực sự là tài liệu theo nghĩa có cấu trúc, chúng là hình ảnh quét của tài liệu giấy, đóng gói trong vỏ PDF vì PDF là định dạng phổ quát để gửi những thứ giống giấy tờ qua internet. PDF quét không có luồng nội dung văn bản; mỗi trang là một hình ảnh raster nhúng đơn lẻ tình cờ mô tả văn bản nhưng không chứa nó dưới dạng ký tự máy đọc được. Trích xuất văn bản từ PDF như vậy đòi hỏi Nhận dạng Ký tự Quang học (OCR), một thao tác về cơ bản khác với trích xuất văn bản.

Công cụ OCR mã nguồn mở thống trị là Tesseract, ban đầu được phát triển tại HP Labs từ năm 1985 đến 1995, mở mã nguồn năm 2005, và được Google duy trì từ năm 2006 cho đến khi Google chuyển quyền quản lý chính cho một nhóm cộng đồng vào khoảng năm 2018. Tesseract hỗ trợ hơn một trăm ngôn ngữ, chạy trên mọi nền tảng lớn và cung cấp tính năng OCR cho vô số công cụ máy tính để bàn và máy chủ. Vision framework của Apple, có sẵn trên macOS và iOS từ năm 2017, bao gồm API nhận dạng văn bản nhanh và chính xác được sử dụng bởi ứng dụng chụp màn hình và ảnh tích hợp của hệ điều hành. Google Cloud Vision, Azure Computer Vision và Amazon Textract là các dịch vụ OCR đám mây lớn; đặc biệt cho tài liệu, Textract và Azure's Document Intelligence đều vượt ra ngoài OCR thô để nhận dạng bảng, cặp khóa-giá trị và trường biểu mẫu.

Bộ chuyển đổi PDF sang HTML dựa trên trình duyệt chạy hoàn toàn phía khách không thể thực hiện OCR, các mô hình OCR có kích thước hàng chục megabyte tối thiểu và suy luận quá chậm để chạy tương tác trên laptop của người dùng. Nếu PDF của bạn chứa các trang quét không có văn bản có thể trích xuất, công cụ này sẽ tạo ra đầu ra trống cho những trang đó, và bước tiếp theo phù hợp là công cụ OCR riêng biệt hoặc dịch vụ phía máy chủ.

Tại sao mọi người chuyển đổi PDF sang HTML

Các trường hợp sử dụng rơi vào một số mẫu lặp đi lặp lại:

Mỗi loại có yêu cầu hơi khác nhau, nhưng chúng chia sẻ một điểm chung: người dùng muốn nội dung của PDF (các từ, cấu trúc, ý nghĩa) mà không bị ràng buộc bởi định dạng cứng nhắc theo trang mà tài liệu gốc đã chọn.

Câu hỏi thêm

Tại sao HTML được chuyển đổi của tôi trông khác với PDF gốc?

Công cụ này ưu tiên luồng: nó trích xuất văn bản và phát ra các đoạn sạch bằng phông mặc định của trình duyệt, ưu tiên khả năng đọc, tiếp cận và lập chỉ mục tìm kiếm hơn là trung thực trực quan. Nếu bạn cần tái tạo pixel hoàn hảo của bố cục gốc (phông nhúng, vị trí chính xác, màu gốc) hãy xem các công cụ ưu tiên trung thực như pdf2htmlEX, vốn phát ra các phần tử div định vị tuyệt đối khớp với PDF nguồn về mặt trực quan nhưng tạo ra HTML về cơ bản không thể đọc được bởi trình đọc màn hình và cứng nhắc trên màn hình điện thoại.

Tại sao PDF nhiều cột của tôi bị xáo trộn?

PDF không lưu thứ tự đọc, chỉ có vị trí. Bộ chuyển đổi phải suy ra ranh giới cột từ sự phân bố không gian của văn bản. Đối với bố cục hai cột đơn giản, phép tắc heuristic thường hoạt động; đối với bố cục phức tạp với ghi chú bên, chú thích cuối trang xen kẽ với văn bản chính hoặc văn bản vượt qua rãnh cột, nó có thể tạo ra đầu ra không đúng thứ tự. Nếu bạn có PDF được gắn thẻ (một PDF bao gồm cây cấu trúc), độ chính xác cải thiện đáng kể; đối với PDF không gắn thẻ, kết quả phụ thuộc vào mức độ rõ ràng mà các cột được phân tách bằng khoảng trắng.

PDF của tôi là bản quét (chỉ là hình ảnh), tại sao không có gì được trích xuất?

PDF quét không có nội dung văn bản, mỗi trang là hình ảnh raster của văn bản thay vì văn bản mà trình phân tích cú pháp có thể đọc. Trích xuất văn bản đòi hỏi OCR (Tesseract, Google Cloud Vision, Vision framework của Apple, v.v.), là thao tác về cơ bản khác với phân tích cú pháp PDF. Công cụ này không tích hợp công cụ OCR vì các mô hình quá lớn để tích hợp với công cụ trình duyệt. Bước tiếp theo phù hợp là dịch vụ OCR chuyên dụng hoặc công cụ máy tính để bàn có OCR tích hợp.

Tôi có thể chuyển đổi PDF được bảo vệ bằng mật khẩu không?

Nếu PDF có mật khẩu mở (bạn cần nhập mật khẩu để xem), PDF.js sẽ báo lỗi thay vì chuyển đổi. Nếu PDF chỉ có mật khẩu quyền (mở tự do nhưng in/sao chép bị hạn chế), hành vi khác nhau, hầu hết các bản dựng PDF.js hiện đại tôn trọng các quyền và có thể từ chối trích xuất văn bản. Dù thế nào, con đường sạch nhất là xóa bảo vệ trong công cụ PDF gốc trước, rồi chuyển đổi. Xóa bảo vệ trên PDF bạn hợp pháp sở hữu là ổn; thực hiện trên PDF bạn không sở hữu có thể không.

Công cụ liên quan

Văn bản → CSV

Chuyển dữ liệu dạng bảng sang CSV.

Trình mã hóa Base64

Mã hóa các tệp sang Base64.

Trình định dạng JSON

Định dạng và xác thực JSON.