So I am cloning some java files from git to eclipse. There are special characters like Ü è. letters you would see in the Spanish language that java normally does not like. When I open up the project in java it turns them into the square with the ? in the middle of it and java complains about it saying there is a special character problem. It wouldn't be that big of a problem but I'm doing it for work and there are A LOT of code and go through and a lot of special characters. Anything I can do about this to either make java like it or not change the characters when I go from git to eclipse?
(Assuming that when you say "I open up the project in java" you actually mean opening the project in Eclipse:)
You need to do two things: first figure out what the file encoding is, second change your settings so Eclipse would use that encoding. Figuring out the encoding can be troublesome. With a git remote repository on Unix the obvious guess would be UTF-8, with Windows UTF-16 would also come into my mind as a possibility. In worst case you can always open your file in a hex editor and check how are your special characters actually encoded. After that making Eclipse use that encoding is easy. (And you may consider changing it only for this special project of yours.)
Related
I have recently starting using the Java based language Processing.
I started off with using the standard processing editor that has been installed on my Windows machine, but didn't quite take to it. It's not very customizable and lacks things like highlighting variable and function names throughout the code.
So I decided to use Atom instead, and so far it's been great. Although with one problem:
I can't build sketches that have spaces in their directories.
If I want to build a sketch that has the path...
C:\Users\Sulu\Documents\Processing\Test Sketches\Test\test.pde
I get the message:
DPI detection failed, fallback to 96 dpi
C:\Users\Sulu\Documents\Processing\Test does not exist.
[Finished in 1.008s]
I'm sure this is down to the fact that there is a space in the path.
My question is this. Is there anyway that I can get Atom, or maybe it is the 'processing-java.exe' I need to modify, to ignore space names in the path?
To automatically add doublequotes?
I'd be really grateful to any help with this as I have a lot of sketches that have spaces in their path names and renaming them all would be tedious.
Thanks.
It is a part of Processing language, it is a rule, just like syntax which you have to follow and can't be modified, at least as far as I know.
This is what the official github wiki says -
Names of sketches cannot start with a number, or have spaces inside. This is mostly because of a restriction on the naming of Java classes. I suppose if lots of people find this upsetting, we could add some extra code to unhinge the resulting class name from the sketch name, but it adds complexity, and complexity == bugs. :)
So, I am afraid there is no solution to your problem other than renaming your sketches, at least not yet!
EDIT :
Seems like I misinterpreted the question a little bit, I would suppose your sketch works with processing editor but not in external editors because they use cli to compile your project, and the instructions do contain the file path, which can not have spaces when present in bash, if they do, they need to be enclosed within quotes or spaces need to be "escaped" with \, which is again, controlled by processing and I don't think you can somehow modify "processing" to add quotes to paths during "building" or escape spaces \ so the answer still remains the same.
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'm trying to use Chinese characters in Java GUI components. I have changed my keyboard output to Chinese and can type in Netbeans in Chinese. Further, I can compile these Java files. However, when I run these programs, the characters are displayed as English question marks. What can I do to change this?
First, you have to make sure that you are compiling with a suitable setting for the encoding option to javac.
Second, you have to be running with a suitable character encoding. In most cases, setting -Dfile.encoding=UTF8 will do it, but it also depends on what sort of program (command line? GUI?) and what environment you're running it in.
I don't think the shortest answer is best here so I recommend you read this excellent blog post on "The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)" by Joel Spolsky.
I think the couple minutes spent reading this will be more than worth it.
I have written an application which takes folder path and perform some operation. But if folder path contains characters of language other than English then it is not working. It only support English characters. How to handle this problem?
Theoretically it should work. Practically in most cases it is a problem of passing parameters from shell to java application. Try to verify that this works correctly: run application from command prompt exactly as you are doing but with remote debugging. Create breakpoint in your code where you are reading the parameter and see what is the value. I believe that the value is corrupted at this phase. This is a typical problem if you are on windows.
In this case you have to configure your system to support unicode characters in command prompt correctly.
If the path is read correctly from command line try to continue debugging and see where it is broken. Check which separator are you using. Avoid using both / and \, use File.separator instead.
I have a java application which has a GUI in both English and French, using the standard Java internationalisation services. I wrote it in JBuilder 2005 on an old machine, and recently upgraded, which has meant changing IDEs. I have finally settled on IntelliJ.
However, it doesn't seem able to handle the accented characters in my ListResourceBundle descendants which contain French. When I first created the IntelliJ project and added my source (which I did manually, to be sure nothing weird was going on behind the scenes), I noticed that all the accented characters had been changed into pairs of characters such as é. I went through the code and corrected all of these, and assumed that the problem was fixed.
But I find on running the (rebuilt) project that the pairs of characters are still showing, instead of the accented characters that I see in my code!
Can someone who has done internationalisation in IntelliJ please tell me what I need to do to fix this?
PS: I'm on the Mac.
Two things --
First, make sure your files are being stored as UTF, and that your source control supports the encoding.
Second, consider using the resource bundle editing support built into IntelliJ http://www.jetbrains.com/idea/features/i18n_support.html
Java resource bundles should only hold ascii and Unicode escape codes
see [http://java.sun.com/developer/technicalArticles/Intl/ResourceBundles/].
e.g. \u00d6ffnen for German Öffnen.
The command line tool native2ascii converts from your native format to ascii plus unicode escape codes. It is a bit of a hassle but not an Intellij but a Java problem.
Note: I use Intellij on a Mac to create programs localized in English, German and Japanese.