Каталог решений - Описание формата внутреннего представления данных 1С в контексте обмена данными

Содержание.

• Зачем нужна эта статья?
• Общие правила и Рекомендации.
• Примитивные типы.
• Коллекции.
  • Массив
  • Структура и Соответствие
  • Фиксированные массив, структура и соответствие
  • Список значений
  • Таблица значений
  • Дерево значений
• Ссылочные типы.
• Заключение.

Зачем нужна эта статья? 

Несколько лет назад я работал над проектом логистического ПО. И у нас был расчетный сервер, который на вход получал из торговой 1С сотни точек пути с графиками их работы, тысячи заказов на доставки с параметрами совместимости товаров для возможности совместной доставки, описание парка из десятков машин с различными параметрами и разными тарифами; а на выход выдавал наиболее оптимальное решение по критериям времени/денег/выполнимости в виде сложной древовидной структуры сформированных маршрутов. Объем потока информации был огромен и важным стал вопрос формата для выполнения обмена. 

В первых релизах я пробовал обмен сначала с помощью XML, а потом и на JSON. Но слишком много времени уходило на конвертацию. Попробовал вместо типовых функций написать собственный "велосипед" с потоковым парсингом, но и тут получил лишь незначительный выигрыш.

Тогда я вспомнил про внутреннее представление. По моему ТЗ наш сишник сделал задачу парсинга "формата 1С" на расчетном сервере и в результате у нас получилось практически мгновенное превращение расчетного задания в текст для сервера, а затем не менее быстрое превращение результатов расчета в объект, готовый для демонстрации логисту на карте.

К сожаления, я тогда не сохранил свои наработки, так как посчитал, что у нас весьма экзотический случай и ценность для других данной темы не высока. И был крайне удивлен, когда на днях на Toster.ru (сайт вопросов-ответов) один php-программист попросил помощи с парсингом формата 1С. Внезапно оказалось, что:

1. До сих пор появляются задачи обмена именно в "формате 1С",
2. До сих пор отсутствует документация, которая может помочь специалистам, не знающим внутреннюю кухню платформы 1С.

Общие правила и Рекомендации.

Строка внутреннего представления данных, получаемая с помощью ЗначениеВСтрокуВнутр() или ЗначениеВФайл() — это текст, обычно в формате UTF-8. Отличительная особенность от других текстовых форматов — синтаксис фигурных кавычек. Описание данных, которые представлены внутренним форматом 1С, начинается с открывающейся фигурной скобки "{" и заканчивается закрывающейся фигурной скобкой "}". Содержимое между фигурными скобками — это инструкции парсеру данных (далее — параметры). Если параметров больше одного, то они разделяются символом запятой. Первый параметр — это всегда один символ признака типа в двойных кавычках. Остальные параметры — это или уточнение типа, или указание на количество элементов, или указание на конкретные элементы из множества, или описание значения свойств, или другие инструкции парсеру по сборке.

По моему опыту, для полноценного обмена вполне достаточно описать такие типы как Число, Строка, Дата, Булево, Массив, Соответствие и Неопределено. Эти простые типы, которые интуитивно понятны современным системным и веб-программистам, в которых те увидят аналогии с базовыми типами в своих языках. Тип Структура — это частный случай Соответствия и с точки зрения внутренней структуры они полностью идентичны, а потому я его не рекомендую. СписокЗначений, ТаблицыЗначений и особенно ДереваЗначений — будут мало интересны из-за своей направленности на интерактивную работу с пользователем, а потому имеющие сложную внутреннюю структуру, которую запросто можно повторить многомерным Массивом или Массивом Соответствий. Ссылочные типы я бы тоже не рекомендовал использовать из-за избыточности представляемой информации — те же код/номер или УИД из ссылки будут намного компактнее.

Важные замечание из моего опыта парсинга:

1. Регистр символов для обозначения типов (первый параметр) имеет важное значение!
2. Игнорируются все пробельные символы (пробелы, табуляции, переносы строк) в произвольных местах между фигурными скобками и параметрами — т.е. руки развязаны и для эстетов, и для любителей покомпактнее.
3. Выражения в неправильном формате, но с правильной структурой (ошибочный тип или идентификатор) распознаются как Неопределено!
4. Нарушение структуры или неправильные типы параметров на предопределенных позициях приводят к выводу ошибки: "Ошибка преобразования: Ошибка формата потока"
5. Лишние параметры игнорируются и не считаются нарушением структуры. Для примера {"N", 5, "S", "Test"} — это все равно будет число 5.

Примитивные типы.

Примечание 1. Еще раз обращаю внимание на замечания из предыдущего пункта. Так при парсинге из выражения {"N" , 7     } — мы получаем цифру 7, но если напишем {"n",7} — то в результате будет значение Неопределено!

Примечание 2. С точки зрения логики внутреннего формата к примитивным типам так же относятся Типы (идентификаторы классов данных). Описание Типа состоит из двух параметров — "T" и внутреннего идентификатора. Примеры: тип Строка = {"T",9b6abf8b-0173-48e5-b0a0-83b21fcf63c5}, тип Число = {"T",b0be78f2-0ee6-4d31-a3bb-77dd32ba5bec}, тип Массив = {"T",51e7a0d2-530b-11d4-b98a-008048da3034}.

Коллекции.

Чтобы описать коллекцию значений, необходимо в качестве первого параметра указать символ типа "#", а вторым параметром записать идентификатор типа. Для коллекций (также как и для Ссылок, Объектов, Списков, Выборок и так далее), в качестве идентификатора используется 32-разрядное 16-ричное число. Регистр для символов A-F (цифры с 10 по 15) не имеет значение — хоть большие и маленькие вперемешку. Но важно наличие разделение дефисами на 5 групп символов по правилу 8-4-4-4-12 и отсутствие пробельных символов внутри идентификатора — нарушение этих правил приводит к ошибке потока.

Для коллекций значений предопределены (со времен 7.7, а может даже раньше) следующие идентификаторы:

Примечание. Если заменить символ "#" на "T", то получим вместо объекта значения объект его типа.