Code Pages
The RFC performs the conversion between different technical formats (integer display, Little versus big Endian, and so on), as well as between code pages of sender and recipient.
In the case where two SAP systems that have different code pages exchange data with each other, and where these do not use Unicode code pages, the code page conversion is performed on the receiver system side. The binary codes of characters that cannot be converted into the code page of the receiver system are retained.
In the case where two SAP systems that have different code pages exchange data with each other, and where one of these systems uses a Unicode code page, the code page conversion is always performed on the side of the system that uses the Unicode code page. The binary codes of characters that can not be converted into the non-Unicode code page, are substituted with replacement characters.
In the case where two SAP systems of the same code page (non-Unicode or Unicode) exchange data with each other, the RFC only performs the technical conversions, no code page conversion.
RFC and Unicode
The RFC between a Unicode system and a non-Unicode system must convert the text data between the code pages that are use 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 following 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 that contains characters such as these are therefore already incorrect before the conversion; they may have entered the system from outside, through uncontrolled channels, or may have arisen from using text processing operations in the system that are unsuitable.
RFC Between Unicode Systems and MDMP Systems
If the RFC takes place between a Unicode system and a non-Unicode system that has multiple code pages (MDMP system), then 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 (in principle, these are tables that have a flat row structure). The RFC transmits deep structures (structures that have at least one table type; see section BC-ABAP Dictionary, Types, Structures in the online documentation) in XML, and codes the text data in UTF-8. If a non-Unicode system receives such data, then it converts it into the code page of the logon language. If a non-Unicode system sends such data, then it converts it from the code page that is currently set.
The language-related conversion of 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).
Structures with LANG Fields
The RFC gets the language from the LANG fields that are included in the transported tables of type 1. In each case, the 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, then 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 that has 1 LANG field, this implicitly serves as the text language; when such a structure is created, the DDIC attribute is activated. This setting can be reset in transaction SE11.
Structures Without LANG Fields
If a structure has no LANG field, or if none of the LANG fields are flagged as the text language, then the Unicode system converts in the following way:
MDMP system calls Unicode system
|
Corresponding to the code page given by the sender
|
Unicode system calls MDMP system
|
Converts into the non-Unicode code page that is normally assigned to the logon language (in the Unicode system).
You also have the option of using the logon language of the RFC destination (instead of that of the current context), by making a special setting for the RFC destination in SM59: call transaction SM59 and for this destination select theRFC Bit Options on the tab page Special Options in the section Special Flags. Then select the checkboxDetermined Communication Code Page (hexadecimal value 0x200).‑{}‑ |
