Multibyte characters(Chinese Data)

Hi,
We have a table in oracle(10g) which stores Chinese data as well English characters.
Production is designed in such a way that, we can' t increase size of the columns.
Is there any way to handle multi-byte characters like Chinese with the same length?
Pls help me out on this and my heartful thanks for any replies

You need some basic understanding of how language and territory handled by database, read this article,
NLS_LANG FAQ
http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm

Similar Messages

  • Chinese Data Fields not displaying Chinese Characters

    Hi There,
    Wonder if someone can help. We are currently running reports in Crystal 8.5 but are in the process of upgrading our business systems to latest version and this includes converting all our Crystal 8.5 reports to Crystal Reports XI R2 SP4.
    During the process we are experiencing some difficulties in displaying Chinese characters, which have previously worked fine in version 8.5. The system we are running Crystal from has Oracle client 11 installed and the OS system locale is set to Chinese PRC. Our application is displaying Chinese characters properly and if we have any text fields on the report, these are also displaying properly when changing Font to Arial Unicode MS. The only thing that doesn't display properly is the field data which after checking has the correct Chinese data stored in the database. For some reason Crystal 11.5 doesn't seem to be transferring the data correctly which points to some sort of encoding problem.
    Is there something I am missing here or is there something else I need to install for this to work?
    Any hep would be appreciated.

    What is your Oracle database's language set? Is it set to UTF-8 or non UTF-8 (such as American_America.WE8ISO8859P1" )?
    There is a similar issue tracked under ID ADAPT00528561 (Crystal cannot display non-UTF-8 Chinese characters from an Oracle database ) and has been fixed and you should set the following registry key to make it effective:
    Set the following registry key "UseOSLocaleForConversion" to "Yes" under:
    HKEY_LOCAL_MACHINE\Software\Business Objects\Suite 11.5\Crystal Reports\Database\Oracle

  • Can not read Chinese data when DB Connect to SQL server 2000

    Hi,
       Our BW server( BW3.5 not unicode ) is installed on MS SQL server 2000. We try to connect the BW SQL server with db connect function. We create some test views in the Northwind DB. We are be able to access data from source system in rsa1 by db connect. The problem is that all the Chinese characters are displayed as ?????. Is there any special setting for accessing multibyte characters in MS SQL server 2000? Please advise.
    Thank you,
    Jeff

    The field of VIEW in the sqlserver which code is chinese must be the nvarchar.
    You can try it.

  • Multibyte character (Chinese, Korean....) support problem

    I used OLE DB(C++) and JDBC(Java) in Oracle 8i server with no problem. I worked very well.
    but using ADO.NET(C#), there are the critical problem in selecting and inserting multibyte character (Chinese,Korean.. so on)
    Oracle 8i Server charset : US7ASCII
    Client NLS_LANG : AMERICAN_AMERICA.US7ASCII
    - SELECT multibyte column
    SELECT DUMP(multibyte) FROM table;
    DUMP(multibyte)
    Typ=1 Len=8: 199,209,177,219,195,226,183,194
    - value in OracleString
    OracleString.Value = ������� (broken character 0xfffd)
    I think Oracle Data Provider for .NET can handle only ASCII characters with setting charset US7ASCII.
    How I can get multibyte characters through byte array as binary data? (not String)

    Since your database character set is not UTF8 or Chinese character set, when inserting Chinese, if the character is not found/mapped in the database character set, a replacement character is used which will be the question marks you see.
    Ashish

  • Problem While Converting File From .xls to .csv consisting of Chinese Data

    Hi,
    I want to import the Excelsheet data to HTML DB which consists of information in chinese language. To import this excelsheet data i am converting this excel file to .csv. After coverting it to .csv every chinese character will gets converted to question mark (???). I want to import this chinese data as it is. Please help me regarding this issue.
    Vilas Magi.

    Hi
    I am trying to export Japanese data to .CSV but the CSV contains junk characters which are correctly displayed in the browser.
    Can anybody help me on this issue?
    Thanks in advance

  • Need help to upload Excel Chinese data into Oracle

    Hello
    I am very new at internationalization. We are writing an application that
    reads Chinese data from a Microsoft Excel file and writes it out into Oracle
    8i. This is what we have done:
    1. Use JDBC-ODBC driver to read the Excel data directly from .xls.
    2. Write data into oracle database.
    When we open Excel, we can view the Chinese characters. When we use SQL
    PLus, we see only ????. When we write another servlet to retrieve the data,
    it is displayed as ????. The few questions I have are:
    1. How can I verify that the Chinese data has been accurately inserted into
    the database?
    2. Do I need to set anything special (environment variables, config files
    etc) in BEA Weblogic 5.1 and Oracle 8i?
    The environment we have are:
    1. BEA Weblogic SP9 running on WIn NT.
    2. Oracle 8i running on Solaris.
    Thanks

    Make sure that the characters are correct in the app server after you get
    them out of Oracle and before you put them into the web page. This will help
    you determine if the problem is in the JDBC access to Oracle or the encoding
    into the web page. Make sure that you verify that the hex values of each
    character from the db test case are what you expect.
    Peace,
    Cameron Purdy
    Tangosol Inc.
    << Tangosol Server: How Weblogic applications are customized >>
    << Download now from http://www.tangosol.com/download.jsp >>
    "Bernard Ong" <[email protected]> wrote in message
    news:[email protected]...
    Hi Kev
    1. "It doesn't work" means that I still see ??? in the database. WHen I
    retrieve the data, it is still displayed as ??? in a browser.
    2. Codeset to use to display should be UTF-8.
    3. Charset in database server is UTF8. I did a "select * from
    database_parameters" to get this value.
    4. I copied the Chinese characters from Excel and pasted on Notepad. Icould
    see the Chinese characters with the Chinese emulator turned on. WHen Icopy
    ??? from SQL*Plus and paste it into notepad, I see ???.
    Presume:
    1. Yes, running SQL*PLUS on BEA machine.
    2. BEA machine running on WIndows 200 professional. We downloaded aChinese
    emulator. WIndows 2000 is the English version.
    Cheers
    "Kevin Lu" <[email protected]> wrote in message
    news:[email protected]...
    Hi Bernard,
    Please first clarify:-
    1) "It doesn't work" means... cannot display the chinese character as
    you
    desired?
    2) Which codeset that you want it to display, Chinese traditional big5?UTF-8,
    i would think it's still in Java/JDBC codeset.
    3) What's the charset in the database server? Get help from DBA if you
    not
    sure
    how to obtain this information.
    4) Try paste the result(select via SQL*Plus) onto Win Notepad, what's
    the
    outcome?
    Presume:
    1) you're running SQL*Plus on your BEA machine?
    2) BEA machine is running on Chinese O/S or hv NJStar installed andrunning?
    Let me know if i could be of further help.
    -Kev
    "Bernard Ong" <[email protected]> wrote:
    Thanks Kev.
    We had changed the registry in the BEA machine to
    AMERICAN_AMERICA.UTF8.
    THis was done for the Oracle registry in the BEA machine.
    Unfortunately,
    it
    still doesn't work.
    Cheers,
    Bernard
    "Kevin Lu" <[email protected]> wrote in message
    news:[email protected]...
    Hi Bernard,
    I take about the same approach as you while resolving codeset
    problem.
    So,
    first
    i make sure SQL*Plus could display my desired result before proceedto
    application(be
    it Swing, servlet, JSP console etc..). You may try set the NLS_LANGon
    your client
    machine(same machine as where you run SQL*Plus) to the SAME as
    database
    server
    character set, for instance America_American.US7ASCII. You should
    able
    to
    see
    the Chinese characters.
    Hope this help with your first question. I can't help for the restanyway.
    good luck!
    -Kev
    "Bernard Ong" <[email protected]> wrote:
    Hello
    I am very new at internationalization. We are writing an
    application
    that
    reads Chinese data from a Microsoft Excel file and writes it outinto
    Oracle
    8i. This is what we have done:
    1. Use JDBC-ODBC driver to read the Excel data directly from .xls.
    2. Write data into oracle database.
    When we open Excel, we can view the Chinese characters. When we useSQL
    PLus, we see only ????. When we write another servlet to retrievethe
    data,
    it is displayed as ????. The few questions I have are:
    1. How can I verify that the Chinese data has been accurately
    inserted
    into
    the database?
    2. Do I need to set anything special (environment variables, configfiles
    etc) in BEA Weblogic 5.1 and Oracle 8i?
    The environment we have are:
    1. BEA Weblogic SP9 running on WIn NT.
    2. Oracle 8i running on Solaris.
    Thanks

  • IMPDP SQLFILE : multibyte characters in constraint_name leads to ORA-00972

    Hi,
    I'm actually dealing with constraint_name made of multibyte characters (for example : constrain_name='VALIDA_CONFIRMAÇÃO_PREÇO13').
    Of course this Bad Idea® is inherited (I'm against all the fancy stuff like éàù in filenames and/or directories on my filesystem....)
    The scenario is as follows :
    0 - I'm supposed to do a "remap_schema". Everything in the schema SCOTT should now be in a schema NEW_SCOTT.
    1 - The scott schema is exported via datapump
    2 - I do an impdp with SQLFILE in order to get all the DDL (table, packages, synonyms, etc...)
    3 - I do some sed on the generated sqlfile to change every occurence of SCOTT to NEW_SCOTT (this part is OK)
    4 - Once the modified sqlfile is executed, I do an impdp with DATA_ONLY.
    (The scenario was imagined from this thread : {message:id=10628419} )
    I'm getting some ORA-00972: identifier is too long at step 4 when executing the sqlfile.
    I see that some DDL for constraint creation in the file (generated at step#2) is written as follow :ALTER TABLE "TW_PRI"."B_TRANSC" ADD CONSTRAINT "VALIDA_CONFIRMAÃÃO_PREÃO14" CHECK ...Obviously, the original name of the constraint with cedilla and tilde gets translated to something else which is longer than 30 char/byte...
    As the original name is from Brazil, I also tried do add an EXPORT LANG=pt_BR.UTF-8 in my script before running the impdp for sqlfile. This didn't change anything. (the original $LANG is en_US.UTF-8)
    In order to create a testcase for this thread, I tried to reproduce on my sandbox database... but, there, I don't have the issue. :-(
    The real system is an 4-nodes database on Exadata (11.2.0.3) with NLS_CHARACTERSET=AL32UTF8.
    My sandbox database is a (nonRAC) 11.2.0.1 on RHEL4 also AL32UTF8.
    The constraint_name is the same on both system : I checked byte by byte using DUMP() on the constraint_name.
    Feel free to shed any light and/or ask for clarification if needed.
    Thanks in advance for those who'll take on their time to read all this.
    I decided to include my testcase from my sandbox database, even if it does NOT reproduce the issue +(maybe I'm missing something obvious...)+
    I use the following files.
    - createTable.sql :$ cat createTable.sql
    drop table test purge;
    create table test
    (id integer,
    val varchar2(30));
    alter table test add constraint VALIDA_CONFIRMAÇÃO_PREÇO13 check (id<=10000000000);
    select constraint_name, lengthb(constraint_name) lb, lengthc(constraint_name) lc, dump(constraint_name) dmp
    from user_constraints where table_name='TEST';- expdpTest.sh :$ cat expdpTest.sh
    expdp scott/tiger directory=scottdir dumpfile=testNonAscii.dmp tables=test- impdpTest.sh :$ cat impdpTest.sh
    impdp scott/tiger directory=scottdir dumpfile=testNonAscii.dmp sqlfile=scottdir:test.sqlfile.sql tables=testThis is the run :
    [oracle@Nicosa-oel test_nonAsciiColName]$ sqlplus scott/tiger
    SQL*Plus: Release 11.2.0.1.0 Production on Tue Feb 12 18:58:27 2013
    Copyright (c) 1982, 2009, Oracle.  All rights reserved.
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    SQL> @createTable
    Table dropped.
    Table created.
    Table altered.
    CONSTRAINT_NAME                  LB       LC
    DMP
    VALIDA_CONFIRMAÇÃO_PREÇO13             29         26
    Typ=1 Len=29: 86,65,76,73,68,65,95,67,79,78,70,73,82,77,65,195,135,195,131,79,95
    ,80,82,69,195,135,79,49,51
    SQL> exit
    Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    [oracle@Nicosa-oel test_nonAsciiColName]$ ./expdpTest.sh
    Export: Release 11.2.0.1.0 - Production on Tue Feb 12 19:00:12 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Starting "SCOTT"."SYS_EXPORT_TABLE_01":  scott/******** directory=scottdir dumpfile=testNonAscii.dmp tables=test
    Estimate in progress using BLOCKS method...
    Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
    Total estimation using BLOCKS method: 0 KB
    Processing object type TABLE_EXPORT/TABLE/TABLE
    Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
    . . exported "SCOTT"."TEST"                                  0 KB       0 rows
    Master table "SCOTT"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
    Dump file set for SCOTT.SYS_EXPORT_TABLE_01 is:
      /home/oracle/scott_dir/testNonAscii.dmp
    Job "SCOTT"."SYS_EXPORT_TABLE_01" successfully completed at 19:00:22
    [oracle@Nicosa-oel test_nonAsciiColName]$ ./impdpTest.sh
    Import: Release 11.2.0.1.0 - Production on Tue Feb 12 19:00:26 2013
    Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
    Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Master table "SCOTT"."SYS_SQL_FILE_TABLE_01" successfully loaded/unloaded
    Starting "SCOTT"."SYS_SQL_FILE_TABLE_01":  scott/******** directory=scottdir dumpfile=testNonAscii.dmp sqlfile=scottdir:test.sqlfile.sql tables=test
    Processing object type TABLE_EXPORT/TABLE/TABLE
    Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
    Job "SCOTT"."SYS_SQL_FILE_TABLE_01" successfully completed at 19:00:32
    [oracle@Nicosa-oel test_nonAsciiColName]$ cat scott_dir/test.sqlfile.sql
    -- CONNECT SCOTT
    ALTER SESSION SET EVENTS '10150 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    ALTER SESSION SET EVENTS '10904 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    ALTER SESSION SET EVENTS '25475 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    ALTER SESSION SET EVENTS '10407 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    ALTER SESSION SET EVENTS '10851 TRACE NAME CONTEXT FOREVER, LEVEL 1';
    ALTER SESSION SET EVENTS '22830 TRACE NAME CONTEXT FOREVER, LEVEL 192 ';
    -- new object type path: TABLE_EXPORT/TABLE/TABLE
    CREATE TABLE "SCOTT"."TEST"
       (     "ID" NUMBER(*,0),
         "VAL" VARCHAR2(30 BYTE)
       ) SEGMENT CREATION DEFERRED
      PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 COMPRESS FOR OLTP LOGGING
      TABLESPACE "MYTBSCOMP" ;
    -- new object type path: TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
    ALTER TABLE "SCOTT"."TEST" ADD CONSTRAINT "VALIDA_CONFIRMAÇÃO_PREÇO13" CHECK (id<=10000000000) ENABLE;I was expecting to have the cedilla and tilde characters displayed incorrectly....
    Edited by: Nicosa on Feb 12, 2013 7:13 PM

    Srini Chavali wrote:
    If I understand you correctly, you are unable to reproduce the issue in the test instance, while it occurs in the production instance. Is the "schema move" being done on the same database - i.e. you are "moving" from SCOTT to NEW_SCOTT on the same database (test to test, and prod to prod) ? Do you have to physically move/copy the dmp file ? Hi Srini,
    On the real system, the schema move will be to and from different machines (but same DBversion).
    I'm not doing the real move for the moment, just trying to validate a way to do it, but I guess it's important to say that the dump being used for the moment comes from the same database (the long story being that due to some column using object datatype which caused error in the remap, I had to reload the dump with the "schema rename", drop the object column, and recreate a dump file without the object_datatype...).
    So Yes, the file will have to move, but in the current test, it doesn't.
    Srini Chavali wrote:
    Obviously something is different in production than test - can you post the output of this command from both databases ?
    SQL> select * from NLS_DATABASE_PARAMETERS;
    Yes Srini, something is obviously different : I'm starting to think that the difference might be in the Linux/shell side rather than on the impdp as datapump is supposed to be NLS_LANG/CHARSET-proof +(when traditional imp/exp was really sensible on those points)+
    The result on the Exadata where I have the issue :PARAMETER                      VALUE
    NLS_LANGUAGE                   AMERICAN
    NLS_TERRITORY                  AMERICA
    NLS_CURRENCY                   $
    NLS_ISO_CURRENCY               AMERICA
    NLS_NUMERIC_CHARACTERS         .,
    NLS_CHARACTERSET               AL32UTF8
    NLS_CALENDAR                   GREGORIAN
    NLS_DATE_FORMAT                DD-MON-RR
    NLS_DATE_LANGUAGE              AMERICAN
    NLS_SORT                       BINARY
    NLS_TIME_FORMAT                HH.MI.SSXFF AM
    NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
    NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_DUAL_CURRENCY              $
    NLS_COMP                       BINARY
    NLS_LENGTH_SEMANTICS           BYTE
    NLS_NCHAR_CONV_EXCP            FALSE
    NLS_NCHAR_CHARACTERSET         AL16UTF16
    NLS_RDBMS_VERSION              11.2.0.3.0the result on my sandbox DB :PARAMETER                      VALUE
    NLS_LANGUAGE                   AMERICAN
    NLS_TERRITORY                  AMERICA
    NLS_CURRENCY                   $
    NLS_ISO_CURRENCY               AMERICA
    NLS_NUMERIC_CHARACTERS         .,
    NLS_CHARACTERSET               AL32UTF8
    NLS_CALENDAR                   GREGORIAN
    NLS_DATE_FORMAT                DD-MON-RR
    NLS_DATE_LANGUAGE              AMERICAN
    NLS_SORT                       BINARY
    NLS_TIME_FORMAT                HH.MI.SSXFF AM
    NLS_TIMESTAMP_FORMAT           DD-MON-RR HH.MI.SSXFF AM
    NLS_TIME_TZ_FORMAT             HH.MI.SSXFF AM TZR
    NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZR
    NLS_DUAL_CURRENCY              $
    NLS_COMP                       BINARY
    NLS_LENGTH_SEMANTICS           BYTE
    NLS_NCHAR_CONV_EXCP            FALSE
    NLS_NCHAR_CHARACTERSET         AL16UTF16
    NLS_RDBMS_VERSION              11.2.0.1.0------
    Richard Harrison .  wrote:
    Hi,
    Did you set NLS_LANG also when you did the import?Yes, that is one of the difference between the Exadata and my sandbox.
    My environnement in sandbox has NLS_LANG=AMERICAN_AMERICA.AL32UTF8 where the Exadata doesn't have the variable set.
    I tried to add it, but it didn't change anything.
    Richard Harrison .  wrote:
    Also not sure why you are doing the sed part? Do you have hard coded scheme references inside some of the plsql?Yes, that is why I choose to sed. The (ugly) code have :
    - Procedures inside the same package that references one another with the schema prepended
    - Triggers with PL/SQL codes referencing tables with schema prepended
    - Dynamic SQL that "builds" queries with schema prepended
    - Object Type that does some %ROWTYPE on tables with schema prepended (that will be solved by dropping the column based on those types as they obviously are not needed...)
    - Data model with object whose names uses non-ascii characters
    +(In France we use to call this "gas power plant" in order to tell how a mess it is : pipes everywhere going who-knows-where...)+
    The big picture is that this kind of "schema move & rename" should be as automatic as possible, as the project is to actually consolidate several existing databases on the Exadata :
    One schema for each country, hence the rename of the schemas to include country-code.
    I actually have a workaround yet : Rename the objects that have funky characters in their name before doing the export.
    But I was curious to understand why the SQLFILE messed up the constraint_name on one sustem when it doesn't on another...

  • EXTRACT function and Chinese data

    Hi !
    I'm working with PL/SQL web applications, and I'm having trouble viewing it on a webpage when I use EXTRACT function for Chinese data.
    <abccompany> <department> &#20975;&#20262;·&#23041;&#24265;&#26031;&#26159;&#19968;&#23478;&#23567;&#22411;&#31038;&#21306;&#21046;&#33647;&#21378;&#30340;&#25152;&#26377;&#32773;&#65292;&#22905;&#27491;&#32771;&#34385;&#24320;&#22987;&#25552;&#20379;&#33647;&#26041;&#36882;&#36865;&#30340;&#26381;&#21153;&#65292;&#21516;&#26102;&#20063;&#24050;&#32463;&#23601;&#27492;&#20107;&#24449;&#27714;&#20102;&#20445;&#38505;&#19987;&#23478;&#40077;&#21187;·&#24067;&#26391;&#30340;&#24847;&#35265;&#12290;&#20975;&#20262;&#35810;&#38382;&#40077;&#21187;&#65292;&#38656;&#35201;&#36141;&#20080;&#21738;&#20123;&#20445;&#38505;&#12289;</department></abccompany>
    The Chinese xml data is stored as 'xmltype' in the Oracle database.
    1)
    When I run the below query, the output shown on a web page is upside down question marks like this
    select v.xtext.EXTRACT('/abccompany/department/text()').GetClobVal()
    into text
    from case_text v
    where case_identifier=inIdx;
    htp.print('<html><body>')
    htp.print(text);
    htp.print('</body></html>');
    2)
    However, the EXTRACT function works perfectly for English data.
    3)
    I also observed that, when I replace
    select v.xtext.EXTRACT('/abccompany/department/text()').GetClobVal()
    with
    to_clob(xtext)
    the web page displays the Chinese contents of the whole file and not just within the nodes <abccompany><department>.
    How can I make Extract function work with Chinese data ?
    Any help appreciated !
    -Sara

    Sara
    This normally happens when the client character set is not capable of showing chinese data. For instance on my laptop I cannot show the results of an extract() which returns chinese or japanese data in sqlplus (which cannot show chinese data on my machine) but I can in ISQL*PLUS which is web based and can show chinese data.
    THis might be a result of your NLS_LANG settings. The database translates from the database character set (I'm assuming AL32UTF8 in this case, into the client character set (as defined by NLS_LANG). Again if the characters cannot be converted this can cause this issue.

  • Handling multibyte characters

    Hi ,
    I have created a procedure which sends e-mail using UTL_SMTP.
    The procedure has a part in which we add the attachments to e-mail.
    Now , the issue is when i am adding an attachment which contains multibyte characters , these characters are replaced with '?'.
    Can anyone provide any guidance on this?

    First, you should not append 'charset="us-asci"' in this line:
      UTL_SMTP.WRITE_DATA(L_MAIL_CONN, 'Content-Type: ' || IN_ATT_MIME_TYPE ||'charset="us-ascii"'||'; name="' || IN_ATT_FILE_NAME || '"' || UTL_TCP.CRLF);
    The default IN_ATT_MIME_TYPE has this clause already, hence you would have a duplicate. Moreover, you add it without the required preceding semicolon. Further, in the Content-Type, you should pass the original character set of the file, not "us-ascii". This character set must support characters included in the file.
    Second, the NCLOB is not written correctly either. UTL_ENCODE.BASE64_ENCODE expects a RAW value. If you give it an NVARCHAR2 value returned by DBMS_LOB.SUBSTR, then PL/SQL will implicitly apply HEXTORAW.to the value. HEXTORAW fails, if the NCLOB content is not a valid sequence of hex digits. Treating the content of NCLOB as a string of hex digits is obviously not your goal. You should use UTL_I18N.STRING_TO_RAW to convert NVARCHAR2 from DBMS_LOB.SUBSTR to the desired target encoding (the one specified in Content-Type) and cast it to RAW at the same time. UTF-8 (i.e. AL32UTF8) is usually the best choice for the target encoding. You should then apply UTL_RAW.CAST_TO_VARCHAR2 to change the RAW representation of base64-encoded value to VARCHAR2 expected by UTL_SMTP.WRITE_DATA.
    Of course, passing DBMS_LOB.SUBSTR result directly to UTL_ENCODE.BASE64_ENCODE would make sense for a BLOB attachment. However, even then the encoded result should be passed to UTL_RAW.CAST_TO_VARCHAR2, not UTL_RAW.CAST_TO_RAW.
    Third, if you use UTF-8 as Content-Type encoding, you may want to prepend three bytes (0xEF 0xBB 0xBF) to the NCLOB value before base64 encoding. This three-byte character is the UTF-8 Byte Order Mark. It helps some editors, such as Notepad, to recognize the file as encoded in UTF-8.
    Fourth, if the target encoding is UTF-8, l_step should be no more than 8191. This is to avoid intermediate values exceeding 32767 bytes.
    Fifth, the whole procedure will not work well on EBCDIC platform. In contrary to what documentation says, UTL_SMTP.WRITE_DATA does not seem to convert data to US7ASCII before sending (unless the package is ported separately by platform vendors). I guess this is not your worry but I thought I will mention this, just in case.
    Thanks,
    Sergiusz

  • JSPs, UTF-8 & multibyte characters

              In our project we have a situation where we must output some multibyte characters
              to a JSP page. The data is retrieved from an Oracle database using BEA ELink and
              XML (don't ask why). The XML-data is UTF-8 encoded, and the data seems to be ok
              down to the JSP level, because I can output it to a file and it's properly UTF-8
              encoded.
              But when I try to write the data to the final reply (using <%=dataObject.getData()%>
              the results definitely are not UTF-8 encoded. On the client browser they show
              up as garbage, occupying more than twice the actual length of the data. The response
              headers and META-tags are all set to UTF-8 encoding, and the browser is set to
              use UTF-8.
              The funny part is, that the string seems to be encoded twice or something similar
              as is shown by the next example:
              This is the correct UTF-8 byte sequence for the first twice characters (they are
              just generated data for debugging purposes):
              C3 89 C3 A5
              Which translates to Unicode characters 00C9 and 00E5.
              But on the final page that is sent to the client this sequence has been changed
              to:
              C3 83 E2 80 B0 C3 83 C2 A5
              Which just doesn't make sense since it shows up as five different garbage characters.
              Does anyone have any ideas what is causing the problem and any suggestions? What
              are those extra characters in the final encoding?
              .Pete.
              

    It sounds like the Object.toString is coming back already encoded in UTF8,
              and thus the JSP writer encodes that UTF8 using UTF8 again, which is what
              you see. Try making the String value be:
              > ... characters 00C9 and 00E5.
              ... instead of:
              > C3 89 C3 A5
              Then it will be encoded correctly.
              Peace,
              Cameron Purdy
              Tangosol Inc.
              << Tangosol Server: How Weblogic applications are customized >>
              << Download now from http://www.tangosol.com/download.jsp >>
              "Petteri Räisänen" <[email protected]> wrote in message
              news:[email protected]...
              >
              > In our project we have a situation where we must output some multibyte
              characters
              > to a JSP page. The data is retrieved from an Oracle database using BEA
              ELink and
              > XML (don't ask why). The XML-data is UTF-8 encoded, and the data seems to
              be ok
              > down to the JSP level, because I can output it to a file and it's properly
              UTF-8
              > encoded.
              >
              > But when I try to write the data to the final reply (using
              <%=dataObject.getData()%>
              > the results definitely are not UTF-8 encoded. On the client browser they
              show
              > up as garbage, occupying more than twice the actual length of the data.
              The response
              > headers and META-tags are all set to UTF-8 encoding, and the browser is
              set to
              > use UTF-8.
              >
              > The funny part is, that the string seems to be encoded twice or something
              similar
              > as is shown by the next example:
              >
              > This is the correct UTF-8 byte sequence for the first twice characters
              (they are
              > just generated data for debugging purposes):
              >
              > C3 89 C3 A5
              >
              > Which translates to Unicode characters 00C9 and 00E5.
              >
              > But on the final page that is sent to the client this sequence has been
              changed
              > to:
              >
              > C3 83 E2 80 B0 C3 83 C2 A5
              >
              > Which just doesn't make sense since it shows up as five different garbage
              characters.
              >
              >
              > Does anyone have any ideas what is causing the problem and any
              suggestions? What
              > are those extra characters in the final encoding?
              >
              > Pete.
              

  • Unicode Characters in Data Field

    Hi,
    The client has requested us to print the chinese characters in the Data field.
    We are able to add chinese text to the designer, but when we map the data field to the chinese output we are unable to capture the chinese data and the output is showing some Junk characters while opening in PDF (PDF has all chinese font installed).
    Tried all the possible chinese available including the Arial Unicode fonts in Presentment Target.
    Has any body faced the issue with language or unicode while capturing the data??
    Since this is issue is critical..Prompt solution is appreciated.
    Thanks
    Dinesh

    Hi Rick,
    Here is the solution...
    Since all desktops which were used normally has US installed as their base language.
    So all data that you input from your keyboard or paste from others are English and they are single byte. So you don't face problem.
    But since many of the east Asian languages are double byte and if your desktop doesn't have Chinese language installed as your regional language.. you will not be able to see the Chinese characters whey they are input from your keyboard or paste it from other.
    So you need to have Chinese language installed as one of your regional language.
    It can be done this way...
    Go to Control Panel --> Regional Language and options --> Languages (TAB) --> check the check boxes..
    You need to have your operating system CD to install the East Asian languages.
    Hope this solve your problem...
    Please get back to me if you still have problem.
    Thanks
    Dinesh

  • Multibyte characters not displaying on report

    Hi there,
    I am having a problem displaying multibyte characters on my report (Oracle reports 6i). These characters are needed for barcode encoding. e.g chr(203) . But when I run my report they are missing.
    Also when I do the following sql in oracle11g (the version of the db the report is working against) :-
    select chr(203) from dual;
    I get the error :-
    ORA-29275: partial multibyte character
    though it works fine for oracle 8.
    Any help much appreciated.

    Everything depends on your NLS parameters. If I do this on Oracle 11g I get:
    select chr(203) from dual;
    C
    ËFor bar coding you should use a special bar code font, e.g.:
    http://www.idautomation.com/font-encoders/oracle-reports/

  • How to Search for a Date in a string having both characters and date

    Hi ,
      I have a requirement to search DATE in the String having Both Characters and DATE . Please kindly let me know as early as possible.
    Regards
    Anil Kumar K

    Try to use SEARCH command with the pattern, making the pattern as fine as it can, like if you have your date in the format 02/23/2007, you can give
    SEARCH STRING FOR ' //'. (assuming the date has at least a single blank before it)
    WRITE:  SY-SUBRC UNDER 'SY-SUBRC',
    SY-FDPOS UNDER 'SY-FDPOS'.
    SY-FDPOS is set to offset of the string from which you can get the date value
    Refer here
    http://help.sap.com/saphelp_47x200/helpdata/en/fc/eb33cc358411d1829f0000e829fbfe/frameset.htm
    It would have been better if there is something like UNIX "regular expression" matching in ABAP

  • Indexes not getting used in schema having chinese data

    I have a database with chinese data in it. When i execute few queries in that schema it does not use the available indexes of that table. Query takes long time to execute and the temp tablespace gets full. But when i execute the same query in another schema having english data the query executes quickly and uses all the indexes.
    I tried gathering database statistics and rebuilding the indexes but that did not work out as well.
    Can any body tell me whether the index creation differs for foreign languages? Do i need to create the indexes differently then normally we create?
    why the indexes are not being used in the schema having chinese data?
    Edited by: user621442 on Dec 17, 2009 10:03 AM

    user621442 wrote:
    I have a database with chinese data in it. When i execute few queries in that schema it does not use the available indexes of that table. Query takes long time to execute and the temp tablespace gets full. But when i execute the same query in another schema having english data the query executes quickly and uses all the indexes.
    I tried gathering database statistics and rebuilding the indexes but that did not work out as well.
    Can any body tell me whether the index creation differs for foreign languages? Do i need to create the indexes differently then normally we create?
    why the indexes are not being used in the schema having chinese data?
    Edited by: user621442 on Dec 17, 2009 10:03 AMHi,
    I do not think so index would behave differently for different languages, yes sorting may behave in a diffierent way.
    Can you post the explain plan from both the database.
    And also nls_sort parameter from both the database.
    I believe that you have order by clause which is not able to sort using index.
    Regards
    Anurag

  • How to insert chinese data into MS SQL Server 2000 through JDBC

    I am trying to insert chinese data into MS SQL server 2000 using JDBC. how to do this?
    can anybody help me.
    thanx.

    I am trying to insert chinese data into MS SQL server 2000 using JDBC. how to do this?
    can anybody help me.
    thanx.

Maybe you are looking for