ABAP Keyword Documentation → ABAP - Overview → ABAP Character Sets
Switching to Unicode
Before Unicode support was introduced, many ABAP programmers assumed that one character corresponded to one byte. Before a non-Unicode system is converted to Unicode, therefore, ABAP programs must be changed wherever an explicit or implicit assumption is made about the internal length of a character. This mainly affects
- access to structures. The latter case applies since flat structures in non-Unicode programs are handled like character-like data objects and some programming techniques exploit this fact. The Unicode fragment view was introduced to enable the handling of structures.
ABAP supports this conversion using new syntax rules and new language constructs with emphasis placed on retaining as much of the existing source code as possible. As a preparation for the conversion to Unicode (but also independently of whether a system will actually be converted to Unicode), the checkbox Unicode checks active should be selected in the program attributes. The transaction UCCHECK supports the activation of this check for existing programs. If this property is set, the program is identified as a Unicode program. In a Unicode program, an additional stricter syntax check is performed than in non-Unicode programs. In some cases, statements must also be enhanced by using new additions. A syntactically correct Unicode program will normally run with the same semantics and the same results in Unicode and non-Unicode systems. (Exceptions to this rule are low-level programs that query and evaluate the number of bytes per character.) Programs that are required to run in both systems should therefore also be tested on both platforms.
In a Unicode system, only Unicode programs can be executed. Before converting to a Unicode system, the profile parameter abap/unicode_check should be set to "ON" so that only the execution of Unicode programs is permitted. Non-Unicode programs can only be executed in non-Unicode systems. All language constructs that have been introduced for Unicode programs can, however, also be used in non-Unicode programs.
It has been established that existing programs that have been programmed with no errors mostly fulfill the new Unicode rules and therefore require very little modification. Conversely, most programs that require significant changes are due to an error-prone and therefore questionable programming style. Even if planning a conversion to a Unicode system is not planned, Unicode programs are preferable because they are more easily maintained and less prone to errors. Just as outdated and dangerous language constructs are declared obsolete and are no longer permitted for use in ABAP Objects, the rules for Unicode programs also offer increased security when programming, for example when working with character fields and mixed structures. This applies particularly for the storage of external data (for example using the file interface), which has been completely reviewed for use in Unicode programs. When creating a new program, SAP therefore recommends that the program is always identified as a Unicode program; older programs can be converted to Unicode in stages.
Other versions:
7.31 | 7.40 | 7.54
Notes
- The program RSUNISCAN_FINAL can be used instead of transaction UCCHECK.
- A Unicode program with correct syntax must be checked for functional correctness in Unicode systems (and possibly also in non-Unicode systems). This can be done using unit tests from ABAP UNIT and associated test coverage checks from Coverage Analyzer.
- Unicode programs can run in both Unicode systems and non-Unicode systems, which makes non-Unicode programs obsolete.
- The ABAP keyword documentation describes the behavior of each language construct in Unicode programs by default. The behavior of the constructs in obsolete non-Unicode programs is also stated.