So I have an application written in JavaFx 2.2 that has been packaged for linux, mac, and windows. I am getting a strange issue with some of the text fields though. The application will read a file and populate some labels based on whats found in the file. When run on ubuntu or mac we get a result like as you can see we have that special accent character over the c and it looks just fine. However in Windows it shows up like this . Any idea as to why this is happening? I was a bit confused as it is the same exact application on all three. Thanks.
Make sure to specify character encoding when reading the file, in order to avoid using the platform's default encoding, which varies between operating systems. Just by coincidence, the default on Linux and Mac happens to match the file encoding and produces correct output, but you should not rely on it.
Related
In my application, I'm reading the properties file(UTF-8 encoded) containing Chinese characters and printing them on the Windows command line. But,for some reason the the messages are not getting displayed correctly(some extra characters are coming). However the same mesages are getting displayed correctly on Eclipse console and Cygwin. I've set the command line code page to utf-8(65001) and used "Lucida" font as well.
If you see the above image, on Windows it printed one extra 0 on the second line, but that is not expected;on cygwin the message was printed correctly.
Please let me know if I'm missing something. From this post , I can see that there are some issues with Windows UTF-8 code page implementation. If so, is there any other way to get over this problem ?
I can see that there are some issues with Windows UTF-8 code page implementation
oh most surely yes
is there any other way to get over this problem ?
The typical solution is to accept that the Windows command prompt is a broken disaster and move on. But if you really have to, you can use JNA to call the Win32 function WriteConsole directly, avoiding the broken byte encoding layer, when you can determine you are outputting to the console (rather than eg a pipe).
I have an issue where I think my local JVM is running with a different character encoding to one that runs on a server. Is there a command I can pass to the vm to display what character encoding is has? Something like
java show 'charset'
I've been searching for ages, and all of the solutions require writing a test in java code, but I don't really want to have to write code, deploy it to the server, etc.
I am confronted with a strange situation that I do not understand. I run a Java-Swing test application, that reads Arab-UTF8 hard-coded strings, builds a simple JXTable and shows the UTF8 strings on a column. The application is an executable jar that is run with command
java -cp test.jar org.test.MainTest
If there is a need I can attach the code of the application. The application shows Arab characters if run on Windows, or Mac but not HP-UX. We are talking about HP-UX B11.31 running jdk 1.7.0.0.05.
Please note that I checked the character settings at all possible levels on the HP-UX system. At Java level the default encoding is UTF-8 (file.encoding) and, at Swing level, the default font used by JXTAble (and enclosing panel) is Dialog and this font tested for a hard-coded arab string with method canDisplayUpTo(String x) returns -1 (all characters are displayable). I don't understand especially that, up to the moment the strings are fed into Swing, I manipulate only Java strings that are UTF8 compatible, or should be by definition.
Is anyone aware of HP-UX UTF8 encoding/decoding for Java/Swing? Is there something that escapes me, something that I should check? Any help will be greatly appreciated. Thanks.
I have a simple program that makes a request to a remote server running a service which I believe is written in Delphi, but definately running on Windows.
I'm told the service will be using whatever the default encoding is for Windows.
When I get a response and use println to output it I'm getting some strange symbols in the output, which make me think it is a character encoding issue.
How can I tell Java the the input from the remote system is in the windows encoding?
I have tried the following:
_receive = new BufferedReader(new InputStreamReader(_socket.getInputStream(),"ISO-8859-1"));
_System.out.println(_receive.readLine());
The extra characters appear as squares in the output with 4 numbers in the square.
Unless you KNOW what the "default encoding" is, you can't tell what it is. The "default encoding" is generally the system-global codepage, which can be different on different systems.
You should really try to make people use an encoding that both sides agree on; nowadays, this should almost always be UTF-16 or UTF-8.
Btw, if you are sending one character on the Windows box, and you receive multiple "strange symbols" on the Java box, there's a good chance that the Windows box is already sending UTF-8.
Use cp1252 instead of ISO-8859-1, as it is default on windows.
I have a problem with Tapestry form.
My XML database is very sensible with encoding, and need utf-8.
When i put the char 'à' in my form, tapestry receive 'Ó' and my core get an error : Invalid byte 2 of 3-byte UTF-8 sequence.
I haven't the problem in eclipse with local default configuration for tomcat.
But whatever the tomcat configuration, i think my application must do the conversion itself.
So i try :
charset="utf-8" in form => FAIL
buildUtf8Filter in AppModule => FAIL
The charset of every page is always utf-8.
So, what could i do before using java Charset encoder ?
thank you for helping me. :)
I wouldn't think there's anything wrong with your application. Tapestry does everything in UTF-8 by default; that wiki page is fairly out of date (referring to the 5.0.5 beta, where apparently forms with file uploads still didn't use UTF-8 properly).
You're saying you don't have the problem locally. Have you tried running on a different server? If you do not have the problem there, there's probably something wrong with the codepage settings of the operating system on the server.
Purely anecdotal evidence below
I have once had a similar character set problem in a Tapestry 5 app on the production server (running SUSE Linux) that I could not reproduce on any other server. All seemed fine with the application, the Tomcat server, and the codepage settings of the system, but POST data would end up decoded as ISO 8859-1 instead of UTF-8 in the application. The app had run on that server for a year before the problem manifested - maybe through an update in the operating system.
Afer a day of not getting anywhere, we ended up just re-installing the whole server OS, and everything was fine again.
The problem was about the default charset of the JVM launched into windows shell.
It caused trouble with FileWriter and then show bad character in the console :)