This content has been marked as final. Show 9 replies
pls make sure u mention the forms version, ie , other stuff
check the use of...
CHINESE_CHINA.WE8ISO8859P1 character set.Amatu Allah
Sorry forgot the version. We are using Forms 11g 126.96.36.199. Character set is set to AL32UTF8 in forms and database (so it should be able to anything and does since we can read and write to Chinese characters to the database). Also the Chinese characters were just some random stuff I got of Google.
Maybe it is just a problem with the display in the console.
Did you try to Google for Java + UTF8 ?
Did some more digging and I figured out that if I set the Runtime Parameters to "-Dfile.encoding=utf8" in the Java control panel the applet runs and outputs utf8 as expected. The problem is I cannot possibly expect our users to make this change themselves (too many countries and languages to deal with). I've been looking at how we can set this setting for the users with no luck so far.
i have also made extensive search best i found
cause am interested to know i stopped to a point of square where we go !?
many solution on line help but need 2 know what we r using...!
u have many programs free on web where u can access clients pc where ever they r can't remember any of them but it stats with
i found out also from the surfing Google that u can use from browser menu try to as select
edit >encoding >select the appropriate languageWill make the difference.
pls keep on touch if any updates u get am anxious to know to restart from an end and collect the ends to get a solution.
If the problem is writing files in UTF-8 then you can implement this yourself; you just need to set the characterset for the OutputStreamWriter:
The problem isn't actually writing the file in UTF-8. The problem is that between the call to SET_CUSTOM_PROPERTY in the form and the setProperty method being called in the PJC the encoding is getting lost. As a result I simply cannot get the characters from the original string into the Java bean. I have a feeling the fix for this will have to come from Oracle.
You could try to encode the string in base64 before calling the set_custom_property(), then decode it in the PJC...
You read my mind. :) I tried it quickly and it does work (we already have base64 file writing to handle non-text files so it was easy to test). I just need to work on the code to split the varchar2's into a couple parts to handle the increase in size of the encoded string in case someone sends in a string that hits the varchar2 size limit.