delphi 2009 with DOA 4.1.1. Japanese Mojibake

[gtsr]

Hello,

Now I'm using delphi 2009 with DOA 4.1.1.
Session DB is OracleXE10.2.0.1.(UnicodeDB)

I have simple application with TOracleSession,TOracleDataSet,TDataSource and TDBGrid.

Try View Japanese Lang.
NVERCHAR2 --> OK
VERCHAR2 --> Japanese Mojibake

Connection is
OracleInstantClient 10.2.0.4
NLS_LANG=JAPANESE_JAPAN.AL32UTF8
NLS_NCHAR=JAPANESE_JAPAN.AL32UTF8
TOracleSession.Preferences.ForceWideStringFields=true

By the way
TOlacleDataSet SQL Editor GridView is No problem.
And ADO Connection DBGridView too.
NVERCHAR2 --> OK
VERCHAR2 --> OK

Please help me, I'm in trouble with this...

 

[Marco Kalter]

What exactly is the problem?

 

[gtsr]

Hello

The indication of some Japanese letters stored away by VERCHAR2 is not right.

I link the picture of the test result.
Item name NAME_NVERCHAR2 and NAME_VERCHAR2 are the same Japanese UNICODE data.

Why will indication be different?

Will any setting be necessary for TOracleSession?

 

[Marco Kalter]

The only requirements for Unicode support is that you set TOracleSession.BytesPerCharacter to bcAutoDetect, that you use TWideStringFields, and that you use Unicode compliant controls.

 

[gtsr]

Hi, Marco.
Thank you for coping with my problem.

I Set TOracleSession.BytesPerCharacter to bcAutoDetect.
and I use TWideStringFields.
Will not unicode support DBGrid of delphi2009?

I think that TOracleSession may fail in conversion to UTF16 from UTF8.
I want you to test the next SQL in delphi2009.
If conversion succeeds, should see the same Japanese data...

select
DT_AL16UTF16,
DUMP(DT_AL16UTF16,1016) DUMP_UTF16,
DT_AL32UTF8,
DUMP(DT_AL32UTF8,1016) DUMP_UTF8
from
(
select
UNISTR('\3042\3044\3046\3048\304A') DT_AL16UTF16,
TO_CHAR(UNISTR('\3042\3044\3046\3048\304A')) DT_AL32UTF8
from dual
) test

Will not there be the method to display Japanese of VERCHAR2 normally?

 

[Marco Kalter]

This is what I get:

Is this the correct Japanese representation of these characters?

 

[gtsr]

Hi, Marco.
Thank you for testing it.

Your result is right.
It is the result that I want.
but, I cannot get it by my setting.
Why will be it...?

Will you teach your setting in detail?
*OracleServer version and setting ?
*Delphi version and setting ?
*WinOS version ?
*NLS_LANG ?
etc...

In addition, Do not you get exe and a source?
I want to test it by my setting.

p.s. My OS is Vista 32Bit.

 

[Marco Kalter]

• Delphi 2009 no update packs
• Direct Oracle Access 4.1.2
• Windows Vista 32
• Oracle Client and Server 11.1.0.6.0
• Server character set AL32UTF8
• Client NLS_LANG = AMERICAN_AMERICA.WE8MSWIN1252

 

[gtsr]

Hi, Marco.
Thank you.

I think. Is this a problem of the VISTA OS?

I tested it.
VISTA for English ver --> No problem (result same as you)
VISTA for Japanese ver --> Japanese Mojibake (result same as my)

VISTA for Japanese ver, I cannot use DOA now.

But this problem occurs only in TOracleDataSet.
TOracleQuery is No problem.

ShowMessage(OracleQuery.Field(2)); --> not Mojibake

ShowMessage(OracleDataSet.Fields[2].AsVariant);--> Mojibake
ShowMessage(OracleDataSet.Fields[2].AsString);--> Mojibake
ShowMessage(OracleDataSet.Fields[2].AsWideString);--> Mojibake

What will you do?

 

[Marco Kalter]

This could perhaps indicate an AnsiString conversion issue. I assume these are TWideStringFields though?

 

[gtsr]

There seems to be a problem in AnsiString conversion.

TOracleDataSet cannot support CP932(Windows Codepage) ?
----------------------------------------------------------------------
program Project1;
uses
Forms,
Unit1 in 'Unit1.pas' {TestTable};

{$R *.res}
begin
SetMultiByteConversionCodePage(932); // add code
Application.Initialize;
Application.MainFormOnTaskbar := True;
Application.CreateForm(TTestTable, TestTable);
Application.Run;
end
----------------------------------------------------------------------
http://en.wikipedia.org/wiki/Code_page_932

In addition, I discovered another problem in a test.
NVARCHAR2 item.
TOracleDataSet --> TDBEDIT or TDBGrid(EditingTrue)
A letter of UNICODE bytecode the second byte 00
　I cannot input it.
ex:#E000

 

[Nathanael Schmied]

Hy all,

I have the same issue with chines character.

If I use this select

select
DT_AL16UTF16,
DUMP(DT_AL16UTF16,1016) DUMP_UTF16,
DT_AL32UTF8,
DUMP(DT_AL32UTF8,1016) DUMP_UTF8
from
(
select
UNISTR('\53EF\7528\7684') DT_AL16UTF16,
TO_CHAR(UNISTR('\53EF\7528\7684')) DT_AL32UTF8
from dual
) test

The result it's not the same on Windows Chines or Windows English.
See picture.


I guess the problem occur with Utf8Decode and Utf8Encode procedure in Oracle.pas file.
You have used Delphi 7 procedure, why you don't use Delphi 2009 ?