This document covers the following topics:
In Natural, you can specify Unicode strings with the format U and U constants.
Format U
With format U, you can define data which holds Unicode strings. The Natural data
format U is internally UTF-16.
See also Format and Length of User-Defined Variables in the Programming Guide.
U Constants
You can define Unicode constants with the prefix "U". For
example:
U'Äpfel'
The prefix "UH" can be used for defining Unicode constants in hexadecimal format. Four hexadecimal digits represent one UTF-16 code unit as defined by the Unicode Standard. So the overall length must be a multiple of four. For example, if you need the hexadecimal form of
U'Äpfel'
you need the UTF-16 code units for "Ä", "p", "f", "e" and "l" (which are "U+00C4", "U+0070", "U+0066", "U+0065" and "U+006C") and you have to combine them to the following hexadecimal string:
UH'00C4007000660065006C'
See also Unicode Constants in the Programming Guide.
The data format U is endian-dependent. This has to be considered when moving between the formats B and U.
The advantage of the U format (as compared with the A format) is, that it can hold any
combinations of characters from different languages and that it does not depend on the
default code page (value of the system variable *CODEPAGE).
Moreover, the U format makes it easier to share data between different platforms; no
more conversions (for example, from EBCDIC to ASCII) are necessary.
On the other hand, U format data consumes more memory than A format data. For languages in which most strings can be represented by single-byte encoding, U format will result in strings occupying twice the space that was previously required. However, for East Asian languages, the memory consumption will often not be higher.
Basically, U format can be used in most statements which allow A format. However, if a
Natural object name is given as an operand of a statement (for example, in the CALLNAT statement), U cannot be used
because Natural object names have A format. For information on a specific statement, see
the Statements
documentation.
Basically, A and U format can be used together in one statement, for example:
EXAMINE S FOR P WITH DELIMITER D REPLACE R
where S is U format, and P,
D and R are A format.
In the above example, the variables P,
D and R are temporarily
converted into the target format U before the actual execution of the EXAMINE statement. The conversion from
Unicode to code page or vice versa requires calling an ICU function. The conversion
requires additional computing time and additional memory. This disadvantage is even
greater with very large variables. To avoid frequent conversions, it is recommended that
you use only one format within one statement. When all operands in the above example are
specified in either U format or A format, a conversion is not necessary. However, if you
choose to specify only U operands, this variant will be slower since (due to its nature)
this operand type consumes more resources; one character is then coded with 2 bytes
(instead of 1 byte which is used with A format).
With a conversion (especially from U format to A format), there is always the risk that
characters cannot be represented in the target code page. For example, you want to
convert the Unicode character "U+05D0" (Hebrew letter Alef)
into the code page IBM01140 (English). Since this character is not contained in the code
page IBM01140, either the substitution character for this code page is used, or the
place holder which was specified when defining the code page in NATCONFG. When the parameter CPCVERR is set to
ON, an error message will be issued in this case, indicating a conversion
error. In any case, the original information will be lost.
The following statements are particularly affected when using Unicode:
Normalization in Unicode: A process of removing alternate representations of equivalent sequences from textual data in order to convert the data into a form that can be binary-compared for equivalence. The Unicode Standard defines different normalization forms. The normalization form that results from the canonical decomposition of a Unicode string, followed by the replacement of all decomposed sequences by primary composites where possible, is called "Normalization Form Composed" (NFC).
Natural assumes that all Unicode data is in NFC format to assure that string operations
can be performed without partial truncation of a Unicode character. Natural conversion
operations assure that the resulting Unicode string is in NFC. If Unicode data is
received from outside of Natural and it is not guaranteed that the data has NFC format,
the MOVE NORMALIZED
statement can be applied.
Example:
| Character Sequence | NFC |
|---|---|
| ê (U+00EA) | ê (U+00EA) |
| e (U+0065) + ^ (U+0302) | ê (U+00EA) |
Note:
Concatenating two or more strings in NFC format can result in not-NFC format.
An implicit conversion between Unicode and the default code page (value of the system
variable *CODEPAGE) is performed when moving strings
from U to A or vice versa with the MOVE statement.
Furthermore, the MOVE
ENCODED statement can be used for conversion between different code
pages or from any available code page to Unicode and vice versa. This can be helpful if
data is coming from outside of Natural and this data is coded in a code page which
differs from the default code page. But even for conversions between the default code
page and Unicode, this statement can be used if you want to obtain a potential
conversion error with the GIVING clause; if CPCVERR is set to
ON, the MOVE statement will stop with a runtime error in
this case.
If a character cannot be converted, it depends on the setting of the
CPCVERR parameter whether a substitution character is used for
this character or whether the conversion fails.
This statement can also be used for conversion from U data into UTF-8 format.
Note:
If you convert data to a code page which differs from the default code page, it is
recommended not to use this data in I/O. I/O is only meaningful with the default code
page.
A "grapheme" is what a user normally thinks of as a character. In most cases, a Unicode code point is a grapheme, however, a grapheme can also consist of several Unicode code points. For example, a sequence of one base character and one or more combining characters is a grapheme.
Example: "a" (U+0061) + "." (U+0323) + "^" (U+0302) defines one grapheme which is displayed as follows:
Note:
If a base/combining character sequence is normalized, this does not mean that the
sequence is always replaced by a pre-composed character, because not all characters are
available in a pre-composed format.
A "supplementary code point" is a Unicode code point between "U+10000" and "U+10FFFF". A supplementary code point is in UTF-16, represented by a surrogate pair which consists of two code units where the first value of the pair is a "high-surrogate code unit", and the second is a "low-surrogate code unit". Such characters are generally rare, but some are used, for example, as part of Chinese and Japanese personal names, and therefore support for these characters is commonly required for government applications in East Asian countries.
The string handling statements such as EXAMINE and its SUBSTRING option work on
UTF-16 code units. It is the user's responsibility that the code does not separate
graphemes or surrogate pairs.
However, the clauses CHARPOSITION and CHARLENGTH of the
EXAMINE statement (see Syntax 3 - EXAMINE for
Unicode Graphemes) can be used to ask for the start and length
(in UTF-16 code units) of graphemes. The result values can be used for
SUBSTRING calls. With these clauses, it is possible to scan a string
grapheme by grapheme.
Example:
DEFINE DATA LOCAL 1 #UNICODE-STRING (U15) 1 #CODE-UNIT-INDEX (N4) 1 #CODE-UNIT-LEN (N4) 1 #GRAPHEME-NUMBER (N4) END-DEFINE MOVE U'' TO #UNICODE-STRING #GRAPHEME-NUMBER := 1 REPEAT EXAMINE FULL VALUE OF #UNICODE-STRING FOR CHARPOSITION #GRAPHEME-NUMBER GIVING POSITION IN #CODE-UNIT-INDEX GIVING LENGTH IN #CODE-UNIT-LEN DISPLAY #UNICODE-STRING #GRAPHEME-NUMBER #CODE-UNIT-INDEX #CODE-UNIT-LEN #GRAPHEME-NUMBER := #GRAPHEME-NUMBER + 1 WHILE #CODE-UNIT-INDEX NE 0 END-REPEAT END
The above example program provides the following output:
Page 1 05-12-15 09:33:49 #UNICODE-STRING #GRAPHEME-NUMBER #CODE-UNIT-INDEX #CODE-UNIT-LEN --------------- ---------------- ---------------- --------------
The document to be parsed is always internally converted to UTF-8 if the document is not already encoded in UTF-8.
See the description of the PARSE
JSON statement for further information.
See also Statements for Internet Access and Parsing in the Programming Guide.
The document to be parsed is always internally converted to UTF-16 (if the document is not already encoded in UTF-16).
See the description of the PARSE
XML statement for further information.
See also Statements for Internet Access and Parsing in the Programming Guide.
Data transfer with the REQUEST DOCUMENT statement normally does not
involve any code page conversion. If you want to have the outgoing and/or incoming data
encoded in a specific code page, you can use the DATA ALL clause and/or the
RETURN PAGE clause of the REQUEST DOCUMENT statement to
specify this.
See the description of the REQUEST
DOCUMENT statement for further information.
See also Statements for Internet Access and Parsing in the Programming Guide.
The DEFINE PRINTER
statement provides a CODEPAGE clause to provide for conversion of print
report data into a code page different from the default code page (value of the system
variable *CODEPAGE).
Data exchange in Unicode format via RPC is supported. See the description of the
CALLNAT statement.
If U data is sent from a platform with big endian encoding to a platform with little endian encoding or vice versa, the encoding is adapted so that it conforms with the encoding on the receiving platform. For example, when U data in little endian encoding arrives on a big endian platform, this data is converted to big endian encoding before it is handed over to the program. When this data is sent back, it is converted back to little endian encoding.
In a logical condition criterion, Unicode operands can be used together with alphanumeric and binary operands. If not all operands are Unicode operands (format U), the second and all following operands are converted to the format of the first operand. If a binary operand (format B) is specified as the second or a following operand, the length of the binary operand must be even; the binary operand is assumed to contain Unicode code points.
If the first operand is a Unicode operand (format U) and the comparison is therefore performed as a Unicode comparison, the ICU collation algorithm is used. The ICU algorithm does not perform a plain binary comparison. For example,
some code points such as "U+0000" are ignored during the comparison process,
combined characters are considered as being equal to the equivalent single code point (for example, the German character "ä" represented by "U+00E4" and the combination of the code points "U+0061" and "U+0308" are considered as being equal by ICU).
Note:
Comparing an alphanumeric and a Unicode operand can deliver different results,
depending on the sequence of the fields.
See also Logical Condition Criteria in the Programming Guide.
The system variable *CODEPAGE is used to return the IANA name
of the default code page, that is, the code page used for conversions between Unicode
and code page format.
The system variable *LOCALE contains the language and country
of the current locale.
U format can be used for large and dynamic variables. For dynamic U variables, *LENGTH returns
the number of UTF-16 code units.
See also Introduction to Dynamic Variables and Fields in the Programming Guide.
The following session parameters are available:
| Parameter | Description |
|---|---|
DL |
Specifies the display length for a field of format A or U. See also Display Length for Output - DL Parameter in the Programming Guide. |
EMU
|
Edit mask in Unicode. |
ICU
|
Insertion character in Unicode. |
LCU
|
Leading characters in Unicode. |
TCU
|
Trailing characters in Unicode. |
As long as Natural was not Unicode-enabled, the length of an alphanumeric field was always identical to the number of columns needed for displaying the field (called number of display columns). This was even true for the East Asian languages which use DBCS code pages: an A format field can hold only half the characters (for example, A10 results in A5).
Example:
DEFINE DATA LOCAL 1 #A8 (A8) END-DEFINE #A8 := 'computer' WRITE #A8 #A8 := '' WRITE #A8 END
The above code results in the following output:
Page 1 ... computer
With U format fields, the length of a field and the number of display columns is no
longer identical. U characters can have narrow width (for example, Latin characters),
wide width (for example, Chinese characters) or no width (for example, combining
characters). Therefore, it is totally unknown how many display columns a U field needs;
this depends on the contents of the field. Natural cannot automatically decide how many
columns are to be reserved on the screen: if the maximum size is assumed, Latin output
will have large gaps, and if the minimum size is assumed, Chinese output cannot be
displayed totally. Therefore, the Natural programmer has to define the display width of
a field; this is done with the DL parameter. The AL parameter cannot be used
for this purpose, because it cuts away the part of the field which exceeds the defined
length. But we do not want to cut any characters from the U field; we only want to
define the start position of the following field.
Example:
DEFINE DATA LOCAL 1 #U8 (U8) 1 #U4 (U4) END-DEFINE #U8 := 'computer' WRITE #U8 #U4 := U'
The above code results in the same output as above:
Page 1 ... computer
On Windows, in a
remote development environment with the Natural Web I/O Interface client, it is possible
to scroll in a field where the defined value for the DL parameter
is smaller than the real display width of the field.
The parameters EMU, ICU, LCU and TCU allow using characters which are not included
in the default code page. They are stored in Unicode format in the generated program.
These parameters can be used with all field formats.
The parameters EM,
IC, LC and TC can also be used with U
format fields. These parameters may also be useful if characters which are contained in
the default code page have different encodings in other code pages. For example, the
Euro sign (€) has the code point "0x80" in the
"windows-1252" (Latin 1) code page, but the code point
"0x88" in the "windows-1251"
(Cyrillic) code page. Thus, using a Unicode parameter (EMU,
ICU, LCU or TCU)
will assure that the Euro sign is always displayed correctly, no matter what code page
is installed on the PC.
Example for EMU:
DEFINE DATA
LOCAL
01 EMPLOYEES-VIEW VIEW OF EMPLOYEES
02 FIRST-NAME
02 NAME
02 SALARY (1)
END-DEFINE
*
READ (6) EMPLOYEES-VIEW
DISPLAY NAME FIRST-NAME SALARY(1) (EMU=999,999
)
END-READ
*
END
The above code results in the following output:
Page 1 05-12-15 11:45:36
NAME FIRST-NAME ANNUAL
SALARY
-------------------- -------------------- --------
ADAM SIMONE 159,980
MORENO HUMBERTO 165,810
BLOND ALEXANDRE 172,000
MAIZIERE ELISABETH 166,900
CAOUDAL ALBERT 167,350
VERDIE BERNARD 170,100
The library SYSEXPG contains sample programs for Unicode and code page
support in Natural:
UNICOX01 lists all Unicode characters.
UNICOX02 converts Unicode characters to code points and vice versa.
CODEPX01 lists all code pages, whether the code page is supported in
Natural and which encoding it uses. For all supported code pages, it offers services
to list the characters of the code page and to convert a string from the code page
into its hexadecimal representation and vice versa.
CODEPXL1 lists all characters of any 1-byte code page.
CODEPXL2 lists all characters of any 2-byte code page.
CODEPXC1 converts a string from any code page into its hexadecimal
representation and vice versa.