topic unicode in Application Development and Automation Discussions

unicode

Former Member — Fri, 12 Oct 2007 09:21:43 GMT

Hi,

this is sunil. i have a doubt. may i know what is the difference between unicode and nonunicode. pls, send me the reply as soon as possible.

Thanks & Regards,

sunil.

Re: unicode

rainer_hbenthal — Fri, 12 Oct 2007 09:23:56 GMT

Unicode is a ethod on how to handle every character existing in the world. In Non.Unicode you can only handle 256 at the same time. In Nonunicode every character needs exactly one byte, in uniocde this is no longer valid.A character may have up to 4 bytes in unicode.

Re: unicode

Former Member — Fri, 12 Oct 2007 09:25:13 GMT

Hi,

Unicode is a character encoding system similiar to ASCII. You can see the definiton for Unicode by Unicode consortium below.

Unicode is the universal character encoding, maintained by the Unicode Consortium.

This encoding standard provides the basis for processing, storage and interchange of text data in any language in all modern software and information technology protocols". Unicode covers all the characters for all the writing systems of the world, modern and ancient. It also includes technical symbols, punctuations, and many other characters used in writing text.

The Unicode Standard is intended to support the needs of all types of users, whether in business or academia, using mainstream or minority scripts.

Most of the SAP implementations are done on Unicode system as it support all kind of languages, which is good for a company to expend their business. Another things is Unicode system requires 70% more storage area and processing speed to run the system perfactly.

There are systems like XI, which can work only on Unicode so it is always advisible to go for unicode then to non-unicode.

Unicode - Overview

Before release 6.10, SAP supported different codes for representing characters of different fonts, for example ASCII, EBCDIC as single-byte code pages or double-bytecode pages:

ASCII (American Standard Code for Information Interchange) encodes every character with one byte. This means that a maximum of 256 characters can be displayed (strictly speaking, standard ASCII only encodes one character using 7 bit and can therefore only represent 128 characters. The extension to 8 bit is introduced with ISO-8859). Examples of common code pages are ISO-8859-1 for Western European, or ISO-8859-5 for Cyrillic fonts.

EBCDIC (Extended Binary Coded Decimal Interchange) also encodes each character using one byte, and can therefore also represent 256 characters. For example,EBCDIC 0697/0500 is an IBM format that has been used on the AS400 platform for Western European fonts.

Double byte code pages require between 1 and 2 bytes per character. This enables the representation of 65,536 characters, of which only 10,000 to 15,000 characters are normally used. For example, the code page SJIS is used for Japanese and BIG5 for traditional Chinese fonts.

Using these character sets, all languages can be handled individually in one ABAP-based SAP system. Difficulties arise if texts from different incompatible character sets are mixed in one central system. The exchange of data between systems with incompatible character sets can also lead to problems.

The solution to this problem is the use of a character set that includes all characters at once. This is realized by Unicode Unicode (ISO/IEC 10646) . A variety of Unicode character representations is possible for the Unicode character set, for example UTF, in which a character can occupy between one and four bytes.

From release 6.10, the SAP NetWeaver Application Server supports both Unicode and non-Unicode systems. Non-Unicode systems are conventional ABAP systems, in which one character is usually represented by one byte. Unicode systems are ABAP systems that are based on a Unicode character set and which have a corresponding underlying operating system, including a database.

Before release 6.10, many ABAP programming methods were based on the fact that one character corresponds to one byte. Before a system is converted to Unicode, ABAP programs must therefore be modified at all points where an explicit or implicit assumption is made about the internal length of a character.

ABAP supports this conversion using new syntax rules and new language constructs, whereby emphasis was 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 can be selected in the program properties. 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.

Reward points if useful

Re: unicode

Former Member — Fri, 12 Oct 2007 09:25:33 GMT

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). The following sections describe the conversions that are necessary:

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.

The examples presented in the following sections are based on a Unicode encoding using 2 bytes per character.

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.

You are recommended to follow the procedure below to make your programs US-compliant:

The UNICODE task in transaction SAMT performs first an NUS and then a US syntax check for a selected program set. For an overview of the syntax errors by systems, programs and authors, consult the following document in SAPNet: Alternatively, you can start the ABAP program RSUNISCAN_FINAL to determine the Unicode-relevant syntax errors for a single program.

Before you can set the Unicode flag in the NUS in the attributes of the program concerned, all syntax errors must be removed.

Having enabled the Unicode flag in the NUS, you can run the syntax check for this program. To display a maximum of 50 syntax errors simultaneously, choose Utilities -> Settings -> Editor in the ABAP Editor and select the corresponding checkbox.

Once all syntactical requirements are met in the NUS, you must test the program both in the NUS and US. The purpose of this test is to recognize any runtime errors and make sure that the results are correct in both systems. To rule out runtime errors in advance, you should always type field symbols and parameters so that any potential problems can be detected during the syntax check.

Re: unicode

Former Member — Fri, 12 Oct 2007 09:30:06 GMT

Unicode is the Language specific/dependent code

we mention this property in the program Attributes in SE38 tcode.

go through the links

http://help.sap.com/search/highlightContent.jsp

<b>Reward if usefull</b>