Russian charset problem

I've got Oracle database 8.1.7 and Oracle 9iAS installed on the same machine, Windows NT.
When I try to create form containing russian field names with Portal, it stores them (and then displays) in wrong charset. NLS_LANG parameters are all set to RUSSIAN_CIS.CL8MSWIN1251.
Does anyone know how to avoid this problem?

It's a bug.
When you create a new form edit it and add labels in Russian, before clicking Ok you should click on the root of the component tree (Form). In this case all Russian characters will be saved with proper encoding.

Similar Messages

[Gnome - GDM] Locale/Charset Problem

Hi everybody,
I´m using Gnome with GDM as Display Manager.
I got a problem with my keyboard settings, but don´t know why
The first charset/locale option is set in the /boot/grub/menu.lst
kernel /vmlinuz26 lang=de locale=de_DE.UTF8 root=/dev.....
I use a LUKS encrypted /home partition and need a german locale/charset for the passphrase/during bootup.
The second charset option is in my /etc/rc.conf:
LOCALE="de_DE.UTF8"
KEYMAP="de"
With those settings I got an almost "normal" keyboard behaviour.
The Umlaut-Character for example arent´t working during bootup or in a tty. In a later started shell inside of Gnome everything works fine.
The second charset problem is during password input inside GDM. The layout isn´t working right here either.
I already tried the ./dmrc settings of Language and Keys, but nothing works.
Anyone got a clue how to fix that?
Greets
Flo

Maybe you can change the subject of this thread, as the issue is not only related to gdm, IMHO.
I don't get it either. Settings are LOCALE="sv_SE" and KEYMAP="sv-latin1" in rc.conf and locale -a gives me
[root@localhost ~]# locale -a
C
POSIX
sv_SE
sv_SE.iso88591
swedish
But something is still wrong, because calling up some manpages gives me
Cannot open the message catalog "man" for locale "sv_SE"
(NLSPATH="<none>")
I ran locale-gen, but I'm pretty lost in this locale business too...

Russian fonts problem

"Hi
We get wrong fonts (character set) from calling jolt connection to tuxedo
The problem the charset that define for conversation to Unicode is good for windows
(Power Builder environment) and not for Unix environment that run the Weblogic server
Unix
CL8ISO8859P5      ISO 8859-5 Latin/Cyrillic      SB, ASCII
Windows
CL8MSWIN1251      MS Windows Code Page 1251 8-bit Latin/Cyrillic      SB, ASCII, EURO
Tuxedo server side define
env | grep LANGNLS_LANG=AMERICAN_AMERICA.CL8MSWIN1251
We need for weblogic server that run in Unix environment define:
NLS_LANG=AMERICAN_AMERICA.CL8ISO8859P5
NLS_LANG = LANGUAGE_TERRITORY.CHARACTER_SET
Where:
LANGUAGE     Specifies the language and conventions for displaying messages, day name, and month name.
TERRITORY     Specifies the territory and conventions for calculating week and day numbers.
CHARACTER_SET     Controls the character set used for displaying messages.
For exmple:
Russian      RUSSIAN_CIS.CL8MSWIN1251
English      AMERICAN_AMERICA.WE8ISO8859P1
The result test with character set CL8MSWIN1251 define in Tuxedo
Test 1
testpet!VIP:/vmpuser1/vmp/vmp/api/Test/joltService> env | grep LANG
LANG=ru
System.getProperty- user.language ru
System.getProperty- file.encoding ISO8859-5
System.get

Hi,
could you please post this to
weblogic.developer.interest.internationalization.
Thanks
Maria Salzberger
Developer Relations Engineer
BEA Customer Support
yaakov lifshitz schrieb in Nachricht <3c33638f$[email protected]>...
"Hi
We get wrong fonts (character set) from calling jolt connection to tuxedo
The problem the charset that define for conversation to Unicode is good forwindows
(Power Builder environment) and not for Unix environment that run theWeblogic server
>
Unix
CL8ISO8859P5 ISO 8859-5 Latin/Cyrillic SB, ASCII
Windows
CL8MSWIN1251 MS Windows Code Page 1251 8-bit Latin/Cyrillic SB, ASCII,EURO
>
>
Tuxedo server side define
env | grep LANGNLS_LANG=AMERICAN_AMERICA.CL8MSWIN1251
We need for weblogic server that run in Unix environment define:
NLS_LANG=AMERICAN_AMERICA.CL8ISO8859P5
NLS_LANG = LANGUAGE_TERRITORY.CHARACTER_SET
Where:
LANGUAGE Specifies the language and conventions for displaying messages,day name, and month name.
TERRITORY Specifies the territory and conventions for calculating week andday numbers.
CHARACTER_SET Controls the character set used for displaying messages.
For exmple:
Russian RUSSIAN_CIS.CL8MSWIN1251
English AMERICAN_AMERICA.WE8ISO8859P1
The result test with character set CL8MSWIN1251 define in Tuxedo
Test 1
testpet!VIP:/vmpuser1/vmp/vmp/api/Test/joltService> env | grep LANG
LANG=ru
System.getProperty- user.language ru
System.getProperty- file.encoding ISO8859-5
System.get

Mail attachment charset problem

Hello,
I have made a program which is able to send Icalendar files as an attachment. I get the data as an InputStream.
My problem is that the Icalendar file doesn�t show the letters '�', '�' and '�'. I have tried to use iso-8859-1 in the MimeBodyPart headerline and in the ByteArrayDataSource, but it doesn�t work?!
Where can I specify which charset I want to use?
MimeBodyPart mbp3 = new MimeBodyPart();
mbp3.setFileName( m.getAttachmentFileName() );
mbp3.setHeader("Content-Class", "urn:content-classes:calendarmessage");
mbp3.setHeader("Content-ID","calendar_message");
mbp3.addHeaderLine("charset=iso-8859-1");
java.io.InputStream inputStream = null;
try {
inputStream = m.getAttachmentFile().getBinaryStream();
mbp3.setDataHandler( new DataHandler( new javax.mail.util.ByteArrayDataSource( inputStream, "text/calendar;charset=iso-8859-1;method=REQUEST" ) ) );
catch ( Exception e ){}
mpRoot.addBodyPart(mbp3);

Yes you are right... Thank you.
I removed the line:
mbp3.addHeaderLine("charset=iso-8859-1"); - and now the letters are shown correct when opening the ICalendar file using a text editor.
But when openning the file using Outlook the letters '�', '�', '�' are removed?! I know that isn�t a problem in my mail code but certainly in the iCal file?!

JSP, Javabean charset problem

I have some JSP pages where I try to dynamically present some drop-down
menus for the users to select values. I use a simple bean to manage it.
The problem is that those values are in non-iso8859-1 charset and I only
get ?????? rendered in the select box. I define an array (inline in the
JSP page as code scriptlet), write all possible (String) options for the
drop-down menu there and in the bean I do some calculations and render
the drop-down menu.
String label[]={"something in iso-8859-7 encoding in here","something in
iso-8859-7 encoding in here","something in iso-8859-7 encoding in here"};
and in the bean I have a for-loop to access this.
The page directive is set to iso-8859-7.
I think there is some kind of transparent translation, that has to do
with Java language, and after the rendering I only get ???? instead of
the correct iso-8859-7 value in the browser.
Any help appreciated.
(Tomcat, Apache web server, JDK 1.3,)
PS: This JSP page is used to submit some data in an Oracle database
(according to the selection of the user in the drop-down box), so I also
use JDBC 1.3, but I don't think that's relevant at all with my problem...
null

I have some JSP pages where I try to dynamically present some drop-down
menus for the users to select values. I use a simple bean to manage it.
The problem is that those values are in non-iso8859-1 charset and I only
get ?????? rendered in the select box. I define an array (inline in the
JSP page as code scriptlet), write all possible (String) options for the
drop-down menu there and in the bean I do some calculations and render
the drop-down menu.
String label[]={"something in iso-8859-7 encoding in here","something in
iso-8859-7 encoding in here","something in iso-8859-7 encoding in here"};
and in the bean I have a for-loop to access this.
The page directive is set to iso-8859-7.
I think there is some kind of transparent translation, that has to do
with Java language, and after the rendering I only get ???? instead of
the correct iso-8859-7 value in the browser.
Any help appreciated.
(Tomcat, Apache web server, JDK 1.3,)
PS: This JSP page is used to submit some data in an Oracle database
(according to the selection of the user in the drop-down box), so I also
use JDBC 1.3, but I don't think that's relevant at all with my problem...
null

JDev 1013 EA1 : embeded OC4J default-charset problem

Hi
I'm a web-application programmer interesting in JDeveloper.
I had tried development using JDeveloper 10.1.2
When I used 10.1.2, I add [default-charset="EUC-KR"] to [JDEV_HOME/systemXX/config/global-application.xml]
- or [deployment-application/XXX/XXX/orion-web.xml] -
Because I don't use alphabet.
Anyway, it have effect.
But I encountered problem, after use JDeveloper 10.1.3 EA1.
I set default-charset in embeded-OC4J.
But it had no effect.
If that is a bug, please tell me how to use a installed OC4J in JDeveloper.
Please help me.
Thanks for read this message
Message was edited by:
user453010

This looks like a bug in OC4J
Can you try this and let us know if it works?
Set the charset in the application level orion-web.xml and deploy it to the Stand alone OC4J and see if it works.
1. Add a new OC4J Deployment Descriptor to your project
2. Choose orion-web.xml
3. Open the file in editor
4. Set the default-charset setting
<orion-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/orion-web-10_0.xsd"
schema-major-version="10" schema-minor-version="0"
servlet-webdir="/servlet/" default-charset="EUC-KR"></orion-web-app>
(Make sure all the other settings are set right. Similar to what you see in [deployment-application/XXX/XXX/orion-web.xml] )
5. Create a WAR deployment profile
6. Deploy the application to Standalone OC4J connection

Russian Translations problem with Translation Tool Package

Hello Everybody.
I'm doing some translations and whenever I try to paste a Russian text into one of the messages in TTP, the app transforms the Russian characters into question marks. For example:
Предупреждение: Контактное лицо X не имеет связи с Бизнес-Партнером Y. Но Активность будет сохранена.
TTP Transforms it into:
??????????????: ?????????? ???? X ?? ????? ????? ? ??????-????????? Y. ?? ?????????? ????? ?????????.
Did anyone come across with this problem?
Please any information would be helpful.
Regards,
Gerardo

Hello
It looks like Translation Tool Package does not support russian character set and that's why it is displaying as '?' which means character is not recognized by the application.
Are you able to type the russian text in a note pad?? If you can type and text is proper, Operarting System is able to recognize russian characters, and not the TTP.
If it displays '?' in the notepad also, it means OS is not able to identify the Russian character set. In this case, you need to install the russian character set in the machine.
Can you please provide which CRM mobile release you are currently using. In case if you are using CRM 5.0 or above, you can translate the texts using Mobile Application Studio itself.
Regards
Shankar

Interactive Report Russian Language Problem

Hello,
Entering Russian characters to search field of Interactive Report APEX transform it to another charset and I receive wrong result. For example entering КС I get РљРЎ, any ideas?
Best Regards, Kostya Proskudin

Answer for my question:
Changing character set in DAD file. From CL8MSWIN1251 to AL32UTF8.
But I still can't understand why it happen only in Interactive Report!!!

Prime Infrastructure 2.0 email charset problem

Dear all,
I have question regarding Guest portal managed through PI. Everything is set, but only one thing doesn't work as I expected.
When I make an account and print it, everything looks fine. When I sent it via email, then enconding of mail is wrong.
Problem is, that PI gives Charset : ANSI_X3.4-1968 (can see in email header).
I would like to have ther (in email) : CP1252 (or UTF) - basically something what can interpret national characters.
I have found this about similar problem, but absolutely have no idea where set it up.
http://thwack.solarwinds.com/thread/58101
http://helpdesk.ibs-aachen.de/2006/05/13/javamail-error-in-subject-ansi_x34-1968qtestmail_-_best3ftigung_ihrer_email-adresse/
In old WCS, there was no problem with this.
Does anyone has solution for this?
Thank you
Pavel

I see now, this is a poor carry over from NCS. The option that says include "controller" in email does provide the switch hostname. Hopefully by version 3.0 they will have all the wireless naming fixed when it applies to converged.
Thanks Rob!

Charset problems

Have also problems with charset.
Installed German translation and IdM doesn't save German special types in my MYSQL DB but shows me cryptic types.
When deleting a user in the english Admin site there's no problem but IdM shows me an errors message when deleting a user in the german surface. Also the user is deleted IdM isn't able to assign the special german fonts...

Hi,
i migrated a production environment with 40k userIds and 160k accounts from mysql 4.0.x to 4.1.x two weeks ago (unsure about the exact subversions atm).
We did have some issues (unable to delete IDM orgs) about collations as there were mayor characterset and collation changes between those mysql versions. This could be fixed with a few alter tables tho.
Oh and i did forget to mention before that 80% of our 380 admins are located in germany just as the servers are. So there are plenty of ��.
As it is a production environment dozens of users get deleted on a dayly basis and i didn't encounter your problem. What jdbc driver (version) are you using?
Regards,
Patrick

Russian font problem in Safari/mac

Hi all.
I have a problem concerning character encoding when I use Safari under Mac.
I am a developer. All the texts in my site are shown normally, only one text group, that comes from another SQL table, isn't encoded normally (Russian letters aren't shown).
Maybe the problem is in my SQL tables? But both of the tables (the one, the text of which isn't shown, and the one, that is shown normally) have character set UTF8.
I don't know where to look for the problem...
I would appreciate any help!
Lili

I am actually sure that the porblem text is in UTF 8, because this is the encoding used for the SQL table, and the text is taken from this table =>concequently it has UTF-8 encoding, right?
Not necessarily. Declaring something to be a certain encoding doesn't make it so. It is not uncommon to find data entered somewhere in the wrong encoding. On a web page, you can use View > Text Encoding to switch the encoding which a browser uses to read a text and thus perhaps find out if it is something other than what it is declared. If it is practical in your case you might try the alternative cyrillic encodings available in Safari on your problem text.

Charset problem!!

Hello everybody, there is something i need help with..
I have xml files, created by me in java, i create xml files in different charsets. The problem is when i try to read a UTF-8 File, with :
StreamSource sts=new StreamSource(new BufferedReader(new InputStreamReader(new FileInputStream(filename),"UTF-8")));when i read a ISO-8859-1 file, it works fine, but with a UTF-8 is seems to be a problem, cause i get a error parsing the xml, but if i use :
StreamSource sts=new StreamSource(filename);it works for UTF-8, but not for ISO, (i think UTF-8 is java's default)..
so, any ideas??

If you pass the XML parser an InputStream or
something else where it can read the bytes, it will
get things right. (Assuming the XML declares its
encoding correctly.) If you pass the XML parser a
Reader where you apply the wrong encoding, the parser
will not be able to get things right. Choose one of
those two.That's why i used:
StreamSource sts=new StreamSource(new BufferedReader(new InputStreamReader(new FileInputStream(filename),"UTF-8")));I read that InputStreamReader is the best way to read characters well using a given encoding.

WebService response charset problems

Some time ago I posted a problem regarding unicode characters in WebService
responses from WL7.0. I received a patch that helped partially - after the
patch was applied, WL no longer threw any exception when an utf character
was included in the response. So far so good.
However, a problem arises when I call the WebService from a .NET client;
.NET doesn't understand that the response is utf-8 encoded, so when the
response is deserialized on the client side the encoded characters (such as
å, ä, ö) come out as question marks. It seems that the Content-Type header
doesn't specify the correct charset (I would expect something like
'Content-Type:text/xml; charset=utf-8', but the charset=... part seems to be
missing)
By fiddling about a bit with the .NET generated proxy class I managed to
force .NET to think that the Content-Type mime header does in fact contain
the correct value (quite messy - I can supply the code if anyone should be
interested). However, this should not be necessary - the solution I came up
with is awkward and the only thing needed is that the correct Content-Type
header be included in the WebService response. Is there a way to specify a
default value for this?
I tried creating a handler to intercept the response and set this specific
mime header, but no luck - the value I set seems to be ignored (i tried
ctx.getMessage().getMimeHeaders().setHeader("Content-Type", "text/xml;
charset=utf-8");, as well as ...addHeader()). Besides, even if this did work
it would seem unnecessarity complicated to create a handler and set it to
handle all the methods in my WebService (there are quite a few).
Any ideas?
/Mattias Arthursson
Compost Marketing

This problem should be fixed in SP1. If the system property
user.lang is not english, then SP1 will use utf-8 as charset
(I think this will be your case).
In SP1 you can also set a system property to change charset :
weblogic.webservice.i18n.charset="my-char-set"
regards,
-manoj
"Mattias Arthursson" <[email protected]> wrote in message
news:[email protected]...
Some time ago I posted a problem regarding unicode characters inWebService
responses from WL7.0. I received a patch that helped partially - after the
patch was applied, WL no longer threw any exception when an utf character
was included in the response. So far so good.
However, a problem arises when I call the WebService from a .NET client;
.NET doesn't understand that the response is utf-8 encoded, so when the
response is deserialized on the client side the encoded characters (suchas
å, ä, ö) come out as question marks. It seems that the Content-Type header
doesn't specify the correct charset (I would expect something like
'Content-Type:text/xml; charset=utf-8', but the charset=... part seems tobe
missing)
By fiddling about a bit with the .NET generated proxy class I managed to
force .NET to think that the Content-Type mime header does in fact contain
the correct value (quite messy - I can supply the code if anyone should be
interested). However, this should not be necessary - the solution I cameup
with is awkward and the only thing needed is that the correct Content-Type
header be included in the WebService response. Is there a way to specify a
default value for this?
I tried creating a handler to intercept the response and set this specific
mime header, but no luck - the value I set seems to be ignored (i tried
ctx.getMessage().getMimeHeaders().setHeader("Content-Type", "text/xml;
charset=utf-8");, as well as ...addHeader()). Besides, even if this didwork
it would seem unnecessarity complicated to create a handler and set it to
handle all the methods in my WebService (there are quite a few).
Any ideas?
/Mattias Arthursson
Compost Marketing

22EL833R Russian Characters problem

I have some problems with Russian characters on Menu, teletext, guide, subtitle... The Russian "E" Letter are in most cases displayed as a question sign... Please, correct this bug

Dear Gus,
is the database UTF-8? In that case the characters are stored correctly in the DB.
Sadly Excel cannot recognize which character set is used, so it defaults to a standard character set. We have solved this by entering a Byte Order Mark to flag the content being UTF-8. This means that at the beginning of the file three bytes are added signaling that the content should be interpreted as UTF-8 (#EFBBBF).
Excel reacts on the BOM and interpretes the characters in the right way.
To open Excel on download, replace the 'text/plain' in your code with ' application/vnd.ms-excel'.
At the start of the file you have to write the BOM. I do not know whether that is possible with http functions.
I myself create the output in a CLOB, which I convert to a BLOB prepended by the BOM bytes.
Then I use wgp_docload.download_file to download the BLOB. The response header should be written in the code, this statement only replaces the htp calls.
Hope this helps

Charset problems using SQLLDR

Hello!
My task is to import data from a Microsoft Access Database into an Oracle Database. I got a Script which creates Flatfiles and Controlfiles with the data from Access. My problem is the characterset. There are some signs (e.g. the typical german quotationmark at the BOTTOM oder the "longer dash" you get from MS Word by using "blank+dash+blank"), which obviously cannot be convertet. So there are "turn-round questionsmarks". So I tried many different char-sets. I tried different nls_charset settings at oracle side and many charset as the parameter of the control files. But none combination let me get the right result. Does anybody know how I can get rid of this consersation desaster?
Best regards, Sascha Meyer

Hello!
Of cource I can give you the information:
Code points:
201C, 201D, 201E, 2013,2014
nls_database_parameters:
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD.MM.RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD.MM.RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY ?
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 10.2.0.2.0
nls_session_parameter:
PARAMETER VALUE
NLS_LANGUAGE GERMAN
NLS_TERRITORY GERMANY
NLS_CURRENCY
NLS_ISO_CURRENCY GERMANY
NLS_NUMERIC_CHARACTERS ,.
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD.MM.RR
NLS_DATE_LANGUAGE GERMAN
NLS_SORT GERMAN
NLS_TIME_FORMAT HH24:MI:SSXFF
NLS_TIMESTAMP_FORMAT DD.MM.RR HH24:MI:SSXFF
NLS_TIME_TZ_FORMAT HH24:MI:SSXFF TZR
NLS_TIMESTAMP_TZ_FORMAT DD.MM.RR HH24:MI:SSXFF TZR
NLS_DUAL_CURRENCY
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
Default value is WE8ISO8859P15
I tried this setting:
Database: WE8ISO8859P15
Charset used in controlfile: WE8MSWIN1252, UTF8, WE8ISO8859P15, we8iso8859p1, AL32UTF8
Database: UTF8
Charset used in controlfile:WE8ISO8859P15, UTF8, we8iso8859p1, AL32UTF8
Database:WE8MSWIN1252
Charset used in controlfile:WE8ISO8859P15, UTF8, WE8MSWIN1252, we8iso8859p1, AL32UTF8

Russian charset problem

Similar Messages

Maybe you are looking for