Копирование + вставка текста на иврите из файлов PDF приводит к неправильному копированию последних букв
Поэтому я получил несколько PDF-файлов на иврите, которые я хотел перевести на английский, и при попытке скопировать и вставить текст из PDF-файлов в текстовый редактор все конечные буквы на иврите были неправильно скопированы.
Я нашел этот вопрос, но решение не было найдено, и этот вопрос говорил только об одном конкретном последнем письме, которое было неправильно прочитано, и это было только ссылка на определенную библиотеку.
Я попытался скопировать и вставить как из Acrobat Reader, так и из Chrome PDF Viewer, но не удалось правильно скопировать содержимое с обоими.
Еще одна интересная вещь, которую я нашел, заключается в том, что когда вы нажимаете Ctrl+F в браузере (я пробовал это на chrome) и, например, выполняете поиск последней буквы "Pe", это даст результаты как для обычного "Pe", так и для конечного "Pe" "(и наоборот, при поиске обычного"Pe"), даже если у них разные кодовые точки (и разные коды в кодовой странице ANSI), что также странно. (Это одинаково для всех последних букв и соответствующих им обычных букв)
Итак, вопрос - кто-нибудь знает, почему это происходит?
Я понимаю, что может не быть действительной кодовой точки, сопоставленной с глифом, но в таком случае как получаются символы? Я не очень знаком с этим предметом, поэтому я был бы признателен за любое объяснение. Кроме того, любое хорошее решение, которое позволит мне извлечь текст с последними буквами, будет очень цениться, так как я хотел бы проанализировать текст, и перепутывание букв приводит к неполным словам.
РЕДАКТИРОВАТЬ:
По просьбе weibeld я добавляю несколько скопированных слов и соответствующие им правильные слова. Я также добавлю их hexdump.
E1 F7 F8 1B בקר. # Should be בקרן (Final letter "Nun") Switches every
final Nun with 1B instead of EF according to the windows 1255 code page.
F2 F1 F7 E9 E9 17 עסקיי. # Should be עסקיים (Final letter "Mem") Switches
every final Mem with 17 instead of ED.
Спасибо!
2 ответа
Таким образом, основываясь на ваших изменениях, файл PDF, похоже, использует какую-то странную (не ASCII-совместимую) ивритскую кодировку для извлечения текста, которая помещает окончательные формы букв в 1X область, где в ASCII находятся непечатные управляющие символы.
Если все, что вам нужно, - это восстановить текст в PDF, самое простое решение может заключаться не в том, чтобы изменить PDF, а в том, чтобы заменить неправильные коды на правильные после копирования текста из PDF.
Например, вставьте текст, скопированный из PDF в file а потом:
cat file | tr '\033' '\357' | tr '\027' '\355' >out_file
То есть один tr за каждое неверное последнее письмо. Число 033, 357 и т.д. - это только восьмеричные формы шестнадцатеричных байтов 1B, EFи т. д., что вы узнали с hexdump, Просто найдите оставшиеся отображения и добавьте их в цепочку. затем out_file должен содержать правильно закодированный текст, и вы можете открыть его в каком-либо текстовом редакторе с помощью Windows-1255.
В PDF Reference практически ничего не говорится о том, как правильно кодировать нелатинский текст не-CJK для извлечения текста (ничего не требуется для рендеринга глифов), но есть два основных способа сделать это: первый - иметь таблицу ToUnicode. (как для простых, так и для составных шрифтов), второе, для простых шрифтов, это указать словарь кодирования с массивом различий, идентифицирующий каждый глиф с именем из реестра Adobe (например, https://github.com/adobe-type-tools/agl-aglfn/blob/master/glyphlist.txt).
Кодировка Identity-H подразумевает составной (двухбайтовый) шрифт, который может иметь таблицу ToUnicode. Пользовательская кодировка подразумевает словарь кодирования с массивом различий. Стандартное кодирование подразумевает, что не было задано (или пользовательское) кодирование.
Сочетание всех трех вместе подразумевает очень запутанное происхождение.