Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
So I am having problems reading from a serialized file.
More specifically, I have serialized an object to a file written in a hexadecimal format. The problem occurs when I want to read one line at a time from this file. For example, the file can look like this:
aced 0005 7372 0005 5465 7374 41f2 13c1
215c 9734 6b02 0000 7870
However, the code underneath reads the whole file (instead of just the first line). Also, it automatically converts the hexadecimal data into something more readable: ¬ísrTestAòÁ
....
try (BufferedReader file = new BufferedReader(new FileReader(fileName))) {
read(file);
} catch ...
....
public static void read(BufferedReader in) throws IOException{
String line = in.readLine();
System.out.println(line); // PROBLEM: This prints every line
}
}
This code works perfectly fine if I have a normal text file with some random words, it only prints the first line. My guess is the problems lies in the serialization format. I read somewhere (probably the API) that the file is supposed to be in binary (even though my file is in hexadecimal??).
What should I do to be able to read one line at a time from this file?
EDIT: I have gotten quite a few of answers, which I am thankful for. I never wanted to deserialize the object - only be able to read every hexadecimal line (one at a time) so I could analyze the serialized object. I am sorry if the question was unclear.
Now I have realized that the file is actually not written in hexadecimal but in binary. Further, it is not even devided into lines. The problem I am facing now is to read every byte and convert it into hexadecimal. Basically, I want the data to look like the hexadecimal data above.
UPDATE:
immibis comments helped me solve this.
"Use FileInputStream (or a BufferedInputStream wrapping one) and call read() repeatedly - each call returns one byte (from 0 to 255) or -1 if there are no more bytes in the file. This is the simplest, but not the most efficient, way (reading an array is usually faster)"
The file does not contain hexadecimal text and is not separated into lines.
Whatever program you are using to edit the file is "helpfully" converting it into hexadecimal for you, since it would be gibberish if displayed directly.
If you are writing the file using ObjectOutputStream and FileOutputStream, then you need to read it using ObjectInputStream and FileInputStream.
Your question doesn't make any sense. Serialized data is binary. It doesn't contain lines. You can't read lines from it. You should either read bytes, with an InputStream, or objects, with an ObjectInputStream.
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 months ago.
Improve this question
I'm using a specific library (unfortunately can't be avoided) that writes some information from a class to a file using a utility function that receives a DataOutputStream as the input.
I would like to get the resulting file's content as a String without actually creating a file and writing into it as the writing can be pretty "taxing" (1000+ lines).
Is this possible to do by using a dummy DataOutputStream or some other method and without resorting to creating a temporary file and reading the result from there?
P.S: the final method that actually writes to the DataOutputStream changes from time to time so I would prefer not actually copy-paste it and redo it every time.
As java.io.DataOutputStream wraps around just any other java.io.OutputStream (you have to specify an instance in the constructor) I would recommend that you use a java.io.ByteArrayOutputStream to collect the data in-memory and get the String of that later with the .toString() method.
Example:
ByteArrayOutputStream inMemoryOutput = new ByteArrayOutputStream();
DataOutputStream dataOutputStream = new DataOutputStream(inMemoryOutput);
// use dataOutputStream here as intended
// and then get the String data
System.out.println(inMemoryOutput.toString());
If the encoding of the collected bytes does not match the system default encoding, you might have to specify a Charset as parameter of the toString.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 3 years ago.
Improve this question
I am coding an Huffman compression algorithm for an assignement.
I got everything working except the conversion of binary to bytes and back again on the decompression.
When I compress, I append all my codes in order to get a string like this for example: "01001100 10000000"
Now I want this in a byte array: {76, -128} with Byte.parseByte("01001100", 2).
I end up with a text file coded in ANSI with L€
The problem is on the decompression when I have the text file above s.getBytes("Cp1252").
I get the byte array {76, 63}, therefore I am unable to retrieve the binary code 10000000 required to decode my compression.
I expect to get {76, -128} so I can convert it into binary and replace it with the original message.
To convert a String str1 to byte[]:
byte[] bytes = str1.getBytes(StandardCharsets.ISO_8859_1);
To convert bytes back to a String:
String str2 = new String(bytes, StandardCharsets.ISO_8859_1);
Instead of StandardCharsets.ISO_8859_1 you can also use another encoding or (as you did) use a charset name (String).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
This is the steps im supposed to go through. I tried writing the files but i think its wrong.
Creates 10 binary files in a folder called “binaryfiles”. The files must be named “temp0.dat”, “temp1.dat”, etc. to “temp9.dat”.
In each file, write 20 random doubles between 0 and 500. Inclusivity doesn’t matter.
Once the files are written, open each one in sequence from “temp0.dat” to “temp9.dat” and read them one character at a time. As you read the files, print the characters to the output window. Most of the characters will look like Chinese characters.
public class Homework7 {
public static void main(String[] args) throws IOException {
File file = new File("binaryfiles");
file.listFiles();
System.out.println("We have a file" + file);
System.out.println("Does it exist" + file.exists());
System.out.println("?" + file.isDirectory());
Random random = new Random(20);
random.setSeed(500);
double num = random.nextDouble();
OutputStream outStream = new FileOutputStream(file);
outStream.write((int) num);
outStream.close();
}
All files are binary at the lowest level (we talk about different types of files because we choose to interpret the bytes as something else on a higher level) and you create one using an OutputStream and then you write to it either using the stream directly or by using something that writes to the stream for you.
I'm not going to solve this for you since it sounds like a learning assignment, so instead I suggest you look closer at FileOutputStream and DataOutputStream.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
We added a new feature in our web application that has the the following code, basically decompressing the inputstream and creating a new String with UTF-8 encoding
....
// is is an instance of java.util.zip.GZIPInputStream
byte[] payloadBuf = org.apache.commons.compress.utils.IOUtils.toByteArray(is);
String plainPayload = new String(payloadBuf, CharEncoding.UTF_8);
...
when we run an intensive load test that triggers this path many times, we see an abnormal increase of not-heap memory in JVM. Can anyone give some hint on interpreting this? And even better, is there a way to avoid it somehow? Thanks a lot
There is nothing abnormal about your results:
If you call this code in a tight loop you are creating lots and lots of short lived objects. 3 byte[] instances ( all Objects ) as well as a ByteArrayStream for every call! And for no reason apparently.
So you are creating and copying a bunch of byte[] instances around and then the String constructor creates at least one more byte[] and copies that as well, all for nothing.
Are not accomplishing what you think you are doing:
You are not creating a new String with UTF-8 encoding, you are creating a new String which is interpreting the byte[] as UTF-8.
Java stores all String objects in memory as UTF-16, so you are not creating a new String with UTF-8 encoding.
Solution:
You should just read the file into a String to begin with and be done with it, you are creating this intermediate byte[] for nothing!
Here is a couple of examples using Guava:
final String text = CharStreams.toString(new InputStreamReader(is,Charsets.UTF_8));
or
final ByteSource source ...
final String text = source.asCharSource(Charsets.UTF_8).read();
Opinion:
That org.apache.commmons stuff is crap with all the cancerous dependencies and it is not doing anything special to begin with and still makes you deal with a checked exception on top of it all!
165 public static byte[] toByteArray(final InputStream input) throws IOException {
166 final ByteArrayOutputStream output = new ByteArrayOutputStream();
167 copy(input, output);
168 return output.toByteArray();
169 }
If you follow the rabbit hole you will find out that one call to .toByteArray() creates at least 3 instances of byte[] objects, a couple of ByteArrayStream objects that all end up as garbage just to get to String.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
i have a text file which contains 100000 line as below
be3c152f6f6bcd5 AL9 60 51.7458349055774 -0.191050898942398 F
be3c15cd5 AL9 30 51.79055774 -0.191050898942398 M
now i have to create a design where i need to read all this and based on test condition
needs to generate the output in same file format which i read
i was thinking this to implement by
reading all lines of input file
keeping them in List<some pojo>
now this pojo will have reference to all condition and generate the o\p
my question is loop readline 1 l00000 times and generate the pojo is good or not ?Also in the final o\p folder for each test case condition i have to convert this List<pojo to text format as above what we read.
please let me know some better way.
Read line, process line, write line. No need to keep them all in memory.
It's a simple problem for parsing records.
You don't want each line in a List; you want the POJO containing the data after you tokenize each line.
Here's pseudo-code:
Open file
Loop over all lines in file
Tokenize each line and populate POJO
Add POJO to List
Close file
Perform any operations you wish on POJOs
Output POJO List in desired format
If it's just tab delimited, perhaps you can use a library that already deals with .csv files.
I assume, the test conditions only depend on one line at a time:
You should stream the data both in and out.
After processing the first line - which consists of reading and parsing - check the conditions. If the line should be kept in the output, you can now stream it to the (different) output file. If it should be deleted, you can just ignore it and skip to the next line of the input.
It sounds like a good idea to create an Element which has the different columns of the file as fields. You could then overwrite to String to generate the desired output and a Constructor which takes the String in the input Format to parse it.