OCR văn bản dọc tiếng Nhật: Bảo toàn thứ tự cột và xử lý Furigana

Đối với OCR văn bản dọc tiếng Nhật, hãy kiểm tra chiều viết trước khi thay đổi bộ lọc hình ảnh. Sử dụng mô hình tiếng Nhật và cài đặt phân đoạn có thể xử lý văn bản dọc, xác minh các cột theo đúng thứ tự dự định và quyết định xem bạn chỉ cần văn bản chính hay cần cả furigana. Một trang đầy các ký tự dễ nhận biết vẫn có thể là một bản phiên mã không thể sử dụng nếu thứ tự của chúng bị sai.

Chúng tôi đã chạy một thí nghiệm cục bộ nhỏ, có thể tái tạo để làm cho các quyết định đó trở nên cụ thể. Cấu hình ngang làm xáo trộn ba cột dọc của chúng tôi. Cấu hình dọc khôi phục văn bản thân thuần túy, nhưng việc thêm furigana làm thay đổi hai dấu câu, và việc cắt bỏ chú thích ruby không loại bỏ được lỗi dấu câu.

Đó là kết quả từ một mẫu tổng hợp cố ý nhỏ, không phải là tuyên bố độ chính xác về tất cả các sách tiếng Nhật. Bài học hữu ích hẹp hơn: đánh giá việc nhận dạng ký tự, thứ tự đọc và cách xử lý chú thích một cách riêng biệt. Không gửi kết quả đi dịch chỉ vì nó trông giống tiếng Nhật.

Đầu tiên hãy xác định văn bản bạn thực sự muốn

Trong bố cục dọc truyền thống của tiếng Nhật, các ký tự tiến triển xuống dưới một dòng và các dòng tiến hành từ phải sang trái. Ruby là văn bản nhỏ hơn được liên kết với các ký tự cơ sở; furigana thường cung cấp cách phát âm của chúng. Tài liệu Requirements for Japanese Text Layout của W3C mô tả các hướng viết và mối quan hệ ruby này.

Trước khi thực hiện OCR, hãy dán nhãn các vùng có ý nghĩa của trang:

• các cột dọc chính;
• chú thích ruby nhỏ dọc theo phần thân;
• tiêu đề ngang, chú thích ảnh hoặc bảng;
• số trang và tiêu đề đầu trang;
• ghi chú lề hoặc các trang liền kề không liên quan.

Không coi mọi dải dọc là một đoạn văn độc lập. Một dải kana nhỏ bên cạnh 図書館 có thể là cách đọc của nó, としょかん, không phải câu tiếp theo.

Chọn chính sách đầu ra trước khi đánh giá kết quả OCR:

Cùng một đầu ra có thể đạt qua một tác vụ nhưng lại thất bại ở tác vụ khác. Thử nghiệm của chúng tôi sử dụng phiên âm chỉ gồm phần thân văn bản làm mục tiêu so sánh. Phương pháp này không coi việc thiếu furigana là chấp nhận được đối với một ấn bản dùng để học phát âm.

Một thử nghiệm OCR ba câu thực tế

Mẫu này sử dụng các câu do chính tác giả viết:

朝の図書館で本を読む。
古い地図には川が見える。
明日は友人と駅で会う。

Các câu này mô tả việc đọc sách ở thư viện, nhìn thấy một con sông trên bản đồ cổ và gặp một người bạn ở nhà ga. Có 34 điểm mã Unicode văn bản chính khi loại bỏ dấu ngắt dòng, bao gồm cả ba dấu chấm câu tiếng Nhật.

Chúng tôi đã kết xuất cùng một phần thân văn bản ở ba dạng:

1. Văn bản ngang.
2. Ba cột dọc, đọc từ phải sang trái.
3. Cùng các cột dọc đó kèm theo furigana bên cạnh 図書館, 地図, 友人, và 駅.

Đây là những hình ảnh minh họa sạch, không phải là trang quét từ sách. Trình kết xuất sử dụng phông chữ Noto Sans CJK JP, ký tự văn bản chính 64 pixel, chữ ruby 24 pixel và cách sắp xếp theo chiều dọc từng glyph đơn giản hóa. Nó vẽ các dấu chấm câu dọc thành các vòng tròn nhỏ có viền ở các vị trí được chọn thủ công thay vì sử dụng định vị glyph dọc chuẩn của phông chữ; do đó, kết quả dấu câu không phản ánh chính xác hiệu suất của OCR đối với một cuốn sách được dàn trang đúng chuẩn. Nó không tái tạo mọi quy tắc dàn trang tiếng Nhật. Không có hiện tượng mờ, lệch, kết cấu giấy, chữ viết tay, kiểu chữ lịch sử hoặc trang có hướng kết hợp trong bài kiểm tra này.

Công cụ, mô hình và cài đặt

Thử nghiệm được thực hiện vào ngày 7 tháng 9 năm 2026, sử dụng Tesseract.js 7.0.0 với Tesseract.js-core 7.0.0 chạy cục bộ trên macOS ARM64. Tất cả các lệnh gọi thành công đều sử dụng chính thức tessdata_fast các mô hình tại commit 87416418657359cb625c412a48b6e1d6d41c29bd, với OEM 1, chế độ công cụ chỉ dùng LSTM.

Kho lưu trữ mô hình chính thức của Tesseract cung cấp riêng biệt jpn và jpn_vert các tệp. Tài liệu của nó mô tả PSM 5 là một khối căn chỉnh theo chiều dọc đồng nhất và PSM 6 là một khối văn bản đồng nhất; hãy chọn giả định phân đoạn phù hợp với vùng đang được nhận dạng. Xem tài liệu phân đoạn trang.

Các trường hợp được ghi lại của chúng tôi đã sử dụng jpn với PSM 6 cho văn bản ngang, jpn_vert với PSM 5 cho văn bản dọc, và một sự không khớp có chủ ý jpn/PSM 6 điều khiển theo chiều dọc. Cả thay đổi mô hình và phân đoạn đều diễn ra giữa hai cấu hình dọc, vì vậy đây là sự so sánh quy trình làm việc chứ không phải là một thí nghiệm cô lập hiệu ứng của riêng cài đặt nào.

Một nỗ lực ban đầu với tessdata_best đã bị hủy bỏ trong lõi WebAssembly khả dụng trước khi tạo ra văn bản OCR. Chúng tôi đã chuyển sang số nguyên chính thức tessdata_fast các mô hình để tương thích và ghi lại lỗi đó. Không có kết luận nào về độ chính trị của một họ mô hình được rút ra từ việc chuyển đổi đó.

Kết quả thực tế trả về

Phép so sánh loại bỏ khoảng trắng và áp dụng chuẩn hóa Unicode NFC. Nó không thay thế dấu câu, sửa chữ kanji hay sắp xếp lại văn bản. Hoàn chỉnh các đầu ra thô và mã băm phiên bản/mô hình, CSV so sánh thân bài, và chú thích lỗi có thể tải xuống.

Ví dụ, trường hợp furigana đã trả về dòng đầu tiên này:

Expected: 朝の図書館で本を読む。
Observed: 朝 の 図書 館 で 本 を 読む .

Quy tắc so sánh đã nêu của chúng tôi bỏ qua khoảng trắng nhưng không bỏ qua dấu câu cuối câu. Một quy trình chỉ dựa trên tìm kiếm có thể châm chước sự khác biệt đó, nhưng một bản chuyển tự chuẩn xác cần phải ghi nhận và chỉnh sửa nó.

Kiểm soát chiều dọc bị lệch bắt đầu từ 明 古 昌, nhảy qua các ký tự trên cùng của các cột thay vì tuân theo câu đầu tiên dự định. Kết quả của nó minh họa lý do tại sao việc nhận dạng các ký tự đơn lẻ không giống với việc tái tạo lại trình tự đọc.

Đã có bảy lệnh gọi OCR hoàn tất: bốn trường hợp nguyên ảnh và ba trường hợp cắt xén. Chúng tôi giữ lại mọi kết quả. Một tác nhân đã so sánh các kết quả với dữ liệu thực tế đã được soạn thảo và kiểm tra trực quan các hình ảnh; không có đánh giá mù quáng từ con người hay cơ sở dữ liệu chuẩn rộng rãi. Thử nghiệm không xác định được công cụ tốt nhất trên toàn cầu, tỷ lệ chính xác cấp độ sách, hay hiệu suất trên bản quét của bạn.

Sử dụng quy trình ưu tiên vùng trên trang của riêng bạn

1. Giữ nguyên nguồn và chọn một trang khó

Giữ nguyên hình ảnh hoặc tệp PDF gốc. Làm việc trên một bản sao và ghi lại số trang. Chọn một trang chứa vấn đề bạn đang cố gắng giải quyết: furigana dày đặc, lề hẹp, tiêu đề ngang nằm trên văn bản dọc, hoặc kiểu chữ nhỏ bất thường.

Một trang tiêu đề sạch sẽ không phải là một bài kiểm tra chấp nhận hữu ích cho một cuốn sách mà các trang nội dung có bố cục khác. Nếu nguồn là một tệp PDF, hãy trích xuất hoặc kết xuất trang đã chọn bằng một công cụ bạn tin tưởng trước khi chạy quy trình OCR chỉ gồm hình ảnh. Các tập lệnh trong bài viết này chấp nhận tệp PNG; chúng không xử lý tệp PDF hoặc xây dựng các lớp PDF có thể tìm kiếm.

Để biết toàn bộ quá trình chuẩn bị và dịch tài liệu được quét, hãy sử dụng quy trình PDF được quét rộng hơn. Hướng dẫn này tập trung vào các quyết định về hướng, phân đoạn, furigana và chuyển tự tiếng Nhật.

2. Khắc phục các lỗi chụp ảnh mà không làm hỏng văn bản nhỏ

Kiểm tra các ký tự thực tế ở mức thu phóng hữu ích. Làm thẳng các góc nghiêng ngoài ý muốn, loại bỏ các viền trang không liên quan và duy trì độ tương phản đủ để phân biệt các chữ kana nhỏ và dấu câu. Tránh coi việc ngưỡng hóa hoặc làm sắc nét mạnh mẽ là một sự cải thiện tự động: hãy so sánh hình ảnh kết quả với bản gốc trước khi tin tưởng kết quả OCR.

Hướng dẫn về chất lượng hình ảnh của Tesseract đề cập đến độ phân giải, nhiễu, độ nghiêng và viền. Những yếu tố đó tách biệt với hướng viết. Việc làm thẳng một trang được chụp ở góc nghiêng không phải là thao tác giống như xoay văn bản tiếng Nhật dọc thẳng đứng sang một bên.

Các tệp mẫu mang siêu dữ liệu 300 dpi, nhưng con số đó không tạo ra các chi tiết bị thiếu. Kích thước glyph nội dung thực tế của chúng là 64 pixel. Một bức ảnh độ phân giải thấp được dán nhãn lại là “300 dpi” vẫn là bức ảnh độ phân giải thấp đó.

3. Tách các vùng khi trang vi phạm một giả định về bố cục

Hãy thử khối dọc chính một mình trước khi yêu cầu một lệnh gọi OCR xử lý tiêu đề ngang, văn bản dọc, hình minh họa và số trang. Giữ một bản ghi vùng đơn giản chẳng hạn như “trang 12, nội dung, cột 1 từ bên phải”. Bản ghi đó giúp cho việc lắp ráp sau này có thể được kiểm toán.

Đối với tài liệu có nhiều hướng khác nhau, hãy nhận dạng vùng ngang với cài đặt ngang thích hợp và vùng dọc với cài đặt dọc, sau đó lắp ráp chúng theo thứ tự mà tài liệu mong muốn. Đây là một quy trình được khuyến nghị để thử nghiệm trên tệp của bạn, không phải là khả năng bố cục hỗn hợp được đo lường bằng ba hình ảnh mẫu của chúng tôi.

Thử nghiệm cắt xén của chúng tôi đã sử dụng các tọa độ đã biết chính xác để loại trừ dải furigana bên cạnh mỗi cột tổng hợp trong khi vẫn giữ lại văn bản nội dung và lề trắng. Đó là một bản minh họa lựa chọn vùng thủ công, không phải là một thuật toán loại bỏ furigana tự động. Không áp dụng tọa độ của nó cho một trang sách thực tế.

4. Kiểm tra các cột trước khi rà soát từng ký tự

So sánh các ký tự nội dung đầu tiên và cuối cùng của mỗi cột, làm việc theo hướng dự định. Xác nhận rằng không có cột nào bị thiếu, bị trùng lặp, bị đảo ngược hoặc bị trộn lẫn với cột lân cận. Sau đó kiểm tra các câu ở ranh giới các cột.

Chỉ sau đó, bạn mới nên sửa từng kanji, kana, dấu câu, số và tên riêng. Nếu không, bạn có thể tốn thời gian trau chuốt các phân đoạn bị lắp ráp nhầm đoạn văn.

Quy trình xem xét ba bước hữu ích là:

1. Vùng và thứ tự: mọi vùng nội dung dự kiến đều xuất hiện một lần và đúng trình tự.
2. Ký tự: so sánh ảnh thực tế với văn bản, bao gồm cả các dấu câu nhỏ và ký hiệu kana.
3. Chú thích: quyết định xem từng mục ruby, ghi chú hay nhãn bên lề có được giữ lại, tách riêng hay chủ động loại bỏ.

Chỉ số độ tin cậy của một bộ máy không thể thay thế cho các bước kiểm tra này. Bài kiểm tra xáo trộn của chúng tôi vẫn trả về một con số độ tin cậy do bộ máy cung cấp; điều đó không làm cho thứ tự đọc của nó trở nên chấp nhận được.

Đừng xóa furigana cho đến khi bạn biết lý do tại sao

Đối với việc trích xuất chỉ văn bản chính, ruby không nên vô tình trở thành lớp văn bản thứ hai. Tuy nhiên, việc xóa mọi chuỗi kana nhỏ không phải là quy tắc chung an toàn. Cách đọc có thể giúp làm rõ một cái tên, bảo tồn cách phát âm do tác giả lựa chọn hoặc hỗ trợ nhiệm vụ học tập của người đọc.

Trong hình ảnh furigana của chúng tôi, đầu ra OCR chứa các kanji chính nhưng không trả về bốn cách đọc như một tập chú thích riêng biệt. Điều đó có thể là đủ sau khi sửa dấu câu cho một tác vụ tìm kiếm chỉ văn bản. Nó sẽ không đủ nếu sản phẩm cam kết cung cấp thông tin phát âm.

Lưu trữ các cách đọc quan trọng một cách riêng biệt và liên kết chúng với lần xuất hiện phù hợp. Ví dụ:

Page: sample 1
Column: 1 from the right
Base text: 図書館
Reading shown: としょかん
Decision: retain body text; save reading in the annotation record

Mẫu bản phiên âm ruby riêng biệt làm cho chính sách đó trở nên rõ ràng. Đó là dữ liệu gốc được tạo ra cùng với hình ảnh, chứ không phải tuyên bố thành công của OCR.

Nếu OCR trộn lẫn kana vào một từ hoặc làm mất liên kết của nó, hãy so sánh với hình ảnh và sửa lại bản phiên âm. Đừng yêu cầu một mô hình ngôn ngữ đoán nguồn gốc rồi trình bày phỏng đoán đó như là văn bản được khôi phục. Thay vào đó, hãy đánh dấu một cách đọc không chắc chắn để xem xét lại.

Kết quả cắt ảnh cũng phản bác quy tắc đơn giản hóa “xóa ruby và mọi thứ đều cải thiện”: hai điểm khác biệt về dấu câu vẫn còn, và phần kết thúc câu bị ảnh hưởng đã thay đổi. Nhận xét đó thuộc về bộ mẫu thử nghiệm sạch cụ thể này. Nó cho thấy chúng ta cần xác minh kết quả sau khi phân đoạn, chứ không có nghĩa là việc cắt ảnh nói chung luôn có ích hoặc có hại cho OCR.

Tái tạo bài kiểm tra hoặc duy trì nhật ký xem xét

Tải xuống tệp README thử nghiệm để biết các nguồn mô hình và phông chữ được ghim, phiên bản phần phụ thuộc, mô tả tệp và các lệnh. trình tạo mẫu, trình chạy OCR, và tập lệnh so sánh tách biệt việc tạo, nhận dạng và đánh giá hình ảnh.

Trình chạy sử dụng API worker của Tesseract.js đã được ghi lại tài liệu. Đối với một vùng dọc, các thiết lập cơ bản của nó là:

const worker = await createWorker("jpn_vert", 1, {
  langPath: modelDirectory,
  gzip: false,
  cacheMethod: "none",
});
await worker.setParameters({
  tessedit_pageseg_mode: "5",
  user_defined_dpi: "300",
});

modelDirectory phải chứa tệp jpn_vert.traineddata đã tải xuống và giải nén. Đây là một đoạn trích, không phải chương trình hoàn chỉnh; trình chạy được cung cấp cũng lưu các kết quả thô và chấm dứt các worker.

Nếu bạn sử dụng ứng dụng OCR khác, hãy giữ nguyên các bằng chứng ngay cả khi tên thiết lập khác nhau: vùng nguồn, tệp gốc, phiên bản mô hình hoặc công cụ, hướng, lựa chọn phân đoạn, kết quả thực tế, văn bản đã sửa và các ký tự chưa giải quyết. biểu mẫu nhật ký đánh giá để trống để không ngầm hiểu rằng các trang của bạn đã được thông qua.

Đừng chuyển đổi kết quả khớp chính xác nhỏ của chúng tôi thành một tỷ lệ phần trăm được hứa hẹn cho toàn bộ cuốn tiểu thuyết. Các phông chữ khác nhau, cột đông đúc, hình thức lịch sử, bản quét chất lượng thấp và bong bóng hội thoại manga đòi hỏi các bài kiểm tra đại diện của riêng chúng. Bố cục manga và nhận dạng chữ viết tay nằm ngoài thí nghiệm này.

Chỉ dịch khi nguồn được khôi phục đáng tin cậy

Nếu mục tiêu của bạn là tìm kiếm, sao chép trích dẫn hoặc tra cứu từ điển, văn bản tiếng Nhật đã được xác minh có thể là kết quả cuối cùng. Bạn không cần phải dịch toàn bộ tài liệu chỉ vì có liên quan đến OCR.

Nếu rào cản ngôn ngữ vẫn cản trở việc đọc và bạn có một tệp khả dụng để tải lên, hãy tiếp tục với quy trình dịch PDF. Bảo lưu bản quét gốc và bản phiên âm đã kiểm tra để bạn có thể phân biệt lỗi nhận dạng với lỗi dịch thuật. Trình chạy mẫu tạo ra các tệp văn bản và TSV, chứ không phải tệp PDF sẵn sàng để tải lên tự động; hãy chuẩn bị định dạng đầu vào thực tế mà công cụ tiếp theo của bạn yêu cầu.

Chế độ OCR của BookTranslator tái tạo nội dung đã dịch thay vì đảm bảo bố cục dọc ban đầu. Đừng giả định rằng nó sẽ bảo lưu mọi liên kết ruby hoặc sửa chữa các lỗi nhận dạng chưa được xác minh. Xem xét thứ tự đọc và định dạng của tài liệu cuối cùng bằng cách sử dụng hướng dẫn bảo 1lưu định dạng PDF và bảng kiểm tra QA PDF cuối cùng.

Việc bàn giao đáng tin cậy không phải là “OCR đã hoàn thành.” Mà là “văn bản tiếng Nhật dự định đã có mặt, trình tự của nó đã được kiểm tra, và việc xử lý các chú thích đã được ghi lại.”