Я пытаюсь декодировать якобы шестую строку. В MS SQL Server (11.0.2100) данные имеют тип char(8)
.Декодирование шестнадцатеричной строки на 4 части, которая отображается на двоичную карту значений
В руководствах не был четким способом декодирования данных, но документы, что он содержит:
Учитывая шестнадцатеричную строку, т.е..
0001003F
с длиной 4. Нижний байт находится справа, старший байт слева. Для каждого из 4 'bytes
' была дана ссылочная таблица, которая отображает бит для определенного значения правды . Немного заказ также учитывая, имеющий бит 0 или битого в самом правом быть 1-й бита, ... и т.д.
таблица выглядит следующим образом:
первых «байты»:
|Bit Order | Description | 1 | 0 | trigger |
|-----------|---------------|-------------------|-------------------|---------------|
|BIT0 | state foo | state foo is ON | State foo is OFF | high level |
|BIT1 | state bar | in state bar | not in state bar | high level |
| ...
|BIT7 | state bazz | in state bazz | not in state bazz | high level |
(еще 3 таблицы следует для следующих 3 других «байт в ..., каждый из 4» байт-х предположительно имеет 8 равное количество „биты“)
я думал, способ декодирования этой информации является разделение шестнадцатеричной строки int O 4 части и преобразовывать их в виде бинарной строки шириной фиксировали из 8.
В PHP
, взятый пример шестигранной «0001003F
», первый байт был «3F
», имея преобразованы в двоичный, 0011 1111
(пространство для ясности). Затем было установлено, что значение для первого байта:
'state foo is on', 'in state bar', ..., 'not in state bazz'
.
Я также пытался: hex2bin("0001003F")
, но он выводит strin(4) " # "
.
Это правильный способ декодирования этих данных?
(прошу прощения, если теги неверны.)
Мое решение было очень похоже на ваш ответ. Существует ли такое кодирование/декодирование на практике? Я действительно не знаком с этой схемой кодирования/декодирования. –
@ javiniar.leonard, это зависит от проблемы. В частности, я не думаю, что 'CHAR (8)' является хорошим выбором для бит-маски. Если точно известно, что число бит не будет больше 64, я бы предпочел использовать 'BIGINT'. Если свойства состояний, вероятно, будут расти, или состояния могут иметь отношения с другими таблицами в будущем, я бы создал таблицу для состояний и таблицу для состояний объектов, таких как «obj_states (object_id, state_id)». Однако некоторые реализации СУБД могут содержать побитовые операции над полями BINARY (плановое расширение для MySQL 8.0). –
Но вы, очевидно, сохраняете некоторое пространство, сохраняя шестнадцатеричные символы по цене сложности кода. Вы можете сжать их лучше с помощью поля «BINARY»; 'HEX (bin_field)' может вернуть шестую строку для дальнейшей обработки в PHP. –