I am reading a local CSV file using a web UI, and the HTML5 FileReader interface to handle the local file stream. This works great.
However, sometimes I want the file being read to be updated continuously, after the initial load. I am having problems, and I think it might have something to do with the FileReader API. Specifically, after the initial file load, I maintain a reference to the file. Then, when I detect that the size of the file has increased, I slice off the new part of the file, and get a new Blob object. However, there appears to be no data in these new Blobs.
I am using PapaParse to handle the CSV parsing, though I don't think that is the source of the problem (though it may be).
The source code is too voluminous to post here, but here is some pseudocode:
var reader = new FileReader();
reader.onload = loadChunk;
var file = null;
function readLocalFile(event) {
file = event.target.files[0];
// code that divides file up into chunks.
// for each chunk:
readChunk(chunk);
}
function readChunk(chunk) {
reader.readAsText(chunk);
}
function loadChunk(event) {
return event.target.result;
}
// this is run when file size has increased
function readUpdatedFile(oldLength, newLength) {
var newData = file.slice(oldLength, newLength);
readChunk(newData);
}
The output of loadChunk when the file is first loading is a string, but after the file has been updated it is a blank string. I am not sure if the problem is with my slice method, or if there is something going on with FileReader that I am not aware of.
The spec for File objects shouldn't allow this: http://www.w3.org/TR/FileAPI/#file -- it's supposed to be like a snapshot.
The fact that you can detect that the size has changed is probably a shortcoming of an implementation.
Related
I have been successfully using FileReader to parse some XML data to HTML page from a local file. If I make changes to the DOM, I can successfully parse the data back to an XML file, but if I try to overwrite the file that was used to read, it does not successfully download. If I save the file with a different name, it successfully downloads.
I use FileReader like this from a browse/input selector:
function handleFileSelection(evt) {
var files = evt.target.files;
var url = window.URL.createObjectURL(files[0]);
reader = new FileReader();
reader.onload = function (e) {
Then if I make changes, I save the data like this:
var blob = new Blob(
arrayOfUnits,
{ type: "text/xml" }
);
window.navigator.msSaveBlob(blob, 'Units.xml');
I feel like the FileReader either has the file locked, or perhaps JavaScript cannot overwrite local files?
I have tried using: FileReader.abort() which seems to be like FileReader.close() in java, but this didn't fix my issue.
Any help is appreciated, I am new to using JavaScript with local file system.
FileReader won't write to the file system. You need FileWriter to do so.
Now most of browsers are supporting IndexedDB to store data/file directly as File, Blob or ArrayBuffer.
This code saves a IDB key 'File1' as File
<input type="file" id="userfile" />
var a = document.getElementById("userfile");
var b = a.files[0];
Now we can directly save this file to IDB using the following code
//LocalForage is a library for indexedDB developed by Mozilla
//Note: localforage._config.driver=asyncStorage (IDB method)
function run(){
//"File1" = IDB data table key and b=value
localforage.setItem("File1", b, function(err, value) {
console.log(err)
});
}
a.onchange = function(){
run()
}
This code saves a IDB key 'BlobFile' as Blob
mb = new Blob([b],{type:b.type});
function runB(){
localforage.setItem("BlobFile", mb, function(err, value){
console.log(err)
});
}
a.onchange = function(){
runB()
}
I want to know what is the best practice to store the file to IDB. (File/Blob/ArrayBuffer)
The files could be images or very small size videos.
I recommend using Blob for images & videos as the API is fairly straightforward for downloading as blob and saving to db, as well as retrieving from db and creating URL for src attribute
Check this sample here for implementation
https://hacks.mozilla.org/2012/02/storing-images-and-files-in-indexeddb/
This is a debatable matter, but there are some lines we can draw here, I am quoting MDN here:
The File interface is based on Blob, inheriting blob functionality and expanding it to support files on the user's system.
so between file and blob, it's a matter of needed functionality (my preference is blob as it's a bit more handy).
now between blob and ArrayBuffer, this one is tricky, since it totally depends on what you need, ArrayBuffer is very helpful in some cases but it's a structured and it's a
fixed-length container for binary data
so your file size can make a huge difference.
another big point is, ArrayBuffer is in-memory, while blob can be any where, disk or memory, so with using blob you might be reducing over head a lot.
so for your case, imho, blob wins.
now on a side note, I don't know what you are trying to do exactly, but storing the whole file in a db is not a good idea unless your target is indexing the whole file content and querying it, because, not all user devices can handle that type of overload, so, if you don't need the content, index the file names only, it saves time and storage space.
I hope this helps.
I don't quite understand what is happening in the following code, if someone can guide me to the right direction maybe it will be easier for me to get the same variable as in the else statement but manually (in case FileReader api isn't supported).
Basicly in my if statement I want to make an ajax call and transform the picture to the base64 string and save it to the read variable same structure as in my else statement:
$('#file').on('change', function(){
if(typeof FileReader === "undefined") {
//AJAX CALL HERE
}
else {
var reader = new FileReader();
}
reader.onload = function(e) {
options.imgSrc = e.target.result;
cropper = $('.imageBox').cropbox(options);
}
reader.readAsDataURL(this.files[0]);
this.files = [];
console.log(reader);
})
console log for the read variable in the else statement shows: Picture
You can't do that without some kind of Polyfiller, the reason being that Javascript (without the FileReader API) cannot handle files and cannot pass them about. You will not be able to send the file to the server with Javascript.
There are 2 ways you can do this :
Cause a postback to occur in which you get the file on the server
and then convert it to Base64 (can be done in PHP/ASP.NET (and
probably lots of others))
Or you can use a Polyfiller such as
moxie, this will load when the
page loads and if File API is not supported it will add a
Flash/Silverlight plugin to mimick the support.
I have an HTML5/javscript app which uses
<input type="file" accept="image/*;capture=camera" onchange="gotPhoto(this)">
to capture a camera image. Because my app wants to be runnable offline, how do I save the File (https://developer.mozilla.org/en-US/docs/Web/API/File) object in local storage, such that it can be retrieved later for an ajax upload?
I'm grabbing the file object from the using ...
function gotPhoto(element) {
var file = element.files[0];
//I want to save 'file' to local storage here :-(
}
I can Stringify the object and save it, but when I restore it, it is no longer recognised as a File object, and thus can't be used to grab the file content.
I have a feeling it can't be done, but am open to suggestions.
FWIW My workaround is to read the file contents at store time and save the full contents to local storage. This works, but quickly consumes local storage since each file is a 1MB plus photograph.
You cannot serialize file API object.
Not that it helps with the specific problem, but ...
Although I haven't used this, if you look at the article it seems that there are ways (although not supported yet by most browsers) to store the offline image data to some files so as to restore them afterward when the user is online (and not to use localStorage)
Convert it to base64 and then save it.
function gotPhoto(element) {
var file = element.files[0];
var reader = new FileReader()
reader.onload = function(base64) {
localStorage["file"] = base64;
}
reader.readAsDataURL(file);
}
// Saved to localstorage
function getPhoto() {
var base64 = localStorage["file"];
var base64Parts = base64.split(",");
var fileFormat = base64Parts[0].split(";")[1];
var fileContent = base64Parts[1];
var file = new File([fileContent], "file name here", {type: fileFormat});
return file;
}
// Retreived file object
Here is a workaround that I got working with the code below. I'm aware with your edit you talked about localStorage but I wanted to share how I actually implemented that workaround. I like to put the functions on body so that even if the class is added afterwards via AJAX the "change" command will still trigger the event.
See my example here: http://jsfiddle.net/x11joex11/9g8NN/
If you run the JSFiddle example twice you will see it remembers the image.
My approach does use jQuery. This approach also demonstrates the image is actually there to prove it worked.
HTML:
<input class="classhere" type="file" name="logo" id="logo" />
<div class="imagearea"></div>
JS:
$(document).ready(function(){
//You might want to do if check to see if localstorage set for theImage here
var img = new Image();
img.src = localStorage.theImage;
$('.imagearea').html(img);
$("body").on("change",".classhere",function(){
//Equivalent of getElementById
var fileInput = $(this)[0];//returns a HTML DOM object by putting the [0] since it's really an associative array.
var file = fileInput.files[0]; //there is only '1' file since they are not multiple type.
var reader = new FileReader();
reader.onload = function(e) {
// Create a new image.
var img = new Image();
img.src = reader.result;
localStorage.theImage = reader.result; //stores the image to localStorage
$(".imagearea").html(img);
}
reader.readAsDataURL(file);//attempts to read the file in question.
});
});
This approach uses the HTML5 File System API's to read the image and put it into a new javascript img object. The key here is readAsDataURL. If you use chrome inspector you will notice the images are stored in base64 encoding.
The reader is Asynchronous, this is why it uses the callback function onload. So make sure any important code that requires the image is inside the onLoad or else you may get unexpected results.
You could use this lib:
https://github.com/carlo/jquery-base64
then do something similar to this:
//Set file
var baseFile = $.base64.encode(fileObject);
window.localStorage.setItem("file",basefile);
//get file
var outFile = window.localStorage.getItem("file");
an other solution would be using json (I prefer this method)
using: http://code.google.com/p/jquery-json/
//Set file
window.localStorage.setItem("file",$.toJSON(fileobject));
//get file
var outFile = $.evalJSON(window.localStorage.getItem("file"));
I don't think that there is a direct way to Stringify and then deserialize the string object into the object of your interest. But as a work around you can store the image paths in your local storage and load the images by retrieving the URL for the images. Advantages would be, you will never run out of storage space and you can store 1000 times more files there.. Saving an image or any other file as a string in local storage is never a wise decision..
create an object on the global scope
exp: var attmap = new Object();
after you are done with file selection, put your files in attmap variable as below,
attmap[file.name] = attachmentBody;
JSON.stringify(attmap)
Then you can send it to controller via input hidden or etc. and use it after deserializing.
(Map<String, String>)JSON.deserialize(attachments, Map<String,String>.class);
You can create your files with those values in a for loop or etc.
EncodingUtil.base64Decode(CurrentMapValue);
FYI:This solution will also cover multiple file selection
You could do something like this:
// fileObj = new File(); from file input
const buffer = Buffer.from(await new Response(fileObj).arrayBuffer());
const dataUrl = `data:${fileObj.type};base64,${buffer.toString("base64")}`;
localStorage.setItem('dataUrl', dataUrl);
then you can do:
document.getElementById('image').src = localStorage.getItem('dataUrl');
I need to serialize a File object from a file input, so that the object can be saved, parsed back to a file object, and then read using the FileReader object.
Does anyone know if this is possible in Google Chrome?
I think the problem lies in the protection of the file.path property. Webkit browsers hide this property, so I am guessing when you serialize it, the path is removed.
Then of course, the FileReader is unable to read it without path information.
Here is an example:
var files = uploadControl.files[0];
var dataFile = JSON.stringify(files);
var newFile = JSON.parse(dataFile);
var reader = new FileReader();
reader.onload = (function(event) {
var fileContents = event.target.result;
});
reader.readAsText(newFile);
Nothing happens. The reader is not loaded. If I pass the JSON object, it doesn't work either.
As a matter of principle, what you are asking for will not be possible. If it were possible to have some text which represented the file object, then you could construct that text from scratch, unserialize it, and thus get access to files the user did not grant permission to.
(The exception to this is if the representative text is some sort of robustly-secret bitstring (cryptographically signed, or a sparse key in a lookup table) that only the browser could have given out in the first place — but I expect if that feature existed, it would be documented and you would have found it already.)