Трансляция CSV-XML. Пример. УФ

В задаче было загрузить данные из двух таблиц — CSV и XML, содержащих разные данные по одним и тем же объектам и объединить их в одну финальную таблицу XML.

Обработка считывает любой CSV файл.

Она также способна считать любой XML файл структуры вида (названия тегов не важны):

<Xml>
<Object>
<Field1>Value1</Field>
<Field2>Value1</Field>
<Field3>Value1</Field>
…..
<Object>
….
</Xml>

Вся обработка осуществляется на клиенте, чтобы не передавать данные на сервер.

Для универсальности данные из файла загружаются в структуру Данные с полям:

  1. Колонки — соответствие Имя колонки — Номер колонки (с единицы)
  2. Строки — массив строк. В строке может быть меньше колонок, чем в файле, но порядок колонок соблюдается.
  3. Массив колонок — формируется через индексированное соответствия Колонки. В каждом элементе — название колонки на этой позиции.

В коде можно посмотреть, как считываются CSV и XML файлы.

Для считывания CSV использовался не очень быстрый метод считывания файла в строку с последующим разбором отсюда. Метод реально медленный на 72 Мб файле работал 10 минут. Но работает правильно, т.к. обрабатывает переносы строк.

XML считывается и разбирается быстрыми эффективными рекурсивными методами.

Считанный CSV или XML можно выгрузить в XML файл в структуру Вида xmldata — Products — FieldN:

В коде можно посмотреть, как было сделано объединение файлов:

Обработка имеет форму:

Сначала нужно прочитать XML или CSV.

Далее присвоить в результат CSV или XML.

После этого можно получить финальный XML через «Записать результат в XML».

Обработка была написана за 3.5 часа.

Список полей для вставки в XML стал универсальным.

Первоначальная версия обработки.

комментариев 6

  1. bob:

    Надо же какой перфоманс в 1С. На Go подобная задача будет обрабатывать 150-метровые XML-ки за несколько секунд (больше скорость диска влияет). Делал, знаю.

    • Тут XML тоже быстро гоняется. А вот CSV обрабатывается как строка в памяти, поэтому медленно.

      • bob:

        Буфферизация чтения. CSV парсится еще быстрее XML. Проблема выбора адекватных инструментов для решения подобных задач.
        Если задача делается редко — пишется скрипт на Python, если надо часто — нормальное консольное приложение на Java/Go/C/C++.
        1C для решения данной задачи не является адекватным выбором (если только мы не грузим данные сразу в 1С)

        • Тут на самом деле много критериев выбора.
          В тч и наличие кадров, которые могут это сделать.
          если это может сделать знакомый 1сник, зачем искать незнакомого питониста?

          • bob:

            1Сик может написать и на Питоне (или другом скриптовом языке). Скрипты неотьемлимая часть работы программиста и такое знание не повредит никому. Выбирать инструмент надо адекватно задаче, а не пытаться забивать микроскопом гвозди. К сожалению, многие решают задачу на том, что знают, а не что адекватно задаче. Это не связано с 1С и встречается среди всех типов программистов.

          • Видишь ли, сложно знать широко и глубоко одновременно.
            Если задача нормально решается на 1С, смысл тратить силы мозга на изучение питона?
            Аналогично, есть регулярные выражения, но они сложнее, чем поиск и замена.
            Причем сложнее не в плане понять их, а в плане повседневного использования, если используешь их редко.
            Это специализация.
            Программист 1С заточен не на строковый парсинг.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *