International characters and mod_plsql

We are having troubles with mod_plsql translating international characters.
Here is the scenario:
We have an HTML form whereby the user can enter a letter.
If they enter the letter 'X', by the time it calls the ACTION in the
html form, it has changed it from 'X' to '&_Oslash' (I have inserted an
underscore character for demonstration purposes).
The ACTION in the HTML form is a plsql procedure which does nothing more
than display the character the user entered. It "visually" displays the
X character because the browser knows how to interpret the &_Oslash,
however the "real" character should have been 'X' since we want to store
this character in the UTF8 database. We need to store the 'X' character
in order to search on it (you can't search on &_Oslash).
Any help on this would be appreciated. We only have thousands of hotels internationally,
it would be nice to use other languages besides english.
Sun OS 5.8
9ias 1.0.2.2.0
mod_plsql 3.0.9.8.3b
rdbms 8.1.7.3.0
NLS_CHARACTERSET=UTF8 (and NLS_NCHAR_CHARACTERSET)
NLS_LANGUAGE=AMERICAN
owa_util plsql toolkit 3.0.0.0.5
Thanks, Kate

I'm picking up the IP address but I also want to pick up the name the username and the %u doesn't seem to be capturing the mod_plsql login name.
Jeremy.

Similar Messages

Firefox Chrome Showing ???? instead of International Characters

Hi,
I have a flash movie at this site
http://preview.tinyurl.com/5289rz
When you click on the rendered thumb nail (with a link
containing international characters) it takes you to a URL with
those same characters in IE 7 it displays international characters
and takes you to a correct page but in Firefox, Chrome and Opera
the international characters are displayed correctly in the flash
movie, but the URL turns those characters into question marks ????
and the pages shows a 404 not found error.
Firefox
http://www.site.com/video/??????_??????_???????_???????_???????_???_????????

Does that mean we should ignore those millions of users
around the world that would be plain foolish. I am here to get this
problem solved not to be told to just ignore users who use other
browsers.

Messenger and international characters

I posted this earlier this month on the blackberryforums.com and crackberry.com web sites but didn't really get a answer. Hopefully it will have a better outcome here
Hi, we switched from the 7250 to the 8330 model (what an upgrade!). I have a question though regarding the 83xx messenger, I can't get international characters to work (by holding the key and moving the trackball). It works in other application (like while sending an email or in the address book) but not in messenger. We did not have that problem with the 7250 model.
Is this a known issue/limitation? My firmware version is 4.3.0.124 and my carrier is Telus.
Thanks.

Hello,
I just joined this community, and of course I started my search for this same issue.
After spending more than 4 hours with Tech Support from my Carrier, then going to the Carrier's Store and wasting 2 more hours, then back to the phone with the carriers tech support this time with a spanish speaking cust. svc. agent, this issue is still unresolved, I think, and everyone else who tried to help as well, that this is a GLITCH in Blackberry's phones, I have a Curve 8330, and a Storm, and they both do not allow you to type international characters in SMS ....GRRRRRRRR! yes it works in everything else except there.
I tried the new Tour at the store and it does allow the international characters in SMS messages, but of course they wanted me to dig into my pocked to pay for the difference.
I think we should all come together and write something to Blackberry and let them know that we need this fixed, it's aggravating having to compensate through apologies and typing extra characters just to be able to communicate in a different language with these phones.
I think that these Smart Phones, are not so smart after all....LOL

XMLTYPE and International Characters

Database: Oracle9i
Characterset: US7ASCII
I am trying to insert a very small xml document into an XMLTYPE column in a table.
My xml document, however, contains international characters like French and Spanish letters with their accompanying accent marks.
I have tried setting various encoding schemes in the encoding attribute on the xml document but none of them work.
The parser stops at the first international character and complains that it is invalid.
Is there anything I can do to insert these characters into my XMLTYPE column without complaint?
Thanks.

Please post this message at:
Forums Home » Oracle Technology Network (OTN) » Products » Database » XML DB

Issue with displaying international characters returned by Search And Promote.

Hi,
     I am trying to display international characters being returned by Search and Promote. The actual text returned by S&P is televisión, while the one being displayed is televisiÃ³n
I am usging r.get() to fetch values returned by S&P. The issue is only with data returned by S&P. Local international texts are being properly displayed.
Thanks in advance!

Thanks Sham! Found the fix. I am checking for invalid characters in the byte stream and then applying corresponding encoding.
This method checks for invalid characters.
public static boolean isValidUTF8( byte[] input ) {
    CharsetDecoder cs = Charset.forName("UTF-8").newDecoder();
    try {
        cs.decode(ByteBuffer.wrap(input));
        return true;
    catch(CharacterCodingException e){
        return false;
This statement performs corresponding encoding.
String utf8 = new String(inputString.getBytes(encoded format), Charset.forName("UTF-8"));

JDK1.3 + Tomcat and International Characters-- Working!

I am involved with a project that has people using a "command/ prompt" based system to enter data. Lets assume this is a simple java program that uses system.out. The data they are entering uses international characters such as the � character.and others. Now that the data was captured I wanted to display the data through JSP on a webpage. When doing so I ran into a problem where the � where translated into ?. Thus started the journey
After much research, and alot of trial and error I came up with the following Test JSP that finally works
---- copy / past this to file and type it out from a windows command prompt ---
<%@page contentType="text/html; charset=Cp1252" %>
<% String test = "��"; %>
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=CP437">
</HEAD>
<BODY>
TEST: XX <%=test%> XX
</BODY>
</HTML>
When you do this you will see �� for the test string. By the way if you use Visual Slick you will see the characters properly as apposed to lets say note pad.
Putting this file in a jsp and runing it under tomcat 4.01 you will see the expected result mainly:
TEST: XX �� XX
As you can see though by the file the character set the jsp is set to use is cp1252 but the meta tag uses cp437.
which gives the desired effect of properly printing the characters as I would have hoped.
So here is my question:
Am I correct in assuming that the windows command prompt uses CP1252 as a character set (there for any dos / non-windows tool uses the same thing) and that Windows graphical ie notepad, and webpages uses CP437.
Since this seems to be correct. Is this the right way of doing this? Seems a bit hard coded. I have not tried this on UNIX or a unix based text browser but I suspect this will not work on them. What is the correct way to do this?
Thanks
Mike..

Wow, that seems like a sticky little issue to have overcome. I can offer you no better way to do it, but can wish you luck in your future endeavors!!!!

Ovi and international characters

Hi,
I started using Ovi sync services due to the end of Goosync free services. Ovi works great, except for international characters (I write in Spanish). I tried changing the way my browser displays text but it seems that the problem is in the synchronization itself ¿Does anyone have a workaround for this?
Thanks in advance
Enrique S.
Santiago, Chile

Please post this message at:
Forums Home » Oracle Technology Network (OTN) » Products » Database » XML DB

Parsing International Characters

Hi folks,
I am trying to parse an xml document which has international characters like "�" (accentuated e used in french). But my parser crashes trying to parse a document containing these characters:
System.out.println("******************* 1");
DocumentBuilderFactory lFactory = DocumentBuilderFactory.
newInstance();
System.out.println("******************* 2");
DocumentBuilder lDB = lFactory.newDocumentBuilder();
System.out.println("******************* 3");
lDoc = lDB.parse(new FileInputStream(pFileName));
System.out.println("******************* 4");
The exception occures after 3rd println. Here is what I get:
[17/May/2005 08:50:14:640] info: The Exception Stack Trace is : The element type "FirstName" must be terminated by the matching end-tag "</FirstName>".: org.xml.sax.SAXParseException: The element type "FirstName" must be terminated by the matching end-tag "</FirstName>".
     at org.apache.xerces.framework.XMLParser.reportError(XMLParser.java:1213)
     at org.apache.xerces.framework.XMLDocumentScanner.reportFatalXMLError(XMLDocumentScanner.java:579)
     at org.apache.xerces.framework.XMLDocumentScanner.abortMarkup(XMLDocumentScanner.java:628)
     at org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XMLDocumentScanner.java:1136)
     at org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.java:381)
     at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1098)
     at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:195)
     at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:76)
     at com.exult.andy.mbcommon.utilities.AncestorXMLUtil.fileToDoc(AncestorXMLUtil.java:328)
     at com.exult.andy.importadapter.base.AncestorDeployImportAdapter.main(AncestorDeployImportAdapter.java:62)
The element is indeed correctly terminated.
I appreciate any help. Thanks in advance.
-r

Then you don't have a well-formed XML document. If it doesn't declare its encoding in its prolog <?xml version="1.0" ?> then it should be encoded in UTF-8 (or, less likely, some variant of UTF-16) and it's probably encoded in ISO-8859-1 or something like that. If that's the case then fix the prolog to declare the encoding: <?xml version="1.0" encoding="ISO-8859-1" ?> or encode the document in UTF-8.

BIG PROBLEM: CSS files not loading because of international characters in file name

I have Muse Beta 7 in Spanish.
The program creates a css file called master_a-página-maestra.css in css folder. It is referenced in the resulting HTML code here:

<link rel="stylesheet" type="text/css" href="css/site_global.css?3951792836"/>
<link rel="stylesheet" type="text/css" href="css/master_a-p%c3%a1gina-maestra.css?fileVersionPlaceholder"/>
<link rel="stylesheet" type="text/css" href="css/index.css?3948175564"/>
When you work locally in your Windows formatted har drive, everything looks fine, but when you upload your files to a server, everything is screwed up. The server doesn't recognizes the URL and returns an error page, resulting in style errors in the entire site.
This can also happens with html files if the title of the page contains international characters or with images if the image file name in your Hard Drive contains international characters.
I already pointed out long time ago Muse was generating file names with international characters like á, ñ, etc but nobody cared about it. Too bad. I had to activate file name customization but I think that Muse should replace automatically this characters in the same way that it replaces other conflictive characters like commas or ampersands.
This is not a fault of the FTP client. Accented characters are not web safe regardless of the FTP client you are using. It is a server side issue. Some servers support it some others don't. I don't mind if it works in Adobe Catalyst server because the final website is going to be in another server and maybe next year when paid hosting is ended the client may move it to another server.
It makes more sense to replace accented characters in file names by their not accented equivalents ('a' instead of 'á', 'N' instead of 'Ñ', etc) and avoid all this problem.

Zak, It is funny you mention it, because the site I am talking about is hosted in 1and1. try this: http://www.artofwalls.com/rosannawalls/biografía.html
As you can see, the offending "í" in the file name causes 1and1 server to throw a "page not found" error. And this has happened with many other servers I have tried since.
Muse boast of generating code fully compatible with all major web browsers but by using international characters in file names it ggenerates code suitable only for very few web servers. International characters have been always a no-no for internet URLs. Internet was designed by people who didn't care about ascii codes beyond 127 so using international characters in html file names is just call for problems.
"to work with your hosting provider to determine how to enable Unicode encoded (UTF-8) file names and HTML files on their servers" is not a viable solution most of the time unless you are a Very Important Client of your host provider. If not, making changes means money for them and if you are the only one who complains, they are going to just tell you to not use international characters in your names.

SAPSCRIPT: Printing international characters on ZEBRA; How to do?

Hi,
I use software NiceLabel software to design barcode forms. I upload the design to so10 Sapscript text and print it on the Zebra ptinter. I used device tape ASCIIPRI. The SAP system is unicode.
Now I need to print chinese pallet labels and I get unexpected problems. I found a lot information but no solution. Is it possible to print international charcters form SAPScript on Zebra?
I got the information from Zebra's White Paper: Solution for Printing International Characters. There it says:
"Unicode UTF-8 is embedded within Zebra printers."
"SAP Forms can be universal. Labels and forms ... do not need to be modified or recreated to print in different languages."
"SAP-developed UTF-8 device type and code page support for SAPscript users"
"Label design software that can generate ZPL with support for Unicode ZPL commands"
Do you now which device type I have to use? I think I need an UTF-8 device type. Do you know how to go on?
Please help. Thanks
Frank

Hi Frank,
as far as I know, it might be possible when using SMARTFORMS instead of SAPScript!
In that case, it depends of the device type and the printer type, of course.
Have a look on SAP Note 750002 SmartForms: Support für Zebra Etikettendrucker (ZPL2).
Cheers
Klaus

International characters not showing up in certain apps?

I'm using Dreamweaver CS3 and international characters aren't showing up. There are blank spaces where they used to be. The characters are still there, it's just that they appear as blank spaces (I can copy and paste them and see them elsewhere).
This change occurred after I installed 10.6. Is there any way to fix this?

I've seen the same thing on Photoshop and Fireworks CS3, and even just the other day on iMovie '09, but I was still on Leopard – so are you sure it's Snow Leopard-related?
In my case, CS3 apps would show squares, and iMovie wouldn't even move the cursor (it wouldn't even let me enter curly quotes). With iMovie it was easily fixed by typing in TextEdit, then copying and pasting to iMovie. No success in CS3 apps, which categorically refused to enter any glyphs that weren't more or less standard Latin.

Jforum international characters problem

Hi all,
Has anyone used jforum (www.jforum.net)? It is an open source forum software
I am having problems with international characters.
Please let me know if you have had so I'll post my question.
Thank you.

Hi,
So here is the problem. JFORUM is a very easy to use forum that can be set up within a short period of time. It is all nice UI configuration.
In admin control I reconfigure the forum to be in Russian.
When I store messages in DB and later on retrieve them they come up as question marks :(
I tried to alter the table but it did not work. Here is an example of one table:
create table jforum_posts_text
     post_id int(11) not null default '0',
     post_text text CHARACTER SET utf8,
     post_subject varchar(100) default NULL,
     primary key (post_id)
)engine=InnoDB default charset=utf8;Any ideas, help, suggestions?
Thank you.

Displaying International Characters

Some users have been concerned about the fact that Buzzword
does not display some international characters - ranging from Greek
to Russian. This is accentuated by the fact that we have Buzzword
users in well over 100 countries.
The problem occurs when users attempt to insert some
international characters - say, the Greek letter omega - and
Buzzword instead displays a dot on the screen. Here's what's going
on, for anyone interested:
Like virtually all modern software, Buzzword adheres to the
Unicode standard, where characters are defined with 16 bits,
resulting in a total of over 65,000 possible characters.
However, unlike most desktop software, Buzzword must use
something called "embedded fonts". This means that we can't read
fonts off a user's computer, but instead we have to download fonts
from our server.
This is where our challenge begins. A font family contains
characters - called "glyphs" when drawn on the screen - for some
portion of the 65,000 possible characters defined by Unicode. Each
available character is downloaded as a small program containing
instructions on how to draw the glyph. The instructions are
relatively small, but each takes time to download - you can see
evidence of this in our "loading fonts" progress bar.
For Buzzword to load relatively quickly, we need to limit the
number of characters downloaded with each of our seven font
families. Most people use far fewer than 65,000 characters, so for
our first phase of deployment, we identified a couple hundred
characters to download for each font family. Because our initial
market focus was North America, we chose characters from Latin-1,
the Western European character set.
The result: when a user attempts to enter the Greek letter
omega, Buzzword recognizes the Unicode character but does not have
the downloaded instructions to display the glyph on the screen. The
little dot that is displayed instead is an indication that the
requested glyph has not been downloaded with the font set.. If the
user were to export the document to be read by a desktop program,
the glyph would probably be displayed using the computer's fonts.
Longer term, we'll handle this differently by downloading
fonts dynamically, based on the document's contents and a user's
settings. In the meantime, we apologize to everyone who uses
characters outside the Western European set. We will work to get
you a solution as soon as we possibly can.

quote:
Like virtually all modern software, Buzzword adheres to the
Unicode standard, where characters are defined with 16 bits,
resulting in a total of over 65,000 possible characters.
Actually, Unicode (the standard) does not care about the
number of bits.
It has enough space to encode more than one million
characters, and the current version (Unicode 5.1) already encodes
more than 100,000 characters (
http://www.unicode.org/versions/Unicode5.1.0/)
quote:
Buzzword must use something called "embedded fonts".
Nothing prevents Flash/Flex from using fonts "html style".
In fact, Buzzword can add a "Generic sans-serif" font as an
option (font-family: Verdana, Arial, Helvetica, sans-serif;) with
zero effort.
The document will not look the same on all computers, but
this might be better than the current bullets.
So this is not a "must".

International characters not showing

When some international character set is selected in Language
bar (windows), and typing text in the Freehand MX, garbage
characters are showed.
This is related to Freehand only, becouse when typing in any
other aplication (ms word, publisher, even notepad), proper
characters are shown.
Is there any settings that I need to change or any other
intervention for international characters to be used in FH ?
BTW even when pasting text containing international
characters to FH, the same problem is happening.
Thanks
Nicky

> When some international character set is selected in
Language bar (windows),
> and typing text in the Freehand MX, garbage characters
are showed.
>
> This is related to Freehand only, becouse when typing in
any other aplication
> (ms word, publisher, even notepad), proper characters
are shown.
This is FreeHand only because FreeHand does not support as
wide character set (Unicode) as most of the apps.
There are language versions of FreeHand, like Hebrew, that
support some extended character sets but the standard English
version can handle about the set available in Type1 font.
Jukka

International characters in IOS filenames

Hello,
My movie compiles fine but when I add this file name to the package:
ahí1.wav
I get an applicationverificationfailed message when I try to send it to the device from flash cc
if I rename it to:
ahi1.wav
It will work without failure.
I've got hundreds of files that have international characters do I have to rename them all or is there a special flag, switch, or trick I can use to get around this?

Stefan,
It's good news that you are not having this problem, as it means that perhaps I won't shortly either. If we can characterize the differences between our setups, maybe I can have the same result as you do.
I've just run the obvious case - I've created a file using TextEdit with a German name out on the volume from the Mac, stopped TextEdit, and successfully retrieved it. So it doesn't look like a filesystem mounting issue. I wonder what is so weird about these files. There must be something odd in the header, because it is definitely at the file info level that it is going off the rails. While the name is the obvious differentiator, maybe something else is odd as well.
One thing I could try is to zip one of the directories affected on the Windows side and then try unzipping it into place there, then boot over to the Mac side and see if things have improved. If that doesn't resolve the problem, I could try unzipping it into place on the Mac side, but first I'll boot over to the Windows side and make sure it can read the file I just created in TextEdit from that end.
By the way, the KB article you referenced was about shares and about problems with punctuation mounting Mac shares on Windows, so I don't think it pertains. In any case, I'm mounting a FAT volume, not a share, so the drivers would be completely different.
Anyway, thank you for your help. Now that I'm no longer chasing phantoms, I can attend the real problem.
Thanks,
Ralph

International characters and mod_plsql

Similar Messages

Maybe you are looking for