Какова цель?
Закрыть модули, не устанавливая пароль на модуль и не поставляя модули без исходников.
Есть решение?
Создать новую базу в списке информационных баз. Открыть конфигуратор. Создать любой объект метаданных, например, обработку. В обработке создать форму обработки, в модуле формы написать любой код. Открыть модули объекта и менеджера обработки и написать любой код.
Пример кода:
Сохранить конфигурацию.
В меню конфигуратора нажать "Конфигурация" - "Создать мобильное приложение", нажать "Записать в файл", выбрать файл для сохранения, нажать "Сохранить", появляется окно с надписью "Мобильное приложение записано", нажать "Ок". Всё, модули закрыты.
Как понять что модули закрыты?
Разархивировать сохранённый файл 1cema.zip. В архиве лежат 2 файла 1cema.xml и 1Cv8.1CM. Открыть файл 1Cv8.1CM блокнотом Notepad++. Формат файла 1Cv8.1CM напоминает формат информационной файловой базы 1Cv8.1CD.
Создать еще одну новую базу в списке информационных баз. В каталоге новой базы заменить 1 файл 1Cv8.1CD на 1Cv8.1CM. В списке информационных баз нажать "Конфигуратор". Появляется окно "Информационная база не обнаружена. Создать новую базу?", нажать "Нет". Пробуем переименовать расширение файла 1CM на 1CD. Снова открыть конфигуратор, конфигуратор открылся. Что!?! Открыть окно конфигурации, далее открыть по очереди все модули обработки (объект, менеджер, форма).
Что видим? У модуля формы код остался в целости и сохранности открыт, у других модулей исходники пропали. Как так!?!
Давайте разбираться. Сначала выгрузим конфигурацию в файлы, нажав "Конфигурация" - "Выгрузить конфигурацию в файлы". В открывшемся окне выбрать пункт "XML файлы", выбрать каталог для выгрузки конфигурации в файлы и нажать "Выгрузить".
Упс, ошибка.
А что с файлом CF?
Ок, пробуем сохранить конфигурацию в файл, нажав "Конфигурация" - "Сохранить конфигурацию в файл". Выбрать файл *.cf для сохранения и нажать "Сохранить". Файл сохранился. Открыть файл 1Cv8.cf блокнотом Notepad++. Формат cf мобильного приложения напоминает формат обычного cf.
Распаковываем файл *.cf всем давно известным инструментом V8Unpack.
В списке распакованных файлов есть файлы:
ee4abc77-b917-438c-8e58-5bb55c15be9f.0_1
ee4abc77-b917-438c-8e58-5bb55c15be9f.0_3
Открыть любой из вышеперечисленных файлов блокнотом Notepad++.
Код, содержащий непонятные символы, но со знакомыми строками. Это, видимо, и есть старый добрый байт-код.
А что пишут другие эксперты? (выделил светло желтым фоном)
Ответ:
Очень похоже на скомпилированную в бинарное представление скобочную запись как в DT.
На глаз - вроде оно, с теми же кодами команд.
И как преобразовать бинарный байт-код в текстовый?
Есть описание формата. Сделать конвертер из бинарного представления данных во внутреннее.
А обратного преобразования нет?
В данный момент нет. Но сделать вроде не сложно.
Ответ:
Одну и ту же конфу сохранить как обычный cf (и распаковать), и из неё же сделать apk (затем вытащить 1СМ, из него cf, и тоже распаковать). Сравнить, понять принцип отличий и сделать конвертер. То есть, идти методом индукции, от частного к общему. На основании нескольких примеров создать алгоритм преобразования.
Есть ли возможность выгрузить CF без использования стороннего инструмента?
Ответ:
Публикуешь мобильное приложение, скачиваешь конфу не 1сным клиентом, а просто браузером. Получаешь конфу полностью в нормальном виде по объектам.
Что означают расширения файлов 0_1 и 0_2?
Ответ:
По сути, с помощью директив компиляции, также как и с помощью инструкций препроцессора в одном исходном модуле описываются сразу несколько модулей. Один модуль исполняется на клиенте, другой на сервере, третий на сервере без контекста. Для каждой директивы компиляции (а их всего 5) 1С компилирует отдельный модуль. Увидеть это можно на примере cf-файла мобильного приложения, а также файла 1cema.xml. Формат cf мобильного приложения немного отличается от формата обычного cf. Одно из отличий состоит в том, что в cf мобильного приложения все модули хранятся без исходных текстов, в скомпилированном виде. Даже модули управляемых форм. И хранятся скомпилированные модули управляемых форм в 4-х отдельных файлах, по одному скомпилированному модулю для каждой из 4-х доступных для управляемых форм директив компиляции (&НаКлиенте, &НаСервере, &НаСервереБезКонтекста, &НаКлиентеНаСервереБезКонтекста).
Собственно, из всего вышесказанного я делаю вывод, что директивы компиляции - это другая форма инструкций препроцессора. Как конкретно 1С внутри себя реализовала обработку директив компиляции, на стадии препроцессинга или на стадии компиляции - не так уж и важно, имхо. Главное, что смысл директив компиляции, но мой взгляд, тот же, что и у инструкций препроцессора.
Вопросы есть?
Вопрос:
Почему же не реализована возможность в обычной (не в мобильной) конфигурации поставить пароль на модуль управляемых форм или сделать поставку без исходных текстов модулей управляемых форм? Ведь, по сути, в мобильной платформе это реализовано.
Ответ:
Установить пароль можно на общий модуль, в нем реализовать всю логику, а в модуле формы вставить вызовы этого общего модуля.
Во многих отраслевых решениях 1С сделано примерно так.
