Перетворення файлів .docx у звичайний текст та збереження розривів рядків для підтримки посилань на номер рядка на вихідний документ: як і наслідки?

Я експортую вміст MS Word у звичайний текст для використання з утилітами тексту та файлів. У мене є обмеження, коли функція нумерації рядків була включена в програмному забезпеченні MS, і будь-яке посилання на номери рядків у кінцевому висновку повинно відповідати цій нумерації. Тому введіть "нумерацію рядків":

( По, Е.А. )

Очевидно, що для Word такий тип нумерації не порушує рядки на новому рядку , він розриває "рядки" після правого поля (або чогось іншого). Такий сценарій, як docx2txtправило, не враховує це, як здається, і розбиває рядки на новому рядку. Тож якщо я використовую grep -nнумерацію, рядки не відповідають функції вихідних номерів рядків, як показано вище. З документації не зовсім зрозуміло, як мені потрібно редагувати скрипт Perl для перетворення файлів так, як мені потрібно в цьому випадку:

our $config_newLine = "\n"; # Alternative is "\r\n".
our $config_lineWidth = 80; # Line width, used for short line justification.

Я спробував підставляючи \nдля \r\nале це не схоже на роботу для мене. Тож я вдався до експорту документів безпосередньо з Word із такими налаштуваннями (збережіть як звичайний текст , на v.2013,64pc):

• Unicode (UTF-8)
• Вставити розриви рядків + кінцеві рядки за допомогою (CR / LF)
• Дозволити заміну символів

І тепер дійсно , коли я використовувати ті .txtфайли , є ідеальний збіг між номерами рядків , особливо нумерації джерела і grep -nвиведення.

• Чи є якась конкретна конфігурація / процес, про який я повинен знати, docx2txtабо аналогічна утиліта командного рядка, яка дозволила б мені конвертувати свої файли .docx у звичайний текст, зберігаючи розриви рядків, не вдаючись до Word, як я?
• Які найкращі практики для експорту документів MS Word (які можуть містити символи з наголосом) до звичайного тексту для використання з утилітами файлів / текстів щодо розривів рядків та форматування; чи є якісь негативні наслідки з налаштуваннями, які я вибрав для експорту, тобто вставкою CR / LF?

Зразок

Як було запропоновано, я надаю зразок. У цьому архіві rar я поєднав файл .docx з простими абзацами та експортував його .txt файл, використовуючи Word з вищезазначеними параметрами. Останнє можна порівняти із запуском за замовчуванням docx2txtу вихідному файлі.

docx2txtпрацює над інформацією у docxфайлі, що представляє собою накладений набір файлів XML.

Що стосується обертання рядків, .docxдані XML включають лише інформацію про абзаци та жорсткі перерви, а не про програмні перерви. Проміжні перерви - це результат відображення тексту певним шрифтом, розміром шрифту та шириною сторінки. docx2txtзазвичай намагається вмістити текст у 80 стовпців (80 стовпців налаштовується), не враховуючи шрифту та розміру шрифту. Якщо ваша .docxінформація містить шрифт із системи Windows, яка недоступна в Unix / Linux, то експорт до .txtOpen / LibreOffice також навряд чи призведе до того ж макета, хоча він намагається зробити гарну роботу¹.

Так docx2txtчи будь-яка інша утиліта командного рядка, включаючи обробку Open / LibreOffice, керовану командним рядком, не гарантує перетворення тексту в той самий макет, що й експорт із Word does².

Якщо ви хочете (або змушені клієнтські вимоги) відображати саме так, як це робить Word, на мій досвід існує лише один спосіб: нехай Word робить візуалізацію. Зіткнувшись з подібною проблемою, як і ваша, і маючи несумісні результати за допомогою інших інструментів, включаючи OpenOffice, я повернувся до встановлення Windows VM на хост-сервері Linux. На клієнтській програмі VM програма спостерігає вхідні файли, які потрібно перетворити на хост, що запустить і запустить Word зробити перетворення, а потім скопіювати результат copy.

Рішення про використання лише CR / LF або LF, або UTF-8 або якесь інше кодування .txtзначною мірою залежить від того, як використовуються отримані файли. Якщо отримані файли використовуються в Windows, я б точно перейшов з CR / LF, UTF-8 і UTF-8 BOM . Сучасні програми в Linux здатні визначити, що файл - це UTF-8, але вони не перетворюють на BOM та / або використовують цю інформацію. Ви повинні перевірити всі цільові програми на сумісність, якщо вони відомі наперед.

¹ _{Цей вид несумісності є основною причиною того, що деякі мої друзі не можуть перейти на Linux з Windows, хоча вони цього хочуть. Їм доводиться використовувати MicroSoft Word, як Open / LibreOffice раз у раз обманюючи тексти, якими вони обмінюються з клієнтами.}
² _{Ви можете встановити всі шрифти, які використовуються у файлах Word, а десь час може пощастити для деяких текстів.}
³ _{Надання PDF-файлів від.doc/.docx}
⁴ _{Програма використовує автоматизований графічний інтерфейс (як би хтось клацає на його меню), і не намагається запустити Word через API. Я впевнений, що останнє можна зробити так само і матиме перевагу не руйнувати речі, якщо Word буде модернізований}