Jump to content




Compression/Decompression not working for 1 file whilst working for others


  • You cannot reply to this topic
7 replies to this topic

#1 eniallator

  • Members
  • 56 posts

Posted 29 July 2016 - 04:53 AM

Hi, I recently started trying to compress/decompress various files and i've run into a bug. I've tried the functionality with massive files and also smaller files and it works 100% (i've stored the contents of the before and after if the file in variables and compared with a originalFile == fileAfterCompression and it's returned true). I've been trying to go through the code to see for myself if i could find it, but with no luck.

compression program:
Spoiler

original file that broke it:
Spoiler

compressed/decompressed version of the file:
Spoiler

I hope you guys can help because i'm completely lost about how it's breaking :(

#2 valithor

  • Members
  • 1,053 posts

Posted 29 July 2016 - 01:29 PM

I didn't find the error in your code, but I found the difference between the two files. Let's say you have the original file named original, and the compressed/decompressed version named decompressed. You can get the original back by doing this:
local original --# equals the original file that you posted
local decompressed --# equals the decompressed file that you posted
local fixed = decompressed:gsub(string.char(10),string.char(13)..string.char(10))
print(fixed==original) --# prints true
Sense you know the code, this might help you find the bug. :P

Edited by valithor, 29 July 2016 - 01:37 PM.


#3 eniallator

  • Members
  • 56 posts

Posted 30 July 2016 - 01:02 PM

View Postvalithor, on 29 July 2016 - 01:29 PM, said:

I didn't find the error in your code, but I found the difference between the two files. Let's say you have the original file named original, and the compressed/decompressed version named decompressed. You can get the original back by doing this:
local original --# equals the original file that you posted
local decompressed --# equals the decompressed file that you posted
local fixed = decompressed:gsub(string.char(10),string.char(13)..string.char(10))
print(fixed==original) --# prints true
Sense you know the code, this might help you find the bug. :P
it didn't seem to do anything, im not sure what you mean :P

#4 valithor

  • Members
  • 1,053 posts

Posted 30 July 2016 - 05:33 PM

View Posteniallator, on 30 July 2016 - 01:02 PM, said:

View Postvalithor, on 29 July 2016 - 01:29 PM, said:

I didn't find the error in your code, but I found the difference between the two files. Let's say you have the original file named original, and the compressed/decompressed version named decompressed. You can get the original back by doing this:
local original --# equals the original file that you posted
local decompressed --# equals the decompressed file that you posted
local fixed = decompressed:gsub(string.char(10),string.char(13)..string.char(10))
print(fixed==original) --# prints true
Sense you know the code, this might help you find the bug. :P
it didn't seem to do anything, im not sure what you mean :P

In my test the only difference between the two files, was the original had the character 13 before every newline char, while the compressed and decompressed one did not. After I added them back in, they were the same string.

Do keep in mind the code I posted is not runnable. The original variable needs to contains the file contents of the original file, and the decompressed variable needs to contain the file contents of the file that was compressed and decompressed. You would have to set those yourself.

#5 Emma

  • Members
  • 216 posts
  • Locationtmpim

Posted 30 July 2016 - 07:07 PM

View Postvalithor, on 30 July 2016 - 05:33 PM, said:

was the original had the character 13 before every newline char
The reason character 13 was before every newline was probably because the file was created in a windows environment, as windows editors (like notepad and such) end lines with carriage-return>linefeed (\r\n where \r == char 13), whereas pretty much everything else uses just linefeed (\n). This is (most likely) also the reason why cc converts 13 to 10, because 10 is linefeed, and cc is trying to normalize the endings to linefeeds only.

#6 eniallator

  • Members
  • 56 posts

Posted 30 July 2016 - 11:23 PM

View Postvalithor, on 30 July 2016 - 05:33 PM, said:

In my test the only difference between the two files, was the original had the character 13 before every newline char, while the compressed and decompressed one did not. After I added them back in, they were the same string.

Do keep in mind the code I posted is not runnable. The original variable needs to contains the file contents of the original file, and the decompressed variable needs to contain the file contents of the file that was compressed and decompressed. You would have to set those yourself.

but like, if you look at the body of the compressed/decompressed file, theres a massive difference because something in the algorithm stuffed up which is why i made a thread here. like if you just look at the entire compressed/decompressed file, you will see that its not just the newlines but the actual text itself.

Edited by eniallator, 30 July 2016 - 11:24 PM.


#7 valithor

  • Members
  • 1,053 posts

Posted 31 July 2016 - 02:12 AM

View Posteniallator, on 30 July 2016 - 11:23 PM, said:

View Postvalithor, on 30 July 2016 - 05:33 PM, said:

In my test the only difference between the two files, was the original had the character 13 before every newline char, while the compressed and decompressed one did not. After I added them back in, they were the same string.

Do keep in mind the code I posted is not runnable. The original variable needs to contains the file contents of the original file, and the decompressed variable needs to contain the file contents of the file that was compressed and decompressed. You would have to set those yourself.

but like, if you look at the body of the compressed/decompressed file, theres a massive difference because something in the algorithm stuffed up which is why i made a thread here. like if you just look at the entire compressed/decompressed file, you will see that its not just the newlines but the actual text itself.

Very well... I will go redo my test. If I get the same result I can not help you. In my original test, the file (the one posted in the op) that I compressed and then decompressed after doing the gsub was the exact same as the original one. This, to me at least, means that any formatting errors was in some way caused by the missing characters. I will edit this post when I have done the test.

edit:

I see what happened now. I compressed and decompressed the file, and it did not have the same results as when you did it (I should have checked to make sure I got the same results before I posted the first time). I got a file that looked the same (although it was missing those characters). So... Either there is a difference between the file you posted and the one you tried to compress, a different version of the program was used, or there is something with the environment you tried to compress it in that caused it to act up. This could have been caused by you using a emulator (I tested in game), or some other thing that had been done to the computer prior to compressing/decompressing.

Another thing is I could be using the program in a way that is different from how it is supposed to be used. Is this the correct usage:

Program is named compress.

compress com file1 file2
compress decom file2 file3

After running the program with the following two arguments file1 and file3 should be the same (relatively).

Edited by valithor, 31 July 2016 - 02:41 AM.


#8 eniallator

  • Members
  • 56 posts

Posted 01 August 2016 - 06:32 AM

View Postvalithor, on 31 July 2016 - 02:12 AM, said:

Very well... I will go redo my test. If I get the same result I can not help you. In my original test, the file (the one posted in the op) that I compressed and then decompressed after doing the gsub was the exact same as the original one. This, to me at least, means that any formatting errors was in some way caused by the missing characters. I will edit this post when I have done the test.

edit:

I see what happened now. I compressed and decompressed the file, and it did not have the same results as when you did it (I should have checked to make sure I got the same results before I posted the first time). I got a file that looked the same (although it was missing those characters). So... Either there is a difference between the file you posted and the one you tried to compress, a different version of the program was used, or there is something with the environment you tried to compress it in that caused it to act up. This could have been caused by you using a emulator (I tested in game), or some other thing that had been done to the computer prior to compressing/decompressing.

Another thing is I could be using the program in a way that is different from how it is supposed to be used. Is this the correct usage:

Program is named compress.

compress com file1 file2
compress decom file2 file3

After running the program with the following two arguments file1 and file3 should be the same (relatively).

Hmmm that is odd. The CC version i am using is 1.79 for minecraft version 1.8.9 (not on an emulator). Now im just even more confused >.<





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users