Java & the Euro Symbol

[JDOne]

Hello,

We have a time and expense applet which features a comment window for users to place comments for their expenses. When a user puts the Euro symbol into the comment window and then attempts to save his/her information, the following application error message results:

org.omg.CORBA.DATA_CONVERSION: char of value 8364 is not an 8-bit entity minor code 1330446337 completed: No

Thanks for your help.

JD

 

[idarke]

You could try encoding the string before saving it using java.net.URLEncoder.encode().

You have to decode() when you read it back from storage, of course.

 

[JDOne]

idarke -

Thanks for your reply. Could you provide me a small example of how this is done? Thanks.

JD

 

[idarke]

It's really simple.

String newString = java.net.URLEncoder.encode(oldString);

String oldString = java.net.URLDecoder.decode(newString);

 

[JDOne]

Hi -

Thanks again. These comment texts are being saved into an Oracle database. Because the euro symbol is not an 8-bit entity, the save feature crashes. I can type the symbol into the text editor by pressing Alt 0128. The Java source code for the euro symbol is "\u20AC". So, how would I use the encode/decode syntax in my save method (which is on the client side)? Something like this?:

String newString = java.net.URLEncoder.encode("\u20AC");
String oldString = java.net.URLDecoder.decode(newString);

Do I put this into a condition - not all users will use the euro symbol.

Sorry for being confused - appreciate your help.

JD

 

[Diancecht]

I think what's idarke is trying to say is that you always use URLEncoder for the text stored in the database. You've found the problem with the € but could appear with other symbols.

Cheers,

Dian

 

[JDOne]

Thanks Dian and all -

Still having problems. Using the encoder isn't working. The platform we're using is JDK 1.2.2 - could this be the problem -- do we need to use a newer platform such as 1.4?

Thanks.

JD

 

[jstreich]

Not working how? Have you checked the JavaDoc for 1.2.2 to see if the URLEncoder is part of the older compiler and JRE? Is it compiling? Or?

This before you save newstring to the database:

String newString = java.net.URLEncoder.encode(oldstring);
// save here

pull the newString from the database, and turn it back into UTF string.

//pull newString out of database here
String oldString = java.net.URLDecoder.decode(newString);

Please post all error messages and information related to the problem. Please post code from around the areas listed in compiler errors. When posing code use [ code ] [ /code ] tags around it (without the spaces). Doing this will keep the members of the board happy, and help us to help you.

[plug=shameless]

http://game-master.us/phpx-3.4.0/

[/plug]

 

[JDOne]

Thanks for your reply, jstreich.

What I mean by it "not working" is that I'm still getting the corba data conversion error notwithstanding the fact that I've used the URLEncoder -- which BTW did, in fact encode the euro "\u20AC" into %80 - nonetheless, it still crashed trying to save to the database.

And yes, I did check the jdk1.2.2 specs and URLEncode & decode are there, compiling is fine, etc. And the java.net.URLEncode.encode() evidently is doing its job. Do you think it might be possible that the problem lies in the database character set - or would that have yielded me a different type of error such as some sort of SQL error?

Thanks.

JD

 

[jstreich]

Questions I'd try to answer by running a bunch of different tests:

What if it's not the EURO sign that's crashing it, did you try and send clear text?
Are you forgetting to escape chars that are meaningful to a database that are alright in a URL? (things like the single quote)
Do you get the same thing trying to enter the same data into the database via the database's frontend?

[plug=shameless]

http://game-master.us/phpx-3.4.0/

[/plug]

 

[JDOne]

Hi -

I'm sure its the euro sign that's crashing it. Clear text doesn't crash it, entering the same data into the database's front end doesn't work. It doesn't recognize the euro character. Perhaps this is the crux of the problem? Perhaps a different character set is required? IYO, would this be the cause of the corba data conversion error?

Thanks.

 

[jstreich]

Did you try entering the URLEncoded version of the string to frontend of the database? (just covering all bases)

I know that databases can be very finiky about the encoding of the input. If what the database is giving cobra is unexpected and not meaningful, i.e. erroring out, cobra would stumble on the error and pass out some "more meaningful" error. If everything works fine for clear text and the EURO symbol is all that causes both DB to choke and the cobra to throw that error, my money would be on the database passing back some crypic goobly-gook, and cobra not knowing what to do with it. To be honest the URLEncoded string SHOULD fix the problem... as the return is just a niced up version with code to replace the odd chars (codes that aren't nice ascii text)...



[plug=shameless]

http://game-master.us/phpx-3.4.0/

[/plug]