Globalization support features enable you to develop multilingual applications that can be run simultaneously from anywhere in the world. An application can render the content of the user interface, and process data, using the native language and locale preferences of the user.
This section contains:
Oracle Database enables you to store, process, and retrieve data in native languages. The languages that can be stored in a database are all languages written in scripts that are encoded by Oracle-supported character sets. Through the use of Unicode databases and datatypes, Oracle Database supports most contemporary languages.
Additional support is available for a subset of the languages. The database can, for example, display dates using translated month names, and can sort text data according to cultural conventions.
In this document, the term language support refers to the additional language-dependent functionality, and not to the ability to store text of a specific language. For example, language support includes displaying dates or sorting text according to specific locales and cultural conventions. Additionally, for some supported languages, Oracle Database provides translated error messages and a translated user interface for the database utilities.
|
See Also:
|
Oracle Database supports cultural conventions that are specific to geographical locations. The default local time format, date format, and numeric and monetary conventions depend on the local territory setting. Setting different NLS parameters enables the database session to use different cultural settings. For example, you can set the euro (EUR) as the primary currency and the Japanese yen (JPY) as the secondary currency for a given database session, even when the territory is AMERICA.
Different countries have different conventions for displaying the hour, day, month, and year. For example:
| Country | Date Format | Example | Time Format | Example |
|---|---|---|---|---|
| China | yyyy-mm-dd |
2005-02-28 |
hh24:mi:ss |
13:50:23 |
| Estonia | dd.mm.yyyy |
28.02.2005 |
hh24:mi:ss |
13:50:23 |
| Germany | dd.mm.rr |
28.02.05 |
hh24:mi:ss |
13:50:23 |
| UK | dd/mm/yyyy |
28/02/2005 |
hh24:mi:ss |
13:50:23 |
| U.S. | mm/dd/yyyy |
02/28/2005 |
hh:mi:ssxff am |
1:50:23.555 PM |
Oracle Database stores this calendar information for each territory:
First day of the week
Sunday in some cultures, Monday in others. Set by the NLS_TERRITORY parameter.
First week of the calendar year
Some countries use week numbers for scheduling, planning, and bookkeeping. In the ISO standard, this week number can differ from the week number of the calendar year. For example, 1st Jan 2005 is in ISO week number 53 of 2004. An ISO week starts on Monday and ends on Sunday. To support the ISO standard, Oracle Database provides the IW date format element, which returns the ISO week number. The first calendar week of the year is set by the NLS_TERRITORY parameter.
Number of days and months in a year
Oracle Database supports six calendar systems in addition to the Gregorian calendar, which is the default. These additional calendar systems are:
Japanese Imperial
Has the same number of months and days as the Gregorian calendar, but the year starts with the beginning of each Imperial Era.
ROC Official
Has the same number of months and days as the Gregorian calendar, but the year starts with the founding of the Republic of China.
Persian
The first six months have 31 days each, the next five months have 30 days each, and the last month has either 29 days or (in leap year) 30 days.
Thai Buddha uses a Buddhist calendar.
Arabic Hijrah has 12 months and 354 or 355 days.
English Hijrah has 12 months and 354 or 355 days.
The calendar system is specified by the NLS_CALENDAR parameter.
First year of era
The Islamic calendar starts from the year of the Hegira. The Japanese Imperial calendar starts from the beginning of an Emperor's reign (for example, 1998 is the tenth year of the Heisei era).
Different countries have different numeric and monetary conventions. For example:
| Country | Numeric Format | Monetary Format |
|---|---|---|
| China | 1,234,567.89 | ¥1,234.56 |
| Estonia | 1 234 567,89 | 1 234,56 kr |
| Germany | 1.234.567,89 | 1.234,56€ |
| UK | 1,234,567.89 | £1,234.56 |
| U.S. | 1,234,567.89 | $1,234.56 |
Different languages have different sort orders. In addition, different cultures or countries that use the same alphabets may sort words differently. For example, in Danish, Æ is after Z, while Y and Ü are considered to be variants of the same letter.
Sort order can be case-sensitive or case-insensitive. Case refers to the condition of being uppercase or lowercase. For example, in a Latin alphabet, A is the uppercase glyph for a, the lowercase glyph.
Sort order can ignore or consider diacritics. A diacritic is a mark near or through a character or combination of characters that indicates a different sound than the sound of the character without the diacritic. For example, the cedilla (,) in façade is a diacritic. It changes the sound of c.
Sort order can be phonetic or it can be based on the appearance of the character. For example, sort order can be based on the number of strokes in East Asian ideographs. Another common sorting issue is combining letters into a single character. For example, in traditional Spanish, ch is a distinct character that comes after c, which means that the correct order is: cerveza, colorado, cheremoya. This means that the letter c cannot be sorted until Oracle Database has checked whether the next letter is an h.
|
See Also:
|
In single-byte character sets, the number of bytes and the number of characters in a string are the same. In multibyte character sets, a character or code point consists of one or more bytes. Calculating the number of characters based on byte length can be difficult in a variable-width character set. Calculating column length in bytes is called byte semantics, while measuring column length in characters is called character semantics.
Character semantics is useful for specifying the storage requirements for multibyte strings of varying widths. For example, in a Unicode database (AL32UTF8), suppose that you must have a VARCHAR2 column that can store up to five Chinese characters with five English characters. Using byte semantics, this column requires 15 bytes for the Chinese characters, which are 3 bytes long, and 5 bytes for the English characters, which are 1 byte long, for a total of 20 bytes. Using character semantics, the column requires 10 characters.
Unicode is a character encoding system that defines every character in most of the spoken languages in the world. In Unicode, every character has a unique code, regardless of the platform, program, or language.
You can store Unicode characters in an Oracle Database in two ways:
You can create a Unicode database that enables you to store UTF-8 encoded characters as SQL character datatypes (CHAR, VARCHAR2, CLOB, and LONG).
You can declare columns and variables that have SQL national character datatypes.
The SQL national character data types are NCHAR, NVARCHAR2, and NCLOB. They are also called Unicode data types, because they are used only for storing Unicode data.
The national character set, which is used for all SQL national character data types, is specified when the database is created. The national character set can be either UTF8 or AL16UTF16 (default).
When you declare a column or variable of the type NCHAR or NVARCHAR2, the length that you specify is the number of characters, not the number of bytes.
|
See Also:
|