Vegyes nyelvű PDF OCR-feldolgozása: a kínai, az angol és a számok külön ellenőrzése
Válassz OCR-nyelveket egy vegyes kínai–angol PDF-hez, nézd meg valódi mintakimeneteket, és ellenőrizd a karaktereket, azonosítókat, számokat és táblázatkapcsolatokat.

Vegyes nyelvű PDF OCR-feldolgozásához azonosítsd az oldalon található írásrendszereket, válassz egy olyan eszközt, amely a megfelelő felismerési nyelvekkel tudja feldolgozni a PDF-et, majd vesd össze a kinyert szöveget a képpel. A kínai szöveget, az angol szöveget, a számokat és a címkekapcsolatokat külön-külön ellenőrizd. Az, hogy egy angol címet megtalálsz a keresésben, még nem jelenti azt, hogy a kínai törzsszöveget is felismerte a rendszer.
Egy további nyelv hozzáadása tesztelésre érdemes, nem automatikus javulás. A kis kínai–angol kísérletünkben az angol hozzáadása kijavított egy angol címkét, de károsított egy kínai mondatot, amelyet a csak kínai beállítás helyesen ismert fel. Két táblázatkonfigurációnk egyike sem adott vissza szöveget egy egyszerű vonalas táblázatból.
Ez nem a többnyelvű OCR általános elítélése. Inkább ok arra, hogy a szükséges kimenetet ítéld meg, ne a kiválasztott nyelvek számát.
Először különböztesd meg a hiányzó szöveget a hibás szövegtől
Az eredeti fájlt hagyd változatlanul. Egy másolaton jelölj ki egy mondatot egy reprezentatív oldalról, és illeszd be egy egyszerű szövegszerkesztőbe. Próbálj ki egy kínai és egy angol szövegrészt, ne csak a dokumentum címét.
| Amit tapasztalsz | Mit tegyél ezután |
|---|---|
| Semmit sem lehet kijelölni vagy másolni | Tekintsd az oldalt esetlegesen csak képből állónak, és futtass OCR-t. |
| A szöveg másolható, de a karakterek eltérnek a látható oldaltól | Vizsgáld meg a hibás meglévő szövegréteget; pusztán a megnyitás és mentés változatlanul hagyhatja. |
| Egyes oldalak helyesen másolhatók, mások nem | Leltározd fel az érintett oldalakat, mielőtt teljes dokumentumra kiterjedő műveletet alkalmaznál. |
| A szavak helyesen másolhatók, de a sorok vagy bekezdések összeolvadnak | A szegmentálást és az olvasási sorrendet a felismerési nyelvtől függetlenül ellenőrizd. |
A meglévő szövegréteg számít. Például a NAPS2 OCR-dokumentációja szerint az importált PDF-oldalakat, amelyek már tartalmaznak szöveget, érintetlenül hagyja. Egy rosszul OCR-elt oldal újraimportálása ezért ebben a munkafolyamatban nem megbízható javítási módszer.
Ha a valódi probléma az alacsony felbontású, görbült vagy ferde szkennelés, azt előbb javítsd, mielőtt egy nyelvi beállítások összehasonlítását értelmeznéd. A szkennelt PDF-ekről szóló átfogó útmutatónk kitér erre az előkészítésre és a későbbi fordítási szakaszokra is.
A felismerési nyelveket válaszd ki, ne a fordítás célnyelvét
A felismerés arra válaszol, hogy „milyen karakterek vannak ezen az oldalon?” A fordítás arra, hogy „hogyan kellene ezt a tartalmat egy másik nyelven olvasni?” Ne kérd az OCR-től, hogy csendben egyszerűsítse a hagyományos kínait, lefordítson egy angol idézetet, vagy átírjon egy ismeretlen azonosítót.
Készíts rövid leltárt:
- Kínai írás: egyszerűsített, hagyományos vagy mindkettő, beleértve a címsorokat és a jegyzeteket.
- Latin szöveg: angol mondatok, szerzőnevek, hivatkozások, rövidítések és típusszámok.
- Vezérelt értékek: dátumok, tizedespontok, mértékegységek, negatív előjelek, azonosítók és kis- és nagybetűre érzékeny kódok.
- Területek: folyószöveg, táblázatok, képaláírások, lábjegyzetek vagy külön nyelvű függelék.
Egy hagyományos kínai jelentés például tartalmazhat angol absztraktot és hivatkozásokat. Egy egyszerűsített kínai fejezet tartalmazhat egy táblázatot A-01, 23.5 és °C értékekkel. Egyiket sem szabadna csupán a leghosszabb kínai bekezdés vizsgálatával értékelni.
A Tesseract külön chi_sim, chi_tra és eng modelleket kínál a hivatalos modell-tárolójában. A parancssori dokumentációja támogatja a kombinált nyelvválasztást, és megjegyzi, hogy a nyelvek sorrendje befolyásolhatja az eredményeket. Ezek konfigurációs lehetőségek, nem garanciák arra, hogy minden további modell segít.
Ha a dokumentumod ehelyett függőleges japán oszlopokat és furiganát tartalmaz, használd a japán függőleges OCR útmutatót. Ez egy más elrendezési és jelölési probléma, nem csupán egy újabb nyelvi jelölőnégyzet.
Olyan munkafolyamatot használj, amely valóban elfogad PDF-eket
Asztali útvonal: NAPS2
A NAPS2 dokumentált módszert kínál a beolvasott PDF-ek kereshetővé tételére:
- Importáld a fájl egy másolatát, és nyisd meg az OCR-beállításokat.
- Töltsd le a dokumentumhoz szükséges felismerési nyelveket.
- Válaszd a Több nyelv lehetőséget, és jelöld ki a releváns nyelveket.
- Engedélyezd a kereshető PDF OCR-t, és mentsd új fájlba.
- Nyisd meg újra a fájlt, és hasonlítsd össze a kimásolt kínai, angol és numerikus szöveget a látható oldallal.
A többnyelvű választás akkor jelenik meg, ha egynél több nyelvet töltöttél le. Ezek a lépések a hivatalos NAPS2 útmutatót követik; ehhez a cikkhez nem végeztünk gyakorlati NAPS2-tesztet.
Parancssori útvonal: OCRmyPDF
Egy csak képet tartalmazó egyszerűsített kínai/angol PDF esetén a hivatalos dokumentáción alapuló példa:
ocrmypdf -l chi_sim+eng --output-type pdf \
--sidecar recognized.txt input.pdf searchable.pdf
Először telepítsd a szükséges nyelvi csomagokat. Hagyományos kínai teszthez használj chi_tra-t ahelyett, hogy feltételeznéd, hogy az írásrendszerek felcserélhetők.
Az OCRmyPDF szakácskönyv dokumentálja a PDF- és a sidecar-szöveg kimeneteket. A sidecar nem feltétlenül a teljes dokumentum: azoknak az oldalaknak a szövege, amelyek már tartalmaztak szöveget, vagy amelyeket az OCR során kihagytak, hiányozhat. Ellenőrizd magát a kimeneti PDF-et. A meglévő hibás OCR szándékos újrafeldolgozási munkafolyamatot igényel; ne kényszerítsd minden oldal raszterizálását anélkül, hogy megértenéd, mit változtat.
Ez egy dokumentáción alapuló útvonal, nem a mért tesztkörnyezetünk. Itt nem futtattuk az OCRmyPDF-et.
A sima Tesseractnak renderelt oldalakra van szüksége
Ne használd a tesseract input.pdf ... parancsot úgy, mintha PDF-olvasó lenne. A Tesseract nem fogad el PDF bemenetet, bár PDF kimenetet tud előállítani. A Tesseract.js ugyanezt a PDF-bemeneti megkülönböztetést alkalmazza: először rendereld az oldalakat egy PDF-könyvtárral, majd ismerd fel a képeket.
Ez az alábbi kísérletünkben használt útvonal. Szöveget és TSV-bizonyítékot állít elő, nem tesztelt kereshető kimeneti PDF-et.
Mi történt tíz helyi OCR-hívás során
Létrehoztunk egy háromoldalas, csak képet tartalmazó PDF-et, amely a következőket tartalmazza:
- egyszerűsített kínai próza angol hivatkozásokkal, azonosítókkal, tizedesjegyekkel és mértékegységekkel;
- egy megfelelő hagyományos kínai oldal;
- egy kis kínai-angol táblázat három adatsorral.
A szöveg és az értékek saját készítésű oktatási anyagok, nem ügyfélfájlok vagy valós mérések. Minden prózai cél 124 nem szóköz karaktert tartalmaz, köztük 41 han karaktert. A táblázat 79 nem szóköz karaktert tartalmaz.

A PDF forrásoldalain nem volt kinyerhető szöveg. Poppler 26.08.0-val rendereltük őket 300 dpi felbontással, 1600×1000 pixeles képeket előállítva. A betűméret 48 pixel volt Noto Sans CJK SC/TC Regular betűtípusban. Minden írásjel a betűtípusok szokásos vízszintes glyphjeiből származott.
2026. szeptember 8-án helyben futtattuk a Tesseract.js 7.0.0-t a tesseract.js-core 7.0.0-val macOS ARM64-en. A hivatalos tessdata_fast modellek a 87416418657359cb625c412a48b6e1d6d41c29bd commitra voltak rögzítve. Minden hívás OEM 1 és PSM 6 beállítást használt, az egységes szövegblokk beállítást, ugyanazzal az oldalképpel minden nyelvi összehasonlításhoz.
Négy nyelvi recept volt minden prózai oldalhoz és kettő a táblázathoz. Mind a tíz hívás befejeződött; egyetlen eredményt sem dobtunk el, és egyetlen paramétert sem hangoltunk a kimenet láttán. A pontos bemenetek, modell-hashek, verziók és nyers eredmények és a reprodukciós utasítások elérhetők.
Egy beállítás javíthat az egyik mezőn és ronthat a másikon
A hagyományos oldalon a chi_tra sorrendben megtartotta mind a 41 han karaktert, de továbbra is elkövetett nem kínai hibákat. Például a Document ID angol címkét Document 1ID-re változtatta, és félreolvasta a fokjelet.
Az eng hozzáadása visszaállította a Document ID-t, de a hőmérsékletre és tömegre vonatkozó mondat egy része latin betűs töredékekké vált:
Expected: 樣本溫度為 23.5 °C,質量為 1.08 kg。
Observed with chi_tra+eng: RA MEA 23.5°C > HBA 1.08 kg。
A számok megmaradtak abban a sorban, míg a környező kínai nem. Ha csak a 23.5-öt és az 1.08-at ellenőriztük volna, elkerülte volna a figyelmünket a kár.
Az egyszerűsített oldal más kompromisszumot mutatott. Az angol hozzáadása visszaállította a BK-2026-A07-et, amelyet a csak kínai futtatás BK-2026-AO7-ként adott vissza. De máshol a 与-t 5-re változtatta. A vizuálisan kétértelmű O0I1-l azonosító hibás maradt.
A következő diagnosztikák mutatják, miért nem hirdettünk győztest:
| Bemenet és nyelvválasztás | Han-szekvencia szerkesztések | Megtalált védett karakterláncok |
|---|---|---|
Bármelyik prózai oldal, csak eng | 41 várt han karakterből 41 hiányzik | 10-ből 9 |
Egyszerűsített oldal, chi_sim | 1 | 10-ből 7 |
| Egyszerűsített oldal, bármelyik kínai/angol sorrend | 2 | 10-ből 8 |
Hagyományos oldal, chi_tra | 0 | 10-ből 9 |
| Hagyományos oldal, kínai/angol sorrendben | 9 | 10-ből 9 |
Táblázat, eng vagy chi_sim+eng | Nem adott vissza szöveget | 9-ből 0 |
A „Han-sequence edits” csak a kínai írásjegyeket hasonlítja össze. Nem pontozza az angol szöveget, az írásjeleket vagy a szóközöket. A „Protected strings found” csak azt ellenőrzi, hogy az előre meghatározott azonosítók, számok, mértékegységek és hivatkozási tokenek jelen vannak-e; nem ellenőrzi a pozíciójukat vagy a kapcsolatukat. A csak angol kimenetek mutatják a csapdát: a legtöbb védett karakterlánc jelen volt, mégis egyetlen kínai írásjegy sem került vissza.
A teljes összehasonlító CSV a teljes szöveg szerkesztési távolságait is jelenti. Az összehasonlítás Unicode NFC-t alkalmaz és eltávolítja a szóközöket; nem javítja az írásjeleket, nem változtatja meg a kis- és nagybetűket, nem alakítja át a kínai írásmódokat és nem rendezi át a karaktereket. A nyelvi sorrend megfordítása megváltoztatta a szóközöket ezekben a prózai kimenetekben, de a normalizált karaktersorozatot nem. Ez a megfigyelés nem általános szabály a nyelvi sorrendre vonatkozóan.
Az üres táblázat nem sikeres kinyerés

Mindkét táblázathívás üres szöveget adott vissza, annak ellenére, hogy OCR-végrehajtási hiba nélkül fejeződtek be. A kínai hozzáadása nem mentette meg a rögzített, egységes blokkokra épülő receptet.
Nem teszteltünk más szegmentálási módokat, cellakivágásokat vagy táblázatfelismerő motort. Az eredmény ezért nem azt mutatja, hogy a Tesseract nem tud táblázatokat olvasni. Azt mutatja, hogy a felismerési nyelv önmagában történő megváltoztatása nem oldotta meg ezt a mintát az általunk használt beállítások mellett.
Egy valódi táblázat esetén követelje meg a teljes Temperature → A-01 → 23.5 → °C kapcsolatot, ne csak azt, hogy négy token valahol az oldalon megtalálható legyen. Ha a kimenet üres, vagy a kapcsolatok nem ellenőrizhetők, ne tekintse megbízható átiratnak. Próbáljon elrendezésre érzékeny munkafolyamatot, vagy írja át a szükséges cellákat a kép alapján.
Mit nem tud megállapítani ez a kísérlet
Ez három tiszta, szintetikus oldal egyetlen betűtípuscsaládból, amelyet egyetlen íróügynök vizsgált felül. Nem volt vak, emberi felülvizsgálat, éles dokumentumkorpusz, sem elmosódott szkennelések, kézírás, összetett táblázatok, függőleges szöveg vagy történelmi karakterek tesztje.
Az eredmények hasznos ellenpéldák a feltétel nélküli „adjunk hozzá több nyelvet” szabályra. Nem motorrangsor, nem általános pontossági arány és nem előrejelzés az Ön PDF-jére vonatkozóan. Ez nem BookTranslator-teszt volt, és a csak képet tartalmazó forrás-PDF nem OCR-rel elkészített olvasmány.
Négylépéses elfogadási ellenőrzést alkalmazzon a saját fájlján
Töltse le a üres ellenőrzőlapot. Válasszon egy oldalt, amely tartalmazza a tényleges nehézséget, majd a teljes fájl feldolgozása előtt adja hozzá a következő ellenőrzéseket:
- Kínai szöveg: hasonlítson össze egy teljes mondatot, beleértve a kevésbé gyakori írásjegyeket és a szándékolt egyszerűsített/hagyományos alakokat. Ne normalizáljon csendben egy hibás írásjegyet a várt írásjegyre.
- Angol szöveg és azonosítók: vizsgálja meg a szerzőneveket, hivatkozásokat, rövidítéseket, a kis- és nagybetűhasználatot, valamint a hasonló kinézetű karaktereket, például az
O/0vagyI/l/1esetében. Az ismeretlen kód nem szó, amelyet automatikusan javítani kellene. - Számok és mértékegységek: hasonlítsa össze az egyes értékeket az előjelükkel, tizedespontjukkal, mértékegységükkel és címkéjükkel. A
0.05és a0.50maradjon megkülönböztethető; egy felismert23.5a helyes mértékegység nélkül hiányos. - Kapcsolatok és teljesség: ellenőrizze, hogy minden bekezdés vagy táblázatsor ott van-e, ahol várható. Győződjön meg arról, hogy a képaláírások, jegyzetek és a kisebb, másodlagos nyelvű szövegrészek is jelen vannak, nem csak a fő szöveg.
Jegyezze fel az eredeti szöveget, a megfigyelt eredményt, az oldalt/régiót és a szükséges műveletet. Ha egy konfiguráció javít egy ellenőrzésen, de ront egy másikon, mindkét megfigyelést tartsa meg. Ne fogadja el a fájlt egyetlen megbízhatósági pontszám vagy átlagos karakterszám alapján.
Különíts el három kimenetet: az adott célra változatlanul használható, konkrét javításokat igényel, vagy még nem megbízható. Egy keresési feladathoz elég lehet egyetlen ellenőrzött szövegrész; egy teljes olvasmányhoz a dokumentum teljes lefedettsége szükséges, nem egy tiszta címlap.
Csak azután fordíts, hogy tudod, mit mond a forrás
Ha a keresés és a másolható eredeti szöveg megoldja a problémádat, állj meg itt. Az OCR elvégezte a dolgát; a fordítás külön döntés.
Ha a teljes dokumentumot egy másik nyelven kell elolvasnod, tartsd meg az eredeti szkennelt és a javított szöveget referenciaként, majd kövesd a szkennelt PDF fordítása munkafolyamatot. Egy alkalmas fájl esetében a BookTranslator PDF-fordítója lehet a következő lépés. Az OCR módja a lefordított tartalmat rekonstruálja, nem ígéri az eredeti oldalelrendezéssel való pontos egyezést; nem szünteti meg a kinyert szöveg és a táblázatok közötti kapcsolatok ellenőrzésének szükségességét.
Fordítás után használd a PDF-fordítás ellenőrzőlistáját, hogy megkülönböztesd a forrásfelismerési hibát a fordítási vagy elrendezési hibától. A rossz szakasz javítása az, ahogy egy olvasható hiba bekerül a végleges fájlba.
Kapcsolódó bejegyzések





