Skip to Content
Internationalization and Unicode

SAP Blended Code Page Solution

Several years ago, SAP developed blended code pages as a workaround to the problems caused by the MNLS (Multi National Language Support) solution. SAP also pushed ahead with the MDMP solution, which became preferable to blended code pages because the number of supported languages increased. With the first Unicode-enabled Basis release 6.10, both solutions have become obsolete.

The following document describes what to watch out for when converting a Blended Code Page system to Unicode, and what constraints apply to the data transfer between a Blended Code Page system and a Unicode system.

Note: New installations of blended code pages are desupported with SAP_BASIS 6.xx releases and higher! Support for existing installations is deprecated with SAP NetWeaver 7.xx releases and higher.

There are two types of SAP Blended Code Pages: Ambiguous Blended Code Pages and Unambiguous Blended Code Pages.

Ambiguous Blended Code Pages



Ambiguous Blended Code Pages
6100SAP Unification

all Latin-1 languages(with some characters not allowed), all Latin-2 languages (with some characters not allowed), Greek, Turkish, Japanese (without single byte Katakana and part of SJIS Level 2 Kanjis)

(ISO1 + ISO2 + ISO7 + SJIS1)

6200SAP Asian Unification

English, Chinese (simplified and traditional), Korean, Japanese (without single byte Katakana and part of SJIS Level 2 Kanjis)

(ASCII + SJIS1 + Asian)

6500SAP Diocletian

all Latin-1 languages and Greek

(ISO1 with ISO7 D7 and F7)

UnAmbiguous Blended Code Pages

Header 1Header 2UnAmbiguous Blended Code Pages
1180Transliteration from Latin-2 to Latin-1(ISO1 + transliteration from ISO2 to ISO1)
1810Hebrew with LTRmark(ISO8 + LTRmark)
6230SAP Asian UnificationT(trad. Chinese + SJIS1)
6240SAP Asian UnificationC(simp. Chinese + SJIS1)
6250SAP Asian UnificationK

(Korean + SJIS1)

6300SAP Eurojapan


all Latin-1 languages, Japanese (without single byte Katakana and part of SJIS Level 2 Kanjis)

(ISO1 + SJIS1)

6400SAP Silk Road


English, Greek, Japanese (without single byte Katakana and part of SJIS Level 2 Kanjis)

(ISO7 + SJIS1)

6600SAP Nagamasa

English, Thai, Japanese (without single byte Katakana and part of SJIS Level 2 Kanjis)

(Thai + SJIS1)

6700SAP Trans Siberian

English, Russian, Japanese (without single byte Katakana and part of SJIS Level 2 Kanjis)

(ISO5 + SJIS1)

What is the Difference?

When you use an Ambiguous Blended Code Page, several characters can be assigned to one and the same byte sequence. Each character can be represented by different byte sequences.

Example: 6100 SAP Unification

Ambiguous Byte SequenceHeader 2Ambiguous Character IDHeader 4

U+00C0

LATIN CAPITAL LETTER A WITH GRAVE

--> x'C0

U+00A7

SECTION SIGN

= x'A7

U+0154

LATIN CAPITAL LETTER R WITH ACUTE

--> x'C0

U+00A7

SECTION SIGN

= x'8198


When you use an Unambiguous Blended Code Page,  each byte sequence is assigned exactly one character. Each character can be represented by different byte sequences.
Example: 6300 SAP Eurojapan

Ambiguous Character ID
U+00A7 SECTION SIGN= x'A7
U+00A7 SECTION SIGN= x'8198


How Does This Affect the Charcter Set Conversion Between Non-Unicode System and Unicode System?

Non-Unicode → Unicode

Ambiguous blended code pages: The corresponding Unicode characters must be determined by using a language key. The mapping from the ambiguous blended code page to Unicode is not unique; i.e. language-specific.


Unambiguous blended code pages: The assignment of the corresponding Unicode characters is guaranteed. The mapping from the unambiguous blended code page to Unicode is unique.


Unicode → non-Unicode

Ambiguous blended code pages: The mapping from Unicode to the ambiguous blended code page is not unique; i.e. language-specific. This non-unique characteristic cannot be solved for data marked with language key 'E'.


Unambiguous blended code pages: The mapping from the unambiguous blended code page to Unicode is not unique; i.e. language-specific. This non-unique characteristic cannot be solved for data marked with language key 'E'.


Problematic Scenarios

Data flow from Unicode to non-Unicode (for both ambiguous and unambiguous blended code pages)

In general, a Blended Code Page system must not be the target of a data transfer from a Unicode system, if non-7 bit ASCII text data is to be transferred.

But:

If the data to be transferred is marked with an unambiguous language information (e.g. language field in the TABLES parameter of an RFC function module), it is possible to transfer the data:

• if an MDMP-like configuration of the target destination is maintained in transaction SM59 for RFC transfer, and
• if an according utilization of the language field is done in the program doing the file transfer.


Data flow from non-Unicode to Unicode (only for ambiguous blended code pages)
In general, an Ambiguous Blended Code Page system must not be the source system for data transfer to a Unicode system, if non-7 bit ASCII text data is to be transferred.

If the data to be transfered is marked with an unambiguous language information (e.g. language field in the TABLES parameter of an RFC function module), it is possible to transfer the data, as RFC is automatically assigning an unambiguous standard code page matching the language information. File transfer is possible, if an according utilization of the language field is done in the program used for reading the file.

Former Member

No comments