We Keep Coding

.java file saved in eclipse is filled with null charcters

saved a .java file using eclipse and its filled with invalid characters and gibberish
at first I thought it was encoding wrong but I couldn't get it work no matter what I tried
this is the file when opened in notepad++ encoding using ANSI
PK :kךN summerWork/.classpath}Kֲ0„ֿ
‏‡’»[½ץ׀*"¬ ױ«₪ֹR£qSע‎ק>PAo3ֳ·ֻL:<utBכ”¡ץ¡ַ"$a₪¢:cכrׂM״p׀i§Bsחמw7׃z;$o/ׁA‘ּ˜0ִ¢{˜1ck#¡Uדצׂƒזִמצfֻ|;^וhZהֻר›Sהׁ׳ ±
חִֿwO,~®
ֵ‘ W*צ•ה‚,[—¯ lיֶאֵ³™Lzֻ¢²[י´#rיj%÷-רh¢]wחָ^ֹ)ֹ“p+|‘$… t&ּq!–ׂX0E{k„yCd¼ן
¢5C±צ¨8L¢:…ן‚׳Mצשָןק^ׂ—$ר״ֱI`/ 0¥…·ןֶבֶ½7XˆFׁT‡³-«at¡ׂדֿן/¯gg׳׃׃ֵס¯}ו¿y¼$װכ{€•נ?`jװ¬~zִא־$:לת־טOH€$3Y²ׁjשֲPK$›?H ר PK :kךNhJ¹ - summerWork/.classpathPK :kךNB ¨%ְ ‚   summerWork/.projectPK :kךNֻץb¾ V / ‎ summerWork/.settings/org.eclipse.jdt.core.prefsPK qODPH ¼ & summerWork/bin/summerWork/myOval.classPK –OֻZ
ָ ÷ ) ´ summerWork/bin/summerWork/myPicture.classPK qOPגּ₪ז % ׃ summerWork/src/summerWork/myOval.javaPK –O$›?H ר (  summerWork/src/summerWork/myPicture.javaPK 5 ×
never encountered this before and was wondering if there was a way to fix it because it would be really inconvenient to redo this.

PK at the start of the file, together with recognizable file names showing in between gibberish, is a good indication that you're actually looking at a zip archive.
Try renaming the file to something.zip and attempt to look at it with your favorite way to unpack zip files.

Java Ilegal character in path at index 2

I am getting this error:
Caused by: java.net.URISyntaxException: Illegal character in opaque part at index 2: C:\Users\Emre\Desktop\PN1g1z.gif
And I really don't get what's wrong.
This is what throws the exception:
Media media = new Media(file.getAbsolutePath());

Media expects an URI as String in the constructor. So, instead of using File#getAbsolutePath(), you should be using File#toURI() instead.
https://docs.oracle.com/javase/7/docs/api/java/io/File.html#toURI%28%29
From the Media#new JavaDoc (thanks #Andreas):
source - The URI of the source media.

Actually, it's a big problem where you put your server.
I already faced this problem before. I used Geronimo with the space in my direction D:\Common DevTool\Geronimo.
You have two ways to resolve:
Change to D:\Tool\Geronimo. It ran well.
Your directory is not correct: C:/Program Files. You should move your server to another place without the space in the name.
Upgrade the JSF version.

I had a similar problem but another exception: java.lang.IllegalArgumentException: Illegal character in opaque part at index 2: C:\Users\MyUser\project\src\main\packagex\file.csv
The project was created using java not by me. It tried to read a csv file. It worked ok on linux but crashed on windows 10.
My solution was change the absolute path to relative and switch reverse slash to "normal" slash. The url finally worked with this:
src/main/packagex/file.csv
It seems colon and reverse slash triggered the exception. That is the reason exception indicates index 2 because colon is located in second position at url
Illegal character in opaque part at index 2: C:\Users\MyUser...
Reference:
https://background.sysfactory.online/index.php/2022/09/23/solucion-java-lang-illegalargumentexception-illegal-character-in-opaque-part-at-index-2-cusersmyuser/

Both mkdir(0 from File and forceMkdir() from FileUtils fail to create a folder that its name contains unicode characters. Any idea?

I want to create a folder, which has a unicode character in its name, using Java within a Matlab code. I tried both mkdir() of java.io.File and forceMKdir() of org.apache.commons.io.FileUtils. However, the unicode character is replaced with two characters, which are its UTF-8 representation, when the folder is created. Any idea? A sample code is below.
feature('DefaultCharacterSet', 'UTF-8')
u0_filename = 'é'
curre_output_dir = java.lang.String(root_meddir).concat(java.lang.String(relative_output_meddir).concat(u0_filename).concat(java.lang.String(prior.slash_symbol)))
test_dir1 = java.io.File(curre_output_dir)
With mkdir():
test_dir1.mkdir()
with mkdirs():
test_dir1.mkdirs()
with forceMkdir():
javaMethod('forceMkdir', 'org.apache.commons.io.FileUtils', test_dir1)
But, all create a folder with the name 'é', which is incorrect. The file system is Ubuntu.
Thanks.
EDIT:
To use the Files.createDirectory(), as suggested by fge, I followed this steps:
Set the variable MATLAB_JAVA to the path to Java 7 JRE:
$ export MATLAB_JAVA=/usr/lib/jvm/java-7/jre/
Start Matlab, and check the Java version:
>> version -java
Java 1.7.0_55-b13 with Java HotSpot(TM) 64-Bit Server VM mixed mode
However, the methods do not seem to properly work:
>> java.nio.file.Files.createDirectory('test')
No method 'createDirectory' with matching signature found for class 'java.nio.file.Files'.

So I am answering the edit from May 9.
The reason why the code does not work at that point is because the wrong signature is being provided as the error message says. You are passing a String to the method when it requires a Path object.
Now, this tutorial illustrates three different ways of creating a Path object. I will summarize because we hate links.
Path path = FileSystems.getDefault().getPath("test"); seems to do what you wish.
Path path = Paths.get("test"); which also would work in your case as it is a shortcut for the item #1.
File f = new File("test");Path path = f.toPath();

How to break up long continuous lines in log by inserting line breaks on Solaris 10

I need your assistance to chop a single continuous line from a log file of HL7 messages, into individual lines such as the following in using Unix commands / Java or Both:
Timestamp : 20130221 001805
Code : OUT031
Severity : F
Component : cmHL7OutboundBuild_jcdOutboundBuild1/cmHL7OutboundBuild/dpPRODHL7Outbound
Description : Last HL7 Message read <MSH|^~\&|target application|hostname|source application|A212|201302210016||ORM^O01|62877102|D|2.2|||ER
PID||.|0625176^^^00040||JOHN^SMITH^ ||19390112|F||4|address||^^^^^^93271081||||||41253603422
PV1|1||ED^^^40||||||name of physician||||||||physician operator id
ORC|SC||13-4529701-TFT-0|13-4529701|P|||||||name of physician
OBR|1||13-4529701-TFT-0|0360000^THYROID FUNCTION TESTS^1||201302212108|201302212102|||||||201302212108||name of physician||.|||13-4529701|201302210016||department|P||^^^201302212108
> Exception:com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Cannot add or update a child row: a foreign key constraint fails (`schema/table`, CONSTRAINT `table_ibfk_request_order_panel` FOREIGN KEY (`fk_gp_latest_request_order_panel`) REFERENCES `gp_request_order_panel` (`gp_request_order_panel_seq`))
SendEmail : Y
The issue is that all 11 lines are wrapped around in one continuous line which made up a single record, followed by the next record of another 11 lines and so on Solaris 10 Unix server. Yet
the same log would display properly when ftped over to a desktop Windows side. As a result, I am looking for a solution, possibly a combination of Unix & Java to break down each record of
11 lines on their own and the same thing for the next record....
Below is a break down on what I believe need to be done on the Solaris 10 server:
( i ) Would be great if this log could be converted to Windows ASCII format but staying on the Solaris 10 server, like the one being ftped to Windows. When the same file is ftped from
Windows back to Solaris 10 server, it reverted back to its original 1 continuous line format.
( ii ) Otherwise, break it down line by line or insert and end of line but where to?
I have tried various Unix string manipulated commands such as sed, awk, grep, fold, cut, unix2dos including from
Bash: how to find and break up long lines by inserting continuation character and newline? without success.
Your assistance would be much appreciated.
Thanks,
Jack

This is a windows text file (windows carriage control) since it displays ok in Windows but not UNIX.
Solaris has a dos2unix command to handle this issue.
dos2unix filename > newfilename
Try that. To see what I mean use the vi editor on "filename" in the example above. You will see ^M characters in the file. UNIX does not use those for formatting lines.
If you have the vim editor it will read "long lines". Or try od -c < filename | more to see the ^M or ascii 13 characters. od will show them as \r I'm reasonably sure the issue is that the carriage control on the file prevents UNIX from seeing the lines. Try the od approach.

How do I correctly set the HTTP Content-Disposition for large file names in Java?

I'm working on some requirements that will lead to arbitrary PDF files being downloaded from a J2EE web server. The names may look like this:
Xxxxxxxxxxxxxxxxxx - Yyyyyyyyyy - Aaaaaaaaaaa - Bbbbbbbb ccc Dddddddddddddd - abc1234560 - 2009-03-26 – 235959.pdf
Now I've read a couple of sections in RFC2183:
http://www.ietf.org/rfc/rfc2183.txt
For instance
A short (length <= 78 characters) parameter value containing
only non-tspecials' characters SHOULD be represented as a single
token'. A short parameter value containing only ASCII characters,
but including tspecials' characters, SHOULD be represented as
quoted-string'. Parameter values longer than 78 characters, or
which contain non-ASCII characters, MUST be encoded as specified in
[RFC 2184].
Etc etc. Now there are millions of things that can go wrong, if I don't read through all of those RFC's... Or I choose a library which handles such RFC specifications. Is there any such thing for Java? Or am I paranoid, and actually it's sufficient to just write this header to the out stream:
String filename = "\"" + filename.replace("\"", "\\\"") + "\"";
addHeader("Content-Disposition", "attachment; filename=" + filename);

I had similar problem in past and found the following solution.
The first URL looks like http://myhost.com/file/1234
where 1234 is the file ID. Let's say that the file name should be my-very-long-file-name.pdf. So, instead of setting HTTP header redirect the call to URL like
http://myhost.com/download/1234/my-very-long-file-name.pdf
The sevlet mapped to /download/ will take ID from URL and print the file to its output stream. But browser will extract the file name from URL and offer you to download and save the file because its name is into the URL. I hope this will work for you also for long file names.

RFC 2183 isn't relevant, RFC 6266 is.
Also, the 78 character limit only applies to email, not http, so you don't have to worry about that.