I have a JavaFX/Groovy application that I'm trying to localize.
It turns out that when I use JavaFX standard execution with the Java VM arg "-Dfile.encoding=UTF-8" locally, all of my international characters (for example, ü) display correctly.
However, if I invoke the app via a JNLP file, using java-vm-args="-Dfile.encoding=UTF-8" e.g.
<resources>
<j2se version="1.6+" java-vm-args="-Dfile.encoding=UTF-8"/>
...other stuff...
</resources>
The application shows international characters as a couple of other random characters (like √¬).
Am I specifying the file encoding incorrectly in the JNLP, or is there some difference between Standard Execution and Webstart that affects this?
Much Appreciated.
EDIT: I am using a Groovy API to access the Remember The Milk RESTful web service. All text that is problematic will come from data retrieved (like task names) and is not actually stored on disk in binary or text. It's curious that "-Dfile.encoding=UTF-8" would actually fix it locally.
I would strongly advise you to explicitly specify the encoding everywhere you're going to be converting text to binary or vice versa. Relying on the JVM default - even after you've set that default - doesn't feel like a good idea to me. You haven't really said what you're doing with text, but if you explicitly set the encoding when you save or load, it should be fine.
Related
((I'm an industrial construction engineer (recently graduated) and at the place I recently started working we use a Java Program, developed by an external company, to calculate the price of industrial buildings including everything.))
I have a html link on my desktop and it starts a Java Applet/ Web Start (?), I have to click Run, and after that a new (native windows) window pops up with the program running in it.
Everything looks super old, ugly skin, bad fonts, I hate it. In old manuals (2013) the program (on screenshots) has a native windows look and feel.
However, the most recent versions look SHIT.
Question: Do I have to contact the writer of the code # the external company to change the look and feel back to native OS?
Or is there someway for me to crack into the code and force a parameter or something?
I'm kinda noob at Java but I'm a quick learner, shoot.
You can try to set the nimbus look-and-feel. You need at least JDK 6 for nimbus. There are more ways how to do it: https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/nimbus.html
As you can see on this link, you can do it programmatically inside the java program.
BUT there are 2 other ways how you can do it by configuration:
1.
Permanently set the default look and feel to Nimbus by adding the
following line to the JAVA_HOME/lib/swing.properties file:
swing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel
If the swing.properties file does not yet exist, you need to create it.
2.
Specify Nimbus as the default look and feel for a particular
application at the command line, as follows:
java -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel MyApp
In the 2nd case the java command line (in case of JWS) is coming from the .jnlp xml descriptor which is part of the deployed JWS application jar file.
There is a resources section in the .jnlp which looks something like this:
<resources>
<j2se version="1.7+" java-vm-args="-esa -Xnoclassgc -Xms32m"/>
...
</resources>
which you should extend with the nimbus property values like this:
<resources>
<j2se version="1.7+" java-vm-args="-esa -Xnoclassgc -Xms32m"/>
<property name="swing.laf" value="com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel" />
<property name="swing.defaultlaf" value="com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel" />
...
</resources>
to get the intended java command line created.
As almost everything in the programming...
It depends. There's a way to get java code from the jar file (The term java developers use is "decompile"), but there's a process called "obfuscation" wich prevents this sometimes. There's a high chance, that the the program you use contains obfuscated code. If the code is obfuscated then you get an uncompilable code, and you would need to pretty much rewrite the whole codebase.
This is not the only problem, deobfuscating code is not 100% illegal, but you are permitted, to share the code or the recompiled program. Keep this in mind, if you choose this path.
To decompile a jar file, you can use jd-gui. Then you need to save the java files you get to a directory. You can open these with a normal text editor, but I'd advise you to get a java IDE, such as Eclipse.
After this, it's pretty easy to change, how a GUI looks. You can check java GUI tutorials about this.
I have this problem that has been dropped on me, and have been a couple of days of unsuccessful searches and workaround attempts.
I have now an internal java swing program distributed by jnlp/webstart, on osx and windows computers, that, among other things, downloads some files from WebDav.
Recently, on a test machine with OSX 10.8 and Java 7, filenames and directory names with accented characters started having those replaced by question marks.
No problem on OSX with versions of Java before 7.
example :
XXXYYY_è_ABCD/
becomes
XXXYYY_?_ABCD/
using java.text.Normalizer (NFD, NFC, NFKD, NFKC) on the original string, the result is different but still wrong :
XXXYYY_e?_ABCD/
or
XXXYYY_e_ABCD/
I know, from correspondence between [andrew.brygin at oracle.com] and [mik3hall at gmail.com] that
Yes, file.encoding is set based on the locale that the jvm is running
on, and if you run your java vm in xxxx.UTF-8 locale, the
file.encoding should be UTF-8, set to MacRoman will be problematic.
So I believe Oracle/OpenJDK7 behaves correctly. That said, as Andrew
Thompson pointed out, if all previous Apple JDK releases use MacRoman
as the file.encoding for english/UTF-8 locale, there is a
"compatibility" concern here, it might worth putting something in the
release note to give Oracle/OpenJDK MacOS user a heads up.
original mail
from Joni Salonen blog (java-and-file-names-with-invalid-characters) i know that :
You probably know that Java uses a “default character encoding” to
convert binary data to Strings. To read or write text using another
encoding you can use an InputStreamReader or OutputStreamWriter. But
for data-to-text conversions deep in the API you have no choice but to
change the default encoding.
and
What about file.encoding?
The file.encoding system property can also be used to set the default
character encoding that Java uses for I/O. Unfortunately it seems to
have no effect on how file names are decoded into Strings.
executing locale from inside the jnlp invariabily prints
LANG=
LC_COLLATE="C"
LC_CTYPE="C"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
the most similar problem on stackoverflow with a solution is this :
encoding-issues-on-java-7-file-names-in-os-x
but the solution is wrapping the execution of the java program in a script with
#!/bin/bash
export LC_CTYPE="UTF-8" # Try other options if this doesn't work
exec java your.program.Here
but I don't think this option is available to me because of the webstart, and I haven't found any way to set the LC_CTYPE environment variable from within the program.
Any solutions or workarounds?
P.S. :
If we run the program directly from shell, it writes the file/directory correctly even on OSX 10+Java 7.
The problem appears only with the combination of JNLP+OSX+Java7
I take it it's acceptable to have maximal ASCII representation of the file name, which works in virtually any encoding.
First, you want to use specifically NFKD, so that maximum information is retained in the ASCII form. For example, "2⁵" becomes "25"rather than just
"2", "fi" becomes "fi" rather than "" etc once the non-ascii and non-control characters are filtered out.
String str = "XXXYYY_è_ABCD/";
str = Normalizer.normalize(str, Normalizer.Form.NFKD);
str = str.replaceAll( "[^\\x20-\\x7E]", "");
//The file name will be XXXYYY_e_ABCD no matter what system encoding
You would then always pass filenames through this filter to get their filesystem name. You only lose is some uniqueness, I.E file asdé.txt is the same
as asde.txt and in this system they cannot be differentiated.
EDIT: After experimenting with OS X some more I realized my answer was totally wrong, so I'm redoing it.
If your JVM supports -Dfile.encoding=UTF-8 on the JVM command line, that might fix the issue. I believe that is a standard property but I'm not certain about that.
HFS Plus, like other POSIX-compliant file systems, stores filenames as bytes. But unlike Linux's ext3 filesystem, it forces filenames to be valid decomposed UTF-8. This can be seen here with the Python interpreter on my OS X system, starting in an empty directory.
$ python
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
>>> import os
>>> os.mkdir('\xc3\xa8')
>>> os.mkdir('e\xcc\x80')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
OSError: [Errno 17] File exists: 'e\xcc\x80'
>>> os.mkdir('\x8f')
>>> os.listdir('.')
['%8F', 'e\xcc\x80']
>>> ^D
$ ls
%8F è
This proves that the directory name on your filesystem cannot be Mac-Roman encoded (i.e. with byte value 8F where the è is seen), as long as it's an HFS Plus filesystem. But of course, the JVM is not assured of an HFS Plus filesystem, and SMB and NFS do not have the same encoding guarantees, so the JVM should not assume this scheme.
Therefore, you have to convince the JVM to interpret file and directory names with UTF-8 encoding, in order to read the names as java.lang.String objects correctly.
Shot in the dark: File Encoding does not influence the way how the file names are created, just how the content gets written into the file - check this guy here: http://jonisalonen.com/2012/java-and-file-names-with-invalid-characters/
Here is a short entry from Apple: http://developer.apple.com/library/mac/#qa/qa1173/_index.html
Comparing this to http://docs.oracle.com/javase/tutorial/i18n/text/normalizerapi.html I would assume you want to use
normalized_string = Normalizer.normalize(target_chars, Normalizer.Form.NFD);
to normalize the file names before you pass them to the File constructor. Does this help?
I don't think there is a real solution to this problem, right now.
Meantime I came to the conclusion that the "C" environment variables printed from inside the program are from the Java Web Start sandbox, and (by design, apparently) you can't influence those using the jnlp.
The accepted (as accepted by the company) workaround/compromise was of launching the jnlp using javaws from a bash script.
Apparently, launching the jnlp from browser or from finder creates a new sandbox environment with the LANG not setted (so is setted to "C" that is equal to ASCII).
Launching the jnlp from command line instead prints the right LANG from the system default, inheriting it from the shell.
This permits to at least preserve the autoupdating feature of the jnlp and dependencies.
Anyway, we sent a bug report to Oracle, but personally I'm not hoping it to be resolved anytime soon, if ever.
It's a bug in the old-skool java File api, maybe just on a mac? Anyway, the new java.nio api works much better. I have several files containing unicode characters and content that failed to load using java.io.File and related classes. After converting all my code to use java.nio.Path EVERYTHING started working. And I replaced org.apache.commons.io.FileUtils (which has the same problem) with java.nio.Files...
...and be sure to read and write the content of file using an appropriate charset, for example:
Files.readAllLines(myPath, StandardCharsets.UTF_8)
I'm writing an application that reads a text file containing a list of vocabulary words in both English and Chinese. These are then displayed in a JTable. When I run or debug the app in Eclipse, everything displays fine. I can see and read the characters and the English. However, when I execute the app from the command line or from an executable jar, it's all wrong. The characters show up as either squares or as gibberish.
I also have a text box that when I type Chinese into it, it displays correctly.
My first thought was that it was a font problem. I was using a font installed on my system. Since I can't guarantee that the person using this app will have that font, I moved it to a resource folder and load the font from a file. The font appears as though it's been loaded so I'm convinced it's not a font issue.
I found another question that suggested using -Dfile.encoding=utf-8. I've tried this and it did not work.
Would the brilliant folks at Stack Overflow have any advice on how to make this work?
I'm writing this on a non-chinese version of Windows.
Well then you won't ever be able to get a Java program to produce Chinese command-line output.
Java, like almost all languages, uses the C standard library which has byte-based IO. The Windows command prompt interprets byte-based IO using the locale-specific default code page. That's never a UTF, so Unicode characters outside of the current locale's default code page just won't work.
(In theory you should be able to get it to work by changing your console fonts and using chcp 65001 (UTF-8) together with -Dfile.encoding=UTF-8, but in practice it doesn't work reliably due to bugs in the C runtime. Unicode on the command prompt is a long-standing sore point.)
The unicode character from a rails app appears as ??? in the mysql database (ie when I view through putty or linux console), but my rails app reads it properly and shows as intended.I have another java application which reads from the rails database and stores the values in its own database. and try to show in from its database. But in the webpage, it appears like ??? instead of the unicode characters.
How is that the rails application is able to show it properly and not the java application. Do I need to specify any encoding within the java application?
You really need to find out whether it's the Java app that's wrong, the Rails app that's wrong, or both. Use PuTTY or a Linux console isn't a great way of checking this, as they may well not support the relevant Unicode characters. Ideally, you should find a GUI which you can connect to the database, and use that to check the values. Alternatively, find some MySQL functions which will return the Unicode code points directly.
It's quite possible that the Rails app is doing the wrong thing, but in a reversible way (possibly not always reversible - you may just be lucky at the moment). I've seen this before, where a developer has consistently used the same incorrect code page when both encoding and decoding text, and managed to get the right results out without actually storing the correct data. Obviously that screws up any other system trying to get at the same data.
You may want to check the connection parameters: http://dev.mysql.com/doc/refman/5.0/en/charset-connection.html
I guess your Java application may use wrong encoding when reading from rails' database, wrong encoding of its own database or in connection with it.
I need assistance finding a delivery method that best fulfills the following requirements:
We wish to deliver a single file to my clients.
Clients should be able to launch this file from the operating system shell - much like running an '.exe' on Windows.
After being launched, the program/script should be able to display a window with HTML content. this may be done using a stand alone program, a runtime or by running within a browser.
We need the ability to embed a resource within the delivered file, such as an mp3 file, which i can later extract programmatically.
Optimally, the solution should run on Windows, Mac and Linux machines. Less than perfect cross-platform interoperability is acceptable, but we want as broad a penetration as possible.
Clients should not need to pre-install anything (unless it is done transparently), pre-configure anything, or approve any thing for this to happen.
For example:
We could use a regular executable file, written in C++ to do this, but it will not be cross-platform.
We could use a sliverlight XAP file, an adobe Flex file or a Java JAR, but internet explorer warns users when local content is launched. In addition these approaches mean that we have less than perfect penetration, even though it is acceptable in these cases.
We could use a python (or equivalent) script, but the installed-base (penetration) of the python interpreter is not good enough.
Using a standard HTML is not enough because of the difficulty of embedding resources in it. Embedding Silverlight XAML or uuencoded content in HTML causes IE to display a warning.
Using something along the lines of a jpeg as a delivery method is not rich enough since we need to display HTML.
..but internet explorer warns users when local content is launched..
I don't get it, what's the problem with IE saying "Hey this app is trying to run your files!"
I don't mean you don't have a good reason for this, it is just, I don't get it.
IE will only warn the user if the app has not been downloaded and try to access local resources, for instance if running from an applet or a JNLP like this one:(click on the first orange button you see )
But if the users download the jar and run it from the computer ( double click on it ) the app is local and can run without problems.
The jar file is a zip file after all, so you can attach your mp3 file with it. Double click is supported in the desired platform, and the HTML content could be either a local file ( un-packed along with the mp3 file ) or an internet web page.
Java is preinstalled on those OS already.
"internet explorer warns users when local content is launched"
There's a reason for this. How can they distinguish your excellent, well-behaved, polite application from a virus?
Since the line between your app and a virus is very, very blurry, go with any of Silverlight XAP file, an adobe Flex file or a Java JAR.
The IE business is a good thing, not a bad thing.
You could try using the 'Jetty' application server.
This supposes there is a working java environment on the target machine.
Jetty is java servlet container but it is possible to configure
everything (web server, html templates, applications, etc.) in a
single executable jar, which launches the web server and opens a default page.
Exactly how the jar file is launched will vary from platform to platform
but otherwise the user interface will be identicle, and, as its a java application
you can do pretty much anything one it has started.
Sounds like MIME HTML does exactly what you want - unfortunately, it is not supported by many browsers other than IE.
I'd investigate Adobe AIR. It can display both HTML and Flex content in a desktop application without using a web browser. However this will require installation of the AIR runtime, also I'm not sure if the Linux version is out of the beta stage.
http://www.adobe.com/products/air/
You can also use a binary for each platform.
As per your description the app is very simple, and porting from one platf to another sounds like just matter of re-compile and offer binary based on the dist.
Is this an option?