This
chapter provides an overview of Oracle globalization support. It includes the following topics:
Globalization Support Architecture
h2>
Oracle's globalization support enables you to store, process, and retrieve d
ata in native languages. It ensures that database utilities, error messages, sort order, and date, time, monetary, numeric, and calen
dar conventions automatically adapt to any native language and locale.
In the past, Oracle'
s globalization support capabilities were referred to as National Language Support (NLS) features. National Language Support is a sub
set of globalization support. National Language Support is the ability to choose a national language and store data in a specific cha
racter set. Globalization support enables you to develop multilingual applications and software products that can be accessed and run
from anywhere in the world simultaneously. An application can render content of the user interface and process data in the native us
ers' languages and locale preferences.
Locale Data on Demand
Oracle's globali
zation support is implemented with the Oracle NLS Runtime Library (NLSRTL). The NLS Runtime Library provides a comprehensive suite of
language-independent functions that allow proper text and character processing and language convention manipulations. Behavior of th
ese functions for a specific language and territory is governed by a set of locale-specific data that is identified and loaded at run
time.
The locale-specific data is structured as independent sets of data for each locale th
at Oracle supports. The data for a particular locale can be loaded independent of other locale data. The advantages of this design ar
e as follows:
- You can manage memory consumption by choosing th
e set of locales that you need.
- You can add and customize locale data for a sp
ecific locale without affecting other locales.
Figure&
nbsp;1-1 shows that locale-specific data is loaded at runtime. In this example, French data and Japanese data are loaded into the
multilingual database, but German data is not.
Figure 1-1 Loading Locale-Specific Data to the Database
Text description of the illustration nlspg002.gif
<
a name="1006363">
The locale-specific data is stored in the $ORACLE_HOME/nls/data directory. The ORA_NLS10 environment variable should be defined only when you need to change the default directory location for the locale-
specific datafiles, for example when the system has multiple Oracle homes that share a single copy of the locale-specific datafiles.<
/p>
A boot file is used to determine the availability of the NLS objects that can be loaded. Or
acle supports both system and user boot files. The user boot file gives you the flexibility to tailor what NLS locale objects are ava
ilable for the database. Also, new locale data can be added and some locale data components can be customized.
Architect
ure to Support Multilingual Applications
The database is implemented
to enable multitier applications and client/server applications to support languages for which the database is configured.
The locale-dependent operations are controlled by several parameters and environment variables on bo
th the client and the database server. On the database server, each session started on behalf of a client may run in the same or a di
fferent locale as other sessions, and have the same or different language requirements specified.
The database has a set of session-independent NLS parameters that are specified when the database is created. Two of the param
eters specify the database character set and the national character set, an alternate Unicode character set that can be specified for
NCHAR, NVARCHAR2, and NCLOB data. The parameters specify the character set that is used to st
ore text data in the database. Other parameters, like language and territory, are used to evaluate check constraints.
If the client session and the database server specify different character sets, then the database converts
character set strings automatically.
From a globalization support perspective, all applica
tions are considered to be clients, even if they run on the same physical machine as the Oracle instance. For example, when SQL*Plus
is started by the UNIX user who owns the Oracle software from the Oracle home in which the RDBMS software is installed, and SQL*Plus
connects to the database through an adapter by specifying the ORACLE_SID parameter, SQL*Plus is considered a client. Its
behavior is ruled by client-side NLS parameters.
Another example of an application being c
onsidered a client occurs when the middle tier is an application server. The different sessions spawned by the application server are
considered to be separate client sessions.
When a client application is started, it initia
lizes the client NLS environment from environment settings. All NLS operations performed locally are executed using these settings. E
xamples of local NLS operations are:
- Display formatting in Ora
cle Developer applications
- User OCI code that executes NLS OCI functions with
OCI environment handles
When the application connects to a database, a session is cre
ated on the server. The new session initializes its NLS environment from NLS instance parameters specified in the initialization para
meter file. These settings can be subsequently changed by an ALTER SESSION statement. The statement changes
only the session NLS environment. It does not change the local client NLS environment. The session NLS settings are used to process
SQL and PL/SQL statements that are executed on the server. For example, use an ALTER SESSION statement to set the
NLS_LANGUAGE initialization parameter to Italian:
ALTER SESSION SET NLS_LANGUAGE=Ita
lian;
Enter a SELECT statement:
SQL> SELECT last_name, hire_date, ROUND(salary/8,2) salary FROM employees;
You should see results similar to the following:
LAST_NA
ME HIRE_DATE SALARY
------------------------- --------- ----------
Sc
iarra 30-SET-97 962.5
Urman 07-MAR-98 975
<
/a>Popp 07-DIC-99 862.5
Note that the m
onth name abbreviations are in Italian.
Immediately after the connection has been establish
ed, if the NLS_LANG environment setting is defined on the client side, then an implicit ALTER SESSION state
ment synchronizes the client and session NLS environments.
Using Unicode in a Multilingual Database
Unicode is a univers
al encoded character set that enables you to store information in any language, using a single character set. Unicode provides a uniq
ue code value for every character, regardless of the platform, program, or language.
Unicod
e has the following advantages:
- It simplifies character set co
nversion and linguistic sort functions
- It improves performance compared with n
ative multibyte character sets
- It supports the Unicode datatype based on the U
nicode standard
| See Also:
|
Globalization Support Features
Oracle's standard features in
clude:
Language Support
The 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, the Oracle database supports most contemporary languages.
Additional support is available for a subset of the languages. The database knows, for example, how to display dates using translate
d month names or how to sort text data according to cultural conventions.
When this manual
uses the term language support, it refers to the additional language-depe
ndent functionality (for example, displaying dates or sorting text), not to the ability to store text of a specific language.
For some of the supported languages, Oracle provides translated error messages and a translated us
er interface of the database utilities.
Territory Support<
/font>
The database supports cultural conventions that are specific to geog
raphical locations. The default local time format, date format, and numeric and monetary conventions depend on the local territory se
tting. Setting different NLS parameters allows 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 databas
e session even when the territory is defined as AMERICA.
Date and Time Formats
Different conventions for displaying the hour, day, month, and year can be handled in local formats. For e
xample, in the United Kingdom, the date is displayed using the DD-MON-YYYY format, while Japan commonly uses the Y
YYY-MM-DD format.
Time zones and daylight saving support are also available.
<
a name="1006154">
Monetary and N
umeric Formats
Currency, credit, and debit symbols can be represente
d in local formats. Radix symbols and thousands separators can be defined by locales. For example, in the US, the decimal point is a
dot (.), while it is a comma (,) in France. Therefore, the amount $1,234 has different meanings in different countries.
| See Also:
Chapter 3, "Setting Up a Globalization Support Environment" |
Cal
endars Feature
Many different calendar systems are in use around the
world. Oracle supports seven different calendar systems: Gregorian, Japanese Imperial, ROC Official (Republic of China), Thai Buddha
, Persian, English Hijrah, and Arabic Hijrah.
Linguistic Sorting
Oracle provides linguistic
definitions for culturally accurate sorting and case conversion. The basic definition treats strings as sequences of independent char
acters. The extended definition recognizes pairs of characters that should be treated as special cases.
<
p class="BP">Strings that are converted to upper case or lower case using the basic definition always retain their lengths. Strings c
onverted using the extended definition may become longer or shorter.
<
h3 class="H2">Character Set Support
Oracle supports a large number of single-byte, multibyte, and fixed-width encoding schemes that are based o
n national, international, and vendor-specific standards.
Character Semantics
Oracle provides character semanti
cs. It is useful for defining the storage requirements for multibyte strings of varying widths in terms of characters instead of byte
s.
Customization of Locale and Calendar Data
You can customize locale
data such as language, character set, territory, or linguistic sort using the Oracle Locale Builder.
You can customize calendars with the NLS Calendar Utility.
Unicode Support
You can store Unicode characte
rs in an Oracle database in two ways:
- You can create a Unicode
database that enables you to store UTF-8 encoded characters as SQL
CHAR datatypes.
- You can support multilingual data in specific columns by using Unicode datatypes. You can store Unicode characters
into columns of the SQL
NCHAR datatypes regardless of how the database character set has been defined. The NCHAR<
/code> datatype is an exclusively Unicode datatype.