Greek Character Set

I am a little confused with documentation about character sets.
In chapter 9 it says that "The database is created using Unicode(AL32UTF8) character set, which is suitable for global data in any language." but in Chapter 10.3 Supported Character Sets it says that "Table 3 lists the supported character sets in Oracle Database XE. The list is ordered alphabetically in each language group." and refers to a lot of character sets.
If Database character set is only AL32UTF8 then why the client can use all character sets described in Table3 of chapeter 10.3?

Because the database character set is just what you use to store data internally. It means that every character that can be mapped to a UTF-8 character can be stored and that is why the number of supported character sets is bigger. So your client can talk ISO8859-15 (for example). Every character in that CS can be mapped to a character in utf-8 and as long as the database knows about this mapping, it will be supported.

Similar Messages

Client-side greek character set problem

hi everyone,
i am a .net developer and absolutelly new to oracle, its my first project that i have make oracle and .net co-operate and it's proving to be a nightmare!
i ll try and provide as much info as possible to you
we have a unix sap server with oracle 10.something on it (i can check exactly what version if that's of importance) and i am writting a .net app which accesses the oracle db and retrieve some data we need
the locale settings of the db are american_america.we8dec and i cannot temper with that machine, it is out of the question
i have made the connection to the db using just connection string info, not tns and stuff, and i have set my dev machine's nls_lang to we8dec everywhere i could find it with a 'find' in the registry
however my app displays the data (which is in greek) showing random symbols that obviously make to sense
furthermore when i connect to the db via sql developer or navicat i still get the same symbols
i understand it is something to do with my client system's settings but i cant work it out
i would really appreciate your help i am sorry if it is something very simple but i just cant find it
thanks

user9084006 wrote:
i am a .net developer and absolutelly new to oracle, its my first project that i have make oracle and .net co-operate and it's proving to be a nightmare!Welcome. It's a brand new universe, but if you take it step by step I'm sure you'll do fine. Get someone near with Oracle dev and dba background to guide you, so you don't get stuck or go down broken roads.
we have a unix sap server with oracle 10.something on it (i can check exactly what version if that's of importance)It is of importance most of the time. Down to at least 4 positions (for example, "10g" is just a marketing label and mostly useless in a techincal context - 10.2.0.5 is more like it).
Also mention platform (unix OS) details.
and i am writting a .net app which accesses the oracle db and retrieve some data we needHow is the to-be retrieved data loaded or entered to begin?
>
the locale settings of the db are american_america.we8dec and i cannot temper with that machine, it is out of the question Please post output from:
SQL> select * from nls_database_parameters where parameter like '%CHARACTERSET';
and i have set my dev machine's nls_lang to we8dec everywhere i could find it with a 'find' in the registryDoes your dev (client) machine use a "we8dec" character set? Likely, as you seem to be on Windows, you should have set nls_lang client char set part to match win-1252 or whatever client char set (code page) is in use.
however my app displays the data (which is in greek) showing random symbols that obviously make to senseNo surprise since DEC character set does not have a greek character in its repertoire. If I'm not all mistaken DEC MCS (or similar) is the charcter set to which WE8DEC corresponds. You could check against mapping table in Locale builder, but available characters should be per following link or close enough.
http://czyborra.com/charsets/iso8859.html#ISO-8859-1 (second chart is DEC-MCS)
Please provide a sample of those "random symbols".
furthermore when i connect to the db via sql developer or navicat i still get the same symbolsIf that's Oracle SQL Developer it should give a true picture of what's actually stored - which, unfortuantely, seem to be invalid character data.
i understand it is something to do with my client system's settings but i cant work it out See above. But even if you correctly setup client environment, the db won't be able to store the data if databas character set is in fact WE8DEC.
>
i would really appreciate your help i am sorry if it is something very simple but i just cant find it I'm not sure, but it would seem as you have been given unfeasible conditions to work from. So maybe it's not up to you, until a character set migration has been taken place.
In general, the Database character set should be a suitable superset (repertoire) that covers all current (and hopefully future) language alphabets requirements.
You might want to search forum for 'we8dec' to find previous related discussions.
Edit:
- Added url with DEC MCS.
- platform info
Edited by: orafad on Jan 26, 2012 12:28 PM
Edited by: orafad on Jan 26, 2012 12:43 PM

Greek Character Set Problem

Dear All,
We are currently working on Oracle 8i to 9i migration and unicode implementation of an application SampleDB. We encountered an issue (described below) while the data migration.
Issue:
We have a database in oracle8i with
NLS_LANGUAGE AMERICAN
NLS_CHARACTERSET WE8ISO8859P1
NLS_NCHAR_CHARACTERSET WE8ISO8859P1
The character set WE8ISO8859P1 does not support GREEK language. The user inserts/modifies records in this database from the front-end. The front end installed in the client machine has the following setting:
Control Panel->Regional settings ->Advanced ->Language for non-unicode programs = Greek
Oracle client installed in English
Greek characters have been inserted/ updated into this database and retrieved and displayed correctly by the GUI.
Note: Greek data has been inserted into WE8ISO8859P1 database which does not support Greek characters.
Hence the actual data that is stored in the database are not Greek. Only while displaying, they are getting converted into Greek characters due to the settings in the client machine.
Requirement: Migrate the database to Oracle 9i - Unicode.
While migration, we need to eliminate any data discrepancy and make sure the data in the Unicode database is in Greek.
Can any one suggest us a method to do the migration to avoid the above mentioned problem?
Further, can any one tell us a way to verify what characters get stored in the database and help us identify if they are real Greek characters

The character set WE8ISO8859P1 does not support GREEK language.If you want to support Greek characters (or 'math' symbols), look at the EL8... char sets.
Control Panel->Regional settings ->Advanced
->Language for non-unicode programs = Greek
Oracle client installed in EnglishThis is dependent on the app and Windows. What is the NLS_LANG value in this Oracle home? NLS_LANG should be adjusted to fit the application.
Note: Greek data has been inserted into WE8ISO8859P1
database which does not support Greek characters.
Hence the actual data that is stored in the database
are not Greek. Only while displaying, they are
getting converted into Greek characters due to the
settings in the client machine.Maybe character data does not get converted, but still shown as greek.
Further, can any one tell us a way to verify what
characters get stored in the database and help us
identify if they are real Greek charactersIn the case of character data, what you really store depends on the db and the character values. You can use dump or some other PL function to look at the values.
There's a Database Globalization Support Guide for 9.2 that might be useful.

Import Term Set with Greek character set

I have been trying to import a Term Set, from a CSV file created using the standard template of SharePoint 2010, however only the first 10 terms get imported. As far as I know, there is no such limitation and the total number of terms in the Term Store
is very small. The import procedure completes with no error message.
Can anybody enlighten me as to why this is happening?
This is a sample of the CSV I am using:
"Term Set Name","Term Set Description","LCID","Available for Tagging","Term Description","Level 1 Term"
"ΜΟΑ - Δήμοι","Δήμοι Κύπρου.",,True,,"Αγγαστίνα"
,,,True,,"Αγγλισίδες"
,,,True,,"Αγγολέμι"
,,,True,,"Αγιά (Aγιά Κεπίρ)"
,,,True,,"Αγία Άννα"
,,,True,,"Αγία Βαρβάρα Λευκωσίας"
,,,True,,"Αγία Βαρβάρα Πάφου"
,,,True,,"Αγία Ειρήνη Κερύνειας"
,,,True,,"Αγία Ειρήνη Λευκωσίας"
,,,True,,"Αγία Μαρίνα Κελοκεδάρων"
,,,True,,"Αγία Μαρίνα Ξυλιάτου"
,,,True,,"Αγία Μαρίνα Σκυλλούρας"
,,,True,,"Αγία Μαρίνα Χρυσοχούς"
etc.
Note: The CSV file has been saved with UTF-8 encoding and the first 10 terms (that do get imported) correctly appear in the Term Store.

Hi,
From your description, I know you do not import all terms when you import a term set.
To reproduce your issue, I copied the items in your issue to my environment, then imported them in to my SharePoint. All items had been imported in my SharePoint, but I found
that default displaying items were the first 10 terms. The screenshot below is my result:
Please click here to find your other terms.
You can refer to this article:http://sharepointquester.com/2012/03/12/importing-term-sets-from-csv-in-sharepoint-2010/.
Best Regard
Vincent Han
TechNet Community Support

Greek Character Display Problem

Hi
Server Side : We are using Oracle 8i . Database Character Set = UTF8.
Client Side: Windows XP. Modified Control Panel->Regional Settings -> Advanced->Language for non-unicode program = Greek.
Changed Alter session set NLS_Language = GREEK
When we opened the oracle connection in our VB application.
From our Visual Basic application
Now I am able to input greek chars, Retrieve it back and displayed correctly.
But When we copy a particular string and paste it in a field, one particular
character is always showing as ?. As we don't have a greek keyboard, I don't
know what combination of keys to press to key-in that particular character.
This is the Word I have copied from Editor and pasted it in the VB field.
Ονοµα επιßάτη .
Except the Character which looks like B, all other greek characters are getting displayed properly and inserted correctly in the database. Only that particular letter is displayed as ? (question mark)
Any idea what is wrong !!.
Thanks in advance.
Regards
Murali

Check this out.
http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang%20faq.htm

Problem inserting XML doc (character set)

Hi all,
I'm having trouble trying to insert XML either "posting" it (xsql) or "putting" it
(OracleXML putXML).
The error that I get: "not supported
oracle-character-set-174".
The environment is:
Oracle 8i 8.1.5
(NLS_CHARACTERSET EL8MSWIN1253 for greek)
JDK 1.2.2
Apache Web Server 1.3.11
Apache JServ 1.1
XSQL v 0.9.9.1 and
XMLSQL, XML parser v2 that comes with it.
I had dropped all java classes and reloaded
them using oraclexmlsqlload batch file.
But still getting the same error.
The thing that is that I am
able to insert XML doc that was generated
with an authoring tool called W4F that extracts data from HTML pages and map them to
XML document, even with greek characters
in it. But when XML is generated using
an editor or the servlet like the following:
newschedule.xsql like
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="latestschedules.xsl"?>
<page connection="dtv" xmlns:xsql="urn:oracle-xsql">
<xsql:insert-request date-format="DD'/'MM'/'YYYY" table="schedule_details_view"
transform="request-to-newschedule.xsl"/>
<xsql:query table="schedule"
tag-case="lower" max-rows="5" rowset-element="latestschedules"
row-element="schedule">
select *
from schedules
order by schedule_id desc
</xsql:query>
</page>
request-to-newschedule.xsl like
<?xml version = '1.0'?>
<ROWSET xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xsl:version="1.0">
<xsl:for-each select="request/parameters">
<ROW>
<SCHEDULE_ID><xsl:value-of select="Schedule_id_field"/></SCHEDULE_ID>
<DESCRIPTION><xsl:value-of select="Description_field"/></DESCRIPTION>
<DETAILS>
<DETAILS_ITEM>
<STARTING_TIME><xsl:value-of select="Starting_Time_field_1"/></STARTING_TIME>
<DURATION><xsl:value-of select="Duration_field_1"/></DURATION>
</DETAILS_ITEM>
<DETAILS_ITEM>
<STARTING_TIME><xsl:value-of select="Starting_Time_field_2"/></STARTING_TIME>
<DURATION><xsl:value-of select="Duration_field_2"/></DURATION>
</DETAILS_ITEM>
<DETAILS_ITEM>
<STARTING_TIME><xsl:value-of select="Starting_Time_field_3"/></STARTING_TIME>
<DURATION><xsl:value-of select="Duration_field_3"/></DURATION>
</DETAILS_ITEM>
<DETAILS_ITEM>
<STARTING_TIME><xsl:value-of select="Starting_Time_field_4"/></STARTING_TIME>
<DURATION><xsl:value-of select="Duration_field_4"/></DURATION>
</DETAILS_ITEM>
<DETAILS_ITEM>
<STARTING_TIME><xsl:value-of select="Starting_Time_field_5"/></STARTING_TIME>
<DURATION><xsl:value-of select="Duration_field_5"/></DURATION>
</DETAILS_ITEM>
</DETAILS>
</ROW>
</xsl:for-each>
</ROWSET>
Hope that someone could help me on this ...
Any advice is highly appreciated.
Thanks in advance
Nicos Gabrielides
email: [email protected]

Hi,
How about applying an XSL on the existing XML doc to create another XML doc to filter out the table column not found in the target db table, so that all the columns are matched and then use putXML to load?
Hope that helps.
OTN team@IDC

DIR7 Character Set Problem / Foreign Language

Hi there,
I am working on an app built using Director 7 that until now
has used the standard English (latin-1) character set.
However, I am required to deliver a new version including
some elements displayed in a second language, in this case Welsh,
which uses characters outside of the normal set. I believe those
required are included in Latin-1 Extended, otherwise in Unicode as
a whole, obviously.
I am having specific problems with two characters that appear
to be missing from Latin-1, which are: ŵ and ŷ
(w-circumflex, and y-circumflex [i think!]).
In a standard text box I create using Director, I am unable
either to paste either character in, or enter it using its
ALT+combination, let alone save to the associated database.
I have read that Dir 11 is the first version with full
Unicode support - which surprises me - however I would assume that
someone would likely have hit this, or a similar issue before the
release of this version and was wondering if there is a possible
solution without upgrade.
My possible thinking is either a declaration that allows
change of a Charset, as I might do in XHTML for example, or
deployment of an Xtra that allows me to use a different character
set.
If anyone could shed some light on the matter, it would be
very helpful! Thanks in advance!
Rich.

Yes, this was always a problem for years. Back when I was
**** this, we had
some projects that needed text displayed in various
languages. Each
language presented its own challenges. Things like Greek
weren't too bad,
because the Symbol font works for most Greek text. (Only
problem was the
's' version of Sigma, which had to switch back to Times New
Roman.) Various
eastern European languages (Polish, Czech, Hungarian, etc.)
posed a problem
with some of the accents that were not available in standard
font sets. We
were forced to live without some of the more exotic accents,
but were told
that it would still be readable without them, if not exactly
correct. This
would probably be the closest to your situation, from what
little I know
about Welsh. It could be worse, though. Hebrew and Arabic
were challenging
as they are written right-to-left, and thus had to have code
written to
input them backwards. Russian was also tough, as the Cyrillic
alphabet has
more characters than the others, but I was able to find a
font to fake it.
(It replaced some of the lesser-used standard characters in
order to fill in
all the letters, which unfortunately meant that in the rare
cases where
those characters *were* needed, we had to improvise.) The
hardest by far
were any east Asian languages. In that case, I gave up on
trying to display
any of the text in text form, and just converted it all to
bitmaps. Without
Unicode, trying to display Mandarin or Japanese or Korean
correctly as text
is pretty much impossible.

Cdrtools package, support for nls/utf8 character sets

Hello ppl,
I've been trying desperetly to burn a cd/dvd(k3b) with greek filenames and directory names. I ended up with file names like "???????????????????? (invalid unicode)"
After a lot of searching, i managed to isolate and solve the problem. There has been a patch(http://bugs.gentoo.org/attachment.cgi?id=52097) for cdrtools to support nls/utf8 character sets.
I guess that 90%+ of people using arch and burning cd's/dvd's, ignore the problem cause they just burn cd's/dvd's using standard english characters.
For all others here it is :
# Patched cdrtools to support nls/utf8 character sets
# Contributor: Akis Maziotis <[email protected]>
pkgname=cdrtools-utf8support
pkgver=2.01.01
pkgrel=3
pkgdesc="Tools for recording CDs patched for nls/utf8 support!"
depends=('glibc')
conflicts=('cdrtools')
source=(ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-2.01.01a01.tar.gz http://bugs.gentoo.org/attachment.cgi?id=52097)
md5sums=('fc085b5d287355f59ef85b7a3ccbb298' '1a596f5cae257e97c559716336b30e5b')
build() {
cd $startdir/src/cdrtools-2.01.01
msg "Patching cdrtools ..."
patch -p1 -i ../attachment.cgi?id=52097
msg "Patching done "
make || return 1
make INS_BASE=$startdir/pkg/usr install
It's a modified pkgbuild of the official arch cdrtools package (http://cvs.archlinux.org/cgi-bin/viewcv … cvs-markup) patched to support nls/utf8 character sets.
Worked like a charm.
If u want to install it, u should uninstall the cdrtools package
pacman -Rd cdrtools
P.S.: I've issued this as a bug in http://bugs.archlinux.org/task/3830 but nobody seemed to care... :cry: :cry: :cry:

Hi Bharat,
I have created a Oracle 8.1.7 database with UTF8 character set
on WINDOWS 2000.
Now , I want to store and retrieve information in other languages
say Japanese or Hindi .
I had set the NLS Language and NLS Terrritory to HINDI and INDIA
in the SQL*PLUS session but could not see the information.You cannot view Hindi using SQL*Plus. You need iSQL*Plus.
(Available as a download from OTN, and requiring the Oracle HTTP
server).
Then you need the fonts (either Mangal from Microsoft or
Code2000).
Have your NLS_LANG settings in your registry to
AMERICAN_AMERICA.UTF8. (I have not tried with HINDI etc, because
I need my solution to work with 806,817 and 901, and HINDI was
not available with 806).
Install the language pack for Devanagari/Indic languages
(c_iscii.dll) on Windows NT/2000/XP.
How can I use the Forms 6i to support this languages ?I am not sure about that.
Do write back if this does not solve your problem.
--Shirish

Character Set questions on setup

I am trying to determine what the best setup recommendations are for creating non_English Oracle 10g databases. I have not had much experience building databases for non_English locales, so this is getting a little overwhelming as I have been researching Oracle's Database Globalization Support Guide. Obviously it has a wealth of information and I am trying to determine what applies to us at this point and time.
Generally when someone buys our product they create a new Oracle instance for our app. I need to be able to recommend proper database settings/parameters for potential global customers who purchase our software to run on Oracle.
Currently my biggest question is what to recommend for the Database Characterset on db creation. Currently the DB Character Set we recommend (for standard U.S. installs on Windows) is the default WE8MSWIN1252 character set. Our application is non-unicode. It has been recommended to me from an outside consultant that we "must" use UTF-8 for DB and National Character Set settings, as opposed to WE8MSWIN1252 or WE8ISO8859P1. I should mention that our focus at this point and time is getting a solution for French, German, and Spanish. We are also more concerned about a single language setup than multilanguage - although that is a definite future consideration.
What impact can using UTF-8 as opposed to WE8MSWIN1252 or WE8ISO8859P1 have on a non-unicode application? I hope I am explaining the situation well enough as I am fairly new and still getting to know our application. I am kind of getting thrown into the i18n fire...
Any input is greatly appreciated. Thanks.

Your questions are certainly valid but you have not given any details about your application: what it does, what technologies and access drivers are employed, and what client operating systems are supported. This determines how much effort is required to make the application Unicode-enabled and what are the risks coming from each of the possible approaches.
As long as your application can work with single-byte character sets only and as long as it is not expected to contain multibyte data, and as long as it supports Windows only, the Oracle character set corresponding to relevant Windows ANSI code page is the correct choice. For English, French, German, Spanish, and other Western European languages, WE8MSWIN1252 is right one.
Processing of WE8MSWIN1252 is easier and somehow faster than processing AL32UTF8 (i.e. UTF-8) data. One character corresponds to one byte and this simplifies some aspects of text processing.
On the other hand, world becomes smaller and smaller in the Internet area. Companies that never did any business abroad start to talk to customers around the world because somebody found their website. Western European companies take advantage of the European Union enlargement and start making business in new countries. Therefore, it is dangerous to assume that a company currently interested in a monolingual, single-byte solution will not want to migrate to a multilingual and multibyte solution in few years.
If you follow a few rules in database design and programming, you can run your single-byte application against an AL32UTF8 database, even if you do not get a multilingual system in this way. Such configuration has the huge advantage of avoiding the need of a complex and resource consuming task of migrating the database character set to Unicode in future, when your customer asks for multilingual support. Upgrading binaries of your application to an Unicode-enabled version is usually fast, migrating the database character set is not.
The main rules you should follow are:
1) Use character length semantics to define column and PL/SQL variable lengths, i.e. say VARCHAR2(10 CHAR) instead of VARCHAR2(10 [BYTE]). If you do not want to modify all creation scripts to include the CHAR keyword, issue ALTER SESSION SET NLS_LENGTH_SEMANTICS=CHAR at the beginning of each script. I recommend modifying the scripts.
2) Do not use VARCHAR2 columns longer than 1000 characters, CHAR columns longer than 500 characters, and PL/SQL VARCHAR2/CHAR variables longer than 8190 characters. This guarantees that in the future no AL32UTF8 string will exceed the hard limit of 4000/2000/32760 bytes. Use CLOB for longer text.
3) Use SUBSTR/LENGTH/INSTR in place of SUBSTRB/LENGTHB/INSTRB. Use SUBSTRB/LENGTHB/INSTRB only when dealing with legacy stuff or Data Dictionary that still use byte length semantics.
4) Define the client setting - mainly NLS_LANG - to correctly correspond to the character set processed by your application.
5) Modify interfaces to other databases, if any, to cope with the character length semantics. You do not have to do much if the other databases follow the same rules.
The cost of running the database in Unicode is not high for most languages, though languages that do not use Latin script, such as Russian, Greek, or Japanese, need significantly more storage for the textual data (but only textual data in those languages - this is only some fraction of all data in the database). Processing is slower by a few percent as compared to single-byte character sets (unless a lot of textual processing is performed in the database, in which case the percentage may be higher - benchmark recommended). This costs can be usually compensated by adding some more computing power (GHz and disks). Unless your application needs a VLDB (very large database) and almost saturates the system, you should not notice a big difference.
-- Sergiusz

Windows "Regional Options" locale - JCE for 8bit vs 16bit character sets

I have a Java application that reads in an Encrypted text file. The text file was Encrypted using JCE 1.2.1 and Encrypted on a Windows system with the locale set to English(US). The Encryption uses Sun's version of the DES encryption algorithm.
This app reads in the Encrypted text file and Decrypts it and processes it's information.
This works fine on Windows systems if the Regional Options control panel is set to a region that uses 8bit character sets:
- English
- Italian
- Spanish
- French
But, if the locale is set to 16bit character set regions, the text file cannot be read and parsed. Such regions include:
- Russian
- Greek
- English (Hong Kong)
At this point, I think I have two options, but I would love to hear about more:
- Edit the Encrypting/Decrypting code (or the parsing code - parses through a comma deliminated file) so that the file that is Encrypted and Decrypted can handle either an 8bit or 16bit character sets
(Don't know how to do this)
or
- Programatically change the locale of Windows machines to English(US) at application start-up and then change it back to the previous locale setting on application shut-down
(Don't know how to do this either)
I'd appreciate any help. I'm not sure if this is an International issue or an JCE issue.
Thanks in advance

I found an answer to the problem I was having.
The culprit were two special characters that the client was using in the encrypted text to distinguish between different fields and to distinguish carriage returns (� and �). The non Latin alphabet languages didn't know what to do with those characters so they substituted there own characters, thus breaking the parsing logic which was hard coded to look for � and �.
The problem also was related to the fact that the JCE works with byte[] arrays. FileInputStreams (which deal with byte[] arrays) seem to convert the special characters to new characters in non Lating languages to match what was going on in the JCE logic.
The easiest fix I could come up with, was to include a new properties file to be read by a separate FileInputStream. This properties text file contained just two characters (��). When I loaded in this new properties file via a FileInputStream, the two characters (��) in the properties file magically change to match the currently active alphabet (or didn't change at all if the computer was using a Latin alphabet).
By checking the new properties file to see what the characters had changed to (if they had), I was able to know what to use to parse the encrypted data. And as such, regardless of what language the computer was set to, the encrypted data is now parsed correctly, as I took out the hard coding that looked specifically for the characters � and � and instead rewrote the code so it now uses the characters from the properties file (or whatever characters they change to) for parsing the content data.
I hope others find this useful.

Windows "Regional Options" locale (8bit vs 16bit character sets)

I have a Java application that reads in an Encrypted text file. The text file was Encrypted using JCE 1.2.1 and Encrypted on a Windows system with the locale set to English(US). The Encryption uses Sun's version of the DES encryption algorithm.
This app reads in the Encrypted text file and Decrypts it and processes it's information.
This works fine on Windows systems if the Regional Options control panel is set to a region that uses 8bit character sets:
- English
- Italian
- Spanish
- French
But, if the locale is set to 16bit character set regions, the text file cannot be read and parsed. Such regions include:
- Russian
- Greek
- English (Hong Kong)
At this point, I think I have two options, but I would love to hear about more:
- Edit the Encrypting/Decrypting code (or the parsing code - parses through a comma deliminated file) so that the file that is Encrypted and Decrypted can handle either an 8bit or 16bit character sets
(Don't know how to do this)
or
- Programatically change the locale of Windows machines to English(US) at application start-up and then change it back to the previous locale setting on application shut-down
(Don't know how to do this either)
I'd appreciate any help. I'm not sure if this is an International issue or an JCE issue.
Thanks in advance

I found an answer to the problem I was having.
The culprit were two special characters that the client was using in the encrypted text to distinguish between different fields and to distinguish carriage returns (� and �). The non Latin alphabet languages didn't know what to do with those characters so they substituted there own characters, thus breaking the parsing logic which was hard coded to look for � and �.
The problem also was related to the fact that the JCE works with byte[] arrays. FileInputStreams (which deal with byte[] arrays) seem to convert the special characters to new characters in non Lating languages to match what was going on in the JCE logic.
The easiest fix I could come up with, was to include a new properties file to be read by a separate FileInputStream. This properties text file contained just two characters (��). When I loaded in this new properties file via a FileInputStream, the two characters (��) in the properties file magically change to match the currently active alphabet (or didn't change at all if the computer was using a Latin alphabet).
By checking the new properties file to see what the characters had changed to (if they had), I was able to know what to use to parse the encrypted data. And as such, regardless of what language the computer was set to, the encrypted data is now parsed correctly, as I took out the hard coding that looked specifically for the characters � and � and instead rewrote the code so it now uses the characters from the properties file (or whatever characters they change to) for parsing the content data.
I hope others find this useful.

Character set Problem (From WE8ISO8859P1 to EL8MSWIN1253)

Hi there,
I would like to describe a problem that I face with import, export and Greek characters.
I have two databases with the following characteristics
Source database:
O/S version Windows
Database version à 10GR2
NLS_CHARACTERSET à WE8ISO8859P1
NLS_NCHAR_CJARACTERSET à AL16UTF16
NLS_LANGUAGE à GREEK
NLS_TERRITORY à GREECE
Target database:
O/S version Windows
Database version à 10GR2
NLS_CHARACTERSET à EL8MSWIN1253
NLS_NCHAR_CJARACTERSET à AL16UTF16
NLS_LANGUAGE à GREEK
NLS_TERRITORY à GREECE
From the source database, using the export tool I am exporting a table (TABLE_A) which contains Greek records. At this point I want to mention that the from the source database I am able to read the Greek characters from TABLE_A by using sqlplus i.e (select * from table_a;)
On the target database by using import I load the table TABLE_A into the database.
When I select the newly imported TABLE_A on the target database I am not able to read the Greek characters.
I have tested various scenarios by using different values for the NLS_LANG variable regarding export and import clients but I did not manage to read the Greek characters on the target database.
If anyone faced the same or a similar problem please I am asking for assistance.
Thank you in advance

Please, review this thread:
Re: Arabic Character set conversion-help needed
The thread describes a similar issue for Arabic data. Therefore, when reading the thread, substitute 'WE8ISO8859P1' for 'AR8ISO8859P6', 'EL8MSWIN1253' for 'AR8MSWIN1256', and 'Greek' for 'Arabic'.
-- Sergiusz

Problem with character set - Reports 11.1.1.4

Hi!
I have a problem with Oracle Reports 11g regarding character set configuration. The default character set WE8ISO8859P1 works, so PDF reports have a regular display except for Eastern European (EE) letters which are replaced by "¿" sign.
So, when I set any other character set in reports.sh, which would be a normal step to get EE letters, I'm always getting Greek Alphabet in PDF reports. Why Greek Alphabet?
The character sets I tried to use are: EE8ISO8859P2, UTF8 and AL32UTF8.
I changed uifont.ali and included PDF Subset with all four Arial font variants and, of course, I placed all fonts in fonts folder which is pointed by REPORTS_FONT_DIRECTORY.
In Reports Builder everything works fine, but when I have to deploy the report to the Reports Services, the problem occurs.
Also, when I've tried to execute PDF report using In-Process Reports Server (rep_wls_reports_hostnameasinst1) instead of AS Instance Reports Server (RptSvr_hostnameasinst1, which is a regular server), I'm getting Greek Alphabet in PDF reports even if the default character set is WE8ISO8859P1 in reports.sh. What is wrong with it? Where is Greek Alphabet configured?
The production environment is 64-bit Oracle Linux 5.6 with Weblogic 10.3.4 and Forms&Reports 11.1.1.4. Forms works fine with character set EE8ISO8859P2 defined in default.env file.
Thanks in advance!
Regards,
Dejan

Thank you, Denis!
Doc 300416.1 was very useful but Note 356221.1 - A Practical Methodology on Porting Reports from Windows to Unix with Different Font is actually crucial for configuring Reports on Linux.
Also, there is a bug in 11.1.1.3 and 11.1.1.4, which can be fixed using the patch ( Note 1138405.1 - PDF Reports With Font Subsetting Raises Error "Bad /Bbox" on 64-Bit Linux ).
Kind regards!

Setting the character set

Hey all,
i am serializing some objects to a file, sending the file to a server and then deserializing the objects there...
all my objects are of the type of the following Word class :
public class Word {
     String source;
     String translation;
     public Word (){
          this.source=null;
          this.translation=null;
     public Word ( String source, String translation){
          this.source=source;
          this.translation=translation;
     public String getSource(){
          return source;
     public String getTranslation(){
          return translation;
     public void setSource(String source){
          this.source=source;
     public void setTranslation(String translation){
          this.translation=translation;
}i have another class which makes word objects and sets data to them before serializing them to a file... How can i insert strings of different character sets? for example if the word class is used for translation the source attribute may be in English and the translation in Greek... how can i save these data to the object and then to the file without having conflicts with the character set..?
thx!

Start a reply and look for "Add images" below the text entry box here on this thread.
Automatically generated email messages tend to suffer in this way; they are often generated by scripts (rather than by proper email clients) and don't adhere closely to the accepted standards for email communications.
They probably look fine in Apple's Mail. Why would they expect you to use anything else? ;-)

Problem with character set (ubuntu linux)

hello everyone.
I 'have already installed oracle-xe-universal_10.2.0.1-1.1_i386 in ubuntu.
The problem is that greek characters from the db appear like ??????.
How can i set the right nls_lang character set to solve the problem in ubuntu linux?
Thank you in advance!

Character code point translation is in the realm of the client, try setting NLS_LANG environment variable.
If your client programs handle UTF8, as do many linux utilities, that is the best choice, set your <language>_<locale>.<characterset>, i.e.
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8
Or french_france, or german_germany ... depends on the locale you want to use. Try a `putty` session to the host, the terminal can be set for many different character sets, i.e. ISO8859-<n> a.k.a. the WE8<n> or Western European, UTF, etc. under Window/Translation.
Try a few select ... from dual; statements in sqlplus with a literal, and different unicode values- the unistr() and dump() functions can come in quite handy.
select unistr('\ac20 euro' ) from dual;
... € euro ...
select dump( unistr('\ac20 euro' ) ) from dual;
... <ascii codes for the character values> ...
select dump( unistr('\ac20 euro' ),16 ) from dual; -- this one for hex dump

Greek Character Set

Similar Messages

Maybe you are looking for