- From: Nigel Tao <nigel.tao.gnome@gmail.com>
- Date: Mon, 27 Jul 2009 22:38:06 +1000
- To: arun@mozilla.com
- Cc: public-webapps@w3.org
2009/7/22 Arun Ranganathan <arun@mozilla.com>: > So, currently, we provide a fileData.getAsText(fileCallback, encoding, > error) > > and > > within fileCallback (a callback function) you can get the file's data as a > string (say a UTF-8 encoded string, or any encoding specified by > "encoding"); it is passed as an argument to fileCallback. > > Then, you can append to the string (or prepend, in the case of the header) > using the standard JavaScript string methods. And you can, of course, post > the string via XHR. > > Along with a similarly asynchronous splice method to generate "ranged" > subsets of a FileData object, I think that we've got *most* of the features > exposed by both BlobBuilder and Blob. > > Have I missed something important? I'm jumping in late to the mailing list, so I might have missed something said earlier... What happens if you call fileData.getAsText on a file whose contents are not valid unicode text (either UTF-8, UTF-16, or some other encoding)? For example, I presume that a significant fraction JPEG-encoded images aren't valid UTF-8. None of the three FileError codes (NOT_FOUND_ERR, NOT_READABLE_ERR, SECURITY_ERR) seem to apply. Or am I just fundamentally confused, and is a DOMString not necessarily valid unicode?
Received on Tuesday, 28 July 2009 08:43:10 UTC