The binary representation of ABAP type I and type F numbers is hardware-specific. The byte order, which is pre-defined by the processor, is important in this respect. The byte order determines whether the highest-value byte ("big endian" binary representation) or lowest-value byte ("little endian" binary representation) is stored first.
Example
You can represent the number 16909060 (in hexadecimal notation) as follows:
| Endian | Byte 1 | Byte 2 | Byte 3 | Byte 4 |
|---|---|---|---|---|
| big | 0x01 | 0x02 | 0x03 | 0x04 |
| little | 0x04 | 0x03 | 0x02 | 0x01 |
The most common processors are Intel and DEC Alpha, both of which use little endian. Most other processors use big endian.
Characters are represented in the Unicode format UCS-2 using 2-byte unsigned integer values. This means that this format depends on the number representation used by the hardware. Thus you must differentiate between UCS-2BE (big endian) and UCS-2LE (little endian).
Character-type or byte-type data objects of the type c, string or x, xstring are often used as anonymous containers for data objects, especially structures, and stored persistently.
If such a container is stored and imported on an application server with a different byte order, problems can arise if the container is used for contents for which the byte order is important. This is always the case when numeric content of the type i or f is stored in character-type or byte-type containers. In Unicode Systems further problems can arise when byte-type content is stored in character-type containers.
Usually, to be able to work with the contents of an imported container, a casting is executed on the data type, whose data is stored in the container. However, because no type information is stored in the container, any necessary conversion of the byte order cannot take place.
The only way to prevent these problems arising is to avoid having numeric components in anonymous containers and never store byte-type contents in character-type fields.