Что такое parser для word

Парсер поддерживает следующие типы файлов Word:

• .doc, .docx, .docm, и т.п. — «обычные» документы Word
• .rtf, .odt и другие форматы, поддерживаемые Word

Для сбора данных из файлов Word используется стандартный алгоритм парсера файлов, со следующими особенностями:

1. Для чтения файла используется действие «Загрузить содержимое из файла MS Word», с параметром «Тип результата» text или HTML:
    

   Действие	Параметр	Значение
   Загрузить содержимое из файла MS Word	Путь к файлу
   Запускать новый экземпляр MS Word	нет
   Открыть в режиме «только чтение»	да
   Тип результата	text / HTML

   Принудительно закрывать файлы Word не требуется (данные из файла считываются, и файл сразу закрывается)
    

2. Тип результата «text» подойдет для простых документов, где есть к чему привязаться для извлечения значений.
   Например, если данные в документе имеют вид Дата: 25.04.2021, то парсер для получения даты может взять текст между словом Дата: и переводом строки {NL}
   Учитывать стили абзацев в данном случае ни к чему (потому разметка HTML не нужна для парсинга)
    
3. Для документов сложной структуры, или с большим объёмом данных, имеет смысл использовать тип результата HTML, и производить разбор данных из файла с учётом стилей (размер шрифта и т.п.).
   Кроме того, в этом случае есть возможность считывать данные из различных объектов Word, таких как например надписи и колонтитулы.
    
4. Есть возможность выгружать фотографии из документа, при помощи действия «Выгрузить картинки из файла Word»

Примеры настройки парсера файлов Word можно найти в каталоге парсеров файлов:

• парсер пропусков
• парсер дипломов
• парсер базы контактов

Разобрать файл Word и извлечь данные с помощью любого современного браузера

Выбрать язык

В процессе анализа информации часто возникает потребность в обработке данных из документов в форматах MS Word или Excel. Как считывать информации из таких файлов с использованием языка C #.

Из практического опыта сотрудника, который всегда успешно решает поставленные задачи.

Для работы с файлами Word и Excel я решил выбрать библиотеки Microsoft.Office.Interop.Word и Microsoft.Office.Interop.Excel, предоставляющие программные интерфейсы для взаимодействия с объектами MS Word и Excel.

Преимущества использования этих библиотек:

Также следует заметить, что у такого похода есть и недостаток: для того, чтобы написанная программа работала на ПК пользователя необходимо, чтобы на нём были установлены программы MS Office и MS Excel. Поэтому такой подход плохо подходит для серверных решений. Также такая программа не будет являться кроссплатформенной.

Добавление библиотек в проект Visual Studio

Библиотеки поставляются вместе с пакетом Visual Studio Tool for Office (платформа .NET Framework).

Для использования библиотеки нужно:

Можно прочитать основные форматы: .doc,. docx,. rtf.

Ниже приведён листинг с примером считывания текста из документа MS Word:

Примечания:

Пример парсинга файла MS Excel

Можно прочитать основные форматы: .xls,. xlsx.

Ниже приведён листинг с примером считывания текста из документа MS Excel (по ячейкам):

Примечания:

Приведенные примеры хорошо подходят для реализации приложения по обработке документов Word и Excel на платформе .NET Framework.

С помощью указанных библиотек можно не только читать текст из документов, но и создавать новые файлы форматов MS Word и Excel.

Время на прочтение
10 мин

Количество просмотров 20K

Хочу представить вашему вниманию способ извлечения данных с документа word в виде картинок. Возможно, представленные идеи будут для кого-то примитивными и очевидными. Но мне пришлось провести пару бессонных ночей, прежде чем дойти до нормального решения. Итак, начинаю.

Было начало 2015-го. Зима. Я радовался хорошей погоде и восхищенно думал, что универ я наконец закончу (вру, сейчас поступаю в магистратуру). Свой диплом я недавно закончил, поэтому радовался еще сильнее. Однако вскоре, по натуре человеческой, состояние безмятежности плавно стало сменяться скукой. И тут, как будто специально, тишину сменил телефонный звонок.

«Алло, привет, как поживаешь?» — прозвучал голос знакомой.

Интуиция тут же определила, что скорее всего разговор будет на тему «тыжпрограммиста». Так оно и было. С унылым видом сначала я слушал про тяжкие времена знакомой и про все остальное, однако ее конечная просьба заставила меня заинтересоваться.

«Ты не мог мне помочь с дипломом? В общем, необходимо сделать сайт-тренажер по математике» — сказала она.

Это было интересно. Меня как раз увлекает разработка сложных фронтендов. Просьбу я тут же одобрил.

На реализацию тренажера ушло суммарно не более 2-х дней. Сайт-тренажер позволяет проходить тесты по высшей математике и просматривать теорию. Тесты можно проходить в двух режимах: в режиме тренировки с подсвечиванием ответов и в режиме тестирования с выводом результата в конце. Реализация была сделана на ReactJS и Bootstrap и сам процесс был достаточно приятным. Но это было только начало. Необходимо было как заполнить данными базу вопросов тестов, которые отнюдь не были в виде готовых упорядоченных данных.

Постановка задачи

Пока я удовлетворенно смотрел на результат работы, знакомая позвонила повторно. Она уведомила меня, что прислала мне небольшой архивчик с вопросами в *.doc файлах на почту. «Если что, я могу помочь перекинуть вопросы и ответы в БД» — добавила она.

Это немного подпортило мое настроение, ведь я не думал, что придется еще заполнять самостоятельно базу тестовых вопросов.

Ладно. Пошел я открывать свой GMail и тут:

И в каждом файле ~50 тестовых заданий в виде:

Мда уж, вручную забивать все это в БД вряд ли получится. К слову, каждое тестовое задание в БД хранилось в виде одной картинки-вопроса, пяти картинок-ответов, уровня сложности (A, B, C) и номера верного ответа (1-5). Расстроенный, я решил пока что отложить этот вопрос на долгий ящик, благо времени было достаточно. Но через несколько дней на почту упало еще одно сообщение от знакомой, а потом еще… В итоге, набралось 4 раздела по высшей математике, каждый из разделов состоял из 14-23 подразделов, каждый подраздел содержал примерно 30-100 тестовых заданий. И тут я окончательно убедился, что вручную все это вбить в базу данных точно не получится.

Кстати про БД. Это MySQL с тремя таблицами: разделов, подразделов и тестовых вопросов. Картинки вопроса задания и пяти ответов хранятся непосредственно в БД, в столбце BLOB. Мне кажется так удобней, поскольку этих картинок очень много, к тому же весят они мало. И будут все они храниться в одном месте, вместе с другими данными.

Итак, что было необходимо? В наилучшем варианте нужно было из папки со всеми word файлами тестовых заданий получить готовые соответствующие записи в БД, что практически и было получено в конечном результате. Нас же интересует главное: непосредственно само извлечение картинок.

Входные данные: файл word с тестовыми заданиями.
Выходные данные (например): папка с изображениями PNG, где задание имеет имя вида 1.png, а ответы имеют имена 1.1.png, 1.2.png, 1.3.png, 1.4.png, 1.5.png, плюс к этому файл answers.txt, внутри которого i-я строка содержит число от 1 до 5, соответствующую правильному ответу i-го задания.

Реализация

Я люблю Qt Creator. А с чего мне его любить? Скорее всего потому, что в универе нас натаскивают именно по нему, я сам не знаю. А еще во время пользования им я испытываю какой-то тихий восторг. Ну в общем вы поняли, на чем я стал писать программу-парсер.

Вначале я гадал, как же вообще взаимодействовать с этим вордом, чтобы как то уж выдергивать оттуда данные. На ум приходили всякие ужасные мысли наподобие конвертации word файла в HTML с последующей обработкой. Но гугление сразу же направило меня на адекватный путь, дав информацию о языке VBA. Я тут же был поражен обилием готовых функций, узнал, что такое параграфы, позиции и т.п., одновременно офигевая от сложности устройства дерева документа word.

Однако я был разочарован, поскольку так и не понял, как же превратить кусок текста в картинку. Сначала было хотел использовать что-либо наподобие text2png, предварительно выдернув нужный кусок текста. Но как же с формулами и картинками? Встроенной функции в VBA не было. В один момент у меня ненарком промелькнуло мыслишко, что вроде бы как я раньше вставлял в документ word ячейки из excel в виде картинок. Так и было! Называлось это «специальной вставкой» и позволяло вставлять любой участок документа в виде картинки. Допустим мы занесли в буфер обмена некий кусок документа, который необходимо сохранить в виде картинки. Но как эту картинку сохранить на диск? Гугление также помогло найти решение. Участок кода ниже сохраняет содержимое буфера обмена на диск в виде универсального векторного файла EMF.

#include <windows.h>

void clipboardDataToEmfFile(QString fileName){
    OpenClipboard(0);
    GetEnhMetaFileBits((HENHMETAFILE)GetClipboardData(14),0,0);
    HENHMETAFILE returnValue = CopyEnhMetaFileA((HENHMETAFILE)GetClipboardData(14),
                                                QDir::toNativeSeparators(fileName).toStdString().c_str());
    EmptyClipboard();
    CloseClipboard();
    DeleteEnhMetaFile(returnValue);
}

Отлично. Однако что это за зверь такой, этот EMF? Необходимо было его превратить в PNG. Начал я искать конвертеры изображений. Перебрав кучу, так и не нашел адекватного. И тут опять (кто-нибудь верит в интуицию?) в голове начал вспоминаться какой-то навороченный просмотрщик изображений, который я ставил в школьные годы из диска с «Золотым софтом» забавы ради. Но вроде это был не конвертер. Однако необходимо было убедиться. В голове крутилось какое-то то ли «Ifran», то ли «Irfan», в общем программа была найдена. Бесплатная, с функцией пакетной обработки изображений, поддерживает командную строку! И самое главное, поддерживает EMF. Это было то, что надо. Исполняемый файл IrfanView с нужными DLL и ini-файлом параметров лежит в одной папке со скомпилированной программой (надеюсь это не нарушает лицензию) и используется через функцию вот так.

void convertEmfsToPng(QString inFolder, QString outFolder){
    QProcess proc;
    QString exeStr = """ + QDir::toNativeSeparators(QDir::currentPath()+"/i_view32.exe") + """;
    QString inFilesStr = """ + QDir::toNativeSeparators(inFolder + "*.emf") + """;
    QString outFilesStr = """ + QDir::toNativeSeparators(outFolder + "*.png") + """;
    QString iniFolderStr = """ + QDir::toNativeSeparators(QDir::currentPath()) + """;
    proc.start(exeStr + " " + inFilesStr + " /advancedbatch /ini=" + iniFolderStr + " /convert=" + outFilesStr);
    proc.waitForFinished(30*60*1000);
}

Теперь осталось копировать в буфер нужные куски из документа word. Для этого необходимо придумать алгоритм разбиения исходного текста на отдельные блоки с заданием, с ответами, с номером верного ответа и уровня сложности.

Первой попыткой реализации было следующее. Берем исходный документ, заменяем в нем текст вида ([1-5])) на n$1), т.е. перед началом каждого ответа добавляем перевод строки. На VBA строки замены пишутся по-другому, я уже не помню. Теперь в параметрах документа ставим ширину страницы максимальной, а шрифт для всего документа уменьшаем. В результате получается, что в документе каждое задание будет занимать ровно 8 строк, причем:

• строка 8*i — это текст с номером верного ответа и уровнем сложности
• строка 8*i+1 — это задание
• строка 8*i+2 — это вариант ответа №1
• …
• строка 8*i+6 — это вариант ответа №5
• строка 8*i+7 — пустая

Теперь после этой обработки ничего не остается, кроме как пройтись по массиву коллекции строк документа, заведя счетчик i, и в зависимости от i % 8 сохранять картинки задания/ответов или извлекать номер верного ответа с уровнем сложности.

Но это не подошло. Виноваты длинные задания, которые будучи написаны в одну строку, выглядят ужасно, мелко и не всегда вмещаются. К тому же иногда замена текста «1)» затрагивает другие места кроме номеров ответов. Опечаленный результатом, я вновь начал думать, что можно будет сделать в данном случае. И тут я вспомнил про конечные автоматы. Вспомнил про состояние, вспомнил про посимвольный ввод. Вспомнил синтаксический анализатор. Возможно это другим было очевидным решением, но я как человек далекий от сложных алгоритмов был безумно рад своей идее.

Теперь настал черед писать и пробовать код парсера на основе конечного автомата. Состояний у нас 7:

• считывание пространства между заданиями, начинается с пустой строки
• считывание строки с номером задания, в котором номер верного ответа и уровень сложности, начинается с «Номер»
• считывание текста задания, начинается с «Задача»
• считывание текста ответа №1, начинается с «Ответы: 1).»
• считывание текста ответа №2, начинается с «2).»
• …
• считывание текста ответа №5, начинается с «5).»

Реализуем, используя условия начала следующего состояния. После тестирования первой версии парсера все прошло великолепно. Картинки получались как в самом word документе, красивенько, крупно. Но тут… время от времени появлялись косяки, например в одной картинке захватывался лишний кусок до следующего блока задания. Значит парсер некорректно распознавал. В чем же дело? Все оказалось просто — задания в word документе набирались вручную и поэтому имел место человеческий фактор, например:

• вместо «Задача» писалось «Задание»
• вместо «Ответы» писалось «Ответ»
• вместо «1).» писалось «1 ).» или «1)» или вообще «1) .»

Это был кошмар. Благо основные ошибки были в написании номеров заданий, их худо-бедно учитывал парсер. Остальные ошибки после извлечения картинок обнаруживались беглым просмотром наиболее больших и маленьких по размеру картинок с последующим исправлением и повторным извлечением.

Итоговым куском парсера является код ниже. Он ужасен, просьба не судить строго. Для хранения VBA-объектов используется QAxObject.

QAxObject *activeDoc = wordApp->querySubObject("ActiveDocument");

int status = -3;
int startind = 0;
int n=0;
QString nstr;
QString str = "";
int lineStart, lineEnd;
QAxObject *lines = activeDoc->querySubObject("Paragraphs");

if (onlyAsnwers)
    for (int ipar = 1; ipar <= lines->property("Count").toInt(); ipar++){
        QAxObject *tline = lines->querySubObject("Item(QVariant)", ipar);
        QAxObject *line = tline->querySubObject("Range");
        QString str = line->property("Text").toString();
        line->clear(); delete line;
        tline->clear(); delete tline;
        int ind = str.indexOf("Номер:");
        if (ind != -1){
            str = str.mid(ind+6);
            answersTxt << getAnswerLine(str);
        }
    }
else
    for (int ipar = 1; ipar <= lines->property("Count").toInt(); ipar++){
        QAxObject *tline = lines->querySubObject("Item(QVariant)", ipar);
        QAxObject *line = tline->querySubObject("Range");
        lineStart = line->property("Start").toInt();
        lineEnd = line->property("End").toInt();
        line->clear(); delete line;
        tline->clear(); delete tline;
        str = "";
        for (int j=lineStart; j<lineEnd; j++){
            QAxObject *tmpObj = activeDoc->querySubObject("Range(QVariant,QVariant)", j, j+1);
            QString currChar = tmpObj->property("Text").toString();
            tmpObj->clear(); delete tmpObj;
            str += currChar;
            switch (status){
            case -3:
                if (j>=4 && str.right(5) == "Номер"){
                    status = -2;
                    startind = j+1;
                }
                break;
            case -2:
                if (str.right(6) == "Задача"){
                    n++; nstr = QString::number(n); while (nstr.length() < 3) nstr = "0" + nstr;
                    status = -1;
                    QAxObject *tmpObj = activeDoc->querySubObject("Range(QVariant,QVariant)", startind, j-6);
                    QString tmp = tmpObj->property("Text").toString();
                    tmpObj->clear(); delete tmpObj;
                    answersTxt << getAnswerLine(tmp);
                    startind = j+2;
                } else if (str.right(7) == "Задание"){
                    n++; nstr = QString::number(n); while (nstr.length() < 3) nstr = "0" + nstr;
                    status = -1;
                    QAxObject *tmpObj = activeDoc->querySubObject("Range(QVariant,QVariant)", startind, j-7);
                    QString tmp = tmpObj->property("Text").toString();
                    tmpObj->clear(); delete tmpObj;
                    answersTxt << getAnswerLine(tmp);
                    startind = j+2;
                }
                break;
            case -1:
                if (str.right(7) == "Ответы:"){
                    status = 0;
                    rangeToEmfFile(outdir+nstr+".emf", startind, j-7, activeDoc);
                    startind = j+1;
                } else if (str.right(6) == "Ответ:"){
                    status = 0;
                    rangeToEmfFile(outdir+nstr+".emf", startind, j-6, activeDoc);
                    startind = j+1;
                }
                break;
            case 0:
                if (str.right(2) == "1)" || str.right(3) == "1 )"){
                    status = 1;
                    startind = j+2;
                }
                break;
            case 1:
                if (str.right(2) == "2)"){
                    rangeToEmfFile(outdir+nstr+".1.emf", startind, j-2, activeDoc);
                    status = 2;
                    startind = j+2;
                } else if (str.right(3) == "2 )"){
                    rangeToEmfFile(outdir+nstr+".1.emf", startind, j-3, activeDoc);
                    status = 2;
                    startind = j+2;
                }
                break;
            case 2:
                if (str.right(2) == "3)"){
                    rangeToEmfFile(outdir+nstr+".2.emf", startind, j-2, activeDoc);
                    status = 3;
                    startind = j+2;
                } else if (str.right(3) == "3 )"){
                    rangeToEmfFile(outdir+nstr+".2.emf", startind, j-3, activeDoc);
                    status = 3;
                    startind = j+2;
                }
                break;
            case 3:
                if (str.right(2) == "4)"){
                    rangeToEmfFile(outdir+nstr+".3.emf", startind, j-2, activeDoc);
                    status = 4;
                    startind = j+2;
                } else if (str.right(3) == "4 )"){
                    rangeToEmfFile(outdir+nstr+".3.emf", startind, j-3, activeDoc);
                    status = 4;
                    startind = j+2;
                }
                break;
            case 4:
                if (str.right(2) == "5)"){
                    rangeToEmfFile(outdir+nstr+".4.emf", startind, j-2, activeDoc);
                    status = 5;
                    startind = j+2;
                } else if (str.right(3) == "5 )"){
                    rangeToEmfFile(outdir+nstr+".4.emf", startind, j-3, activeDoc);
                    status = 5;
                    startind = j+2;
                }
                break;
            case 5:
                if (j>=4 && str.right(5) == "Номер"){
                    rangeToEmfFile(outdir+nstr+".5.emf", startind, j-5, activeDoc);
                    status = -2;
                    str = "Номер";
                } else if (lineEnd-lineStart < 2){
                    rangeToEmfFile(outdir+nstr+".5.emf", startind, j, activeDoc);
                    status = -3;
                }
                break;
            }
        }
        if (status == 5)
            rangeToEmfFile(outdir+nstr+".5.emf", startind, lineEnd, activeDoc);
    }
lines->clear(); delete lines;

activeDoc->clear(); delete activeDoc;

Логика работы приведенного кода немного отличается от описанной выше. Она использует еще разбиение на абзацы. Но это не сильно меняет главную идею.

Вот таким вот образом получилось «победить» этот Word!

Заключение

В итоге были извлечены все задания в количестве ~4 тыс. Нужная оболочка парсера была написана. Программа закачки заданий на удаленную БД и администрирования ею также была написана. Гонорар был получен, ее диплом защищен на отлично, мой также защищен на отлично.

Спасибо за внимание, надеюсь этот пост поможет кому нибудь в аналогичной проблеме. А может кто знает лучшую реализацию?

Update:

Время прочтения: 6 мин.

В
процессе аудита часто возникает потребность в обработке данных из документов в
форматах MS Word или Excel. В своей статье я хочу поделиться опытом считывания
информации из таких файлов с использованием языка C#.

Для
работы с файлами Word и Excel
я решил выбрать библиотеки Microsoft.Office.Interop.Word и Microsoft.Office.Interop.Excel, предоставляющие программные интерфейсы для
взаимодействия с объектами MS
Word и
Excel.

Преимущества
использования этих библиотек:

• созданы корпорацией Microsoft, следовательно, взаимодействие с объектами программ пакета MS Office реализовано наиболее оптимально,
• нужный пакет Visual Studio Tool for Office поставляется вместе с Visual Studio (достаточно отметить его при установке VS).

Также
следует заметить, что у такого похода есть и недостаток: для того, чтобы
написанная программа работала на ПК пользователя необходимо, чтобы на нём были
установлены программы MS
Office и
MS Excel. Поэтому такой
подход плохо подходит для серверных решений. Также такая программа не будет
являться кроссплатформенной.

Добавление библиотек в проект Visual Studio

Библиотеки
поставляются вместе с пакетом Visual
Studio
Tool
for
Office (платформа .NET Framework).

Для
использования библиотеки нужно:

• добавить ссылку на неё: в обозревателе решений необходимо кликнуть правой кнопкой мыши по пункту Ссылки (Рис. 1) и найти нужную библиотеку по ключевым словам (после добавления ссылка появится в списке),

• указать используемое пространство имён в файле программы (в примере ему назначен алиас Word): (Рис. 2):

Пример парсинга файла MS Word

Можно прочитать основные
форматы: .doc, .docx, .rtf.

Ниже
приведён листинг с примером считывания текста из документа MS Word:

object FileName = @"C:test.doc";
object rOnly = true;
object SaveChanges = false;
object MissingObj = System.Reflection.Missing.Value;

Word.Application app = new Word.Application();
Word.Document doc = null;
Word.Range range = null;
try
{
    doc = app.Documents.Open(ref FileName, ref MissingObj, ref rOnly, ref MissingObj,
    ref MissingObj, ref MissingObj, ref MissingObj, ref MissingObj,
    ref MissingObj, ref MissingObj, ref MissingObj, ref MissingObj,
    ref MissingObj, ref MissingObj, ref MissingObj, ref MissingObj);

    object StartPosition = 0;
    object EndPositiojn = doc.Characters.Count;
    range = doc.Range(ref StartPosition, ref EndPositiojn);

    // Получение основного текста со страниц (без учёта сносок и колонтитулов)
    string MainText = (range == null || range.Text == null) ? null : range.Text;
    if (MainText != null)
    {
        /* Обработка основного текста документа*/
    }

    // Получение текста из нижних и верхних колонтитулов
    foreach (Word.Section section in doc.Sections)
    {
        // Нижние колонтитулы
        foreach (Word.HeaderFooter footer in section.Footers)
        {
            string FooterText = (footer.Range == null || footer.Range.Text == null) ? null : footer.Range.Text;
            if (FooterText != null)
            {
                /* Обработка текста */
            }
        }

        // Верхние колонтитулы
        foreach (Word.HeaderFooter header in section.Headers)
        {
            string HeaderText = (header.Range == null || header.Range.Text == null) ? null : header.Range.Text;
            if (HeaderText != null)
            {
                /* Обработка текста */
            }
        }
    }
    // Получение текста сносок
    if (doc.Footnotes.Count != 0)
    {
        foreach (Word.Footnote footnote in doc.Footnotes)
        {
            string FooteNoteText = (footnote.Range == null || footnote.Range.Text == null) ? null : footnote.Range.Text;
            if (FooteNoteText != null)
            {
                /* Обработка текста */
            }
        }
    }
} catch (Exception ex)
{
    /* Обработка исключений */
}
finally
{
    /* Очистка неуправляемых ресурсов */
    if(doc != null)
    {
        doc.Close(ref SaveChanges);
    }
    if(range != null)
    {
        Marshal.ReleaseComObject(range);
        range = null;
    }            
    if(app != null)
    {
        app.Quit();
        Marshal.ReleaseComObject(app);
        app = null;
    }
}

Примечания:

• в коде приводится пример считывания основного текста документа, текста верхних и нижних колонтитулов, а также текста сносок,
• в коде производится очистка неуправляемых ресурсов с использованием класса Marshal (подробнее можно почитать по ссылке )

Пример парсинга файла MS Excel

Можно прочитать основные
форматы: .xls, .xlsx.

Ниже
приведён листинг с примером считывания текста из документа MS Excel (по
ячейкам):

string FileName = @"C:UsersbeeDownloadstest.xlsx";
object rOnly = true;
object SaveChanges = false;
object MissingObj = System.Reflection.Missing.Value;

Excel.Application app = new Excel.Application();
Excel.Workbooks workbooks = null;
Excel.Workbook workbook = null;
Excel.Sheets sheets = null;
try
{
    workbooks = app.Workbooks;
    workbook  = workbooks.Open(FileName, MissingObj, rOnly, MissingObj, MissingObj,
                                MissingObj, MissingObj, MissingObj, MissingObj, MissingObj,
                                MissingObj, MissingObj, MissingObj, MissingObj, MissingObj);

    // Получение всех страниц докуента
    sheets = workbook.Sheets;
                
    foreach(Excel.Worksheet worksheet in sheets)
    {
        // Получаем диапазон используемых на странице ячеек
        Excel.Range UsedRange = worksheet.UsedRange;
        // Получаем строки в используемом диапазоне
        Excel.Range urRows = UsedRange.Rows;
        // Получаем столбцы в используемом диапазоне
        Excel.Range urColums = UsedRange.Columns;

        // Количества строк и столбцов
        int RowsCount = urRows.Count;
        int ColumnsCount = urColums.Count;
        for(int i = 1; i <= RowsCount; i++)
        {
            for(int j = 1; j <= ColumnsCount; j++)
            {
                Excel.Range CellRange = UsedRange.Cells[i, j];
                // Получение текста ячейки
                string CellText = (CellRange == null || CellRange.Value2 == null) ? null :
                                    (CellRange as Excel.Range).Value2.ToString();

                if(CellText != null)
                {
                    /* Обработка текста */
                }
            }
        }
        // Очистка неуправляемых ресурсов на каждой итерации
        if (urRows != null) Marshal.ReleaseComObject(urRows);
        if (urColums != null) Marshal.ReleaseComObject(urColums);
        if (UsedRange != null) Marshal.ReleaseComObject(UsedRange);
        if (worksheet != null) Marshal.ReleaseComObject(worksheet);
    }
} catch (Exception ex)
{
    /* Обработка исключений */
}
finally
{
    /* Очистка оставшихся неуправляемых ресурсов */
    if (sheets != null) Marshal.ReleaseComObject(sheets);
    if (workbook != null)
    {
        workbook.Close(SaveChanges);
        Marshal.ReleaseComObject(workbook);
        workbook = null;
    }

    if (workbooks != null)
    {
        workbooks.Close();
        Marshal.ReleaseComObject(workbooks);
        workbooks = null;
    }
    if (app != null)
    {
        app.Quit();
        Marshal.ReleaseComObject(app);
        app = null;
    }
}

Примечания:

• при обработке текста каждой ячейки
  приходится заранее знать количество задействованных строк и столбцов на текущем
  листе документа,
• такой перебор не совсем оптимален
  (временная сложность алгоритма O(n²)):
  при желании его можно ускорить (например, разбив обработку на несколько
  потоков): в данной статье приводится лишь пример получения текста из каждой
  ячейки,
• при таком переборе ячеек необходимо
  на каждой итерации освобождать неуправляемые ресурсы, чтобы избежать утечек
  памяти (аналогично предыдущему примеру, используется класс Marshal).

Приведенные
примеры хорошо подходят для реализации приложения по обработке документов Word и
Excel
на платформе .NET Framework.

С
помощью указанных библиотек можно не только читать текст из документов, но и
создавать новые файлы форматов MS Word и
Excel.

В 2017 году пакет Microsoft Office был популярной целью для атак хакеров. Вместе с большим числом найденных уязвимостей и опубликованных proof-of-concept эксплойтов у авторов вредоносного ПО появилась необходимость в предотвращении детекта новых модификаций эксплойтов антивирусными средствами. Также стало ясно, что использования легитимных особенностей RTF-парсера более недостаточно для эффективного избегания анализа и обнаружения. Вместе с увеличением атак посредством MS Office, когда файл формата RTF используется как контейнер для эксплойта, мы нашли большое количество сэмплов, которые «эксплуатировали» RTF-парсер в Microsoft Word, чтобы «сломать» все другие имплементации RTF-парсера, включая те, которые используются в антивирусном программном обеспечении.

Для того, чтобы достичь точного парсинга, как в MS Office, нам было необходимо провести реверс-инжиниринг. Работа была начата с MS Office 2010 т.к. когда дело касается парсинга, лучше начать с более старой имплементации, а затем сравнили находки с тем, что удалось обнаружить в более новых версиях.

RTF-парсер представляет собой машину состояний (state machine) с 37 состояниями, 22 из которых уникальны:

Мы рассмотрим самые главные состояния и те, которые относятся к парсингу objdata – контрольного слова (control word), обозначающего назначение (destination) которое содержит данные «обьекта». Эти состояния:

Microsoft Office поставляется без отладочных символов, поэтому я не смог восстановить оригинальные имена. Но верю, что выбрал наиболее подходящие по их функциональности.

Первое состояние, которое выполняется на открытом RTF-файле — PARSER_BEGIN. В большинстве случаев оно также выставляется после обработки очередного контрольного слова. Главная цель состояния – определить следующее состояние, исходя из встреченных символов, установленного назначения, и других значений, содержащихся в ‘this’ структуре и установленных обработчиками контрольных слов. По умолчанию следующее установленное состояние это PARSER_CHECK_CONTROL_WORD.

PARSER_CHECK_CONTROL_WORD проверит, является ли следующий символ началом контрольного слова или же это контрольный символ (control symbol), после чего установит следующее состояние соответственно результату проверки.

Состояния PARSER_PARSE_CONTROL_WORD и PARSER_PARSE_CONTROL_WORD_NUM_PARAMETER сохранят Null-терминированное контрольное слово, состоящее из латинских символов, и Null-терминированный числовой параметр (если он имеется) во временный буфер фиксированного размера.

Этот буфер обрабатывается в состоянии PARSER_PROCESS_CMD, которое вызывает другую функцию ответственную за обработку контрольных слов и контрольных символов. Эта функция учитывает текущее состояние и устанавливает следующее.

В коде есть несколько состояний, ответственных за парсинг шестнадцатеричных данных. Для нас наиболее интересно PARSER_PARSE_HEX_DATA – как можно увидеть, это состояние устанавливается в PARSER_BEGIN, если установлено назначение objdata.

Это состояние распарсит шестнадцатеричные и бинарные данные, если они были объявлены.

Состояния PARSER_PARSE_HEX_NUM_MSB и PARSER_PARSE_HEX_NUM_LSB используются в паре для парисинга шестнадцатеричных значений (данные контрольного слова panose и контрольного символа ‘).

Сброс состояния

Внимательно изучив код состояний PARSER_PARSE_HEX_NUM_MSB, PARSER_PARSE_HEX_NUM_LSB и PARSER_PARSE_HEX_DATA, легко заметить баг. Несмотря на то, что они используют разные переменные для декодированных шестнадцатеричных значений, состояния используют одинаковый бит для определения какой ниббл (полубайт) декодируется сейчас – верхний (MSB) или нижний (LSB). И PARSER_PARSE_HEX_NUM_MSB всегда сбрасывает этот бит на MSB.

Тем самым можно заставить байты исчезнуть из финального результата декодирования, если в контексте PARSER_PARSE_HEX_DATA вынудить смену состояния на PARSER_PARSE_HEX_NUM_MSB.

Для этого достаточно вставить ‘XX в данные, которые идут после контрольного слова objdata. В этом случае, когда данные будут обрабатываться в PARSER_PARSE_HEX_DATA, парсер встретит и вернется в PARSER_BEGIN, а в конце концов попадет в состояние PARSER_PROCESS_CMD. Логика для контрольного символа ‘ устроена так, что назначение не будет изменено, но будет выставлено состояние PARSER_PARSE_HEX_NUM_MSB. После PARSER_PARSE_HEX_NUM_MSB и PARSER_PARSE_HEX_NUM_LSB управление снова перейдет в PARSER_BEGIN и PARSER_PARSE_HEX_DATA, т.к. назначение все еще равно objdata. После этого снова будет декодироваться верхний ниббл.

Также примечательно, что PARSER_PARSE_HEX_NUM_LSB не проверяет валидность значений, т.е. после ‘ могут идти два абсолютно любых байта.

Это можно наблюдать в следующем примере:

«f’cc»будут удалены

Когда исполнение в первый раз передается состоянию PARSER_PARSE_HEX_DATA, после того, как контрольное слово objdata обработано, MSB бит уже установлен. Давайте рассмотрим, как это происходит и как следующий пример будет обработан парсером:

Проведя некоторое время над функцией ответственной за обработку контрольных слов и контрольных символов, я нашел список всех контрольных слов и их структуры.

С этой информацией мы можем найти и взглянуть на конструктор objdata:

Как можно заметить, конструктор устанавливает бит MSB, выделяет новый буфер и заменяет указатель на старый. Таким образом, данные, декодированные между двумя контрольными словами objdata, не используются.

«d0cf11e0a1b11ae1» будут удалены

Пункт назначения

Мы знаем, что если вставить ‘ и objdata, то это изменит выходные данные. Но что по поводу других контрольных слов и символов? Ведь их в парсере больше 1500!

По большей части ничего.

Т.к. часть контрольных слов обозначают назначение, они не могут применяться – результатом будет изменение objdata на назначение контрольного слова, а для декодирования данных нам нужно назначение objdata.

Часть других контрольных слов не имеют эффекта на назначение objdata.

Единственный способ задать другое назначение таким образом, чтобы можно было вернуть назначение objdata без потери декодированных данных, это воспользоваться особыми символами – открывающая фигурная скобка ({) и закрывающая фигурная скобка (}). Эти символы обозначают начало и конец группы.

После того, как парсер встретит конец группы в PARSER_BEGIN, назначение, которое было установлено перед началом группы, будет восстановлено.

Таким образом, если после objdata вставить {aftncn FF}, то FF не попадут в данные objdata, т.к. FF теперь относятся к назначению aftncn и будут обработаны согласно его логике.

В противном случае, если вставить {aftnnalc FF}, то FF попадут в objdata т.к. назначение все еще равно objdata.

Также стоит отметить, что {objdata FF} все-еще нельзя использовать т.к. буфер не будет восстановлен.

Точный список назначений был составлен благодаря простому фаззеру.

Фиксированный буфер

Другая техника обфускации, которая приходит в голову при взгляде на код RTF-парсера, не относится к этому «MSB» багу, но также может использоваться для удаления шестнадцатеричных данных. Техника относится к размеру временного буфера и к тому, как контрольные слова и числовые параметры парсятся в состояниях PARSER_PARSE_CONTROL_WORD и PARSER_PARSE_CONTROL_WORD_NUM_PARAMETER.

Пример злоупотребления представлен на следующей картинке:

В этом примере размер данных, которые будут удалены как часть числового параметра, считается по формуле: 0xFF (размер временного буфера) — 0xB (размер контрольного слова «oldlinewrap») — 2 (null-терминаторы) = 0xF2.

Ненужные данные

Описанные ранее техники относятся к основам парсинга формата RTF, но дополнительная путаница скрывается в обработке особых контрольных слов.

Согласно спецификации, если контрольный символ * находился перед неизвестным контрольным словом или контрольным символом, то считается, что это неизвестное назначение и все данные перед скобкой (}), которая закрывает эту группу, должны быть выкинуты. В MS Office содержатся контрольные слова, которые не упоминаются в спецификации, и вызывает опасение то, что список контрольных слов будет изменен в будущем, оказывая влияние на парсинг документа в различных версиях MS Office. Когда функция, ответственная за обработку контрольных слов и контрольных символов, встретит такой случай или одно из особых контрольных слов (такие как comment, generator, nonshppict и др.), состояние будет установлено на PARSER_SKIP_DATA, а число встреченных открывающих скобок ({) на 1.

Немного магии

Во время анализа состояний из группы PARSER_SKIP_DATA открылись факты, которые идут не только в разрез со спецификацией, но и в разрез с основным кодом парсера.

В поисках контрольного слова bin эти состояния будут пропускать байты, изменяя количество встреченных открывающих и закрывающих скобок, пока их количество не будет равно 0. Западня кроется в том, как обрабатывается числовой параметр в PARSER_SKIP_DATA_GET_BIN_VAL.

Во-первых, максимально допустимая длина числового параметра увеличена до 0xFF байт, длина контрольного слова не учитывается.

Во-вторых, числовой параметр теперь вовсе не числовой! Парсер позволяет передать не только числа, но и латинские буквы. Потом этот параметр передается в кастомную функцию strtol, тем самым позволяя задать длину данных, которые должны быть пропущены, без учета открывающих и закрывающих скобок как шестнадцатеричное число.

Благодаря этим примитивам возможны новые способы обфускации, которые еще не встречались in the wild.

Заключение

Реверс-инжиниринг показал себя как наиболее эффективный способ создания парсера, и в случае с RTF, скорее всего, не удалось бы добиться желаемого результата иначе.

Точный парсинг больше зависит от малых деталей в имплементации и алгоритмических багах, чем от спецификации, которая может быть не точной либо утверждать вещи, противоположные правде.

Продукты «Лаборатории Касперского» распознают все виды RTF-обфускаций и выполняют наиболее корректную обработку документов формата RTF, обеспечивая максимальную защиту для наших пользователей.