We Keep Coding

Java - working with different cmd charsets

I want to read a file path from the user in java console application,
some of the file path may contain some Hebrew characters.
how can i read the input from the command line when i don't know the encoding charset?
I have been spending some time on the web and didn't succeed to find any relevant solution that will be dynamic for every platform.
*
Screen shot when running in console

If you are using windows you need to check the terminal encoding before to make sure that its encoding supports hebrew.
To do this just type chcp in the console
as output you should see chcp 28598
if you see diffrent number type chcp 28598
Now your console encoding is set to hebrew and you should be able to write the path in hebrew without getting any exception.

rendering the US unit separator on unix machine

I have a java application that feeds a file on a unix machine, each string contains multiple US unit separators,
Locally, when i run it on eclipse on a windows machine, it displays fine on the console:
1▼somedata▼somedata▼0▼635064▼0▼somedata▼6
But when i run the program from the unix machine, the content of the file appears as.
1â¼N/Aâ¼somedataoâ¼somedataâ¼somedata
Changing the LANG variable to any value in locale -a seems not to work.

looks like character set mismatch. On linux you most probably have UTF-8. With Java you usually get UTF-16. Try converting from UTF16 to UTF8 with iconv and see how it looks like on linux.
cat file | iconv -f UTF-16 -t UTF-8
But actually it would have been much worse if it was UTF-16. Maybe it is simply a font mismatch. But you can play with character encoding (see what source is and convert to utf-8) if that's the issue. Or maybe your source is UTF-8 and destination - some local encoding.
This makes sense because your special character appears as 2 characters in the UNIX machine. Which means source is pretty much likely UTF-8 and UNIX is using an encoding where each byte is a single character.

Junk character output even after encoding

So, I have basically been trying to use Spanish Characters in my program, but wherever I used them, Java would print out '?'.
I am using Slackware, and executing my code there.
I updated lang.sh, and added: export JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8
After this when I tried printing, it did not print the question marks, but other junk characters. I printed the default Charset on screen, and it has been successfully set, but it is not printing properly.
Help?
Thanks!
EDIT: I'm writing code in windows on NetBeans, and executing .class or .jar on slackware.
Further, I cannot seem to execute locale command. I get error "bash: locale: command not found".
This is what confuses me: When I echo any special characters on Slackware console, they are displayed perfectly, but when I run a java program that simply prints it's command line arguments (and I enter the special characters as Command Line input), it outputs garbage.

If you are using an ssh client such as PuTTY, check that it is using a UTF-8 charset as well.

invalid Xsl format (or) file name

what i wanted to do is to get all the installed applications in a computer and ihave decided to use the /output command of the command prompt using java. my code was working properly with this line of code in my computer:
Process proc = rt.exec("wmic /output:C:\\Users\\Public\\Documents\\list.csv product get name,version /format:csv ");
however, when i try to run the program in another computer, i encounter the "Invalid XSL format or file name" error. I tried reading other problems and i added this line of code before the code above:
proc2 = rt.exec("xcopy /y C:\\Windows\\System32\\wbem\\en-US\\*.xsl C:\\Windows\\System32\\");
but still nothing happened. the error is still there. anyone who can help me with this problem?

This is a bug in Windows 7 WMIC. When you use (for example) Dutch regional settings in an English Windows installation, WMIC searches for the xsl files inside C:\Windows\System32\wbem\nl-NL, instead of C:\Windows\System32\wbem\en-US where they are.
Workarounds:
Copy or move the C:\Windows\system32\wbem\en-US\*.xsl files up into the C:\Windows\system32\wbem\ folder.
Change your regional settings to match your Windows language version, log out and back in.
Specify the full path: WMIC process get /format:"%WINDIR%\System32\wbem\en-US\csv".

Special Characters [^M] appearing at the end of line in file if seen on unix but not when seen in eclipse

As described in questions, if I see a file in unix then I see special characters in it like ^M at the end of every line but if I see same file in eclipse than I do not see that special characters.
How can I remove those characters in the file, if am using eclipse for editing the file, do we have to make any specific changes in the eclipse preferences for the same ?
Any guidance would be highly appreciated.
Update:
Yes indeed it was carriage issue and following command helped me to get it sort out:
dos2unix file1.sh>file2.sh and file2.sh will be the file and it will not have any carriage values.
Possibly we can get warning like
could not open /dev/kbd to get keyboard type US keyboard assumed
could not get keyboard type US keyboard assumed but following command will suppress the warnings:
dos2unix -437 file1.txt>file2.txt

You have saved your text file as a DOS/Windows text file. Some Unix text editors do not interpret correctly DOS/Windows newline convention by default. To convert from Windows to Unix, you can use dos2unix, a command-line utility that does exactly that. If you do not have that available in your system, you can try with tr, which is more standard, using the following invocation:
tr -d '\r' < input.file > output.file

They are probably Windows carriage return characters. In Windows, lines are terminated with a carriage-return character followed by an end-of-line character. On Unix, only end-of-line characters are normally used, therefore many programs display the carriage return as a ^M.
You can get rid of them by running dos2unix on the files. You should also change your Eclipse preferences to save files with Unix end of lines.

Perhape this has suppressed UNIX warning message and worked creating the output file:
$ dos2unix -437 file.txt > file2.txt

You can remove those using dos2unix utility on a linux or unix machine. The syntax is like this dos2unix filename.

This are windows new line chars. You can follow steps shown in this post to have correct this issue.