Develop Reference

\n (new line) not working in creating text file

I want to download the text file by clicking on button, everything is working fine as expected. But the problem is the data I want to insert in text file is just one line.
String fileContent = "Simple Solution \nDownload Example 1";
here, \n is not working. It resulting in output as:
Simple Solution Download Example 1
Code snippets:
interface:
interface implementation in my service class:
controller:

Don't use hardcoded \n nor \r\n - line-separators are platform-specific (Windows differs to all other OS).
What you can do is:
Use System.lineSeparator()
Build content with String.format() and replace \n with %n

The main problem is that the server computer and client computer are basically independent with respect to character set encoding and line separators.
Defaults will not do.
As we are living in a Windows centric world (I am a linuxer), user "\r\n".
Then java can mix any Unicode script. A file does not have info on its encoding.
If it originates on an other computer/platform, that raises problems.
String fileContent = "Simple Solution façade, mañana, €\r\n"
+ "Download Обичам ĉĝĥĵŝŭ Example 1";
So the originating computer explicitly define the encoding. It should not do:
fileContent.getBytes(); // Default platform encoding Charset.defaultCharset().
So the originating computer can do:
fileContent.getBytes(StandardCharsets.UTF_8); // UTF-8, full Unicode.
fileContent.getBytes("Windows-1252); // MS Windows Latin 1, some ? failures.
The contentType can be set appropriately with "text/plain;charset=UTF-8" or for Windows-1252 "text/plain;charset=ISO-8859-1".
And from that byte[] you should take the .length for the contentLength.
Writing to the file can use Files.writeString
In that case use Files.size(exportedPath) for the content length.
Files.newInputStream(exportedPath) is the third goodie from Files.

decode "compiled Java class data, version 52.0" text from file

I have a file without extension but I used an online site to know the type of this file. It says the file contains "compiled Java class data, version 52.0".
The content of the file that I need to read here
 ˛∫æ4)

<init>()VCodeLineNumberTablemain([Ljava/lang/String;)V
StackMapTable
SourceFileHelloWorld.java
SYNT{SBERAFVPF_101} !"#$%&'(
HelloWorldjava/lang/Objectjava/lang/Stringlength()IcharAt(I)Cjava/lang/SystemoutLjava/io/PrintStream;java/io/PrintStreamprint(C)V!
*∑±
«rL=+∂¢g+∂>a°m£
`í>ß?A°M£
`í>ß*n°z£
dí>ßN°Z£ 
dí>≤∂Ñߡó±*
I just need to make this file readable and get the output from it
What is the encoding type used or is there any online site that can read it.

It's a compiled Java class, not some text with an encoding. Compiling means translating human readable text into instructions a PC can understand. So the file contains such CPU instructions similar to machine code, called "intermediate language" or "byte code".
Use java.exe to run it and see the output. Be aware that running a program of an unknown person is dangerous. It could delete files etc.
You can't get the source code back, but you can use a Java Decompiler to get close to the original.

The comment
SourceFileHelloWorld.java
suggests this is a Java "Hello, World!" program (e.g.). The long line in the middle
HelloWorldjava/lang/Objectjava/lang/Stringlength()IcharAt(I)Cjava/lang/SystemoutLjava/io/PrintStream;java/io/PrintStreamprint(C)V!
suggests the program prints "HelloWorld." That would be the output.

line breaker not working after exporting .txt file to sFTP server

I am exporting .txt file to sFTP server, when I am downloading file from sFTP server all text printed in single line means line breaker is not working, even I exported file to local folder line breaker was working perfect but from sFTP line breaker is not working.
Used System.lineSeparator() and \r\n, \r and also more examples but still file is customizing
I want file should be like below:
test|test|test|test
test|test|test|test
test|test|test|test
But it looks as below after download:
test|test|test|test test|test|test|test test|test|test|test test|test|test|test test|test|test|test
I am using Tomcat server and Java 8 in Linux environment.

you should try with :
public static String newline = System.getProperty("line.separator");
if it doesn't work its the "\" that might be the problem here you could try to double it
the first one to say that the second isn't a computer tag

There are line-breaks, however different operating systems recognise different sequences for line-breaks.
Notepad only recognises CR, LF (0x0d, 0x0a), whereas other sources might use CR only, or LF only.
You can't make Notepad behave differently, so your only option is to make sure the content has the right sequence for Notepad. Note that notepad is the only editor with this restriction, so if your content works in Notepad, it will work everywhere else.
One simple way to fix the line-feeds is to copy and paste the text into Word, then back again into notepad, and the line-feeds will get "corrected" to the CR,LF sequence.
Also you can use other text editors like notepad++, sublime, etc. For more information visit here

FTP is notorious in that a Windows line ending \r\n can be converted to a Unix line ending \n when the file in not transferred as binary data (as opposed to text).
On Windows a text file with \n will not be seen as line separator in simple text editors like Notepad.
Use an other editor like Notepad++ or JEdit.
So
On FTP use binary transfer
Use a programmer's editor
There also is a simple bug where lines are read, and text is composed of those lines, forgetting the dropped new lines:
StringBuilder fileContent = new StringBuilder();
BufferedReader in = new BufferedReader(...);
for (;;) {
String line = in.readLine(); // No line ending!
if (line == null) {
break;
}
fileContent.append(line); // Forgotten: `.append("\r\n")`
}
return fileContent.toString();
So
Check the reading code

Java saving a file with special characters in file name

I'm having a problem on Java file encoding.
I have a Java program will save a input stream as a file with a given file name, the code snippet is like:
File out = new File(strFileName);
Files.copy(inStream, out.toPath());
It works fine on Windows unless the file name contains some special characters like Ö, with these characters in the file name, the saved file will display a garbled file name on Windows.
I understand that by applying JVM option -Dfile.encoding=UTF-8 this issue can be fixed, but I would have a solution in my code rather than ask all my users to change their JVM options.
While debugging the program I can see the file name string always shows the correct character, so I guess the problem is not about internal encoding.
Could someone please explain what went wrong behind the scene? and is there a way to avoid this problem programmatically? I tried get the bytes from the string and change the encoding but it doesn't work.
Thanks.

Using the URLEncoder class would work:
String name = URLEncoder.encode("fileName#", "UTF-8");
File output = new File(name);

Failed to check if file with German name is exist in the file system

Background:
I have 2 machines: one is running German windows 7 and my PC running English(with Hebrew locale) windows 7.
In my Perl code I'm trying to check if the file that I got from the German machine exists on my machine.
The file name is ßßßzllpoöäüljiznppü.txt
Why is it failed when I do the following code:
use Encode;
use Encode::locale;
sub UTF8ToLocale
{
my $str = decode("utf8",$_[0]);
return encode(locale, $str);
}
if(!-e UTF8ToLocale($read_file))
{
print "failed to open the file";
}
else
{
print $read_file;
}
Same thing goes also when I'm trying to open the file:
open (wtFile, ">", UTF8ToLocale($read_file));
binmode wtFile;
shift #_;
print wtFile #_;
close wtFile;
The file name is converted from German to utf8 in my java application and this is passed to the perl script.
The perl script takes this file name and convert it from utf8 to the system locale, see UTF8ToLocale($read_file) function call, and I believe that is the problem.
Questions:
Can you please tell me what is the OS file system charset encoding?
When I create German file name in OS that the locale is Hebrew in which Charset is it saved?
How do I solve this problem?
Update:
Here is another code that I run with hard coded file name on my PC, the script file is utf8 encoded:
use Encode;
use Encode::locale;
my $string = encode("utf-16",decode("utf8","C:\\TestPerl\\ßßßzllpoöäüljiznppü.txt"));
if (-e $string)
{
print "exists\r\n";
}
else
{
print "not exists\r\n"
}
The output is "not exists".
I also tried different charsets: cp1252, cp850, utf-16le, nothing works.
If I'm changing the file name to English or Hebrew(my default locale) it works.
Any ideas?

Windows 7 uses UTF-16 internally [citation needed] (I don't remember the byte order). You don't need to convert file names because of that. However, if you transport the file via a FAT file system (eg an old USB stick) or other non Unicode aware file systems these benefits will get lost.
The locale setting you are talking about only affects the language of the user interface and the apparent folder names (Programme (x86) vs. Program Files (x86) with the latter being the real name in the file system).
The larger problem I can see is the internal encoding of the file contents that you want to transfer as some applications may default to different encodings depending on the locale. There is no solution to that except being explicit when the file is created. Sticking to UTF-8 is generally a good idea.
And why do you convert the file names with another tool? Any Unicode encoding should be sufficient for transfer.
Your script does not work because you reference an undefined global variable called $read_file. Assuming your second code block is not enclosed in any scope, especially not in a sub, then the #_ variable is not available. To get command line arguments you should consider using the #ARGV array. The logic ouf your script isn't clear anyway: You print error messages to STDOUT, not STDERR, you "decode" the file name and then print out the non-decoded string in your else-branch, you are paranoid about encodings (which is generally good) but you don't specify an encoding for your output stream etc.