Re: [FileAPI] Updates to FileAPI Editor's Draft

> Sorry if these have all been discussed before. I just read the File 
> API for the first time and 2 random questions popped in my head.
>
> 1) If I'm using readAsText with a particular encoding and the data in 
> the file is not actually in that encoding such that code points in the 
> file can not be mapped to valid code points what happens? Is that 
> implementation specific or is it specified? I can imagine at least 3 
> different behaviors.

This should be specified better and isn't.  I'm inclined to then return 
the file in the encoding it is in rather than force an encoding (in 
other words, ignore the encoding parameter if it is determined that code 
points can't be mapped to valid code points in the encoding... also note 
that we say to "Replace bytes or sequences of bytes that are not valid 
according to thecharsetwith a single U+FFFD character [Unicode 
<http://dev.w3.org/2006/webapi/FileAPI/#Unicode>]").  Right now, the 
spec isn't specific to this scenario ("... if the user agent cannot 
decode blob using encoding, then let charset be null" before the 
algorithmic steps, which essentially forces UTF-8).

Can we list your three behaviors here, just so we get them on record? 
  Which behavior do you think is ideal?  More importantly, is 
substituting U+FFFD and "defaulting" to UTF-8 good enough for your 
scenario above?

>
> 2) If I'm reading using readAsText a multibyte encoding (utf-8, 
> shift-jis, etc..) is it implementation dependent whether or not it can 
> return partial characters when returning partial results during 
> reading? In other words,  Let's say the next character in a file is a 
> 3 byte code point but the reader has only read 2 of those 3 bytes so 
> far. Is implementation dependent whether result includes those 2 bytes 
> before reading the 3rd byte or not?
>

Yes, partial results are currently implementation dependent; the spec. 
only says they SHOULD be returned.  There was reluctance to have MUST 
condition on partial file reads.  I'm open to revisiting this decision 
if the justification is a really good one.

-- A*