23.7 Troubleshooting Globalization Issues

To help resolve globalization issues that may occur in your multilingual applications, this section provides the following troubleshooting information:

Embedding a Character Set in a JSP file Dynamically

In Oracle Reports, Web report templates are configured for Western European character encoding by default. However, for other languages, you can specify the character encoding for every JSP file by using both the charset attribute of the <Meta> tag and the <%@page%> page directive.

To dynamically associate the appropriate character encoding with the JSP file, you can make the following modifications:

  1. Edit the rw*.html files and the blank_template.jsp file:

    1. Modify the page directive to read

      <%@ page contentType="text/html;charset=yourIANAencoding" %>


      yourIANAencoding is the IANA-defined character set name that corresponds to the NLS_CHARACTERSET portion of the NLS_LANG variable.

    2. Modify the <Meta> tag inside the <Head> tag to read:

      <meta http-equiv="Content-Type"
      content="text/html;charset=yourIANAencoding" />


      The template files; that is, rw*.html, and blank_template.jsp, are located in the ORACLE_HOME/reports/templates/ directory.
  2. Edit the template.xsl (ORACLE_HOME/reports/templates/) file:

    1. Modify the <xsl:output> tag to read:



      yourIANAencoding is the IANA-defined character set name that corresponds to the NLS_CHARACTERSET portion of the NLS_LANG variable.

    2. Add the page directive to the file:

      <%@ page contentType="text/html;charset=yourIANAencoding" %>
    3. Add or modify the <META> tag inside the <HEAD> tag:

      <meta http-equiv="Content-Type"
      content="text/html;charset=yourIANAencoding" />


      yourIANAencoding is the IANA-defined character set name that corresponds to the NLS_CHARACTERSET portion of the NLS_LANG variable.

Setting Globalization Support Environment Variables

The Tk2Motif.rgb file contains resource settings for the Motif version of the Oracle Toolkit. For example, it specifies the font mapping between the character set used by Oracle Reports, specified in NLS_CHARACTERSET, and X fonts.

Oracle Reports looks for this file in the directory $DOMAIN_HOME\config\fmwconfig\components\ReportsToolsComponent\<reports_tools_name>\tools\admin\language, where, language is derived from the language setting in NLS_LANG.

If the file does not exist, then Oracle Reports looks for the default version in $DOMAIN_HOME\config\fmwconfig\components\ReportsToolsComponent\<reports_tools_name>\tools\admin. This version is configured for WEISO8859P1, the Western European character set.

If your NLS_LANG or NLS_CHARACTERSET specifies a character set that is not normally used for the language you have set in NLS_LANG, then Oracle Reports generates an error.

For example, if you have set NLS_LANG=AMERICAN_AMERICA.JA16EUC, then Oracle Reports locates Tk2Motif.rgb in the directory $DOMAIN_HOME\config\fmwconfig\components\ReportsToolsComponent\<reports_tools_name>\tools\admin. The language setting in NLS_LANG is AMERICAN, and there is no language subdirectory associated with AMERICAN, so Oracle Reports uses the default file. Since this version is designed for WE8ISO8859P1, and your NLS_LANG character set is JA16EUC, Oracle Reports generates the error REP-3000.

To work around this problem, set the value of the environment variable TK_UNKNOWN to the location of your character set-specific Tk2Motif.rgb file.

For example, if NLS_LANG=AMERICAN_AMERICA.JA16EUC, then set TK_UNKNOWN=$DOMAIN_HOME\config\fmwconfig\components\ReportsToolsComponent\<reports_tools_name>\tools\admin\JA. Even though your language is set to AMERICAN, Oracle Reports will use the Tk2Motif.rgb file in the JA language subdirectory.

With only NLS_LANG settings on Windows platform, it is not possible to display Hebrew messages in the Reports server queue. Also, by setting environment variable _JAVA_OPTIONS=-Duser.language=iw and -Duser.country=IL before starting WLS_REPORTS, the Hebrew messages can only be seen inverted in Reports Server queue page and not left-to-right.

To work around this problem:


  2. Set _JAVA_OPTIONS=-Duser.language=iw -Duser.country=IL before starting WLS_REPORTS in command window.

  3. Set Windows locale to Hebrew

  4. Set Windows Input language to Israel/Hebrew

Repairing Garbled Fonts When Using the WE8ISO8859P15 Character Set

You may see garbled output when you run a multibyte report on UNIX with we8iso8859p15 character set.

To work around this issue, you must do the following:

  1. Make an entry for the fonts used in your default printer's .ppd file. This file is located in the following directory:



    The entries are for the fonts that appears garbled in the report output.
  2. Set the encoding scheme in the font's AFM file to FontSpecific if it is AdobeStandardEncoding. Thus, the following entry in the AFM file:

    EncodingScheme AdobeStandardEncoding

    must change to:

    EncodingScheme FontSpecific

Opening or Running an Encoded JSP Report

If your JSP report's character encoding (for example, EUC-JP) differs from the character set portion of the NLS_LANG environment variable (for example, JA16SJIS), then you will get the following errors:

  • when running the JSP file:

    REP-6106 or 6104 with javax.servlet.jsp.JspException  (multibyte)
    REP-0495 Unable to tokenize the query (singlebyte)
  • when opening the JSP file using Oracle Reports Builder:

    REP-0069 Internal Error or REP-6106

To work around this issue, you must ensure that your JSP report's character encoding matches the IANA-defined character set corresponding to Oracle Reports' character set portion of the NLS_LANG variable.

For example:

JSP Report encoding:

<%@ page contentType="text/html;charset=EUC-JP" %>
<META http-equiv="Content-Type" content="text/html;charset=EUC-JP">

This JSP file needs to be encoded in the character set (EUC-JP).

Oracle Reports encoding:


In this example, the JSP report's encoding (EUC-JP) matches Oracle Reports' character set portion of NLS_LANG; that is, JA16EUC.

Resolving ERR-063001 xxx.dtd null

When you create a report against an XML data source, you must ensure that the encoding of both the XML file (data source) as well as the DTD matches the encoding of Oracle Reports.

When you create an XML report against a table -- for example, a Japanese table-- the group element name is in the table's language that is Japanese. To match the data source, you should set the group's element name in the DTD to Japanese. The XML and DTD files can be in any encoding that supports Japanese, for example, Shift_JIS, EUC-JP, or UTF-8. However, when the encoding of the XML data source as well as the DTD differs from Oracle Reports, you will see the following error:

ERR-063001 xxx.dtd null


This error is not displayed if you use an XML schema to define the rules.

To work around this issue, you must ensure that both the data source XML files as well as the DTD file for an XML report is encoded in the character set portion of Reports Runtime NLS_LANG.

For example, if your NLS_LANG=JAPANESE_JAPAN.JA16SJIS, then both your data source XML file as well as your DTD file should be encoded in Shift_JIS.

Running Oracle Reports in a Japanese Environment on HP-UX

If you want to use Oracle Reports in the HP-UX Japanese environment with NLS_LANG=JAPANESE_JAPAN.JA16SJIS, you must modify the appropriate Tk2Motif.rgb file before using Oracle Reports because this file contains EUC encoded Japanese resources.

Convert the Tk2Motif.rgb file to Shift-JIS encoding, or remove the last seven entries from this file. Otherwise, Oracle Reports may fail.


The Tk2Motif.rgb file for the Japanese environment is: