by gildas on 12/27/24, 11:10 PM with 37 comments
by Retr0id on 12/28/24, 12:28 AM
I looked into this in the past, it's because they check for a "PK" header at the start of the file - which is of course not actually required. I assumed it was deliberate because it does exclude most "weird" ZIPs.
By the way, if you're interested in this sort of file format wrangling, check out Ange Albertini's talk tomorrow at 38c3: https://fahrplan.events.ccc.de/congress/2024/fahrplan/talk/Q...
by gildas on 12/28/24, 1:13 AM
by zzo38computer on 12/28/24, 10:47 PM
The URL jar:https://raw.githubusercontent.com/gildas-lormeau/Polyglot-HT... can be used to display the HTML file in some web browsers, although it cannot display the PNG file in this way since it uses # as the URL of the picture.
by OkGoDoIt on 12/28/24, 1:18 AM
by Dwedit on 12/28/24, 1:52 AM
In the project there, correction data is used to recover bytes that have been changed into LF when they are actually CR or CRLF.
One idea is to store the correction data as binary, then read two bits every time you see a LF byte. It's either an actual LF, a CR, or a CRLF. The downside is that binary data itself could need correction as well, and encoding nearly 1-bit data in 2 bits is still wasteful (but simple). Packing five 3-state values into a byte is less wasteful and would eliminate forbidden symbols, but is still not optimal.
by porridgeraisin on 12/28/24, 6:32 AM
chromium --allow-access-from-files
by lifthrasiir on 12/28/24, 6:47 AM
This is not always the case if the encoded content happens to have `-->`, for example. A better approach would be the `<plaintext>` element which can never be closed.
by nhinck3 on 12/28/24, 6:42 AM
by EmileSonneveld on 12/28/24, 10:20 PM