|
Oracle® Application Server Globalization Support Guide
10g Release 2 (10.1.2) B14004-02 |
|
 Previous |
 Next |
|
Oracle® Application Server Globalization Support Guide
10g Release 2 (10.1.2) B14004-02 |
|
|
Previous |
Next |
When developing and deploying global Internet applications with Oracle Application Server, you need to consider the following tasks:
Configuring Oracle HTTP Server and OC4J for Global Deployment
Configuring Oracle Application Server Portal for Global Deployment
Configuring Oracle Application Server Wireless for Global Deployment
Configuring Oracle Application Server Forms Services for Global Deployment
Configuring Oracle Business Intelligence Discoverer for Global Deployment
Configuring a Centralized Unicode-enabled Database to Support Global Deployment
In addition to the schemas of the infrastructure components, such as Oracle Internet Directory and Distributed Configuration Management (DCM), the Oracle Application Server Infrastructure database stores data pertaining to many Oracle Application Server middle-tier components that are installed on top of it. These components include the following:
Oracle Application Server Portal (OracleAS Portal)
Oracle Application Server Forms Services (OracleAS Forms Services)
Oracle Reports (OracleAS Reports Services)
Oracle Application Server Wireless (OracleAS Wireless)
Oracle Business Intelligence Discoverer (OracleBI Discoverer)
It is important to choose the correct database character set for the infrastructure database at installation time so all the dependent components are able to provide the same level of global support.
During the installation of the Oracle Application Server infrastructure database, you are prompted to choose the database character set you would like to use for the database. The default character set is AL32UTF8. There are two basic scenarios that will determine which choice is best for your environment:
If your environment is intended to support multiple languages in a single global instance of the Oracle Application Server infrastructure, similar to Figure 1-2, then choose UTF-8 as the character set for the infrastructure database. Even if you only support a single language, such as English, you may choose UTF-8 as the database character set. The implications of choosing UTF-8 include, but are not limited to, the following:
Databases with UTF-8 as the database character set are slightly slower than those with single-byte character sets. The performance impact is due to UTF-8 being a multibyte character set and the increase in the number of character set conversions between the middle tier and the database.
Web pages served through mod_plsql must be encoded in UTF-8. However, there are some browsers, such as those for mobile devices, that may have problems supporting UTF-8. Products that deliver Web pages through mod_plsql include Oracle Application Server Single Sign-On and Oracle Application Server Portal.
If your environment is intended to support a single language or a group of languages that share the same native character set, then you can choose the character set that is most commonly used for these languages as an alternative to UTF-8. For example, you can choose WE8MSWIN1252 if you are only interested in supporting Western European languages. You can choose JA16SJIS if you are interested in supporting Japanese and English.
If your environment will support Traditional Chinese, then select ZHT16MSWIN950 or ZHT16BIG5 as the character set.
|
Note: The character set ZHT32EUC does not support Oracle Application Server Portal. |
During installation of any Oracle Application Server installation type, support for user-selected languages is automatically installed and configured. It includes the translation files and fonts being used in the product.
If the required fonts are not available after installation, then you can copy them from the Utilities CD-ROM included in the Oracle Application Server CD pack, or from
into the $ORACLE_HOME/jdk/jre/lib/fonts directory.
|
See Also: Oracle Application Server Portal Developer's Guide for information about creating multilingual portlets |
This section contains the following topics related to configuring Oracle HTTP Server for multilingual support:
If you edit Oracle HTTP Server or OC4J configuration files manually, instead of using Oracle Enterprise Manager 10g, then you must use the DCM command-line utility dcmctl to notify the DCM repository of the changes. Otherwise, your changes will not go into effect and will not be reflected in the Enterprise Manager consoles. The commands are as follows:
To notify the DCM repository of changes made to Oracle HTTP Server configuration files:
ORACLE_HOME/dcm/bin/dcmctl updateConfig ohs
To notify the DCM repository of changes made to OC4J configuration files:
ORACLE_HOME/dcm/bin/dcmctl updateConfig oc4j
To notify the DCM repository of changes made to both Oracle HTTP Server and OC4J configuration files:
ORACLE_HOME/dcm/bin/dcmctl updateConfig
Before you change configuration parameters, manually or using Oracle Enterprise Manager 10g, you can save the current state of Oracle HTTP Server and OC4J configuration files and installed J2EE applications with the following command:
ORACLE_HOME/dcm/bin/dcmctl saveInstance -dir directory_name
You can then restore the state and back out of any subsequent changes that were made using the following command:
ORACLE_HOME/dcm/bin/dcmctl restoreInstance -dir directory_name
The NLS_LANG parameter controls the language, territory, and character set used for database connections in an Internet application. Specify the value of NLS_LANG in the following format, including the punctuation as shown:
language_territory.characterset
In the preceding syntax, language, territory, and characterset must be valid Oracle language, territory, and character set names. The specified language and territory are used to initialize the locale that determines the default date and time formats, number formats, and sorting sequence in a database session. The Oracle database converts data to and from the specified character set when it is retrieved from or inserted into the database.
|
See Also: Oracle Database Globalization Support Guide 10g Release 1 (10.1) in the Oracle Database Documentation Library for a list of valid Oracle language, territory, and character set names |
You can specify the NLS_LANG parameter in the Oracle HTTP Server and OC4J files. The Oracle HTTP Server and OC4J files where NLS_LANG can be specified are as follows:
$ORACLE_HOME/Apache/Apache/conf/httpd.conf
This is the configuration of Oracle HTTP Server powered by Apache, and it defines the environment variables that are passed to Apache modules. If you want to explicitly specify the NLS_LANG parameter for CGI scripts such as Perl and server-side include (SSI) pages, then you can add the following line to this file:
SetEnv NLS_LANG language_territory.characterset
Oracle HTTP Server is already configured to use the NLS_LANG shell environment variable in CGI scripts and SSI pages when NLS_LANG is not explicitly specified as described earlier. It does so by putting the following line into the file:
PassEnv NLS_LANG
$ORACLE_HOME/Apache/Apache/bin/apachectl
This is the Oracle HTTP Server startup script used in UNIX. If you want to start Oracle HTTP Server directly from apachectl, then you can specify the following line in this script file to define an NLS_LANG value:
NLS_LANG=language_territory.characterset; export NLS_LANG
$ORACLE_HOME/opmn/conf/opmn.xml
Oracle Process Manager and Notification Server (OPMN) is used to manage Oracle HTTP Server and OC4J instances. The opmn.xml configuration file allows you to specify the NLS_LANG environment variable for Oracle HTTP Server and OC4J processes through the following XML construct:
<environment>
...
<prop name="NLS_LANG" value="language_territory_characterset" />
...
</environment>
This construct can be specified at the Oracle Application Server instance level where it applies to all Oracle HTTP Server and OC4J instances belonging to the Oracle Application Server instance. It can also be specified for the individual Oracle HTTP Server or OC4J instance where it only applies to the corresponding instance.
$ORACLE_HOME/Apache/modplsql/conf/dads.conf
This file defines database access descriptors (DADs) for mod_plsql to use when creating a database connection. You can specify the NLS_LANG value for the corresponding DAD. For example, you can specify the NLS_LANG value for the /pls/scott DAD as follows:
<Location /pls/scott>
SetHandler pls_handler
Order deny, allow
Allow from all
PlsqlDatabasePassword tiger
PlsqlDatabaseUsername scott
PlsqlDocumentPath docs
PlsqlNlsLanguage NLS_LANG value
</Location>
Note that, when the transfer mode of a DAD is CHAR instead of RAW, the NLS_LANG character set of the DAD should be the same as that of the database character set for mod_plsql to work properly.
$ORACLE_HOME/Apache/Jserv/etc/jserv.properties
If JServ is needed in your environment, then you need to add or modify the following line in this file to define the appropriate NLS_LANG value:
wrapper.env=NLS_LANG=language_territory.characterset
If you do not explicitly specify the NLS_LANG environment variable in these files as described in the preceding, Oracle HTTP Server and OC4J will use the value set as follows:
On UNIX: The NLS_LANG shell environment variable when Oracle HTTP Server and OC4J are invoked
On Microsoft Windows: The NLS_LANG registry key at \\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn in the Win32 registry
The Oracle Application Server installation pre-configures NLS_LANG values in the following Oracle HTTP Server and OC4J files for you based on the locale of the runtime environment on which the product is installed.
$ORACLE_HOME/Apache/Apache/bin/apachectl (for UNIX platforms)
$ORACLE_HOME/opmn/conf/opmn.xml/opmnctl (for UNIX platforms)
The pre-configured NLS_LANG values in the apachectl and opmnctl scripts are specified as follows:
NLS_LANG=${NLS_LANG=language_territory.characterset}; export NLS_LANG
The preceding line means the pre-configured NLS_LANG values are used only when the shell environments from which the scripts are invoked have not defined the NLS_LANG environment variable. If you want to use an NLS_LANG value regardless of the shell environment, then change the line to:
NLS_LANG=language_territory.characterset; export NLS_LANG
The NLS_LANG parameter controls the locale of the runtime environment on which OPMN runs. It should correspond to the default locale of the middle-tier runtime environment, which is the default locale of the operating system. The same NLS_LANG parameter is inherited by the OPMN managed processes, such as Oracle HTTP Server and OC4J, unless it is explicitly specified with a different value in opmn.xml.
For Microsoft Windows platforms, the pre-configured NLS_LANG is automatically registered in the Win32 registry as the NLS_LANG registry key at \\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEn. The NLS_LANG value in this registry key controls the locale of the runtime environment on which OPMN and its managed processes run.
The pre-configured NLS_LANG values are the best values derived from the runtime locale during product installation, and may not represent the appropriate value for your Oracle HTTP Server and OC4J configurations. You may need to alter these values according to your specific requirements and runtime environments.
Setting NLS_LANG for a Monolingual Application Architecture
Set the NLS_LANG parameter to specify the language, territory, and character set that correspond to the locale that its middle-tier server is configured to serve. If most clients are running on Microsoft Windows platforms, then it is a good practice to use the NLS_LANG character set that corresponds to the Microsoft Windows code page of the locale. For example, when you configure the middle-tier server to serve Japanese clients, then specify the following value for NLS_LANG:
JAPANESE_JAPAN.JA16SJIS
JA16SJIS corresponds to code page 932 of the Japanese Microsoft Windows operating system.
Table 6-1 lists the NLS_LANG values for the most commonly used locales.
Table 6-1 NLS_LANG Values for Commonly Used Locales
| Locale | NLS_LANG Value |
|---|---|
|
Arabic (Egypt) |
ARABIC_EGYPT.AR8MSWIN1256 |
|
Arabic (U.A.E.) |
ARABIC_UNITED ARAB EMIRATES.AR8MSWIN1256 |
|
Chinese (Taiwan) |
TRADITIONAL CHINESE_TAIWAN.ZHT16MSWIN950 |
|
Chinese (P.R.C.) |
SIMPLIFIED CHINESE_CHINA.ZHS16GBK |
|
Czech |
CZECH_CZECH REPUBLIC.EE8MSWIN1250 |
|
Danish |
DANISH_DENMARK.WE8MSWIN1252 |
|
Dutch |
DUTCH_THE NETHERLANDS.WE8MSWIN1252 |
|
English (United Kingdom) |
ENGLISH_UNITED KINGDOM.WE8MSWIN1252 |
|
English (U.S.A.) |
AMERICAN_AMERICA.WE8MSWIN1252 |
|
Finnish |
FINNISH_FINLAND.WE8MSWIN1252 |
|
French (Canada) |
CANADIAN FRENCH_CANADA.WE8MSWIN1252 |
|
French (France) |
FRENCH_FRANCE.WE8MSWIN1252 |
|
German (Germany |
GERMAN_GERMANY.WE8MSWIN1252 |
|
Greek |
GREEK_GREECE.EL8MSWIN1253 |
|
Hebrew |
HEBREW_ISRAEL.IW8MSWIN1255 |
|
Hungarian |
HUNGARIAN_HUNGARY.EE8MSWIN1250 |
|
Italian (Italy) |
ITALIAN_ITALY.WE8MSWIN1252 |
|
Japanese |
JAPANESE_JAPAN.JA16SJIS |
|
Korean |
KOREAN_KOREA.KO16MSWIN949 |
|
Norwegian |
NORWEGIAN_NORWAY.WE8MSWIN1252 |
|
Polish |
POLISH_POLAND.EE8MSWIN1250 |
|
Portuguese (Brazil) |
BRAZILIAN PORTUGUESE_BRAZIL.WE8MSWIN1252 |
|
Portuguese (Portugal) |
PORTUGUESE_PORTUGAL.WE8MSWIN1252 |
|
Romanian |
ROMANIAN_ROMANIA.EE8MSWIN1250 |
|
Russian |
RUSSIAN_CIS.CL8MSWIN1251 |
|
Slovak |
SLOVAK_SLOVAKIA.EE8MSWIN1250 |
|
Spanish (Spain) |
SPANISH_SPAIN.WE8MSWIN1252 |
|
Spanish (Latin American) |
LATIN AMERICAN SPANISH_AMERICA.WE8MSWIN1252 |
|
Swedish |
SWEDISH_SWEDEN.WE8MSWIN1252 |
|
Thai |
THAI_THAILAND.TH8TISASCII |
|
Turkish |
TURKISH_TURKEY.TR8MSWIN1254 |
Setting NLS_LANG for a Multilingual Application Architecture
The language and territory components of the NLS_LANG parameter are not as important in the multilingual application architecture as they are in the monolingual application architecture. A multilingual application needs to handle different locales dynamically and cannot rely on fixed settings. The application should always use the UTF-8 character set so that Unicode data can be retrieved from and inserted into the database. An example of an appropriate value for NLS_LANG in a multilingual deployment is:
NLS_LANG=AMERICAN_AMERICA.UTF8
The transfer mode of each database access descriptor (DAD) of the mod_plsql runtime enables PL/SQL to construct HTML content and process HTML form input in different character sets. You must set the transfer mode with the appropriate value.
It is important to configure the transfer mode for the mod_plsql module in the $ORACLE_HOME/Apache/modplsql/conf/dads.conf file where the DADs are specified.
The mod_plsql module supports two transfer modes that you can configure in a DAD:
CHAR mode: This is a default mode where dynamic HTML content is sent as VARCHAR2 data from the database to mod_plsql. In this mode, the NLS_LANG character set must be the same as that of the back-end database character set.
RAW mode: Dynamic HTML content is sent as RAW data from the database to mod_plsql and is subject to character set conversion in the database server where the PL/SQL procedures and Oracle PL/SQL Server Pages (PSP) run. Character set conversion happens only when the HTML page encoding is specified, either by the NLS_LANG character set or by the charset parameter specified in the OWA_UTIL.MIME_HEADER() function call.
You should turn on the RAW transfer mode in a DAD for both monolingual and multilingual Internet applications as follows:
<Location /pls/scott>
SetHandler pls_handler
Order deny,allow
Allow from all
PlsqlDatabasePassword tiger
PlsqlDatabaseUsername scott
PlsqlDatabaseConnectString local
PlsqlDocumentPath docs
PlsqlNlsLanguage AMERICAN_AMERICA.UTF8
PlsqlTransferMode RAW
</Location>
If the value of PlsqlNlsLanguage has a space in it, then the value must be enclosed in quotation marks. For example:
PlsqlNlsLanguage "SIMPLIFIED CHINESE_CHINA.ZHS16GBK"
This section describes how to initialize the runtime default locale for runtime environments that Oracle Application Server supports:
The default locale of a runtime environment controls the default locale-sensitive behavior of the applications, such as the character set used in file I/O operations, the language of the user interface, and the date format used. It needs to be properly set in order for applications relying on the default runtime locale to run with the expected locale-sensitive behavior. The default runtime locale is usually inherited from the default locale of the operating system or the locale of the runtime process.
The default runtime locale should be used as the user's preferred locale for monolingual applications. For multilingual applications, the default runtime locale is used for any server-side I/O operations, such as logging messages.
For UNIX platforms, the LANG or LC_ALL variable defines the following:
The POSIX (also known as XPG4) locale used for a process
How Java VM initializes its default locale
To configure the Java VM for JServ, define the LANG or LC_ALL environment variable with a POSIX locale name in the jserv.properties file. For example, the following line in jserv.properties defines Japanese (Japan) to be the default locale of Java VM for JServ on UNIX:
wrapper.env=LANG=ja_JP
The values for the LANG and LC_ALL environment variables should refer to the same POSIX locale available in your operating system. The LC_ALL environment variable always overrides the LANG environment variable if they are different.
The regional settings of the Control Panel control the default locale of the Java VM for JServ on Microsoft Windows platforms. Change the regional settings to the desired locale from the Control Panel before starting Oracle HTTP Server.
Define the LANG or LC_ALL environment variable with a POSIX locale name in $ORACLE_HOME/opmn/conf/opmn.xml. For example, the following line within the <environment> tags in opmn.xml defines Japanese (Japan) to be the default locale of Java VM for OC4J on Solaris:
<environment> ... <prop name="LANG" value="ja_JP" /> ... </environment>
The regional settings of the Control Panel control the default locale of the Java VM for OC4J on Microsoft Windows platforms. Change the regional settings to the desired locale from the Control Panel before starting Oracle HTTP Server.
PL/SQL and PSP run on an Oracle database in the context of a database session. Therefore, the NLS_LANG parameter controls the runtime default locale. The NLS_LANG parameter should be configured as described in "Configuring the NLS_LANG Parameter".
Perl scripts run on the Perl interpreter that the mod_perl module provides. The locale support in Perl is based on the POSIX locale available in the operating system. It uses the underlying POSIX C libraries as a foundation. To configure the Perl runtime default locale, follow the procedure described for the C/C++ runtime.
|
See Also:
|
The C/C++ runtime uses the POSIX locale system provided by the operating system. You can configure the locale system by defining the LC_ALL or LANG environment variable. Define LC_ALL with a valid locale value that the operating system provides. These values are different on different operating systems.
For UNIX platforms, define LC_ALL as follows:
In the $ORACLE_HOME/Apache/Apache/conf/httpd.conf file, add the following line:
PassEnv LC_ALL
In the $ORACLE_HOME/Apache/Apache/bin/apachectl file, add the following line:
LC_ALL=${LC_ALL=OS_locale}; export LC_ALL
For Microsoft Windows platforms, the POSIX locale should inherit its value from the regional settings of the Control Panel instead of being specified in the LC_ALL environment variable. Change the regional settings to change the default runtime POSIX locale.
Oracle Application Server Portal (OracleAS Portal) is designed to allow application development and deployment in different languages. OracleAS Portal is configured with the languages that are selected in the Oracle Universal Installer during the Oracle Application Server middle-tier installation. The selected languages that are configured show up in the Set Language portlet.
To configure additional languages after installation, use the ptllang script. Once you have installed a language, OracleAS Portal allows you to specify the preferred locale and territory to be used for that language; for example, Australian English or Canadian French.
|
See Also: Oracle Application Server Portal Configuration Guide for information about theptllang script
|
When users access wireless services from their mobile devices, Oracle Application Server Wireless uses the user profile information from Oracle Internet Directory to determine the user's preferred language. Administrators can select the language when creating a new user through the Oracle Application Server Wireless Tools. Users can change their preferred language through the Wireless Customization Tool.
When users send e-mail messages from their mobile devices, Oracle Application Server Wireless sends the messages in the encoding specified in the encoding parameter of the PIM/Mail service.
You can change the default encoding for outgoing e-mail messages by modifying the ORACLE_SERVICES_PIM_MAIL_MESSAGE_ENCODING parameter of the PIM/Mail master service.
The NLS_LANG parameter controls the language, territory, and character set that an Internet application uses for database connections. Specify the value of NLS_LANG in the following format, including the punctuation as shown:
language_territory.characterset
language, territory, and characterset must be valid Oracle language, territory, and character set names. The specified language and territory are used to initialize the locale that determines the default date and time formats, number formats, and sorting sequence in a database session. Oracle Net converts data to and from the specified character set when it retrieves data from or inserts data into the database.
You can set the NLS_LANG parameter in the $ORACLE_HOME/forms/server/default.env file. If you do not set the NLS_LANG parameter in the default.env file, then OracleAS Forms Services uses the value set as follows:
On UNIX: The NLS_LANG shell environment variable when OracleAS Forms Services is invoked
On Microsoft Windows: The NLS_LANG setting at the \\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\FormsServerOracle_HOME in the Microsoft Windows registry
You can have different NLS_LANG settings on the same Forms Server by specifying an alternate environment file. Use the envFile parameter in the formsweb.cfg file. To do this:
Create two environment configuration files under $ORACLE_HOME/forms/server. For example, an American environment configuration file (en-us.env) should contain the following lines:
NLS_LANG=AMERICAN_AMERICA.US7ASCII FORMS_PATH=d:\us
A Japanese environment configuration file (ja.env) should contain the following lines:
NLS_LANG=JAPANESE_JAPAN.JA16SJIS FORMS_PATH=d:\ja
In the $ORACLE_HOME/forms/server/formsweb.cfg file, set the envFile parameter for the alternative setting. For example:
[ja] envFile=ja.env [en-us] envFile=en-us.env
Specify the configuration name in the URL for your forms servlet as follows:
http://formsservermachine/forms/frmservlet?config=ja http://formsservermachine/forms/frmservlet?config=en
The NLS_LANG parameter controls the language, territory, and character set used for database connections in an OracleAS Reports Services application. Specify the value of NLS_LANG in the following format, including the punctuation as shown:
language_territory.characterset
language, territory, and characterset must be valid Oracle language, territory, and character set names. The specified language and territory are used to initialize the locale that determines the default date and time formats, number formats, and sorting sequence in a database session. Oracle Net converts data to and from the specified character set when it retrieves data from or inserts data into the database.
OracleAS Reports Services uses the value of the NLS_LANG parameter set as follows:
On UNIX: The NLS_LANG shell environment variable when OracleAS Reports Services is invoked. The default NLS_LANG value is set in $ORACLE_HOME/bin/reports.sh.
On Microsoft Windows: The value of NLS_LANG set at \\HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\%ReportsORACLE_HOME% in the Microsoft Windows registry
For dynamic environment switching: In the OracleAS Reports Services configuration file through the environment element. On UNIX, the default NLS_LANG value in the reports.sh file needs to be commented out to enable this feature.
|
See Also:
|
OracleBI Discoverer can simultaneously support users with different locales. Users may explicitly control the locale used for the user interface, or they may allow OracleBI Discoverer to automatically determine a default. The order of precedence for determining the language and locale is:
Language and locale settings specified in the URL for OracleBI Discoverer.
Language and locale settings specified in the OracleBI Discoverer Connection. If the Locale set in user's browser option is specified, then the language settings in the each user's browser is used.
Language and locale of Oracle Application Server.
|
See Also: Oracle Business Intelligence Discoverer Configuration Guide for more information on using URL parameters with OracleBI Discoverer. |
You can set up the centralized Oracle database to store Unicode data in the following ways:
As UTF-8 in the SQL CHAR data types (CHAR, VARCHAR2, and CLOB)
As UTF-16 in the SQL NCHAR data types (NCHAR, NVARCHAR2, and NCLOB)
It is good practice to specify the centralized Oracle database to support the following data types:
Specify AL32UTF8 for the database character set when you create the centralized database for UTF-8 in the SQL CHAR data types
Specify AL16UTF16 for the national character set when you create the centralized database for UTF-16 in the SQL NCHAR data types
Example 6-1 shows part of a CREATE DATABASE statement that sets the recommended database character set and national character set.
Example 6-1 Specifying the Database Character Set and the National Character Set
CREATE DATABASE utfdb CONTROL FILE REUSE LOGFILE '/u01/oracle/utfdb/redo01.log' SIZE 1M REUSE '/u01/oracle/utfdb/redo02.log' SIZE 1M REUSE DATAFILE '/u01/oracle/utfdb/system01.dbf' SIZE 10M REUSE AUTOEXTENT ON NEXT 10M MAXSIZE 200M CHARACTER SET AL32UTF8 NATIONAL CHARACTER SET AL16UTF16 ... ;
|
See Also:
|
