Біти і байти

Ця сторінка — про технічне підґрунтя того, як ABAP тримає дані в памʼяті. Зазвичай програміст цим не переймається — runtime інтерпретує байти за типом автоматично. Але розуміння механізму допомагає осмислити casting через field symbols, conversion між типами і поведінку у debugger-i, коли виводиться hex-значення.

Тип визначає інтерпретацію

Ті самі байти в памʼяті можуть означати зовсім різне — все залежить від типу, через який ми до них звертаємось. Три обʼєкти, що посідають по 4 байти з однаковим hex-вмістом 32003700:

DATA num TYPE i.
num = 2 * 3 * 5 * 53 * 2267.
" debugger: hex 32003700, значення 3604530 (little-endian integer)

DATA text TYPE c LENGTH 2.
text = '2' && '7'.
" debugger: hex 32003700, значення '27' (UCS-2: 0032 = '2', 0037 = '7')

DATA hex TYPE x LENGTH 4 VALUE 'CDFFC8FF'.
hex = BIT-NOT hex.
" debugger: hex 32003700, значення X'32003700' (байти інтерпретуються напряму)

Bit-рівень однаковий, але ABAP виводить три різні значення — 3604530, 27, 32003700 — бо тип диктує правила інтерпретації. Від типу залежить і які операції дозволені: арифметика, конкатенація, bit-операції — різні операнди, різні результати.

Byte order (endianness) — для числових типів залежить від платформи. Big-endian записує старший байт першим, little-endian — молодший. Для символьних (UCS-2) кодування також залежить від byte order.

Casting — та сама памʼять, інший тип

Casting не змінює байти — він дає памʼяті нове імʼя з новим типом. Робиться через field symbol з додаванням CASTING:

DATA hex TYPE x LENGTH 4 VALUE '32003700'.
FIELD-SYMBOLS: <num>  TYPE i,
               <text> TYPE c.

ASSIGN hex TO <num>  CASTING.
ASSIGN hex TO <text> CASTING.

" hex    = X'32003700'
" <num>  = 3604530      (ті самі 4 байти як integer)
" <text> = '27'          (ті самі 4 байти як UCS-2 string)

Один memory region, три різні “вікна” в нього. Зміна через <num> одразу видно через hex і <text> — це та сама памʼять.

Type conversion — байти реально змінюються

Type conversion (або просто conversion) відбувається при присвоєнні між різними типами. На відміну від casting, байти реально переписуються — ABAP застосовує conversion rules, щоб зберегти тип-специфічний сенс.

DATA text TYPE c LENGTH 2 VALUE '27'.
DATA num  TYPE i.

num = text.

" text у hex: 32003700 (UCS-2 представлення '27')
" num  у hex: 1B000000 (little-endian integer 27)

Для character → integer runtime розпізнає ‘27’ як число, створює нове hex-представлення (1B000000 = 27 десяткове) і пише його за адресою num. Якщо текст не конвертується у число ('abc') — CX_SY_CONVERSION_NO_NUMBER.

Перевірка через field symbol

Щоб побачити hex будь-якого обʼєкта — каста́й його на байтовий тип:

TYPES hex4 TYPE x LENGTH 4.
FIELD-SYMBOLS <as_hex> TYPE hex4.

DATA num TYPE i VALUE 27.
ASSIGN num TO <as_hex> CASTING.
" <as_hex> = X'1B000000'

Це той самий трюк, що робить ABAP Debugger у вкладці Hexadecimal.

Практичне значення

Для щоденного коду біти і байти не потрібні — тип робить свою роботу. Коли розуміння стає в нагоді:

Debugger показує hex, що не збігається з логічним значенням — це нормально для числових і символьних типів, byte order приховує очевидність.
Casting через field symbol у динамічному програмуванні — коли треба одну й ту саму памʼять обробляти по-різному.
Unicode conversion issues — при роботі з legacy не-Unicode системами, коли символьне значення не збігається з hex-очікуваним.
Serialization / бінарні протоколи — прямий TYPE x LENGTH n + явний контроль порядку байтів.

_{Адаптовано з 09_Bits_and_Bytes.md (Apache 2.0). Повний перелік нюансів — в оригіналі.}