topic Re: unicode in Application Development and Automation Discussions

unicode

Former Member — Fri, 08 Jun 2007 10:34:45 GMT

what are restrictions in unicode ABAP programming

Points will be rewarded

Re: unicode

uwe_schieferstein — Fri, 08 Jun 2007 10:38:42 GMT

Hello Jagrut

The SAP documentation <a href="http://help.sap.com/saphelp_47x200/helpdata/en/62/3f2cadb35311d5993800508b6b8b11/content.htm">ABAP and Unicode</a>

is quite comprehensive on this topic.

Regards

Uwe

Re: unicode

Former Member — Fri, 08 Jun 2007 10:39:24 GMT

Unicode - an international standard that supports virtually all of the languages and scripts used in the world, ensuring that they function no matter what the language or platform. Future versions of SAP applications will be exclusively in 64-bit and Unicode starting in 2007

Regards

Suresh.D

Re: unicode

rainer_hbenthal — Fri, 08 Jun 2007 10:47:42 GMT

The main difference is that one character can be more then one byte now. So weird programs are showing non-aligned lists now. Or interfaces will no more work if the code insist that the starting of some fields always is at the same position.

Casting in a non-unicode envirinment might be ok but can fail in a unicode environment, syntax check does not help you.

You have to test all programs even those untouched if they still do what they are intended to do, listlayout might be disturbed, screen layout might be disturbed, import/export of files is extremly dangerous causi it can happen that no error will occur, but strange data is handled.

Re: unicode

Former Member — Fri, 08 Jun 2007 10:54:20 GMT

Hi,

About brief idea about unicode

In the past, SAP developers used various codes to encode characters of different alphabets, for example, ASCII, EBCDI, or double-byte code pages.

ASCII (American Standard Code for Information Interchange) encodes each character using 1 byte = 8 bit. This makes it possible to represent a maximum of 28 = 256 characters to which the combinations [00000000, 11111111] are assigned. Common code pages are, for example, ISO88591 for West European or ISO88595 for Cyrillic fonts.

EBCDI (Extended Binary Coded Decimal Interchange) also uses 1 byte to encode each character, which again makes it possible to represent 256 characters. EBCDIC 0697/0500 is an old IBM format that is used on AS/400 machines for West European fonts, for example.

Double-byte code pages require 1 or 2 bytes for each character. This allows you to form 216 = 65536 combinations where usually only 10,000 - 15,000 characters are used. Double-byte code pages are, for example, SJIS for Japanese and BIG5 for traditional Chinese.

Using these character sets, you can account for each language relevant to the SAP System. However, problems occur if you want to merge texts from different incompatible character sets in a central system. Equally, exchanging data between systems with incompatible character sets can result in unprecedented situations.

One solution to this problem is to use a code comprising all characters used on earth. This code is called Unicode (ISO/IEC 10646) and consists of at least 16 bit = 2 bytes, alternatively of 32 bit = 4 bytes per character. Although the conversion effort for the R/3 kernel and applications is considerable, the migration to Unicode provides great benefits in the long run:

The Internet and consequently also mySAP.com are entirely based on Unicode, which thus is a basic requirement for international competitiveness.

Unicode allows all R/3 users to install a central R/3 System that covers all business processes worldwide.

Companies using different distributed systems frequently want to aggregate their worldwide corporate data. Without Unicode, they would be able to do this only to a limited degree.

With Unicode, you can use multiple languages simultaneously at a single frontend computer.

Unicode is required for cross-application data exchange without loss of data due to incompatible character sets. One way to present documents in the World Wide Web (www) is XML, for example.

ABAP programs must be modified wherever an explicit or implicit assumption is made with regard to the internal length of a character. As a result, a new level of abstraction is reached which makes it possible to run one and the same program both in conventional and in Unicode systems. In addition, if new characters are added to the Unicode character set, SAP can decide whether to represent these characters internally using 2 or 4 bytes.

A Unicode-enabled ABAP program (UP) is a program in which all Unicode checks are effective. Such a program returns the same results in a non-Unicode system (NUS) as in a Unicode system (US). In order to perform the relevant syntax checks, you must activate the Unicode flag in the screens of the program and class attributes.

In a US, you can only execute programs for which the Unicode flag is set. In future, the Unicode flag must be set for all SAP programs to enable them to run on a US. If the Unicode flag is set for a program, the syntax is checked and the program executed according to the rules described in this document, regardless of whether the system is a US or an NUS. From now on, the Unicode flag must be set for all new programs and classes that are created.

If the Unicode flag is not set, a program can only be executed in an NUS. The syntactical and semantic changes described below do not apply to such programs. However, you can use all language extensions that have been introduced in the process of the conversion to Unicode.

As a result of the modifications and restrictions associated with the Unicode flag, programs are executed in both Unicode and non-Unicode systems with the same semantics to a large degree. In rare cases, however, differences may occur. Programs that are designed to run on both systems therefore need to be tested on both platforms.

Regards

Re: unicode

Former Member — Fri, 08 Jun 2007 11:23:01 GMT

Hi Jagrut,

Following is you answer .

Restrictions in Unicode Programs

The adjustments you have to make and the restrictions that apply in the Unicode context have been limited to the essentials on the ABAP development side to keep the conversion effort for ABAP users to a minimum. In some cases, however, this has led to the emergence of more complex rules, for example, with regard to assignments and comparisons between incompatible structures.

4.1 Character and Numeric Type Operands

Up to now, you have been able to use flat structures as arguments of ABAP statements wherever single fields of type C were expected. In a UP this is no longer generally permitted. In a UP, you can use a structured field in a statement expecting a single field only if this structured field consists of character-type elementary types or purely character-type substructures. The structure is treated like a single field of type C.

The main restrictions applying to a UP in contrast to an NUS result from the fact that flat structures are only considered character-type on a limited basis, and fields of type X or STRING are never considered character-type. In addition, flat structures are only considered numeric-type if they are purely character-type. Numeric-type arguments include, for example, offset or index specifications as in READ TABLE ... INDEX i. The following examples show a structure that is character-type and a structure that is not:

BEGIN OF struc1, BEGIN OF struc2,

a(2) TYPE C, a (2) TYPE C,

b(2) TYPE C, Not n(6) TYPE N, Character- type

x(1) TYPE X, character-type d TYPE D,

i TYPE I, t TYPE T,

END OF struc. END OF struc.

Another example is a control break in an internal table, triggered by the AT keyword. In a NUS, fields of type X to the right of the control key are treated as character-type, and are thus filled with an asterisk. In Unicode systems, conversely, the same type is filled with its initial value.

4.2 Access Using Offset and Length SpecificationsOffset and length specifications are generally critical since the length of each character is platform-dependent. As a result, it is initially unclear as to whether the byte unit or the character unit is referred to in mixed structures. This forced us to put in place certain considerable restrictions. However, access using offset or length specifications is still possible to the degree described in the following. The tasks subject to this rule include accessing single fields and structures, passing parameters to subroutines and working with field symbols.

*Single field accessOffset-based or length-based access is supported for character-type single fields, strings and single fields of types X and XSTRING. For character-type fields and fields of type STRING, offset and length are interpreted on a character-by-character basis. Only for types X and XSTRING, the values for offset and length are interpreted in bytes.

*Structure access

Offset-based or length-based access to structured fields is a programming technique that should be avoided. This access type results in errors if both character and non-character-type components exist in the area identified by offset and length.

Offset-based or length-based access to structures is only permitted in a UP if the structures are flat and the offset/length specification includes only character-type fields from the beginning of the structure. The example below shows a structure with character-type and non-character-type fields. Its definition in the ABAP program and the resulting assignment in the main memory is as follows:

BEGIN OF STRUC,

a(3) TYPE C, "Length 3 characters

b(4) TYPE N, "Length 4 characters

c TYPE D, "Length 8 characters

d TYPE T, "Length 6 characters

e TYPE F, "Length 8 bytes

f(26) TYPE C, "Length 28 characters

g(4) TYPE X, "Length 2 bytes

END OF STRUC.

a b c d A e f g

Internally, the fragment view contains four fragments [F1-F4]. Offset-based or length-based access in this case is only possible in the initial part F1. Statements like struc(21) or struc7(14) are accepted by the ABAP interpreter and treated like a single field of type C. By contrast, struc57(2) access is now only allowed in an NUP. If offset-based or length-based access to a structure is permitted, both the offset and length specifications are generally interpreted as characters in a UP.

Passing parameters to subroutines

Up to now, parameter passing with PERFORM has allowed you to use cross-field offset and length specifications. In future, this will no longer be allowed in a UP. In a UP, offset-based and length-based access beyond field boundaries returns a syntax or runtime error. For example, access types c15 or c5(10) would trigger such an error for a ten-digit C field c.

If only an offset but no length is specified for a parameter, the entire length of the field instead of the remaining length was previously used for access. As a result, parameter specifications are cross-field if you use only an offset, and therefore trigger a syntax error in a UP. PERFORM test USING c+5 is consequently not permitted.

In addition, in a UP, you can continue to specify the remaining length starting from the offset off for parameters using the form field+off(*).

*Ranges for offset-based and length-based access when using field symbolsA UP ensures that offset-based or length-based access with ASSIGN is only permitted within a predefined range. Normally, this range corresponds to the field boundaries in case of elementary fields or, in case of flat structures, to the purely character-type initial part. Using a special RANGE addition for ASSIGN, you can expand the range beyond these boundaries.

Field symbols are assigned a range allowed for offset/length specifications. If the source of an ASSIGN statement is specified using a field symbol, the target field symbol adopts the range of the source. If not explicitly specified otherwise, the RANGE is determined as follows:

ASSIGN field TO <f>.

In a UP, the field boundaries of field are assigned to <f> as the range, where field is no field symbol.

ASSIGN <g> TO <f>.

<f> adopts the range of <g>.

ASSIGN elfield+off(len) TO <f>.

In a UP, the field boundaries of the elementary field elfield are assigned to <f> as the range.

ASSIGN <elfield>+off(len) TO <f>.

<f> adopts the range of the elementary field <elfield>.

ASSIGN struc+off(len) TO <f>.

ASSIGN <struc>+off(len) TO <f>.

In a UP, the purely character-type initial part of the flat structures struc or <struc> determines the range boundaries.

If the assignment to the field symbol is not possible because the offset or length specification exceeds the range permitted, the field symbol is set to UNASSIGNED in a UP. Other checks such as type or alignment checks return a runtime error in a UP. As a rule, offset and length specifications are counted in

characters for data types C, N, D, and T as well as for flat structures, and in bytes in all other cases.

Offset without length specification when using field symbols

Up to now, ASSIGN field+off TO <f> has shown the special behavior that the field length instead of the remaining length of field was used if only an offset but not length was specified. Since an ASSIGN with a cross-field offset is therefore problematic under Unicode, you must observe the following rules:

1. Using ASSIGN field+off(*)... you can explicitly specify the remaining length.

2. ASSIGN <f>+off TO <g> is only permitted if the runtime type of <f> is flat and elementary, that is, C, N, D, T (offset in characters) or X (offset in bytes).

3. ASSIGN field+off TO <g> is generally forbidden from a syntax point of view since any offset other than 0 would cause the range to be exceeded. Exceptions are cases in which a RANGE addition is used.

These rules enable you also in future to pass a field symbol through an elementary field using ASSIGN <f>+n TO <f>, as it is the case in a loop, for example.

Assignments

This section deals with implicit and explicit type conversions using the equal sign (=) or the MOVE statement. Two fields can be converted if the content of one field can be assigned to the other field without triggering a runtime error.

For conversions between structured fields or a structured field and a single field, flat structures were previously treated like C fields. With the implementation of Unicode, this approach has become too error-prone since it is not clear if programs can be executed with platform-independent semantics.

Two fields are compatible if they have the same type and length. If deep structures are assigned, the fragment views must therefore be identical. One requirement in connection with the assignment and comparison of deep structures has been that type compatibility must exist between the operands, which requires both operands to have the same structure. This requirement will continue to apply to Unicode systems.

*Conversion between flat structuresTo check whether conversion is permitted at all, the Unicode fragment view of the structures is set up initially by combining character and byte type groups and alignment gaps as well as any other components. If the type and length of the fragments of the source structure are identical in the length of the shorter structure, conversion is permitted. Assignment is allowed subject to the fulfillment of the following conditions:

1. The fragments of both structures up to the second-last fragment of the shorter structure are identical.

2. The last fragment of the shorter structure is a character or byte type group.

3. The corresponding fragment of the longer structure is a character or byte type group with a greater length.

If the target structure is longer than the source structure, the character-type components of the remaining length are filled with blank characters. All other components of the remaining length are filled with the type-adequate initial value, and alignment gaps are filled with zero bytes. Since longer structures were previously filled with blanks by default, using initial values for non-character-type component types is incompatible. This incompatible change is, however, rather an error correction. For reasons of compatibility, character-type components are not filled with initial values.

BEGIN OF struc1, BEGIN OF struc2,

a(1) TYPE C, a(1) TYPE C,

x(1) TYPE X, b(1) TYPE C,

END OF struc1. END OF struc2.

The assignment struc1 = struc2 is not allowed under Unicode since struc1-x in contrast to struc2-b occupies only one byte.

BEGIN OF struc3, BEGIN OF struc4,

a(2) TYPE C, a(8) TYPE C,

n(6) TYPE N, i TYPE I,

i TYPE I, f TYPE F,

END OF struc3. END OF struc4.

The assignment struc3 = struc4 is allowed since the fragment views of the character-type fields and the integer are identical.

BEGIN OF struc5, BEGIN OF struc6,

a(1) TYPE X, a(1) TYPE X,

b(1) TYPE X, BEGIN OF struc0,

c(1) TYPE C, b(1) TYPE X,

END OF struc5. c(1) TYPE C,

END OF struc0,

END OF struc6.

struc5 = struc6 is again not permitted since the fragment views of both structures are not identical due to the alignment gaps before struc0 and struc0-c.

BEGIN OF struc7, BEGIN OF struc8,

p(8) TYPE P, p(8) TYPE P,

c(1) TYPE C, c(5) TYPE C,

END OF struc7. o(8) TYPE P,

END OF struc8.

The assignment struc7 = struc8 works since the Unicode fragment views are identical with regard to the length of structure struc7.

For deep structures, the operand types must be compatible as usual. As an enhancement measure, we slightly generalized the convertibility in case of object references and table components.

*Conversion between structures and single fieldsThe following rules apply for converting a structure into a single field and vice versa:

1. If a structure is purely character-type, it is treated like a C field during conversion.

2. If the single field is of type C, but only part of the structure is character-type, conversion is only possible if the structure begins with a character-type structure and if this structure is at least as long as the single field. Conversion now takes place between the first character-type group of the structure and the single field. If the structure is the target field, the character type sections of the remainder are filled with blanks, and all other components are filled with the type-adequate initial value.

3. Conversion is not permitted if the structure is not purely character-type and if the single field is not of type C.

As with the assignment between structures, filling non-character-type components with the initial value is incompatible.

* Conversion between internal tablesTables can be converted if their row types are convertible. The restrictions described above therefore also effect the conversion of tables.

* Implicit conversionsThe above rules also apply to all ABAP statements that use implicit conversions according to the MOVE semantics. For example, this is true for the following statements for internal tables:

APPEND wa TO itab. APPEND LINES OF itab1 TO itab2.

INSERT wa INTO itab. INSERT LINES OF itab1 INTO [TABLE] itab2.

MODIFY itab FROM wa. MODIFY itab ... TRANSPORTING ... WHERE ... ki = vi ...

READ TABLE itab ...INTO wa. READ TABLE itab ...WITH KEY ...ki = vi ...

LOOP AT itab INTO wa. LOOP AT itab .... WITH KEY ... ki = vi ...

The restrictions for explicit conversion also apply to the implicit conversion of VALUE specifications.

Hope This Helps....

Reward Points ....

Regards

Jitendra

Re: unicode

Former Member — Fri, 08 Jun 2007 11:23:46 GMT

Hi Jagrut,

Following is you answer .

Restrictions in Unicode Programs

4.1 Character and Numeric Type Operands

BEGIN OF struc1, BEGIN OF struc2,

a(2) TYPE C, a (2) TYPE C,

b(2) TYPE C, Not n(6) TYPE N, Character- type

x(1) TYPE X, character-type d TYPE D,

i TYPE I, t TYPE T,

END OF struc. END OF struc.

*Structure access

BEGIN OF STRUC,

a(3) TYPE C, "Length 3 characters

b(4) TYPE N, "Length 4 characters

c TYPE D, "Length 8 characters

d TYPE T, "Length 6 characters

e TYPE F, "Length 8 bytes

f(26) TYPE C, "Length 28 characters

g(4) TYPE X, "Length 2 bytes

END OF STRUC.

a b c d A e f g

Passing parameters to subroutines

In addition, in a UP, you can continue to specify the remaining length starting from the offset off for parameters using the form field+off(*).

ASSIGN field TO <f>.

In a UP, the field boundaries of field are assigned to <f> as the range, where field is no field symbol.

ASSIGN <g> TO <f>.

<f> adopts the range of <g>.

ASSIGN elfield+off(len) TO <f>.

In a UP, the field boundaries of the elementary field elfield are assigned to <f> as the range.

ASSIGN <elfield>+off(len) TO <f>.

<f> adopts the range of the elementary field <elfield>.

ASSIGN struc+off(len) TO <f>.

ASSIGN <struc>+off(len) TO <f>.

In a UP, the purely character-type initial part of the flat structures struc or <struc> determines the range boundaries.

characters for data types C, N, D, and T as well as for flat structures, and in bytes in all other cases.

Offset without length specification when using field symbols

1. Using ASSIGN field+off(*)... you can explicitly specify the remaining length.

2. ASSIGN <f>+off TO <g> is only permitted if the runtime type of <f> is flat and elementary, that is, C, N, D, T (offset in characters) or X (offset in bytes).

These rules enable you also in future to pass a field symbol through an elementary field using ASSIGN <f>+n TO <f>, as it is the case in a loop, for example.

Assignments

1. The fragments of both structures up to the second-last fragment of the shorter structure are identical.

2. The last fragment of the shorter structure is a character or byte type group.

3. The corresponding fragment of the longer structure is a character or byte type group with a greater length.

BEGIN OF struc1, BEGIN OF struc2,

a(1) TYPE C, a(1) TYPE C,

x(1) TYPE X, b(1) TYPE C,

END OF struc1. END OF struc2.

The assignment struc1 = struc2 is not allowed under Unicode since struc1-x in contrast to struc2-b occupies only one byte.

BEGIN OF struc3, BEGIN OF struc4,

a(2) TYPE C, a(8) TYPE C,

n(6) TYPE N, i TYPE I,

i TYPE I, f TYPE F,

END OF struc3. END OF struc4.

The assignment struc3 = struc4 is allowed since the fragment views of the character-type fields and the integer are identical.

BEGIN OF struc5, BEGIN OF struc6,

a(1) TYPE X, a(1) TYPE X,

b(1) TYPE X, BEGIN OF struc0,

c(1) TYPE C, b(1) TYPE X,

END OF struc5. c(1) TYPE C,

END OF struc0,

END OF struc6.

struc5 = struc6 is again not permitted since the fragment views of both structures are not identical due to the alignment gaps before struc0 and struc0-c.

BEGIN OF struc7, BEGIN OF struc8,

p(8) TYPE P, p(8) TYPE P,

c(1) TYPE C, c(5) TYPE C,

END OF struc7. o(8) TYPE P,

END OF struc8.

The assignment struc7 = struc8 works since the Unicode fragment views are identical with regard to the length of structure struc7.

For deep structures, the operand types must be compatible as usual. As an enhancement measure, we slightly generalized the convertibility in case of object references and table components.

*Conversion between structures and single fieldsThe following rules apply for converting a structure into a single field and vice versa:

1. If a structure is purely character-type, it is treated like a C field during conversion.

3. Conversion is not permitted if the structure is not purely character-type and if the single field is not of type C.

As with the assignment between structures, filling non-character-type components with the initial value is incompatible.

* Conversion between internal tablesTables can be converted if their row types are convertible. The restrictions described above therefore also effect the conversion of tables.

APPEND wa TO itab. APPEND LINES OF itab1 TO itab2.

INSERT wa INTO itab. INSERT LINES OF itab1 INTO [TABLE] itab2.

MODIFY itab FROM wa. MODIFY itab ... TRANSPORTING ... WHERE ... ki = vi ...

READ TABLE itab ...INTO wa. READ TABLE itab ...WITH KEY ...ki = vi ...

LOOP AT itab INTO wa. LOOP AT itab .... WITH KEY ... ki = vi ...

The restrictions for explicit conversion also apply to the implicit conversion of VALUE specifications.

Hope This Helps....

Reward Points ....

Regards

Jitendra