Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

unicode

Yashpal
Active Contributor
0 Likes
986

Hi All,

I want to know how unicode is useful.....I know how it stores data in DB ,how to code ABAP Programs which are unicode complaint......but I am confused about when a user logged as a certain language then he is able to view data in the language it is stored or the data is translated into the logged in language......is user able to insert data in language other than logged in .....in non unicode system we cant see data which is stored in other language for whose the compatible code page is not there.....if user changed the input language to other than logged on if he enters data it is stored in a currupted way...so i would like to know why should we go for unicode and how it is utilized in SAP..... please give some views about my problem.....

Thanks,

Yash

6 REPLIES 6
Read only

Former Member
0 Likes
925

<b>UNICODE :</b>

Data types such as CHAR ASCII and CHAR EBCDIC are mainly suited to English and central European languages. With other character sets, a code attribute is usually used for these data types. This code attribute uses a different presentation code to ASCII and EBCDIC, even for internal storage in the database system. This causes problems if you want to access these database systems using a different character set, or if you want to exchange data between database systems with different character sets.

You can avoid these problems by using internal character coding in accordance with UNICODE. Internally, the UNICODE data is stored in UTF-16/UCS-2 format. In UTF-16/UCS-2 format, all characters are two bytes long.

SAP DB is able to display various presentation codes in UNICODE format (UNICODE code in line with ISO 10646, page 1).

<b>Metadata in UNICODE</b>

The names of the database objects (such as table or column names) can be stored internally in UNICODE and can therefore then be displayed in the required presentation code in the database tools.

<b>in abap</b>

This switch to Unicode affects all statements where an explicit or implicit assumption is made about the internal length of a character. If you use these statements in a program that is designed to exploit the Unicode capabilities of the runtime environment, they must be checked and changed if necessary. Once a Unicode-enabled program has been changed accordingly, it behaves in the same way in both Unicode and non-Unicode systems. You can develop programs in a non-Unicode system (NUS) and then import them into a Unicode system (US).

<b>reward if useful</b>

Read only

0 Likes
925

Check these threads.....

Similar topics are discussed.

1.Unicode- Coverage Analyzer- (SCOV)

2. Problem in unicode check.

3. ABAP Unicode Conversion.

Hope it helps.

Read only

Former Member
0 Likes
925

Hi Yashpal,

Refer to the link<a href="http://help.sap.com/saphelp_erp2005/helpdata/en/62/3f2cadb35311d5993800508b6b8b11/frameset.htm">http://help.sap.com/saphelp_erp2005/helpdata/en/62/3f2cadb35311d5993800508b6b8b11/frameset.htm</a>

and

<a href="http://help.sap.com/saphelp_erp2005/helpdata/en/f2/31c79f828bed47906b882f2af35e3e/frameset.htm">http://help.sap.com/saphelp_erp2005/helpdata/en/f2/31c79f828bed47906b882f2af35e3e/frameset.htm</a>

Hope it helps

Lokesh

Read only

Former Member
0 Likes
925

Hi gupta

From Release 6.10, ABAP supports multi-byte coding for characters in Unicode. Prior to Release 6.10, ABAP used only character sets that were based on single-byte codes – such as ASCII and EBCDIC – or double-byte codes, such as SJIS and BIG5.

This switch to Unicode affects all statements where an explicit or implicit assumption is made about the internal length of a character. If you use these statements in a program that is designed to exploit the Unicode capabilities of the runtime environment, they must be checked and changed if necessary. Once a Unicode-enabled program has been changed accordingly, it behaves in the same way in both Unicode and non-Unicode systems. You can develop programs in a non-Unicode system (NUS) and then import them into a Unicode system (US).

Unicode allocates each character with an individual number irrespective of the platform, programme or language.

That not only allows the application to expand the computer's supply of characters from a previous 256 to approximately 100,000 symbols but in particular, it also maintains a trouble-free understanding between the different language components within a system, said the company.

For futher details refer the links.

http://help.sap.com/saphelp_webas630/helpdata/en/79/c5546ab3dc11d5993800508b6b8b11/frameset.htm

http://help.sap.com/saphelp_erp2005/helpdata/en/74/13453cc7f35d0ee10000000a11405a/frameset.htm

Hope this helps ;>)

Regards,

Rakesh.

Read only

Former Member
0 Likes
925

Hi,

if you read this SAP help you can understand better.

and here you can some examples with unicode and without unicode, see them also..

http://help.sap.com/saphelp_nw04/helpdata/en/79/c554d3b3dc11d5993800508b6b8b11/frameset.htm

Regards

vijay

Read only

Former Member
0 Likes
925

Hi,

Unicode is a big chapter. I'm giving you some points from SAP Docs.

Before Release 6.10, SAP software only used character sets based on codes such as ASCII and EBCDIC. In these codes every character is displayed by one byte, therefore character sets like these are also called single-byte codepages. However, every one of these character sets is only suitable for a limited number of languages. These codes are not sufficient for displaying East Asian languages, so double-byte codepages are used in which every byte consists of one or two bytes.

Problems arise if you try to work with texts written in different incompatible character sets in one central system. If, for example, a system only has a West European character set, other characters cannot be correctly processed. Attempting to exchange data between systems with incompatible character sets can lead to errors.

As of 6.10, to resolve these issues, SAP has introduced Unicode, a form of encoding that complies with ISO/IEC 10646 and covers all languages. Each character is generally mapped using 16 bits (=2 bytes) and this offers a maximum of 65 536 bit combinations.

This conversion to Unicode affects any ABAP programs in which an explicit or implicit assumption is made about the internal length of a character. For an ABAP program to run under Unicode, you must have installed a Unicode-enabled SAP System, connected to a suitable operating system and database.

Thus, a Unicode-compatible ABAP program is one where all Unicode checks are in effect. Such programs return the same results in Unicode systems as in non-Unicode systems. To perform the relevant syntax checks, you must activate the "Unicode checks" flag in the screens of the program and class attributes.

In a Unicode system, you can only execute programs for which the Unicode flag has been set. 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 Unicode or non-Unicode system. In future, the Unicode flag will be set for all new programs and classes.

If the Unicode flag is not set, the program can only be executed in a non-Unicode system. Unicode-specific syntax and semantic changes do not apply to such programs. However, you can use all language extensions that have been introduced as part of SAP's conversion to Unicode.

As a result of the modifications and restrictions associated with the Unicode flag, programs are largely executed with the same semantics in both Unicode and non-Unicode systems. Occasionally, however, there may be differences. Therefore, programs designed to run on both systems must be tested on both platforms.

I hope this helps.

Regards,

Venkat Ramanan