& Joe Boxer ***林弹雨平 女款 角裤JSAN6052-11
物流 至请选择
单价重量克/件
物流可在付款时进行修改，以上罗列的地区仅为预估运费所用，
并不代表此商品可实际发往所有以上地区，可实际发往的地区以下单时的可供选项为准This specification provides an API
for representing file objects in web applications, as well as programmatically selecting them and accessing their data.
This includes:
interface, which represents an array of individually selected files from the underlying system.
The user interface for selection can be invoked via &input type="file"&, i.e. when the
input element is in the File Upload state [] .
interface, which represents immutable raw binary data, and allows access to ranges of bytes within the
object as a separate .
interface, which includes readonly informational attributes about a file
such as its name and the date of the last modification (on disk) of the file.
interface, which provides methods to read a
or a , and an event model to obtain the results of these reads.
for use with binary data such as files, so that they can be referenced within web applications.
Additionally, this specification defines objects to be used within threaded web applications for the synchronous reading of files.
The section on Requirements and Use Cases [] covers the motivation behind this specification.
This API is designed to be used in conjunction with other APIs and elements on the web platform,
with an overloaded send()
method for File or
arguments), postMessage, DataTransfer (part
of the drag and drop API defined in []) and
. Additionally, it should be possible to programmatically obtain a list of files from the
input element when it is
in the File Upload state[].
These kinds of behaviors are defined in the appropriate affiliated specifications.
Status of this Document
This section describes the status of this document at the time of its publication.
Other documents may supersede this document. A list of current W3C publications and the
latest revision of this technical report can be found in the
http://www.w3.org/TR/.
If you have comments for this spec, please send them to
with a Subject: prefix of [FileAPI]. See
for this specification's open bugs.
This document was published by the
as a Working Draft.
This document is intended to become a W3C Recommendation.
If you wish to make comments regarding this document, please send them to
All comments are welcome.
Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or obsoleted by other
documents at any time. It is inappropriate to cite this document as other than work in
This document was produced by a group operating under the
W3C maintains a
made in connection with the deliv that page also includes
instructions for disclosing a patent. An individual who has actual knowledge of a patent
which the individual believes contains
must disclose the information in accordance with
This document is governed by the .
Table of Contents
1. Introduction
This section is informative.
Web applications should have the ability to manipulate as wide
as possible a range of user input, including files that a user may wish to upload
to a remote server or manipulate inside a rich web application. This specification
defines the basic representations for files, lists of files, errors raised by access to files,
and programmatic ways to read files.
Additionally, this specification also defines an interface that represents
"raw data" which can be asynchronously processed on the main thread of conforming user agents.
The interfaces and API defined in this
specification can be used with other interfaces and APIs exposed to the web platform.
interface represents file data typically obtained from the underlying (OS) file system, and the
("Binary Large Object" - a name originally introduced to web APIs in ) represents immutable raw data.
reads should happen asynchronously on the main thread, with an optional synchronous API used
within threaded web applications.
An asynchronous API for reading files prevents blocking and UI "freezing" on a user
agent's main thread.
This specification defines an asynchronous API based on an event model to read and access a
object provides asynchronous read methods to
access that file's data through event handler attributes and the firing of events.
The use of events and event handlers allows separate code blocks the ability
to monitor the progress of the read (which is particularly useful for remote drives or mounted drives, where file access performance may vary from local drives)
and error conditions that may arise during reading of a file.
An example will be illustrative.
In the example below, different code blocks handle progress, error, and success conditions.
ECMAScript
function startRead() {
var file = document.getElementById('file').files[0];
getAsText(file);
function getAsText(readFile) {
var reader = new FileReader();
reader.readAsText(readFile, "UTF-16");
reader.onprogress = updateP
reader.onload =
reader.onerror = errorH
function updateProgress(evt) {
if (evt.lengthComputable) {
var loaded = (evt.loaded / evt.total);
if (loaded & 1) {
function loaded(evt) {
var fileString = evt.target.
if(utils.regexp.isChinese(fileString)) {
function errorHandler(evt) {
if(evt.target.error.name == "NotReadableError") {
2. Conformance
Everything in this specification is normative except for
examples and sections marked as being informative.
The keywords “MUST”,
“MUST NOT”,
“REQUIRED”,
“SHALL”,
“SHALL NOT”,
“RECOMMENDED”,
“MAY” and
“OPTIONAL” in this document are to be
interpreted as described in
The following conformance classes are defined by this specification:
conforming user agent
A user agent is considered to be a
if it satisfies all of the MUST-,
REQUIRED- and SHALL-level
criteria in this specification that apply to implementations.
This specification uses both the terms "conforming user agent" and "user agent" to refer to this product class.
User agents may implement algorithms in this specifications in any way desired, so long as the end result is indistinguishable from the result that would be obtained
from the specification's algorithms.
User agents that use ECMAScript to implement the APIs defined in this specification must implement them in a manner consistent with the
ECMAScript Bindings defined in the Web IDL specification [] as this specification uses that specification and terminology.
3. Dependencies
This specification relies on underlying specifications.
must support at least the subset of the functionality defined in DOM4 that this speci in particular,
it must support EventTarget. []
Progress Events
must support the Progress Events specification. Data access on read operations is enabled via Progress Events.[]
must support at least the subset of the functionality defined in HTML that this speci
in particular, it must support
must also be a conforming implementation of the IDL fragments in this specification,
as described in the Web IDL specification. []
Typed Arrays
must support the Typed Arrays specification [].
Parts of this specification rely on the Web W for those parts of this specification, the Web Workers specification is a normative dependency.
4. Terminology
The terms and algorithms document,
unloading document cleanup steps, event handler attributes,
event handler event type,
effective script origin, incumbent settings object, event loops,
task, task source, URL, global script cleanup jobs list, global script cleanup,
queue a task, UTF-8, UTF-16. structured clone, collect a sequence of characters and converting a string to ASCII lowercase are as defined by the HTML specification [].
The terms origin and same origin are as defined by the Web Origin Concept specification [].
When this specification says to terminate an algorithm the user agent must terminate the algorithm after finishing the step it is on, and return from it.
Asynchronous
defined in this specification may return before the algorithm in question is terminated, and can be terminated by an
The term throw in this specification, as it pertains to exceptions, is used as defined in the DOM4 specification [].
The term byte in this specification is used as defined in the Encoding Specification [].
The term chunk in this specification is used as defined in the Streams Specification [.]
The term context object in this specification is used as defined in the DOM4 specification [].
The terms URL, relative URL, base URL, URL parser, basic URL Parser, scheme, host, relative scheme, scheme data, and fragment are as defined by the WHATWG URL Specification [].
The terms request, response, body and cross-origin request are as defined in the WHATWG Fetch Specification [].
The term Unix Epoch is used in this specification to refer to the time 00:00:00 UTC on January 1 1970 (or T00:00:00Z ISO 8601); this is the same time that is conceptually "0" in ECMA-262 [].
The algorithms and steps in this specification use the following mathematical operations:
max(a,b) returns the maximum of a and b, and is always performed on integers as they are defined in WebIDL []; in the case of max(6,4) the result is 6.
This operation is also defined in ECMAScript [].
min(a,b) returns the minimum of a and b, and is always performed on integers as they are defined in WebIDL []; in the case of min(6,4) the result is 4.
This operation is also defined in ECMAScript [].
Mathematical comparisons such as & (less than), ≤ (less than or equal to) and & (greater than)
are as in ECMAScript
5. The Blob Interface and Binary Data
object refers to a
sequence, and has a
attribute which is the total number of bytes in the byte sequence, and a
attribute, which is an ASCII-encoded string in lower case representing the media type of the
must have a readability state, which is one of
that refers to a
sequence, including one of 0 bytes, is said to be in the OPENED . A
is said to be closed if its
method has been called. A
is said to be in the CLOSED .
must have an internal snapshot state, which must be initially set to the state of the underlying storage, if any such underlying storage exists, and must be preserved through .
Further normative definition of
can be found for .
[Constructor,
Constructor(sequence&(ArrayBuffer or ArrayBufferView or Blob or DOMString)& , optional
options), Exposed=Window,Worker]
interface Blob {
readonly attribute
readonly attribute DOMS
Blob ([Clamp] optional long long ,
[Clamp] optional long long ,
optional DOMString );
dictionary BlobPropertyBag {
5.1. Constructors
The Blob() constructor can be invoked with zero or more parameters.
When the Blob() constructor is invoked, user agents must run the following Blob constructor steps:
If invoked with zero parameters, return a new Blob object with its
set to , consisting of 0 bytes, with
set to 0, and with
set to the empty string.
Otherwise, the constructor is invoked with a
Let a be that sequence.
Let bytes be an empty sequence of bytes.
Let length be a's length.
For 0 ≤ i & length, repeat the following steps:
Let element be the ith element of a.
If element is a DOMString, run the following substeps:
Let s be the result of converting element to a sequence of Unicode characters [] using the algorithm for doing so in WebIDL [].
Encode s as
and append the resulting bytes to bytes.
The algorithm from WebIDL [] replaces unmatched surrogates in an invalid
string with U+FFFD replacement characters. Scenarios exist when the
constructor may result in some data loss due to lost or scrambled character sequences.
If element is an ArrayBufferView [], convert it to a sequence of byteLength bytes from the underlying ArrayBuffer, starting at the byteOffset of the ArrayBufferView [], and append those bytes to bytes.
If element is an ArrayBuffer [], convert it to a sequence of byteLength bytes, and append those bytes to bytes.
If element is a Blob, append the bytes it represents to bytes.
of the Blob array element is ignored.
member of the optional options argument is provided and is not the empty string, run the following sub-steps:
Let t be the
dictionary member. If t contains any characters outside the range U+0020 to U+007E, then set t to the empty string and return from these substeps.
Convert every character in t to lowercase using the "" algorithm [].
Return a Blob object with its
set to , referring to bytes as its associated
sequence, with its
set to the length of bytes, and its
set to the value of t from the substeps above.
The type t of a Blob is considered a parsable MIME type if the ASCII-encoded string representing the Blob object's type, when converted to a byte sequence, does not return undefined for the parse MIME type algorithm [].
5.1.1. Constructor Parameters
The Blob() constructor can be invoked with the parameters below:
A blobParts sequence
which takes any number of the following types of elements, and in any order:
ArrayBuffer [] elements.
ArrayBufferView [] elements.
DOMString [] elements.
An optional
which takes one member:
type, the ASCII-encoded string in lower case representing the media type of the Blob.
Normative conditions for this member are provided in the
Examples of constructor usage follow.
ECMAScript
var a = new Blob();
var buffer = new ArrayBuffer(1024);
var shorts = new Uint16Array(buffer, 512, 128);
var bytes = new Uint8Array(buffer, shorts.byteOffset + shorts.byteLength);
var b = new Blob(["foobarbazetcetc" + "birdiebirdieboo"], {type: "text/charset=UTF-8"});
var c = new Blob([b, shorts]);
var a = new Blob([b, c, bytes]);
var d = new Blob([buffer, b, c, bytes]);
5.2. Attributes
sizeReturns the size of the
sequence in number of bytes.
On getting, conforming user agents must return the total
number of bytes that can be read by a
object, or 0 if the Blob has no bytes to be read.
If the Blob has a readability state of
then size must return 0.
The ASCII-encoded string in lower case representing the media type of the Blob. On getting, user agents must return the type of a Blob as an ASCII-encoded string in lower case, such that when it is converted to a
sequence, it is a parsable MIME type [], or the empty string -- 0 bytes -- if the type cannot be determined. The
attribute can be set by the web application itself through constructor invocation a in these cases, further normative conditions for this attribute are in the , the , and the
respectively. User agents can also determine the
of a , especially if the
sequence is from an on- in this case, further normative conditions are in the .
The boolean value that indicates whether the Blob is in the
On getting, user agents must return false if the Blob is in the
, and true if the Blob is in the
as a result of the
method being called.
Use of the type attribute informs the
5.3. Methods and Parameters
5.3.1. The slice method
The slice method returns a new
object with bytes ranging from the optional
parameter upto but not including the optional
parameter, and with a
attribute that is the value of the optional
parameter.
It must act as follows :
Let O be the
on which the slice method is being called.
The optional start parameter is a value for the start point of a
call, and must be treated as a byte-order position, with the zeroth position representing the first byte.
User agents must process
start normalized according to the following:
If the optional start parameter is not used as a parameter when making this call, let relativeStart be 0.
If start is negative, let relativeStart be max(( + start), 0).
Else, let relativeStart be min(start, size).
The optional end parameter is a value for the end point of a
User agents must process
with end normalized according to the following:
If the optional end parameter is not used as a parameter when making this call, let relativeEnd be .
If end is negative, let relativeEnd be max((size + end), 0)
Else, let relativeEnd be min(end, size)
The optional contentType parameter is used to set the ASCII-encoded string in lower case representing the media type of the Blob.
User agents must process the
with contentType normalized according to the following:
If the contentType parameter is not provided, let relativeContentType be set to the empty string .
Else let relativeContentType be set to contentType and run the substeps below:
If relativeContentType contains any characters outside the range of U+0020 to U+007E, then set relativeContentType to the empty string and return from these substeps.
Convert every character in relativeContentType to lower case using the "" algorithm.
Let span be max((relativeEnd - relativeStart), 0).
Return a new
object S with the following characteristics:
equal to that of O's .
is retained by the
object r this has implications on whether the returned
is actually usable for s or as a .
S refers to span consecutive s from O, beginning with the
at byte-order position relativeStart.
S. = span.
S. = relativeContentType.
The type t of a Blob is considered a parsable MIME type if the ASCII-encoded string representing the Blob object's type, when converted to a byte sequence, does not return undefined for the parse MIME type algorithm [].
The examples below illustrate the different types of
calls possible. Since the
interface inherits from the
interface, examples are based on the use of the
interface.
ECMAScript
var file = document.getElementById('file').files[0];
var fileClone = file.slice();
var fileClone2 = file.slice(0, file.size);
var fileChunkFromEnd = file.slice(-(Math.round(file.size/2)));
var fileChunkFromStart = file.slice(0, Math.round(file.size/2));
var fileNoMetadata = file.slice(0, -150, "application/experimental");
5.3.2. The close method
The close method is said to
a , and must act as follows on the
on which the method has been called:
Otherwise, set the
has an entry in the ,
that corresponds to the .
6. The File Interface
object is a
object with a
attribute, it can be created within the web application via a constructor, or is a reference to a
sequence from a file from the underlying (OS) file system.
object is a reference to a
sequence originating from a file on disk, then its
should be set to the state of the file on disk at the time the
object is created.
This is a non-trivial requirement to implement for user agents, and is thus not a must but a should [].
User agents should endeavor to have a
set to the state of the underlying storage on disk at the time the reference is taken. If the file is modified on disk following the time a reference has been taken, the 's
will differ from the state of the underlying storage.
User agents may use modification time stamps and other mechanisms to maintain , but this is left as an implementation detail.
object refers to a file on disk, user agents must return the
of that file, and must follow the file type guidelines below:
User agents must return the
as an ASCII-encoded string in lower case, such that when it is converted to a corresponding byte sequence, it is a parsable MIME type [], or the empty string -- 0 bytes -- if the type cannot be determined.
When the file is of type text/plain user agents must NOT append a charset parameter to the dictionary of parameters portion of the media type
User agents must not attempt heuristic determination of encoding, including statistical methods.
[Constructor(sequence&(Blob or DOMString or ArrayBufferView or ArrayBuffer)& ,
[EnsureUTF16] DOMString , optional FilePropertyBag options), Exposed=Window,Worker]
interface File :
readonly attribute DOMS
dictionary FilePropertyBag {
6.1 Constructor
The File constructor is invoked with two or three parameters, depending on whether the optional dictionary parameter is used.
When the File() constructor is invoked, user agents must run the following File constructor steps:
Let a be the
sequence argument.
Let bytes be an empty sequence of .
Let length be a's length.
For 0 ≤ i & length, repeat the following steps:
Let element be the i'th element of a.
If element is a DOMString, run the following substeps:
Let s be the result of converting element to a sequence of Unicode characters [] using the algorithm for doing so in WebIDL [].
Encode s as
and append the resulting
The algorithm from WebIDL [] replaces unmatched surrogates in an invalid
string with U+FFFD replacement characters. Scenarios exist when the
constructor may result in some data loss due to lost or scrambled character sequences.
If element is an ArrayBufferView [], convert it to a sequence of byteLength bytes from the underlying ArrayBuffer, starting at the byteOffset of the ArrayBufferView [], and append those bytes to bytes.
If element is an ArrayBuffer [], convert it to a sequence of byteLength bytes, and append those bytes to bytes.
If element is a Blob, append the bytes it represents to bytes.
of the Blob argument must be ignored.
Let n be a new string of the same size as the
argument to the constructor. Copy every character from
to n, replacing any "/" character (U+002F SOLIDUS) with a ":" (U+003A COLON).
Underlying OS filesystems use differing conve with constructed files, mandating UTF-16 lessens ambiquity when file names are converted to
sequences.
If the optional
dictionary argument is used, then run the following substeps:
member is provided and is not the empty string, let t be set to the
dictionary member.
If t contains any characters outside the range U+0020 to U+007E, then set t to the empty string and return from these substeps.
Convert every character in t to lowercase using the "" [].
member is provided, let d be set to the
dictionary member.
If it is not provided, set d to the current date and time represented as the number of milliseconds since the
(which is the equivalent of Date.now() []).
Since ECMA-262 Date objects convert to long long values representing the number of milliseconds since the , the
member could be a Date object [].
Return a new File object F such that:
F refers to the bytes
F.size is set to the number of total bytes in bytes.
F.name is set to n.
F.type is set to t.
The type t of a File is considered a parsable MIME type if the ASCII-encoded string representing the File object's type, when converted to a byte sequence, does not return undefined for the parse MIME type algorithm [].
F.lastModified is set to d.
6.1.1 Constructor Parameters
The File() constructor can be invoked with the parameters below:
A fileBits sequence
which takes any number of the following elements, and in any order:
ArrayBuffer [] elements.
ArrayBufferView [] elements.
elements, which includes
DOMString [] elements.
A name parameter
A DOMString [] parameter representing
normative conditions for this constructor parameter can be found in the .
An optional
dictionarywhich takes the following members:
An optional type the ASCII-encoded string in lower case representing the media type of the File. Normative conditions for this member are provided in the .
An optional
member, which must be a long long; normative conditions for this member are provided in the .
6.2. Attributes
T on getting, this must return the name of the file as a string. There are numerous file name variations and conventions used by different underlying OS
this is merely the name of the file, without path information.
On getting, if user agents cannot make this information available, they must return the empty string.
object is created using a constructor, further normative conditions for this attribute are found in the .
lastModified
The last modified date of the file.
On getting, if user agents can make this information available, this must return a long long set to the time the file was last modified as the number of milliseconds since the .
If the last modification date and time are not known, the attribute must return the current date and time as a long long representing the number of mil this is equivalent to Date.now() []. If a
object is created using a constructor, further normative conditions for this attribute are found in the .
The File interface is available on objects that expose a these objects are defined in
The File interface, which inherits from , is immutable, and thus represents file data that can be
read into memory at the time a
is initiated.
User agents must process reads on files that no longer exist at the time of read as
, throwing a
exception if using a
on a Web Worker [] or firing an
event with the
attribute returning a
In the examples below, metadata from a file object is displayed meaningfully, and a file object is created with a name and a last modified date.
ECMAScript
var file = document.getElementById("filePicker").files[0];
var date = new Date(file.lastModified);
println("You selected the file " + file.name + " which was modified on " + date.toDateString() + " .");
// Generate a file with a specific last modified date
var d = new Date(, 16, 23, 45, 600);
var generatedFile = new File(["Rough Draft ...."], "Draft1.txt", {type: "text/plain"; lastModified: d})
7. The FileList Interface
The FileList interface should be considered "at risk" since the general trend on the Web Platform is to replace such interfaces with the Array platform object in ECMAScript []. In particular, this means syntax of the sort filelist.item(0) most other programmatic use of FileList is unlikely to be affected by the eventual migration to an Array type.
This interface is a list of
[Exposed=Window,Worker] interface FileList {
getter ? (unsigned long );
readonly attr
Sample usage typically involves DOM access to the &input type="file"& element within a form, and then accessing selected files.
ECMAScript
var file = document.forms['uploadData']['fileChooser'].files[0];
7.1. Attributes
lengthmust return the number of files in the
If there are no files, this attribute must return 0.
7.2. Methods and Parameters
item(index)must return the indexth
If there is no indexth
object in the
, then this method must return null.
index must be treated by user agents as value for the position of a
object in the , with 0 representing the first file.
Supported property indices [] are the numbers in the range zero to one less than the number of
objects represented by the FileList object.
If there are no such
objects, then there are no supported property indices [].
The HTMLInputElement interface [] has a readonly attribute of type FileList, which is what is
being accessed in the above example.
Other interfaces with a readonly attribute of type FileList include the DataTransfer
interface [].
8. Reading Data
8.1 The Read Operation
The algorithm below defines a , which takes a
as input, and reads s into a byte stream which is returned as the result of the , or else fails along with a . Methods in this specification invoke the
either set or unset.
The synchronous flag determines if a read operation is synchronous or asynchronous, and is unset by default. Methods may set it. If it is set, the
takes place synchronously. Otherwise, it takes place asynchronously.
To perform a read operation on a
and the , run the following steps:
Let s be a a new , b be the
to be read from, and bytes initially set to an empty byte sequence. Set the length on s to the
of b. While there are still bytes to be read in b perform the following substeps:
The algorithm assumes that invoking methods have checked for . A
state must not have a
called on it.
is set, follow the steps below:
Let bytes be the byte sequence that results from reading a
from b. If
from b, return s with the error flag set, along with a , and .
Along with returning failure, the synchronous part of this algorithm must return the
that occurred for
by synchronous methods that invoke this algorithm with the
If there are no errors, push bytes to s, and increment s's transmitted [] by the number of bytes in bytes. Reset bytes to the empty byte sequence and continue reading s as above.
When all the bytes of b have been read into s, return s and .
Otherwise, the
is unset. Return s and process the rest of this algorithm asynchronously.
Let bytes be the byte sequence that results from reading a
from b. If
from b, set the error flag on s, and
The asynchronous part of this algorithm must signal the
that occurred for asynchronous error reporting by methods expecting s and which invoke this algorithm with the
occurs, push bytes to s, and increment s's transmitted [] by the number of bytes in bytes. Reset bytes to the empty byte sequence and continue reading s as above.
To perform an annotated task read operation on a
b, perform the steps below:
on b with the
unset, along with the additional steps below.
terminates with a ,
to process read error with the
and terminate this algorithm.
When the first
is being pushed to the
s during the ,
to process read.
s from the
has at least one
read into it, or there are no s left to read from b,
to process read data. Keep
read or every 50ms, whichever is least frequent.
When all of the s from b are read into the
s from the ,
to process read EOF.
for all these tasks.
8.2. The File Reading Task Source
This specification defines a new generic
called the file reading task source, which is used for all
in this specification to read byte sequences associated with
It is to be used for features that trigger in response to asynchronously reading binary data.
8.3 The FileReader API
[Constructor, Exposed=Window,Worker]
interface FileReader: EventTarget {
void ( , optional DOMString );
const unsigned short
const unsigned short
const unsigned short
readonly attri
readonly attribute (DOMString or ArrayBuffer)? ;
readonly attribute ? ;
8.3.1. Constructors
When the FileReader() constructor is invoked, the user agent must return a new
In environments where the global object is represented by a Window or a WorkerGlobalScope object, the FileReader constructor
must be available.
8.3.2. Event Handler Attributes
The following are the
(and their corresponding ) that user agents must support on
DOM attributes:
onloadstart
onprogress
8.3.3. FileReader States
object can be in one of 3 states.
readyState attribute, on getting,
must return the current state, which must be one of the following values:
EMPTY (numeric value 0)
The FileReader object has been constructed, and there are no pending reads.
None of the
have been called.
This is the
default state of a newly minted FileReader object, until one of the
have been called on it.
LOADING (numeric value 1)
is being read.
One of the
is being processed,
and no error has occurred during the read.
DONE (numeric value 2)
The entire
has been read into memory,
OR a , OR the read was
aborted using .
is no longer reading a
If readyState is set to DONE it means
at least one of the
have been called on this FileReader.
8.3.4. Reading a File or Blob
Multiple Reads
interface makes available three asynchronous read methods - , , and , which read files into memory.
If multiple concurrent read methods are called on the same
object, user agents must throw an InvalidStateError [] on any of the read methods that occur when
8.3.4.1. The result attribute
On getting, the result attribute returns a 's data as a DOMString, or as
an ArrayBuffer [], or null, depending on the
that has been called on the , and any errors that may have occurred.
The list below is normative for the result attribute and is the conformance criteria for this attribute:
On getting, if the
is EMPTY (no read method has been called)
then the result attribute must return null.
On getting, if an error in reading the
occurred (using any ),
then the result attribute must return null.
On getting, if the
used, the result attribute must return a DOMString that is a Data URL [] encoding of the
or 's data.
On getting, if the
and no error in reading the
has occurred,
then the result attribute must return a string representing the
data as a text string, and should decode the string into memory in the format specified
as a DOMString.
On getting, if the
and no error in reading the
has occurred,
then the result attribute must return an ArrayBuffer [] object.
8.3.4.2. The readAsDataURL(blob) method
When the readAsDataURL(blob) method is called, the user agent must run the steps below.
throw an InvalidStateError exception [] and .
method returns due to the algorithm being .
attribute of the
to return an InvalidStateError
at the . .
Otherwise set
Initiate an
argument as input and handle
per below.
with a , proceed to the .
run these substeps:
attribute to the
returned by the
DataURL []; on getting, the
attribute returns the
Data URL [].
Use the 's
attribute as part of the Data URL if it is available in keeping with the Data URL specification [].
attribute is not available on the
return a Data URL without a media-type.
Data URLs that do not have media-types [] must be treated as plain text by conforming user agents. [].
do NOT fire
8.3.4.3. The readAsText(blob, label) method
The readAsText() method can be called with an optional parameter, label, which is a DOMString argument that represents the label of an encoding []; if provided, it must be used as part of the
used when processing this method call.
When the readAsText(blob, label) method is called (the
argument is optional),
the user agent must run the steps below.
throw an InvalidStateError [] and terminate these steps.
method returns due to the algorithm being .
attribute of the
to return an InvalidStateError
at the . .
Otherwise set
Initiate an
argument as input and handle
per below.
with a , proceed to the .
run these substeps:
attribute to the
returned by the , represented as a string in a format determined by the .
do NOT fire
8.3.4.4. The readAsArrayBuffer(blob) method
When the readAsArrayBuffer(blob) method is called, the user agent must run the steps below.
throw an InvalidStateError exception [] and terminate these steps.
method returns due to the algorithm being .
attribute of the
to return an InvalidStateError
at the . .
method returns due to the algorithm being .
Otherwise set
Initiate an
argument as input and handle
per below.
with a , proceed to the .
run these substeps:
attribute to the
returned by the
as an ArrayBuffer [] object.
do NOT fire
8.3.4.5. Error Steps
These error steps are to
Set the 's
to null if it is not already set to null.
attribute on getting, the
attribute must be a
object that corresponds to the .
do NOT fire
returns due to the algorithm being terminated.
8.3.4.6. The abort() method
When the abort() method is called, the user agent must run the steps below:
If there are any
in an affiliated
, then remove those
from that task queue.
being processed.
8.3.4.7. Blob Parameters
The three , the three ,
parameter.
This section defines this parameter.
argument and must be a reference to a single
argument not obtained from the underlying OS file system.
8.4. Determining Encoding
When reading
objects using the
, the following encoding determination steps must be followed:
Let encoding be null
argument is present when calling the method, set encoding to the result of "getting an encoding" using the Encoding Specification [] for .
If the "getting an encoding" steps above return failure, then set encoding to null.
If encoding is null, and the
argument's
attribute is present, and it uses a Charset Parameter [], set encoding to the result of "getting an encoding" using the Encoding Specification
[] for the portion of the Charset Parameter that is a label of an encoding.
attribute of text/charset=UTF-8 then
"getting an encoding" is run using
as the label.
Note that user agents must parse and extract the portion of the Charset Parameter that constitutes a label of an encoding.
If the "getting an encoding" steps above return failure, then set encoding to null.
If encoding is null, then set encoding to utf-8.
"Decode" [] this
using fallback encoding encoding, and return the result.
On getting, the
attribute of the
object returns a string in encoding format.
The synchronous
method of the
object returns a string in encoding format.
8.5.10. Events
object must be the event target for all events in this specification.
When this specification says to fire a progress event called e (for some
ProgressEvent e at a given
reader as the ),
the following are normative:
The progress event e does not bubble.
e.bubbles must be false []
The progress event e is NOT cancelable. e.cancelable must be false []
The term "fire an event" is defined in DOM Core [].
Progress Events are defined in Progress Events
8.5.10.1. Event Summary
The following are the events that are fired at
is defined in
DOM Core [].
Event name
Fired when…
ProgressEvent
When the read starts.
ProgressEvent
While reading (and decoding)
ProgressEvent
When the read has been aborted. For instance, by invoking the
ProgressEvent
When the read has failed (see ).
ProgressEvent
When the read has successfully completed.
ProgressEvent
When the request has completed (either in success or failure).
8.5.10.2. Summary of Event Invariants
This section is informative.
The following are invariants applicable to
for a given asynchronous
in this specification:
has been fired, a corresponding
fires at completion of the read, EXCEPT if the
has been cancelled using
and a nthe event handler function for a
event the event handler function for a
event initiates a new read.
The events
are not coupled in a one-to-one manner.
This example showcases "read-chaining" namely initiating another read from within an event handler while the "first" read continues processing.
ECMAScript
reader.readAsText(file);
reader.onload = function(){reader.readAsText(alternateFile);}
reader.readAsText(file);
reader.abort();
reader.onabort = function(){reader.readAsText(updatedFile);}
event will fire when
has been completely read into memory.
event fires before .
event fires after any one of , , and
have fired.
At most one of , , and
fire for a given read.
event fires after .
8.6 Reading on Threads
Web Workers allow for the use of synchronous
read APIs,
since such reads on threads do not block the main thread.
This section defines a synchronous API, which can be used within Workers [].
Workers can avail of both the asynchronous API (the
object) and the synchronous API (the
8.6.1. The FileReaderSync API
This interface
provides methods to synchronously read
objects into memory.
[Constructor, Exposed=Worker]
interface FileReaderSync {
ArrayBuffer ( );
DOMString ( , optional DOMString );
DOMString ( );
8.6.1.1. Constructors
When the FileReaderSync() constructor is invoked, the user agent must return a new
In environments where the global object is represented by a WorkerGlobalScope object, the FileReaderSync constructor must be available.
8.6.1.2. The readAsText method
When the readAsText(blob, label) method is called (the
argument is optional), the following steps must be followed:
throw an InvalidStateError exception [] and terminate these steps.
Note: The method returns due to the algorithm being .
has been closed through the
method, throw an InvalidStateError exception [] and .
Note: The method returns due to the algorithm being .
Otherwise, initiate a
argument, and with the
set. If the read operation returns failure, throw the . .
If no error has occurred, return the result of the
represented as a string in a format determined through the
algorithm.
8.6.1.3. The readAsDataURL method
When the readAsDataURL(blob) method is called, the following steps must be followed:
throw an InvalidStateError exception [] and terminate these steps.
Note: The method returns due to the algorithm being .
has been closed through the
method, throw an InvalidStateError exception [] and .
Note: The method returns due to the algorithm being .
Otherwise, initiate a
argument, and with the
set. If the
returns failure, throw the . .
If no error has occurred, return the result of the
as a Data URL [] subject to the considerations below.
Use the 's
attribute as part of the Data URL if it is available in keeping with the Data URL specification [] .
attribute is not available on the
return a Data URL without a media-type.
Data URLs that do not have media-types [] must be treated as plain text by conforming user agents. [].
8.6.1.4. The readAsArrayBuffer method
When the readAsArrayBuffer(blob) method is called, the following steps must be followed:
throw an InvalidStateError exception [] and terminate these steps.
Note: The method returns due to the algorithm being .
has been closed through the
method, throw an InvalidStateError exception [] and .
Note: The method returns due to the algorithm being .
Otherwise, initiate a
argument, and with the synchronous flag set. If the
returns failure, throw the . .
If no error has occurred, return the result of the
as an ArrayBuffer [].
9. Errors and Exceptions
Error conditions can occur when reading files from the underlying filesystem.
The list below of potential error conditions is informative.
being accessed may not exist at the time one of the asynchronous
or synchronous
are called. This may be due to it having been moved or deleted after a reference to it was acquired (e.g. concurrent modification with another application).
may be unreadable.
This may be due to permission problems that occur after a reference to a
has been acquired
(e.g. concurrent lock with another application). Additionally, the
may have changed.
User agents MAY determine that some files are unsafe for use within Web applications.
A file may change on disk since the original file selection,
thus resulting in an invalid read.
Additionally, some file and directory structures may be considered restricted
by the u attempts to read from them may be considered a security violation.
9.1. Throwing an Exception or Returning an Error
This section is normative.
Error conditions can arise when reading a
can terminate due to error conditions when reading a File or a Blob; the particular error condition that causes a read operation to return failure or
is called a failure reason.
Synchronous read methods
exceptions of the type in the table below if there has been an error owing to a particular .
Asynchronous read methods use the error attribute of the
object, which must return a DOMError object [] of the most appropriate type from the table below if there has been an error owing to a particular , or otherwise return null.
Description and Failure Reason
NotFoundError
resource could not be found at the time the read was processed, this is the NotFound . For asynchronous read methods the
attribute must return a "NotFoundError"
and synchronous read methods must
a NotFoundError exception.
SecurityError
it is determined that certain files are unsafe for access within a Web application, this is the UnsafeFile
it is determined that too many read calls are being made on
resources, this is the TooManyReads .
For asynchronous read methods the
attribute may return a "SecurityError"
and synchronous read methods may
a SecurityError exception.
This is a security error to be used in situations not covered by any other .
NotReadableError
does not match the state of the underlying storage, this is the SnapshotState .
cannot be read, typically due due to permission problems that occur after a
has been established (e.g. concurrent lock on the underlying storage with another application) then this is the FileLock . For asynchronous read methods the
attribute must return a "NotReadableError"
and synchronous read methods must
a NotReadableError exception.
10. A URL for Blob and File reference
This section defines a scheme for a URL used to refer to
objects (and
10.1. Requirements for a New Scheme
This specification defines a scheme with URLs of the sort: blob:550ed4-a716-#aboutABBA.
This section provides some requirements and is an informative discussion.
This scheme should be able to be used with web APIs such as XMLHttpRequest [], and with elements that are designed to be used with HTTP URLs, such as the
img element [].
In general, this scheme should be designed to be used wherever URLs can be used on the web.
This scheme should have defined response codes, so that web applications can respond to scenarios where the resource is not found, or raises an error, etc.
This scheme should have an
policy and a
stipulation, to allow safe access to binary data from web applications.
URLs in this scheme should be used as a references to "in-memory" , and also be re-used elsewhere on the platform to refer to binary
resources (e.g. for video-conferencing
URLs in this scheme are designed for impermanence, since they will be typically used to access "in memory" resources.
Developers should have the ability to revoke URLs in this scheme, so that they no longer refer to
This includes scenarios
where file references are no longer needed by a program, but also other uses of
Consider a scenario where a
object can be exported from a drawing program which uses the canvas element and API [].
A snapshot of the drawing can be created by
exporting a .
This scheme can be used with the img [] element to
if the user deletes the snapshot, any reference to the snapshot in memory via a URL should be invalid, and hence the need to be able to revoke such a URL.
10.2. Discussion of Existing Schemes
This section is an informative discussion of existing schemes that may have been repurposed or reused for the use cases for URLs above, and justification for why a new scheme
is considered preferable.
These schemes include HTTP [], file [][], and a scheme such as
urn:uuid [].
One broad consideration in determining what scheme to use is providing something with intuitive appeal to web developers.
HTTP could be repurposed for the use c it already comes with well-defined request-response semantics that are already used by web applications.
resources are typically "in-memory"
resident (e.g. after a file has been read into memory), and are thus unlike "traditional" HTTP resources that are dereferenced via DNS.
While some user agents automatically
"proxy" the underlying file system on the local machine via an HTTP server (e.g. with URLs of the sort http://localhost), HTTP is not traditionally used with local resources.
Moreover, an important use case for these URLs are that they can be revoked with an API call.
HTTP URLs have traditionally been used for resources that may be more permanent
(and that are certainly not chiefly memory-resident, such as files that a web application can read).
Reusing the HTTP scheme might be confusing for web developers owing to well-established
The reuse of file URLs would involve changes to file URL use today, such as adding response codes.
While they are used inconsistently in web applications,
the structure of the URLs would change, and request-response behavior would have to be superimposed on what already works in a more-or-less ad-hoc manner.
Modifying this for the use cases
cited above is imprudent, given legacy usage.
Additionally, the use cases for a Blob URL scheme call for uses beyond the file system.
A scheme of the sort urn:uuid [] could be used, though use of this scheme is unprecedented in HTML and JavaScript web applications.
The urn:uuid scheme is very generic.
URLs in the scheme urn:uuid have the disadvantage of unfamiliarity and inconsistency across the web platform.
A new scheme has the advantage of being explicit about what is being referenced.
In theory, URLs make no guarantee about what sort of resource is obtained when t that is left to content labeling and media type.
But in practice, the name of the scheme creates an expectation about both the resource and the protocol of the request-response transaction.
Choosing a name that clarifies the primary use case - namely, access to memory-resident
resources - is a worthwhile compromise, and favors clarity, familiarity, and consistency across the web platform.
10.3. The Blob URL
A Blob URL must consist of the blob:
followed by
which must consist of a string tuple comprising the , the "/" (U+0024 SOLIDUS) character, and a UUID [; for an ABNF of UUID, see ]. A Blob URL may contain an optional . The Blob URL is serialized as a string according to the
algorithm.
A , if used,
has a distinct interpretation depending on the media type of the
resource in question (see ).
blob = scheme ":" origin "/" UUID [fragIdentifier]
scheme = "blob"
scheme is always "blob"
origin is a string representation of the .
UUID is as defined in [] and
fragIdentifier is optional and as defined in [] and
An example of a Blob URL might be blob:https://example.org/9115d58c-bcda-ff47-86e5-083e9a215304.
10.3.1. Origin of Blob URLs
s are created using
and/or , and are revoked using . The
must be the same as the
specified by the
at the time the method that created it -- either
-- was called. The
of a Blob URL, when serialized as a string, must conform to the Web Origin Specification's Unicode Serialization of an Origin algorithm [].
on Blob URLs must return a .
In practice this means that HTTP and HTTPS
are covered by this specification as valid origins for use with Blob URLs. This specification does not address the case of non-HTTP and non-HTTPS . For instance blob:file:///Users/arunranga/702efefb-c234-04f1b615ee (which uses the "file:" , which is part of the Blob URL's ) may have behavior that is undefined, even though user agents may treat such Blob URLs as valid.
10.3.2. Unicode Serialization of a Blob URL
The Unicode Serialization of a Blob URL is the value returned by the following algorithm, which is invoked by
Let result be the empty string. Append the string "blob" (that is, the Unicode code point sequence U+0062, U+006C, U+006F, U+0062) to result.
Append the ":" (U+003A COLON) character to result.
Let O be the
If the Unicode Serialization of an Origin algorithm [] on O returns null, user agents may substitute an implementation defined value for the return value of the Unicode Serialization of an Origin algorithm. Append the result of the Unicode Serialization of an Origin algorithm for O [] to result.
Append the "/" character (U+0024 SOLIDUS) to result.
Generate a UUID [] as a Unicode string and append it to result.
Return result.
10.3.3. Discussion of Fragment Identifier
The 's resolution and processing directives depend on the media type [] of a potentially retrieved representation, even though such
a retrieval is only performed if the
For example, in an HTML file [] the fragment
could be used to refer to an anchor within the file.
If the user agent does not recognize the media type of the resource, OR if a fragment is not
meaningful within the resource, it must ignore the fragment.
The fragment must not be used to only the blob:
constitute a valid resource identifier.
A valid Blob URL reference could look like: blob:http://example.org:0-e29b-41d4-a716-#aboutABBA where "#aboutABBA" might be an HTML fragment identifier referring to an
element with an id attribute of "aboutABBA".
is not used to identify the resource. Neither the
method nor the
method generate a fragment.
10.4. Dereferencing Model for Blob URLs
Specifications should be considered normative for parsing and fetching . The section below is for informational purposes only, and is not considered normative.
s are dereferenced when the user agent retrieves the resource identified by the Blob URL and returns it to the requesting entity. This section provides guidance on
with GET [] are supported. Specifically,
are only a subset of the following from HTTP []:
10.4.1. 200 OK
is used if the
has succeeded, and no
are generated.
10.4.2. Response Headers
Along with
responses, user agents use a Content-Type header [] that is equal to the value of the 's
attribute, if it is not the empty string.
Along with
responses, user agents use a Content-Length header [] that is equal to the value of the 's
attribute.
If a Content-Type header [] is provided, then user agents obtain and process that media type in a manner consistent with the Mime Sniffing specification [].
If a resource identified with a
object, user agents use that file's
attribute, as if the
had a Content-Disposition header with the filename parameter set to the 's
attribute [].
A corollary to this is a non-normative implementation guideline: that the "File Save As" user interface in user agents takes into account the 's name attribute if presenting a default name to save the file as.
10.4.3. Network Errors
Responses that do not succeed with a
act as if a network error has occurred [].
Network errors are used when:
method other than GET is used.
does not have an entry in the .
The B this also results in the
not having an entry in the .
is made on a .
A security error has occurred.
10.4.4. Sample Request and Response Headers
This section is informative.
This section provides sample exchanges between web applications and user agents using .
can be triggered using HTML markup of the sort &img src="blob:http://example.org:0-e29b-41d4-a716-"&.
These examples merely
web developers are not likely to interact with all the headers, but the getAllResponseHeaders() method of XMLHttpRequest, if used, will show relevant
headers [].
could look like this:
has an affiliated media type [] represented by its
attribute, then the response message should include the Content-Type header from RFC7231 [].
If there is a
associated with the , then a user agent acts as if a
has occurred.
10.5. Creating and Revoking a Blob URL
are created and revoked using methods exposed on the
object, supported by
global objects Window [] and WorkerGlobalScope [].
Revocation of a
decouples the
from the resource it refers to, and if it is dereferenced after it is revoked, user agents must act as if a
has occurred.
This section describes a supplemental interface to the URL specification [] and presents methods for
creation and revocation.
partial interface URL {
static DOMString ( );
static DOMString ( );
static void (DOMString );
ECMAScript user agents of this specification must ensure that they do not expose a prototype property on the URL interface
object unless the user agent also implements the URL [] specification. In other words, URL.prototype must
evaluate to true if the user agent implements the URL [] specification, and must NOT evaluate to true otherwise.
10.5.1. Methods and Parameters
The createObjectURL static methodReturns a unique . This method must act as follows:
If called with a
argument that has a
of , user agents must return the output of the
No en consequently, when this
Otherwise, user agents must run the following sub-steps:
Let url be the result of the
algorithm.
for url and .
Return url.
The createFor static methodR s created with this method are said to be auto-revoking since user-agents are responsible for the revocation of s created with this method, subject to the
This method must act as follows:
If called with a
argument that has a
of , user agents must return the output of the
No en consequently, when this
Otherwise, user agents must run the following steps:
Let url be the result of the .
for url and .
Return url.
In the example below, after obtaining a reference to a
object (in this case, a user-selected
from the underlying file system), the static method URL.createObjectURL() is called on that
ECMAScript
var file = document.getElementById('file').files[0];
blobURLref = window.URL.createObjectURL(file);
myimg.src = blobURL
The revokeObjectURL static method
Revokes the
provided in the string
by removing the corresponding entry from the .
This method must act as follows:
refers to a
that has a
OR if the value provided for the
argument is not a , OR if the value provided for the
argument does not have an entry in the ,
this method call does nothing.
User agents may display a message on the error console.
Otherwise, user agents must
Subsequent attemps to dereference
result in a , since the entry has been removed from the .
The url argument to the
method is a
In the example below, window1 and window2 are separate, window2 could be an iframe
[] inside window1.
ECMAScript
myurl = window1.URL.createObjectURL(myblob);
window2.URL.revokeObjectURL(myurl);
Since window1 and window2 are in the
and share the same , the
URL.revokeObjectURL call ensures that subsequent dereferencing of myurl results in a the user agent acting as if a
has occurred.
10.5.2. Examples of Blob URL Creation and Revocation
s are strings that are used to
Blob objects, and can persist for as long as the document from which they were minted using
This section gives sample usage of creation and revocation of s with explanations.
In the example below, two img elements [] refer to the same :
ECMAScript
&script&url = URL.createObjectURL(blob); &/script&&script& img2.src=&/script&
In the example below,
is explicitly called.
ECMAScript
var blobURLref = URL.createObjectURL(file);
img1 = new Image();
img2 = new Image();
// Both assignments below work as expected
img1.src = blobURL
img2.src = blobURL
// ... Following body load
// Check if both images have loaded
plete && plete)
// Ensure that subsequent refs throw an exception
URL.revokeObjectURL(blobURLref);
msg("Images cannot be previewed!");
// revoke the string-based reference
URL.revokeObjectURL(blobURLref);
The example above allows multiple references to a single , and the web developer then revokes the
string after both image objects have been loaded.
While not restricting number of uses of the
offers more flexibility, it increases the developers should pair it with a corresponding call to URL.revokeObjectURL.
ECMAScript
var blobURLref2 = URL.createFor(file);
img1 = new Image();
img1.src = blobURLref2;
The example above uses , which allows uses such as the one above, and obviates the need for a corresponding call by the web developer to .
ECMAScript
// file is an HTML file
// One of the anchor identifiers in file is "#applicationInfo"
var blobURLAnchorRef = URL.createFor(file) + "#applicationInfo";
// openPopup is an utility function to open a small informational window
var windowRef = openPopup(blobURLAnchorRef, "Application Info");
The example above uses
to mint a , and appends a
that has an understood meaning within the resource (in this case, it references an anchor within the HTML document).
User agents are free to garbage collect resources removed from the .
11. Security Considerations
This section is informative.
This specification allows web content to read files from the underlying file system, as well as provides a means for files to be accessed by unique identifiers,
and as such is subject to some security considerations.
This specification also assumes that the
primary user interaction is with the &input type="file"/& element of HTML forms [], and that all files that are being read by
objects have first been selected by the user.
Important security considerations include preventing malicious file
selection attacks (selection looping), preventing access to system-sensitive files, and guarding against modifications of files on disk after a selection has taken place.
Preventing selection looping.
During file selection, a user may be bombarded with the file picker associated with &input
type="file"/& (in a "must choose" loop that forces selection before the file picker is dismissed) and a user agent may prevent file
access to any selections by making the
object returned be of size 0.
System-sensitive files (e.g. files in /usr/bin, password files, and other native operating system executables) typically should not
be exposed to web content, and should not be accessed via .
User agents may throw a
exception for synchronous read methods, or return a
for asynchronous reads.
This se more security data may supplement this in subsequent drafts.
12. Requirements and Use Cases
This section covers what the requirements are for this API, as well as illustrates some use cases.
This version of the API does not s
subsequent versions may elect to address these.
Once a user has given permission, user agents should provide the ability to read and parse data directly from a local file programmatically.
Example: A lyrics viewer. User wants to read song lyrics from songs in his plist file.
User browses for plist file.
File is opened,
read, parsed, and presented to the user as a sortable, actionable list within a web application.
User can select songs to fetch lyrics.
User uses the
"browse for file" dialog.
Data should be able to be stored locally so that it is available for later use, which is useful for offline data access for web applications.
Example: A Calendar App.
User's company has a calendar. User wants to sync local events to company calendar, marked
as "busy" slots (without leaking personal info).
User browses for file and selects it. The text/calendar file is parsed
in the browser, allowing the user to merge the files to one calendar view.
The user wants to then save the file back to his local calendar file. (using "Save As" ?).
The user can also send the
integrated calendar file back to the server calendar store asynchronously.
User agents should provide the ability to save a local file programmatically given an amount of data and a file name.
While this specification doesn't provide an explicit API call to trigger downloads, the HTML5 specification has addressed this. The download attribute of the a element [] initiates a download, saving a
with the name specified. The combination of this API and the download attribute on a elements allows for the creation of files within web applications, and the ability to save them locally.
Example: A Spreadsheet App.
User interacts with a form, and generates some input.
The form then generates a
CSV (Comma Separated Variables) output for the user to import into a spreadsheet, and uses "Save...".
The generated
output can also be directly integrated into a web-based spreadsheet, and
uploaded asynchronously.
User agents should provide a streamlined programmatic ability to send data from a file to a remote server that works more
efficiently than form-based uploads today
Example: A Video/Photo Upload App. User is able to select large files for upload, which can then be "chunk-transfered" to the server.
User agents should provide an API exposed to script that exposes the features above.
The user is notified by UI anytime interaction with the file
system takes place, giving the user full ability to cancel or abort the transaction.
The user is notified of any file selections, and can cancel these.
No invocations to these APIs occur silently without user intervention.
13. Appendix A
This section uses the Augmented Backus-Naur Form (ABNF), defined in [] to describe components of blob: URLs.
13.1. An ABNF for UUID
The following is an ABNF [] for UUID. UUID strings must only use characters in the ranges U+002A to U+002B, U+002D to U+002E, U+0030 to U+0039, U+0041 to U+005A, U+005E to U+007E [], and should be at least 36 characters long.
= time-low "-" time-mid "-"
time-high-and-version "-"
clock-seq-and-reserved
clock-seq-low "-" node
= 4hexOctet
= 2hexOctet
time-high-and-version
= 2hexOctet
clock-seq-and-reserved = hexOctet
clock-seq-low
= hexOctet
= 6hexOctet
= hexDigit hexDigit
hexDigit =
"0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" /
"a" / "b" / "c" / "d" / "e" / "f" /
"A" / "B" / "C" / "D" / "E" / "F"
13.2 An ABNF for Fragment Identifiers
fragIdentifier = "#" fragment
Fragment Identifiers depend on the media type of the Blob
fragment is defined in []
fragment processing for HTML is defined in []
= *( pchar / "/" / "?" )
= unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved
= ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded
= "%" HEXDIG HEXDIG
sub-delims
= "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
14. Acknowledgements
This specification was originally developed by the SVG Working Group. Many thanks to Mark Baker and Anne van Kesteren for their feedback.
Thanks to Robin Berjon for editing the original specification.
Special thanks to Olli Pettay, Nikunj Mehta, Garrett Smith, Aaron Boodman, Michael Nordman, Jian Li, Dmitry Titov, Ian Hickson, Darin Fisher, Sam Weinig, Adrian Bateman and Julian Reschke.
Thanks to the W3C WebApps WG, and to participants on the public-webapps@w3.org listserv
15. References
15.1. Normative references
, S. Bradner. IETF.
, I. Hickson, R. Berjon, S. Faulkner, T. Leithead, E. Doyle Navara, E. O'Connor, S. Pfeiffer. W3C.
Web Origin Concept
, A. Barth. IETF.
ProgressEvents
, A. van Kesteren. W3C.
, L. Masinter. IETF.
Web Workers
, I. Hickson. W3C.
, A. Gregor, A. van Kesteren, Ms2ger. W3C.
, J. D. Allen, D. Anderson, et al. Unicode Consortium.
, R. Fielding, J. Reschke. IETF.
, R. Fielding, J. Reschke. IETF.
, N. Freed, N. Borenstein. IETF.
, J. Reschke. IETF.
Encoding Specification
, A. van Kesteren, J. Bell.
Streams Specification
, Domenic Denicola, Takeshi Yoshino.
Typed Arrays
, V. Vukicevic, K. Russell. Khronos Group.
, D. Crocker, P. Overell. IETF.
URL Specification
, A. van Kesteren.
Fetch Specification
, A. van Kesteren. WHATWG.
WebIDL Specification
, C. McCormack.
ECMAScript
, A. Wirfs-Brock, P. Lakshman et al.
MIME Sniffing
, A. Barth, I. Hickson.
XMLHttpRequest
, A. van Kesteren.