All the header files there are gold!īeyond that, I just read through the zip looking for key bits to extract the archive information. That Git repo is magic by the way, so bookmark it. I'm terrible at math, so I went ahead and shamelessly lifted some public domain source for doing the decompression from here. Now with all of the disclaimers out of the way, let's explore a little more of what I did. I've tested this code on an ESP32 WROOM with 512kB of RAM (~ 300kB effectively available), which is much more than this needs to run, but it's my go-to platform. A little ATMega2560 only has 8kB of RAM, so it's just not going to cut it, for example. I really hate allocating that much RAM on IoT devices, but unless I can track down and solve the issue with the Arduino File object, I am at a loss.ĭue to the above, when all is said and done, you are almost guaranteed to need an attached SD reader/writer, unless you have something like an ESP32 with a SPIFFS partition in order to store the decompressed stream.Īnother issue is that the Arduino File objects themselves are pretty stack heavy, so even though the zip archive structures are not, you still need to allocate most of your working objects as globals or otherwise on the heap.įinally, if the above didn't make it clear, you need at least middle weight IoT device at least to run this code. So now after all that, I settled in on a method that takes a readable input stream and a writeable output stream to run a Huffman inflate operation, using a temporary 32kB buffer on the heap to perform it. I may eventually implement this optionally at a later date, but doing so would increase the code size substantially. However, doing this requires even more memory. The other issue is this technique is a whole lot slower.įailing that, I was going to implement an on demand decompression stream so you didn't need to extract the whole stream before beginning to view it. Originally, I had implemented a bufferless lookback mechanism that used a seekable output stream rather than a 32kB window in RAM, but I ran into a problem seeking backward into the Arduino File object. This ability to look back complicates things. The other thing about it is that Huffman decoding requires being able to look backward 32kB into your output buffer (yes, the decompressed data you've already written) because it uses that data to do further decompression. It makes it impossible to forward stream with it unfortunately. Reading zip archives is pretty easy, if a little odd, since a lot of the relevant information you need is relative to the end of the file rather than the beginning. You should be able to use zip.hpp/ stream.hpp/ bits.hpp just about anywhere in terms of platform, but I've only tested them on ESP32s. You don't need to do it again unless you switch out the ESP32 you're using. You need to upload the filesystem image before the first time you build in order to set up the SPIFFS partition. You'll need VS Code with PlatformIO installed. The problem is, after hunting, I could not find an adequate offering that would work with under constrained memory environments, much less the Arduino framework. Note: This is not an official Google product.I needed to be able to extract zip files under the Arduino framework and other IoT frameworks. Supportįor any questions about the Drive API, you can also post a question on the Stack Overflow forums: For ZIP Extractor, that configuration information in found in 'config.js' under the '/js/zipextractor/' directory. Note: The resulting App ID, Client ID, and API Key generated as part of that process will need to be put into the your app's configuration (in actual code). In all cases, a configuration will need to be created in the Google Developers Console, as outlined here: Options for hosting include Google App Engine or your own web server. To run this code yourself, it will need to be hosted somewhere. This app uses the zip.js – Javascript-based ZIP library. ZIP extractor also demonstrates how to integrate with the Google Drive web and Android apps. The app also demonstrates the use of the File Picker and Sharing widgets as part of the Drive API. ZIP Extractor makes use of CORS (Cross-Origin Resource Sharing) methods for uploading and downloading files from Drive. The app is based on the drive.file OAuth2 scope, where permission is granted only for individual files that the user authorizes. Hierarchical ZIP files (ZIP files with subfolders) are supported. This is a pure-Javascript app that makes use of the public Google Drive API to read ZIP files from Google Drive and extract their contents into Google Drive. Sample app for extracting ZIP files into Google Drive using the Google Drive API.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |