Code Pages

RFC and Unicode

The RFC between a Unicode system and a non-Unicode system has to convert the text data between the code pages used on both sides. Here, the following situations are possible:

• An input character cannot be converted into the output code page.

  Example: A Chinese Unicode character cannot be displayed in any European code page according to ISO8859.

• The conversion leads to an overrun of the output buffer.

  Example: A sequence of Japanese Unicode characters may cause an output buffer of the same length to overrun, when converting into the Japanese multibyte code page SHIFTJIS.

• Characters in the input data are incorrect; for example, in non-Unicode multibyte code pages, not all combinations of 2 bytes are permitted.

  Example: The Japanese code page SHIFTJIS (SAP number 8000) is a multibyte code page that has byte pairs whose first half lies in the range 0x80-0xEF, and whose second half lies in the range 0x40-0xFC. All other byte pairs are illegal and therefore cannot be converted. Data containing characters of this kind are therefore already incorrect before conversion. They may have entered the system from outside, through uncontrolled channels, or may be the result of using unsuitable text processing operations in the system.

RFC Between Unicode Systems and MDMP Systems

If the RFC is place between a Unicode system and a non-Unicode system with multiple code pages (MDMP system), the data is available on the MDMP side in different code pages. In this case, the RFC takes into account the language keys included in the date, and assigns the code page used in the MDMP system to each language.

The procedure described here is applied to tables of type 1 (these tables normally have a flat row structure). The RFC transmits deep structures in XML, and codes the text data in UTF-8. If a non-Unicode system receives data like this, it converts it into the code page for the logon language. If a non-Unicode system sends this type of data, it converts it from the code page that is currently set.

The language-compatible conversion of the data takes place in the Unicode systems. Here, the Unicode systems emulate non-Unicode systems, thereby ensuring compatibility with old non-Unicode systems (downward compatibility).

During conversion, the Unicode system assigns the MDMP code page to the languages, as follows:

Structures with LANG Fields

The RFC gets the language from the LANG fields in transported tables of type 1. Every relevant LANG field is flagged as a text language by a DDIC attribute. Transaction SE11 enables you to display and maintain this indicator.

If one structure uses .INCLUDE or .APPEND to refer to another structure with LANG fields, the indicator in the structure making the reference must also be reset; the structure being referenced can be opened and displays the indicator field that can be maintained.

In a structure with a 1 LANG field, this implicitly serves as the text language. When this type of structure is created, the DDIC attribute is activated. This setting can be reset in transaction SE11.

Structures Without LANG Fields

If a structure does not have a LANG field, or if none of the LANG fields are flagged as the text language, the Unicode system performs the conversion as follows:

Unknown Languages

The transferred data might contain a language that is unknown in the MDMP system configuration. This can occur in both transfer directions, and independently of the client/server role of the systems involved.

Data may also contain a LANG field with the value " " (space), although this value is invalid according to the value table. Here, the same rules apply as for structures without LANG fields (see above).