Краткое описание формата файлов *.1CD (файловых баз 1Сv8)
Разработка - Математика и алгоритмы
Отмазки.
Данное описание не претендует на законченность, безошибочность и понятность.
Начало.
Описание формата приведено в терминах языка C. Размер типа char – 1 байт, размер типа short int – 2 байта, размер типа int и unsigned int – 4 байта. Префиксом 0x обозначаются шестнадцатеричные числа.
Файлы баз *.1CD состоят из блоков длиной 4096 байт (0x1000). Соответственно, длина файла всегда кратна 4096.
Блок 0.
Нулевой блок имеет следующую структуру:
struct {
char sig[8]; // сигнатура “1CDBMSV8”
char ver1;
char ver2;
char ver3;
char ver4;
unsigned int length;
int unknown;
}
Первые 8 байт – сигнатура базы «1CDBMSV8».
Следующие 4 байта - это версия базы. На данный момент мне встречались только версия «8.0.5.0» (ver1 = 8, ver2 = 0, ver3 = 5, ver4 = 0) – это базы 1Cv8.0 и версия «8.1.0.0» (ver1 = 8, ver2 = 1, ver3 = 0, ver4 = 0) – это базы 1Cv8.1 и 1Cv8.2.
Следующие 4 байт – длина базы (файла) в блоках.
Предназначение поля unknown неизвестно, всегда содержит 1.
Объекты.
Вся остальная информация в базе хранится в объектах (файлах базы). Каждый объект состоит из одного или более блоков. У каждого объекта есть один заголовочный блок, блоки с таблицей размещения, и собственно данные. Второе и третье может отсутствовать.
Структура первого блока каждого объекта такова:
struct {
char sig[8]; // сигнатура “1CDBOBV8”
int length; // длина содержимого объекта
int version1;
int version2;
unsigned int version;
unsigned int blocks[1018];
}
Первые 8 байт – сигнатура базы «1CDBOBV8».
Есть 2 типа объектов.
Блок 1. Таблица свободных блоков.
Первый тип объекта – это таблица свободных блоков. Признаком этого блока является поле version равное 0. Такой объект в базе всегда один, и его заголовочный блок располагается всегда в блоке со смещением 1 (т.е. по адресу 0x1000). Длина данных такого объекта равна (length * 4) байт.
В blocks содержатся номера блоков, в которых собственно и находится содержимое таблицы свободных блоков. Значащими являются ненулевые значения в массиве blocks. Содержимое таблицы свободных блоков – это просто массив номеров свободных блоков:
unsigned int free_blocks[length];
Таким образом, в базе содержатся ровно length свободных блоков.
Когда системе требуется новый блок для данных, то она берет последний свободный блок из массива free_blocks и уменьшает length на 1. Если свободных блоков нет, то он создается в конце файла базы. Блоки, содержащиеся в массиве blocks, не являются свободными, а принадлежат объекту – таблице свободных блоков. В blocks может содержаться больше блоков, чем необходимо для хранения массива free_blocks.
Остальные объекты.
Второй тип объектов характеризуется ненулевым значением поля version. Вся информация в базе, кроме блока 0 и таблицы свободных блоков хранится именно в таких объектах.
В поле length содержится длина в байтах данных объекта.
В массиве blocks находятся индексы блоков, содержащих таблицу размещения данных объекта. Каждый блок, указанный в blocks, и являющийся частью таблицы размещения, имеет следующую структуру:
struct {
int numblocks;
unsigned int datablocks[1023];
}
Поле numblocks указывает количество реальных значений в datablocks (от 1 до 1023). В datablocks содержатся индексы блоков, в которых находится собственно содержимое объекта (данные). Так как в одном блоке таблицы размещения может быть указано максимум 1023 блока с данными, то соответственно, максимальная длина данных, указанных в одном блоке таблицы размещения равна 1023 * 4096 = 4190208 байт (0x3ff * 0x1000 = 0x3ff000). Таким образом, из длины содержимого объекта length мы можем определить количество фактических значений в blocks. Если length равен 0, то в blocks нет значащих данных, иначе количество значений в blocks равно (length - 1) / 0x3ff000 + 1 (деление целочисленное, без остатка). А также можно вычислить максимальную длину данных одного объекта: 4190208 * 1018 = 4265631744 байт (1018 – максимальное количество значений в массиве blocks), это совсем немного меньше 4х гигабайт.
Повторим, в заголовочном блоке объекта находится массив blocks, содержащий индексы блоков с таблицей размещения. А в таблице размещения находятся блоки, содержащие сами данные.
Блок 2. Корневой объект.
Последним объектом с предопределенным расположением является корневой объект. Заголовочный блок корневого объекта располагается в блоке с индексом 2. Все остальные объекты базы могут быть получены через корневой объект. Структура данных этого объекта зависит от версии базы, хотя и различается несильно. Для версии базы «8.0.5.0» эта структура выглядит так:
struct {
char lang[8];
int numblocks;
int tableblocks[numblocks];
}
Для версии «8.1.0.0» структура выглядит так:
struct {
char lang[32];
int numblocks;
int tableblocks[numblocks];
}
Т.е. различаются эти структуры только длиной поля lang. В поле lang содержится код языка базы. Код языка базы представляет собой строку в ANSI-кодировке. Мне встречались только базы с кодами «ru_RU» и «en». На что влияют эти коды языка, я не знаю, возможно, на порядок сортировки строк при построении индексов.
В поле numblocks содержится количество элементов в массиве tableblocks. В массиве же tableblocks содержатся индексы объектов, содержащих все таблицы данных. Т.е. таблиц в базе ровно numblocks.
Объект таблицы.
Каждый объект таблицы, указанный в корневом объекте, содержит просто текстовое описание таблицы в Unicode. Вот пример описания таблицы:
{"_Reference4",0,
{"Fields",
{"_IDRREF","B",0,16,0,"CS"},
{"_VERSION","RV",0,0,0,"CS"},
{"_MARKED","L",0,0,0,"CS"},
{"_ISMETADATA","L",0,0,0,"CS"},
{"_CODE","NC",0,9,0,"CI"},
{"_DESCRIPTION","NVC",0,25,0,"CI"},
{"_FLD7","I",1,0,0,"CS"}
},
{"Indexes",
{"_IDRREFIDX",1,
{"_IDRREF",16}
},
{"_REFERENCE4_CODE_SR",0,
{"_CODE",9},
{"_IDRREF",16}
},
{"_REFERENCE4_DESCR_SR",0,
{"_DESCRIPTION",25},
{"_IDRREF",16}
}
},
{"Recordlock","0"},
{"Files",118,119,96}
}
Как видно из этого примера, здесь присутствуют имя таблицы (_Reference4), раздел описания полей таблицы (Fields), раздел описания индексов (Indexes), параметр Recordlock и раздел Files.
В разделе Files всегда содержатся три числа, которые содержат индексы заголовочных блоков объектов (по порядку) с записями таблицы, Blob-данными (строки неограниченной длины и двоичные данные) и индексами. Если какого-либо объекта у таблицы нет, то соответствующее число равно нулю.
В разделе Fields содержатся описания полей таблицы. Описание каждого поля содержит (по порядку): имя поля (FieldName), тип поля (FieldType), признак использования NULL (NullExists), длину (FieldLength), точность (FieldPrecision) и признак регистрочувствительности (FieldCaseSensitive).
Сколько байт занимает каждое поле в записи, и как его интерпретировать, зависит от параметров поля. Во-первых, если NullExists у поля равен 1, то первый байт поля является признаком NULL. Значение 0 этого байта означает, что поле не содержит значение (т.е. содержит NULL). В противном случае, поле содержит значение. Если же NullExists равен 0, то такого байта в поле нет.
Далее, размер и формат поля зависит от типа поля. Типы поля бывают такими:
- «B» - двоичные данные. Длина поля равна FieldLength байт.
- «L» - булево. Длина поля 1 байт. Нулевое значение байта означает Ложь, иначе Истина.
- «N» - число. Длина поля в байтах равна Цел((FieldLength + 2) / 2). Числа хранятся в двоично-десятичном виде. Первый полубайт означает знак числа. 0 – число отрицательное, 1 – положительное. Каждый следующий полубайт соответствует одной десятичной цифре. Всего цифр FieldLength. Десятичная точка находится в FieldPrecision цифрах справа. Например, FieldLength = 5, FieldPrecision = 3. Байты 0x18, 0x47, 0x23 означают число 84.723, а байты 0x00, 0x00, 0x91 представляют число -0.091.
- «NC» - строка фиксированной длины. Длина поля равна FieldLength * 2 байт. Представляет собой строку в формате Unicode (каждый символ занимает 2 байта).
- «NVC» - строка переменной длины. Длина поля равна FieldLength * 2 + 2 байт. Первые 2 байта содержат длину строки (максимум FieldLength). Оставшиеся байты представляет собой строку в формате Unicode (каждый символ занимает 2 байта).
- «RV» - версия. Длина поля 16 байт. Предположительно содержит четыре числа int.
- «NT» - строка неограниченной длины. Длина поля 8 байт. Первые четыре байта содержат начальный индекс блока в объекте Blob таблицы, вторые четыре – длину данных в объекте Blob. В объекте Blob содержится строка в формате Unicode.
- «I» - двоичные данные неограниченной длины. Длина поля 8 байт. Первые четыре байта содержат начальный индекс блока в объекте Blob таблицы, вторые четыре – длину данных в объекте Blob.
- «DT» - дата-время. Длина поля 7 байт. Содержит данные в двоично-десятичном виде. Первые 2 байта содержат четыре цифры года, третий байт – две цифры месяца, четвертый байт – день, пятый – часы, шестой – минуты и седьмой – секунды, все также по 2 цифры.
Зная теперь длину в байтах каждого поля можно посчитать общую длину одной записи таблицы и смещение каждого поля в записи. Но для этого необходимо учесть следующее. Если в описании полей таблицы нет поля с типом версия (RV), но при этом параметр Recordlock равен 1, то в записи присутствует дополнительное поле, которое я для себя называю короткая скрытая версия. Длина этого поля равна 8 байт. В каждой записи самый первый байт – это признак удаленности записи (признак, что запись не занята). Если этот байт равен 1, то запись свободна, а следующие 4 байта содержат индекс следующей свободной записи. Из этого следует, что запись не может быть короче пяти байт. Если же первый байт записи содержит 0, то далее в записи следуют значения полей. Причем порядок полей определяется таким образом: превым всегда идет поле версии (или описанное в разделе Fields с типом RV или поле скрытой короткой версии), затем все остальные поля в том порядке, как они описаны в разделе Fields.
Объект записей таблицы.
Содержимое объекта записей таблицы содержит просто массив записей. Таким образом, длина данных этого объекта всегда кратна длине одной записи. Первая (точнее нулевая) запись всегда помечена как свободная, она содержит индекс следующей свободной записи (или 0, если таких нет). Т.е. с нее начинается цепочка свободных записей таблицы.
Объект Blob таблицы.
Объект содержит Blob-данные таблицы (строки неограниченной длины и двоичные данные неограниченной длины). Содержимое этого объекта состоит из блоков (не путать с блоками, из которых состоит файл 1CD) длиной 256 байт (0x100). Т.е. это просто массив блоков длиной 256 каждый. Поэтому длина данных объекта всегда кратна 256. Структура каждого блока объекта такова:
struct {
unsigned int nextblock;
short int length;
char[250] data;
}
Поле nextblock содержит индекс следующего блока, содержащего продолжение данных, или 0, если следующего блока нет. Поле length содержит длину данных в этом блоке (максимум 250). Поле data содержит сами данные. Нулевой блок всегда считается свободным, в поле nextblock он содержит индекс следующего свободного блока. Таким образом, с нулевого блока начинается цепочка свободных блоков.
В записях таблицы в полях с типом «NT» и «I» содержится индекс первого блока, с которого начинаются данные, относящиеся к этому полю данной записи.
Объект индексов таблицы.
На данный момент структура индексов до конца не изучена.
...
С благодарностью приму любые уточнения, дополнения, сообщения об ошибках, а также любую другую информацию по теме.
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Математика и алгоритмы Разработчик 1С 8.3 Абонемент ($m)
Данная внешняя обработка для платформы 1С:Предприятие реализует усовершенствованный алгоритм Левенштейна для вычисления схожести строк с учетом различных лингвистических особенностей русского языка. В отличие от классической реализации, этот алгоритм учитывает фонетические, визуальные и контекстные особенности набора текста.
1 стартмани
07.11.2025 7003 18 InFlach 17
Математика и алгоритмы Запросы Разработчик 1С:Предприятие 8 Бесплатно (free)
Рассмотрим быстрый алгоритм поиска дублей с использованием hash функции по набору полей шапки и табличных частей.
08.07.2024 9166 ivanov660 9
Математика и алгоритмы Разработчик 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)
На написание данной работы меня вдохновила работа @glassman «Переход на ClickHouse для анализа метрик». Автор анализирует большой объем данных, много миллионов строк, и убедительно доказывает, что ClickHouse справляется лучше PostgreSQL. Я же покажу как можно сократить объем данных в 49.9 раз при этом: 1. Сохранить значения локальных экстремумов 2. Отклонения от реальных значений имеют наперед заданную допустимую погрешность.
1 стартмани
30.01.2024 16974 stopa85 12
Математика и алгоритмы Бесплатно (free)
Разработка алгоритма, построенного на модели симплекс-метода, для нахождения оптимального раскроя.
19.10.2023 25240 user1959478 57
Математика и алгоритмы Разное 1С:Предприятие 8 1C:Бухгалтерия Россия Абонемент ($m)
Расширение (+ обработка) представляют собою математический тренажер. Ваш ребенок сможет проверить свои знание на математические вычисление до 100.
2 стартмани
29.09.2023 15730 maksa2005 8
Математика и алгоритмы Инструментарий разработчика Разработчик 1С:Предприятие 8 Россия Абонемент ($m)
Что ж... лучше поздно, чем никогда. Подсистема 1С для работы с регулярными выражениями: разбор выражения, проверка на соответствие шаблону, поиск вхождений в тексте.
1 стартмани
09.06.2023 25532 11 SpaceOfMyHead 20
Математика и алгоритмы Разработчик 1С:Предприятие 8 Бесплатно (free)
Три задачи - три идеи - три решения. Мало кода, много смысла. Мини-статья.
03.04.2023 17732 RustIG 10
Механизмы платформы 1С Математика и алгоритмы Разработчик 1С:Предприятие 8 Россия Бесплатно (free)
В статье анализируются средства платформы для решения системы линейных уравнений в 1С. Приводятся доводы в пользу некорректной работы встроенных алгоритмов, а значит потенциально некорректного расчета себестоимости в типовых конфигурациях.
23.11.2022 16619 gzharkoj 17
Помогите, плиз, в решении проблемки с базой.
Бухгалтерия предприятия 2.0 (Базовая), релиз 2.0.35.9
Платформа 8.2.13.219, также запускал и в 8.2.15.289 и в 8.2.16.352, результат один и тотже:
При попытке в конфигураторе открыть конфигурацию выходит "Ошибка формата потока".
chdbfl.exe ошибок не находит
При тестировани ТиИ выходит следуещее:
Тестирование начато
Проверка таблицы Document196.VT5018: удалено 1 записей
Проверка таблицы SeqB8257: удалено 1 записей
Обработка структуры базы данных...
Тестирование закончено
В процессе обновления информационной базы произошла критическая ошибка.
по причине:
Ошибка SDBL:
Тип поля CAST(Document8846.Number AS STRING(11)) AS Number несовместим с типом поля Number
При запуске в пользовательском режиме выдает следующее:
{Обработка.ДокументооборотСКонтролирующимиОрганами.МодульОбъекта(40725)}: Поле объекта не обнаружено (ПервичноеСообщениеСодержащееОтчетность)
по причине:
{Обработка.ДокументооборотСКонтролирующимиОрганами.МодульОбъекта(40725)}: Поле объекта не обнаружено (ПервичноеСообщениеСодержащееОтчетность)
Выгрузка и загрузка в новую базу через dt не помогла.
Также не помогает удаление Кэша, логов и Журнала регистрации.
Утилита Tool_1CD считывает структуру базы без ошибок, в таблице _Document8846 с полем _Number вроде все впорядке - длина 11, тип - fixed string.
Кто сталкивался, подскажите пожалуйста порядок лечения. Архивов к сожалению нет.
Установил пустую конфу того же релиза из шаблона. После запуска конфигуратора пустой конфы открыл конфигурацию. Оставив в таком виде, скопировал файл битой базы вместо живого в каталоге пустой конфы. Закрыл конфигуратор, при этом он сказал, что база повреждена. Затем открыл снова, конфигурация стала открываться. Но это еще не все, ошибка сидит внутри, что бы от нее избавиться полностью, пока конфигурация открыта, сделал обновление следующим релизом. Обновление и реструктуризация прошли успешно, в пользовательском режиме так же все нормально запустилось. Проверил данные, на месте. Далее уже экпериментировал. ТиИ ошибок не показала, последующие обновление также прошли на УРА!!!
неужели такая СЕКРЕТНАЯ информация?? и куда делся 21 пост?
В той ветке было обсуждение, почему убрали с Инфостарта программу Tool_1CD, самой программы там нет.
Сейчас программу Tool_1CD можно найти в других местах, но публично такие ссылки на инфостарте давать неприлично))
Здесь описан формат файла 1CD - а это в общем случае произвольная база данных. Например, хранилище конфигураций - это тоже файловая база данных (файл 1cv8ddb.1CD), однако в этой базе нет таблиц CONFIG, PARAMS, FILES и т.д. Или, например, временная БД 1Cv8tmp.1CD, создаваемая 1С при работе в файловом режиме.
Нигде в Инете не найду, а очень надо
плиз!
Респект автору!
Хотелось бы увидеть продолжение развития 1С Tool.
Лично мне бы хотелось бы, что бы в программе появился бы следующий функционал:
Возможность подсоединения к sql серверу.
Возможность внесения изменения данных в таблицах БД (в особенности в Blob-поля).
Если есть возможность, выложите на файлообменник файл 1CD, может быть удастся что-то сделать...
1) сортировка по степени заполненности внутренних файлов таблиц
2) или хотя бы 3 колонки рядом с идентификатором таблицы: размер data, blob, index
3) ОБЯЗАТЕЛЬНО разделители триад в числах. Прочитать, например, число 1'234'567'890 гораздо легче чем 1234567890
4) Хотелось бы видеть не только идентификаторы таблиц, но и по возможности имена объектов, как они описаны в конфигураторе
chdbfl.exe при проверке выдает: "Поврежден заголовок файла базы данных
Повреждено содержимое внутреннего файла <Описание базы данных>".
Tool_cd - стурктуру не показывает, пишет "длина файла в блоках и количество блоковв заголовке не равны"
Что можно сделать?
Было сделано два важных шага:
1) Сообщение "Поврежден заголовок файла базы данных" было вылечено тем, что изменена в блоке 0 длина файла, т.к. размер файла в байтах не совпадал числом-длиной в блоке 0(шестнадцатиричное число).
2) С помощью обработки Tool_CD открыли файлы битый и нормальной копии:
в конце в битой копии нет таблиц. Вычислили количество небитых. Данное количество таблиц поставили в количество элементов в массиве tableblocks = количеству таблиц в базе.
Таким образом, т.к. у нас были битыми только регистры, удалось войти в базу и вытащить все документы и справочники универсальной обработкой выгрузки/загрузки в нормальную копию.
Хотелось бы побольше информации (например об индексах). Tool_1cd их использует (в моем случае предупреждает
"Ошибка чтения индексов. Индекс первого свободного блока за пределами файла индексов"). Где-нибудь можно узнать побольше информации о формате 1CD?
- int length; // длина содержимого объекта
и т.п.: не совсем ясно, сколько значащих байт к нему относится.
В остальном - очень полезные вещи! И большая работа проделана! Респект автору!
Но как частный случай успешного лечения чтение весьма интересное. Почему бы тебе не создать публикацию здесь, на инфостарте?
Tool_1CD выводит где-нибудь блоки, которые занимает таблица? Я не нашёл, а судя по всему это полезная информация.
Публикации не умею делать, разрешаю скопировать мою статью с указанием ссылки на ЖЖ, чтобы люди могли задать мне вопросы в моём ЖЖ (на инфостарте я не планирую зависать, т.к. не занимаюсь 1С профильно)
Не так страшен 1с,как его распространенность. Если в 1с.проф2.0,1sbw6,1sv7- файлы *.dbf за 30мин. простым Fox ремонтировались, то теперь опять HxD-подавай? 20 лет назад написал cbd.prg(копи бух документ) на Fox21 с интерфейсом NC- c помощью которой легко любой док из одной конф. в другую делал- похоже сейчас опять возникает та же ситуация.
Ошибка СУБД:
Файл базы данных поврежден 'C:\Users\Марина\Desktop\HRMBase1/1Cv8.1CD'
по причине:
Файл базы данных поврежден 'C:\Users\Марина\Desktop\HRMBase1/1Cv8.1CD'
При проверке и исправлении утилитой chdbfl.exe база частично восстанавливается но все равно не читается... Отвечает
Ошибка SDBL
Разрушена структура базы данных 1С:Предприятия
Что посоветуете? Заранее благодарен.
email: all-leukhin@yandex.ru
Попытки сделать выгрузку данных из SQL в SQL в попытке что новая база сама создаст правильную структуру ни к чему не привели, ошибка повторилась. Выгрузка в DT аналогично ни к чему не привела. Попытки сделать ТиИ тоже не помогли.
Правила обмена брались различные и от старых релизов и типовые и скачивал отсюда, редактировали их в КД убирали записи по данному перечисление, толку никакого все равно одна и та же ошибка, как будто она где-то прописалась. Темпы 1С различным чистилками с инфостарта очищал, серваки перегружал. Перечисление переименовывал, возвращал ну и массу всяких вариантов - все в пустую.
В SQL пытались полностью убрать таблицу потом заливали ее из рабочей копии, результат неизменный.
Пришел к выводу что возможно в SQL произошло разрушение какой-то связки между таблицей перечисления и таблицей с указанием типа данных этой таблицы. Это я так предполагаю потому что в SQL не силен.
Подскажите что можно еще попробовать а также кто-то определил в какой таблице мне поискать и подменить указание типа данных таблицы. В файловую выливать не предлагайте сразу 200гигов база это нереально.
Раз ты читаешь байтами, а не более длинными блоками, то формула в твоем случае примерно такая
Байт1 + Байт2 * 256 + Байт3 * 256 * 256 + Байт4 * 256 * 256 * 256
{"USERS",0,
{"Fields",
{"USERID","B",0,16,0,"CS"},
{"NAME","NVC",0,256,0,"CI"},
{"PASSWORD","NC",0,32,0,"CI"},
{"REMOVED","L",0,0,0,"CS"},
{"BINDID","B",1,16,0,"CS"},
{"BINDSTRING","NT",1,0,0,"CI"},
{"RIGHTS","B",0,4,0,"CS"}
},
{"Indexes",
{"PK",0,
{"USERID",16}
},
{"NAME",0,
{"NAME",256}
},
{"BINDID",0,
{"BINDID",16}
}
},
{"Recordlock","0"},
{"Files",10,11,14}
} ПоказатьДалее получаю блок данных - нечто подобное
C0CA649B18CDB9429B05BC5D7517E8570D00100434043C0438043D043804410442044004300442043E044004200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000200020002000350066006100320038003500650031006200650062006500300061003600360032003300650033003300610066006300300034006100310066006200640035000001DB5920C3F09DD54486EAF00B164825DD01010000008C000000FFFF000000и знаю, что там лежит UserID = 7517e857-bc5d-9b05-c0ca-649b18cdb942, name = Администратор, password = 5fa285e1bebe0a6623e33afc04a1fbd5, removed = false, binid = 164825dd-f00b-86ea-db59-20c3f09dd544
Как этот блок данных преобразовать к человеческому виду? Через Tool_1CD я вижу эти данные, а сам выдернуть не могу. Буду рад любой наводке. Прикрепляю файл 1CD с которым работаю, и блок данных.
P.S. так же пробовал вот этой компонентой разбирать файл базы - но там так же можно вытащить только "сырые данные", которые я и привел выше. А вот как их разобрать - загадка...
USERS_Data
Все описано в разделе "Объект таблицы".
Или может проблема с тем, как хранятся и отображаются GUID'ы? Нажмите в Tool_1CD Ctrl-G (или пункт меню Настройки->Отображать Bynary(16) как GUID). Вы сразу увидите соответствие Вашего блока данных и отображаемых данных в Tool_1CD. Дело в том, что почему-то GUID'ы придуманы так, что порядок хранения байт и отображаемое значение не совпадают. Байты как-бы перемешаны. Прочитать про это можно, например, тут .
Положение еще усугубляется тем, что, формат хранения (порядок байт) разный в информационной базе (1Cv8.1CD) и в базе хранилища конфигураций (1cv8ddb.1CD). В 1cv8ddb.1CD он соответствует стандартному формату хранения Microsoft. А вот в 1Cv8.1CD 1С изобрела свой собственный формат. Хотя я думаю, что это просто ошибка, хотели сделать как в Microsoft, но, как всегда, все перепутали. А теперь, в целях совместимости, эта ошибка "узаконена". Типичный пример перевода бага в фичу.
Программа Tool_1CD не смогла открыть файл 1Cv8.1CD, выдав сообщение: "Файл не является базой 1С (сигнатура не равна 1CDBMSV8)".
Как поступить в данном случае, т.е. каким образом хотя бы попробовать изменить енту сигнатуру?
Автор, Валерий, как с вами связаться?
Нужна ваша помощь в восстановлении базы.
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 19734
Создание 23.04.09 01:50
Обновление 23.04.09 01:52
Просмотры 154585
Загрузки 0
Рейтинг
440
Комментарии 85
Код открыт Не указано
Рубрики Математика и алгоритмы
Кому Разработчик
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)