Комментарии 2
Документы Офиса 2007 и более поздних - это XML в зипе. Для них не надо специальных библиотек. Нужна только распаковка zip и парсинг XML. Дальше просто берем для корневого элемента innerText.
Вот так это выглядит на C#:
using System;
using System.IO;
using System.IO.Compression;
using System.Xml;
namespace DocxToText
{
class Program
{
static void Main(string[] args)
{
string docxFilePath = args[0];
XmlDocument doc = new XmlDocument();
using (ZipArchive arch = ZipFile.OpenRead(docxFilePath))
{
ZipArchiveEntry ent = arch.GetEntry("word/document.xml");
using (Stream readStream = ent.Open())
{
doc.Load(readStream);
}
}
string text = doc.DocumentElement.InnerText;
Console.WriteLine(text);
}
}
}
Есть, конечно, у такого подхода недостатки: InnerText не содержит пробелов на месте границ тегов. Т.е. абзацы склеены не просто в одну строку, а еще и без пробела.
Кроме того, грузить весь документ в память абсолютно незачем.
Обе проблемы решаются SAX-парсером.
А как у вашего конвертера потребление памяти зависит от размера документа?
Да, все верно, поздние версии файлов MS Office, как и форматы Open Office, более открыты к извлечению текста. Однако, такие документы в нашем потоке составляют ~7% - остальное это pdf (~70%), и rtf с doc.
По поводу памяти и производительности. Как видно из постановки задачи (часть no/low-code процесса) и выбора средств (универсальный парсер-аггрегатор, основанный на внешних утилитах) - серьезная работа не проводилась.
Могу сказать, что при локальном запуске контейнера в Docker Desktop он при старте забирает ~25-26 Мб и дрейфует около этого значения (с учетом, что используется tmfs).
Тот же локальный экземпляр сервиса проводит конвертацию фалов (приведено к вреднему времени за 1000 символов выходного текста):
- docx - 5,3 ms
- pdf - 9.8 ms
- rtf - ~ 10 ms (но очень большой разброс в зависимости от файлов)
- doc - 5 ms
Преобразование офисных файлов в текст