Hi, I need help to understand BOC. I'm trying to decode "raw data" from https://tonapi.io/account/EQAiIsvar4OYBn8BGBf9flfin6tl5poBx4MgJe4CQJYasy51
Read data-formats/cell-boc from docs, manually broken hex to bytes (lines 1..8) and cells (10..20).
Lines 24-28 are parsed cells shown in explorer (both tonapi and tonscan checked) to compare with.
I can't understand why first (longest) cell has '_' at last position in explorers. This cell must have D5=213 4-bit groups, thats 107 bytes and line afbe...49f5 is 214 chars in length. And trailing '_' is 215's - it seems extra. And source hex data has no any '0' here - after '4915' follows '0102' as links-and-length of next cell.
Why that '_' is there?
Apr 9, 2023, 8:29 PM
so '_' in first and second (x{00C_}) cells have different "meaning":
for first cell that has 213 "full" groups (...49F) and incomplete last ('5') the '_' "notifies" me that last digit means incomplete
while in x{00C_} cell length 03 is same as length of '00C' data, and '_' after 'C' is just "placeholder" and does not mean that I should perform "de-padding" of 'C' from 0b1100 to 0x1
?
for first cell that has 213 "full" groups (...49F) and incomplete last ('5') the '_' "notifies" me that last digit means incomplete
while in x{00C_} cell length 03 is same as length of '00C' data, and '_' after 'C' is just "placeholder" and does not mean that I should perform "de-padding" of 'C' from 0b1100 to 0x1
?
Apr 9, 2023, 8:51 PM
the byte before the data (0x03 in case of the 00c cell) is the d2 descriptor byte, and is equal to ceil(b/8)+floor(b/8), where b is the number of bits in the cell
so this cell is padded too, it has 9 bits, which gives ceil(1.125)+floor(1.125)=3
so this cell is padded too, it has 9 bits, which gives ceil(1.125)+floor(1.125)=3
Apr 9, 2023, 9:06 PM
hmmm why?
cell data are`0103 00c0 03` (in raw hex data).
According to https://docs.ton.org/develop/data-formats/cell-boc#cell-serialization:
01 is "5 flag bits and 3 link count bits" (so, only 1 link)
03 must be "the length of the full 4-bit groups" that's exactly length of "00c"
one more '0' (after 'c') - I thought it is to align to bytes
and 03 is cell ref
cell data are`0103 00c0 03` (in raw hex data).
According to https://docs.ton.org/develop/data-formats/cell-boc#cell-serialization:
01 is "5 flag bits and 3 link count bits" (so, only 1 link)
03 must be "the length of the full 4-bit groups" that's exactly length of "00c"
one more '0' (after 'c') - I thought it is to align to bytes
and 03 is cell ref
Apr 9, 2023, 9:12 PM
kind of feels that the doc you provided is wrong...
this is the way it's done in the serializers and if you do the calculations for your other cells it checks out
Apr 9, 2023, 9:17 PM