Oracle database character set for AMERICAN_AMERICA us7ascii, delphi7 read out the code in Chinese, how to solve, customer database character set can not be changed, only through the Delphi transcoding, nasty

CodePudding user response:

Must first determine the database character set for AMERICAN_AMERICA. Us7ascii or client NLS_LANG Settings for AMERICAN_AMERICA. Us7ascii, if the latter, this setting only, according to the decision does not affect actually stored in the database, you can change, don't change rawtohex function can also be used to obtain the original code of data: select rawtohex (XXX) from... ,
If the former (use up sqlplus client tools to connect to the database, enter the select * from nls_database_parameters; Look at the output), that is more troublesome, US7ASCII 7-bit ASCII code, the highest is 0, so Chinese information lost, when I was put into read also can't be right, only before you write code, such as BASE64, read it out again after decoding,

CodePudding user response:

Hello, thank you very much for the reply, the second floor. The server database character set is AMERICAN_AMERICA us7ascii, this is certain, I set the environment variable in the client machine NLS_LANG is SIMPLIFIED CHINESE_CHINA. After us7ascii by PLSQL query is can show Chinese, but through the Delphi don't know how to convert, read out is stil in Chinese

CodePudding user response:

Then you put the NLS_LANG is SIMPLIFIED CHINESE_CHINA UTF8, D7 read UTF8Decode again, according to

CodePudding user response:

Ok, I'll give it a try

CodePudding user response:

Edit2. Text:=Utf8Decode (YlQuery_Data [' payer ']); Still gibberish, I use the data connection component is unidac, I here set UniConnOracle SpecificOptions. Values: [' Charset ']='SIMPLIFIED CHINESE_CHINA. UTF8'; Or not,

CodePudding user response:

It should be writing data when the database is missing information, you can only use first compatible US7ASCII codes such as BASE64 code first, then write, read after decoding first, then, according to

CodePudding user response:

But through PLSQL connection, direct inquiry can show Chinese, asked the developers said they showed they also is no problem, we can only read their data

CodePudding user response:

You don't use D7, in D2009 + support unicode version,

CodePudding user response:

Oh oh, I see. Anyway, thank you very much

CodePudding user response:

refer to 7th floor zhanghuip response:

but through PLSQL connection, direct query can show Chinese, asked the developers said they showed they also is no problem, we can only read their data

Ah, so that you can use the rawtohex function to get the data coding, and compare the known data,

CodePudding user response:

Character set when the database is English, his original GBK code, if not, it is very easy to the code, then as the upstairs said, dump the Chinese field, and see what the original code, if it is not known coding, it is extremely likely stored transformation happened, at this time, only when you set the environment for the data source is consistent, to solve it, this is coding is missing, but the content can also restore, even GBK code, dump out nor GBK, not several, a try to know

CodePudding user response:

With PL under several NSL_LANG altered can try it out

CodePudding user response:

This is the problem that the system character set,
Fundamental solutions, the use of Delphi2010,

CodePudding user response:

I think UniConnOracle. SpecificOptions. Values [' Charset '] should be set as ASCII

CodePudding user response:

In version of the drunk