jszip
jszip copied to clipboard
Stuk
How do I do....ANYTHING?
Seems like a promising little library, if not for the fact that the documentation is far from adequate.
I read the documentation on how to use it, then how to read files, nothing but errors. the jsziputils referenced by the file reading tutorial apparently doesn't exist. alright... the only error message jszip is even giving me is 'Error: Can't find end of central directory : is this a zip file ? If it is, see http://stuk.github.io/jszip/documentation/howto/read_zip.html' Basically, useless.
I tried using an XHR to load the zip file, ofc this isn't logging/throwing ANYTHING, so I have no way to know IF it's even loading the file or not, and I give up trying. I've already made a complete shambles of the code in this application I'm trying to make trying to figure this all out.
Documentation needs some serious work, clearly explaining the tiniest little details, because in its present form, it's explaining a whole lot of nothing.
I've already confirmed this library is exactly what I need, but to be blunt, the documentation is FAR beyond anyone actually being able to understand it. It's unclear and assumes far too much about what the user knows or can figure-out. I'm stuck, and I've now wasted about an hour on trying to decompress zip files that could've been spent working on dealing with the internal file formats, instead....
PLEASE fix the documentation!
@Brian151 jsziputils refers to https://github.com/Stuk/jszip-utils The documentation is woefully inadequate though :/
The error sounds like an XHR issue. Can you confirm that the data on the client is the same as the original file?
alright... yeah, might want to work on that I only need jszip and jszip-utils to read a file, right?
I can't confirm/deny the XHR even is loading the file... /: and since the only server i have access to is public, and I'm not ready to release the tool/lib I'm making, i can't do online testing. (but some idiot thought it was ok to make this mandatory and sabotage local web pages/apps and their creators as much as humanly possible... >.>)
I'll check this out later, have some chores to deal with Thanks for not just simply closing my issue! (:
Thanks for the feedback. Writing documentation is not easy and it seems I failed to put myself in someone else shoes.
nothing but errors
Are the examples broken / out of date ?
the jsziputils referenced by the file reading tutorial apparently doesn't exist
As @ragingpatatot said, JSZipUtils comes from https://github.com/stuk/jszip-utils. I'll add more references to it.
the only error message jszip is even giving me is 'Error: Can't find end of central directory : is this a zip file ? If it is, see http://stuk.github.io/jszip/documentation/howto/read_zip.html' Basically, useless.
In this case, I think your XHR call tried to decode the content from UTF8 which corrupted it. Here, JSZip only see garbled data. Sending the user to a page explaining (or trying to explain) what happens looks like the best thing to do. How could this be improved ? A better error message ? A better landing page ? Both ?
ofc this isn't logging/throwing ANYTHING
The "logging" part is clearly missing. The "throwing" part exists, but propagates errors in the promises (And yes, this need to be outlined in the documentation).
It's unclear and assumes far too much about what the user knows or can figure-out
What would be a "getting started" page is currently light on some aspects like the promises, binary content in XHR, etc. We could revamp this page into a proper "getting started" page, adding more details on the small things and/or moving some parts elsewhere. Do you have other/better ideas ?
The documentation is woefully inadequate though :/
@ragingpatatot I'll gladly take your input too :)
I only need jszip and jszip-utils to read a file, right?
Yes: jszip-utils to download a zip file and jszip to parse it. Let me quote our wonderful documentation (cough cough):
new JSZip.external.Promise(function (resolve, reject) {
JSZipUtils.getBinaryContent('/jszip/test/ref/all.zip', function(err, data) {
if (err) {
reject(err);
} else {
resolve(data);
}
});
}).then(function (data) {
return JSZip.loadAsync(data);
})
.then(function success(zip) {
console.log("success", zip.files);
}, function failure(e) {
console.error("failure", e);
});
This snippet works (at least when copy/pasted in the demo textarea on JSZip website).
and since the only server i have access to is public, and I'm not ready to release the tool/lib I'm making, i can't do online testing.
How do you load the zip file ? From a local web server or from file:// ?
@dduponchel i understand the difficulty of documentation :) It is obvious to some people because they already know what's going on.
Break the documentation down to three parts:
-
Reading Files: show examples from a wide variety of entry points, like in the browser with a base64 string or in node using readFile
-
Working with the Files: show examples of reading and writing files from the zip archive. Docs here are pretty good
-
Writing files:show examples from a wide variety of exit points, like a downloader in the browser or a node express server
https://github.com/sheetjs/js-xlsx#parsing-workbooks is what I was thinking of. Just list a bunch of ways you would ingest zip files and show how to do it.
I do not yet fully understand how github works, so no proper quotes/mentions...
@dduponchel The documentation thing is a common mistake. Most of my own code is poorly documented/commented, but it's also heavily WIP and most of the classes/APIs could be re-written/removed/re-named at a moment's notice. The tool I'm making falls under this category, everything is in the hacked-together "proof of concept stage" My game library (https://github.com/Brian151/UnNamed-html5-Game-Library/tree/master/) suffers from awful documentation, and it often bites me in the butt...AND I WROTE IT!
I'm not sure if the examples are out of date, I confirmed your tool works for my purposes (the files are technically .zip, but not quite... they're 'special purpose') by testing the file upload example, so I think the examples are fine. The docu is just inadequate. Might also consider not EVERYONE is too keen on using jquery or AJAX , or understands it. Heck, I'm still getting used to event listeners
yeah, but thing is i already know how to GET binary content in XHR. for whatever reason, my file doesn't seem to be loading that way, IDK why... I managed to do this before, even on a local file... jszip requires the arraybuffer response type, right? That's what I tried using. in any case, I'm not getting ANYTHING from firefox's web console (or js alert) when trying to debug even the XHR, but that bit isn't your fault. I don't think it's an XHR encoding error. as for how to improve it, perhaps detect if the file is actually "corrupted" , or if it's just not there, whatever.
well, firefox web console is hit and miss with local files... and so is alert. It loves to affect things like XHR the most, though...
I could probably think of a few things, but I'd need time to organize them...
alright
I use relative paths from whatever, so it works both local (excluding SECURITY ERRORS, hence why I don't use google chrome) and online. so folder/folder2/file.ext
Now, I'm going to test the jszip-utils thing I do somewhat question if that should be a separate repo, though. Seems like something that should be a part of this one, since it's a dependency designed just for jszip.
This seems to do the trick, kinda hurts me eyes to look at, though:
var myZip = new JSZip(); JSZipUtils.getBinaryContent('test/~sprite676.fla', function(err, data) { if(err) { throw err; // or handle err } myZip.loadAsync(data).then(function () { myZip.file("DOMDocument.xml").async("string").then(function(data){ console.log(data.slice(0,32)); }) }); });
and you might see now why I kinda don't want to release this just yet. (also, i'm not entirely allowed/supposed to share the particular files I'm using)
now I just gotta put all the rest together!
I'd advise leaving this issue open for now, in case anything else comes-up (and it most likely will)
Alright, how about verifying if a certain file exists inside of a given .zip? What would be the approach for handling this?
a suggestion concerning errors, btw: Try verifying if the given file: is valid data type/is a valid zip, even exists The error I got didn't help at all for finding the cause of the problem
how about verifying if a certain file exists inside of a given .zip?
If you know the file path, you can check if zip.file(name) returns null or if zip.files[name] is defined.
The error I got didn't help at all for finding the cause of the problem
Do you mean the error The data of 'file.txt' is in an unsupported format ! ?
Right, good old "how to check null" dilemma, I <3 JS //sarcasm
I think so? Pretty sure it was that, yeah. Point is, it does nothing for saying if you passed boolean , null, array, ImageData, txt/String, Number, instead of a valid ArrayBuffer or Unit8Array, or whatever it was you actually take-in as the zipped file. That said, determining if the content was even SENT to JsZip is a little difficult. Checking for other types of compression, or even valid filesizes might be a good idea, too. I'm also assuming you only support 'standard' zip formats, so instead of saying 'invalid file' , saying "7zip format not supported" might make more sense?
I wonder how many people turn away in frustration after trying to solve a simple task: open a zip archive and read a file from it? JSZip examples are wonderful... except they wonderfully cover creation of zip files, not reading them. How many people need creating zip files in their webpages, honestly? Why not concentrate on what users require?
BOTH operations are useful to have, especially with the various HTML/JS based apps appearing left/right...
As for opening zip files, I feel like I'm the only person in the immediate vicinity of myself IRL who even knows what these things are and how to open them... I'm not kidding. I've used them for the easy transportation of MULTIPLE FILES AT ONCE via email, and I always seem to eventually hear complaints people can't open them?! Provided, it's older folks who don't understand computers, generally...[surprise surprise, newer computers actually discourage intimate understanding/configuration of them] but it's annoying these older folks try to organize themselves with this technology, and don't know anything other than DOC and PDF, and images [but not specific image formats and their pros/cons]. And even then, all they know is these files exist, and there's certain programs to open them. anyways, i'm getting a bit rambly...
You're right. For practical purposes, a lot of people came to this library for READING zips, not writing... Still, both are useful, and both should be covered. Ofc, I'm one to speak, my game library is poorly documented, full of prototype-quality code, and I regularly have to check and double-check I'm using MY OWN CODE correctly... /:
You know what else is a deterrent? node/npm... Even some people who use it for their careers don't actually LIKE it, or any of the frameworks... The fastest way to make me reject a javascript library/snippet is NODE/NPM and all the associated toolchains... I see those, I'M OUT! Jquery comes-in second, but I sometimes use it, just trusting the code example I imported works well enough. As a personal preference, I like code that I can understand, have direct control over the internals, and doesn't require 101 steps to make "hello world". I've dealt with a few engines/frameworks before, and I just wasn't satisfied with the results, on top of the catch22's I regularly encountered. If I can get-by without third-party code from 20 different sources, I will... But, this is not one of those cases...
It certainly is amazing how examples/docu never seem to cover what people actually are trying to do. Believe me, I don't love adobe, but their documentation of the AS3 API is...thorough... For being so "open" , HTML/XML/JS/CSS and their frameworks/tools have given me SO MANY problems, which I've had to resolve with help from various sources, sometimes just through trial-and-error. A handful have frustrated me to the point of not bothering with them. At least the frameworks/libraries I have chosen to use have helpful devs whom will answer questions when asked. Also, CreateJS seems fairly sane. I just prefer having much more direct access/control over what I'm doing, and so far it's shown that's not easy to do because it's a fully featured framework that tries to mirror the AS API. That includes taking certain amount of control away. [also one reason I have yet to seriously try dealing with webGL/OpenGL/etc... I like to have that intimate relationship with my code. If I draw a 16x16 graphic at 13,37 on the screen, I prefer to be able to account for every single pixel that was placed. I want to be able to manipulate that pixel if I so choose... and i don't like dealing with the shortfalls of floating point math being applied to data that typically operates on integers cough normalized UV coords...]
well, that became quite the rant...oops...sorry
Assuming the devs here don't address it before then, maybe I can help with this lack of documentation in some parts, some day... I kinda like documenting/explaining things... kinda...
Thank you for your answer, Brian.
What I REALLY would like is to insert in my code something like:
var zipArchive = loadZipFile("sample.zip"); or var zipArchive = loadZipURL("http://some.whe.re/sample.zip"); and var text = zipArchive.getContent("sample.txt", "string");
But I want way too much, right?
Instead, I am supposed to learn async functions and methods of their use. Don't get me wrong, I learn all my life. I've seen lots of languages. But this... I've never seen ANYTHING so unreadable, so logic-ridden, so ugly syntaxed - and I've seen Fortran 77 and coded in assember. I have very little desire to spend weeks of my time and strain my brain to nervous fits. Why the f... I mean, what is the reason that I have to go async here? It's not like I want my page to show fireworks while the file is loading. All that follows next depends on that file, I just want to get it. To wait, if needed, and get it.
Sorry for emotions. It's just that reality differs from my expectations so wildly. Heck, I think I can write a zip decoder myself sooner than I learn how to to use that stuff, and certainly have more fun in the process.
@Brian151 @Bycmep library design is a series of compromises. If you don't like the decisions made, it's not too difficult to write your own library. JSZip version 2 had a simpler API, JSZip 3 switched to promises but many projects still use version 2.
In 2019, the standard interface for binary data is Uint8Array or ArrayBuffer, which are supported input for loadAsync. Actually reading data from an external source and getting an ArrayBuffer or Uint8Array is outside the scope of this and other JS libraries for processing data -- you are expected to know how to set up the plumbing with fetch or XHR or FileReader or whatever.
PS: @Stuk the website http://stuartk.com/jszip is down -- URL should be changed to https://stuk.github.io/jszip/
async programming really is painful there unfortunately are cases where it must be used... although modern languages have over-complicated the hell out of everything, so that makes it worse
i personally find assembly much more sane well, other than complex instructions like certain ones in x86... even with all the, well, arcane, methods of I/O, DMA, etc... it's much more straightforward
loading files in jszip i haven't found to be too difficult.... after it was explained https://github.com/Brian151/Various-Projects/blob/master/Flash/fla_buster/fla.html#L76
oh, and THIS file shows another thing i HATE : parsing XMLs i mean, technically, the XML DOM API does the actual parsing, but then i have to work through this 'exciting' node tree to get the data i want. and THIS is ignoring caveats about how the data i am REALLY after was encoded [flash shapes are brilliant, but they're frustrating/confusing in both how they're stored, and rendered... this arguably is WORSE with the XFL files, and god only knows what the old 'binary blob' format did...]