Re: WE8ISO8859P1 convert to AL32UTF8 unicode character set question
From: lsllcm <lsllcm_at_gmail.com>
Date: Wed, 8 Apr 2009 22:19:39 -0700 (PDT)
Message-ID: <e2278a25-e83e-43a3-97b7-9937c15995b4_at_k38g2000yqh.googlegroups.com>
On Apr 8, 11:24 pm, lsllcm <lsl..._at_gmail.com> wrote:
> Thanks for your comments:
>
> I use convert function is to test becuase the result of convert is the
> same as importing the same string from a WE8ISO8859P1 database to a
> AL32UTF8 database. (From oracle document)
>
> If the varchar2 can be converted to target characterset and can be
> converted back too. That means that the varchar2 can be converted
> successfully.
>
> But as you said that when the char does not exist in db character set.
> It is one problem. It can cause unpredictable conversion.
>
> Fortunately, we use jdbc program to operate on oracle db. Java is
> UTF-16 encoded, Data retrieved from or inserted into the database must
> be converted from UTF-16 to the database character set or the national
> character set and vice versa. (From oracle document)
>
> Each character is converted from UTF-16 to WE8ISO8859P1. It also can
> be converted from WE8ISO8859P1 to UTF-16. Because UTF-16 can be
> converted to AL32UTF8, so all characters can be converted to AL32UTF8
> characterset.
>
> What do you think about?
>
> I will test the way you metioned.
>
> 1. create one db with characterset WE8MSWIN1252, and insert data, and
> convert it.
> 2. create one db with characterset WE8ISO8859P1, and insert data, and
> alter database characterset to WE8MSWIN1252. Then convert it.
>
> Thanks
> Jacky
Max Post Conversion Data Size: 9
Date: Wed, 8 Apr 2009 22:19:39 -0700 (PDT)
Message-ID: <e2278a25-e83e-43a3-97b7-9937c15995b4_at_k38g2000yqh.googlegroups.com>
On Apr 8, 11:24 pm, lsllcm <lsl..._at_gmail.com> wrote:
> Thanks for your comments:
>
> I use convert function is to test becuase the result of convert is the
> same as importing the same string from a WE8ISO8859P1 database to a
> AL32UTF8 database. (From oracle document)
>
> If the varchar2 can be converted to target characterset and can be
> converted back too. That means that the varchar2 can be converted
> successfully.
>
> But as you said that when the char does not exist in db character set.
> It is one problem. It can cause unpredictable conversion.
>
> Fortunately, we use jdbc program to operate on oracle db. Java is
> UTF-16 encoded, Data retrieved from or inserted into the database must
> be converted from UTF-16 to the database character set or the national
> character set and vice versa. (From oracle document)
>
> Each character is converted from UTF-16 to WE8ISO8859P1. It also can
> be converted from WE8ISO8859P1 to UTF-16. Because UTF-16 can be
> converted to AL32UTF8, so all characters can be converted to AL32UTF8
> characterset.
>
> What do you think about?
>
> I will test the way you metioned.
>
> 1. create one db with characterset WE8MSWIN1252, and insert data, and
> convert it.
> 2. create one db with characterset WE8ISO8859P1, and insert data, and
> alter database characterset to WE8MSWIN1252. Then convert it.
>
> Thanks
> Jacky
After tested, csscan also report application data exception when prepare to change character set from WE8ISO8859P1 to WE8MSWIN1252, and we cannot use csalter.plb to change the database character set.
Database character set
WE8ISO8859P1
FROMCHAR
WE8ISO8859P1
TOCHAR
WE8MSWIN1252
Scan NCHAR data?
NO
Array fetch buffer size
1024000
Number of processes
1
Capture convertible data?
NO
[Data Dictionary individual exceptions]
[Application data individual exceptions]
User : JACKY Table : AAA Column: C1 Type : VARCHAR2(1000) Number of Exceptions : 1
Max Post Conversion Data Size: 9
ROWID Exception Type Size Cell Data(first 30 bytes)
------------------ ------------------ ----- ------------------------------ AAALaRAAEAAAAAQAAA lossy conversion sys.…Med
------------------ ------------------ ----- ------------------------------Received on Thu Apr 09 2009 - 00:19:39 CDT