1. 序論
◎非規範的~Web~appは、［ 利用者からの入力をアリな限り広範囲に操作する能 ］を有するべきである — ~fileを［ 利用者が望むなら~remote~serverへ~uploadする／ 多彩な~Web~appの中で操作する ］ことも含めて。 この仕様は、 次を定義する： ◎ 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＼
- 次についての基本的な表現 ⇒＃ ~file, ~fileたちが成す~list, ~fileに~accessする際の~error, ~fileを~program的に読取る仕方 ◎ the basic representations for files, lists of files, errors raised by access to files, and programmatic ways to read files.＼
- 適合~UAの~main~threadと非同期に処理できる， “生~data” を表現する~interface ◎ Additionally, this specification also defines an interface that represents "raw data" which can be asynchronously processed on the main thread of conforming user agents.＼
この仕様で定義される~interfaceと~APIは、 ~Web~platformに公開された他の~interfaceや~APIと伴に利用できるものになる。 ◎ The interfaces and API defined in this specification can be used with other interfaces and APIs exposed to the web platform.
`File$I ~interfaceは、 概して，（利用者~環境の）下層の~file~systemから得された~file~dataを表現する。 `Blob$I ~interface （ "`Binary Large Object^en" — 元々は `Google Gears＠https://developers.google.com/gears/?csw=1$en の~Web~APIに由来する名称） は、 変異-不能な生~dataを表現する。 ［ `File$I ／ `Blob$I ］の読取りは，~main~threadと非同期に行われるべきものであり、 ~thread化された~Web~app【~worker環境下】においては，同期~APIを利用する選択肢もある。 非同期~APIで~fileを読取ることにより、 ~UAの~main~threadにおける~UIの “無反応”は，防止される。 ◎ The File interface represents file data typically obtained from the underlying file system, and the Blob interface ("Binary Large Object" - a name originally introduced to web APIs in Google Gears) represents immutable raw data. File or Blob 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.＼
この仕様は、［ `File$I ／ `Blob$I ］~dataの読取nと~access用に，`~event~model^emに基づく非同期~APIを定義する。 `FileReader$I ~objは、［ ~event~handler内容~属性と~eventの発火を通して~file~dataへ~accessする ］ための`非同期~読取n~method$を供する。 ~eventと~event~handlerを利用することで、［ `読取nの進捗^emを監視するとき （~file~accessの処理能が~local~driveとは異なる， ~remote~driveや~mountされた~drive用に特に有用になる） ］と［ ~file読取n中に起こり得る`~error条件$を監視するとき ］とで，別々な~code~blockを利用できるようになる — 次の例に示されるように： ◎ This specification defines an asynchronous API based on an event model to read and access a File or Blob’s data. A FileReader object provides asynchronous read methods to access that file’s data through event handler content 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.
次の例では、［ 進捗, ~error, 成功 ］各~条件を異なる~code~blockで取扱う。 ◎ In the example below, different code blocks handle progress, error, and success conditions.
function startRead() {
/*
`input$e 要素を~DOMから得する
◎
obtain input element through DOM
*/
var %file = document.getElementById('file').files[0];
if(%file){
getAsText(%file);
}
}
function getAsText(%readFile) {
var %reader = new FileReader();
/*
~UTF-16として~fileを~memory内に読取る
◎
Read file into memory as UTF-16
*/
%reader.readAsText(%readFile, "UTF-16");
/*
進捗, 成功, ~error を取扱う
◎
Handle progress, success, and errors
*/
%reader.onprogress = updateProgress;
%reader.onload = loaded;
%reader.onerror = errorHandler;
}
function updateProgress(%evt) {
if (%evt.lengthComputable) {
/*
%evt . `loaded^m および %evt . `total^m は `ProgressEvent$I の~prop
◎
evt.loaded and evt.total are ProgressEvent properties
*/
var %loaded = (%evt.loaded / %evt.total);
if (%loaded < 1) {
/*
進捗~barの長さを増やす
◎
Increase the prog bar length
*/
// style.width = (%loaded * 200) + "px";
}
}
}
function loaded(%evt) {
/*
読取られた~file~data（この事例では文字列）を得する
◎
Obtain the read file data
*/
var %fileString = %evt.target.result;
/*
得られた~dataを取扱う
◎
Handle UTF-16 file dump
*/
if(utils.regexp.isChinese(%fileString)) {
/*
Chinese 文字~並びの~~処理
◎
Chinese Characters + Name validation
*/
}
else {
/*
他の~charsetについての~test
◎
run other charset test
*/
}
// xhr.send(%fileString)
}
function errorHandler(%evt) {
if(%evt.target.error.name == "NotReadableError") {
/*
~fileを読取れなかった
◎
The file could not be read
*/
}
}
2. 各種用語と~algo
この仕様において，~algoを `終了-@ する所では、 ~UAが~~実行中の段を終えた所で~algoを終了するモノトスル。 この仕様が定義する`非同期~読取n~method$は、 当の~algo【が並列的に走らす下位-手続き】が終了する前に返ることも， `abort()$m ~callにより終了されることもある。 ◎ When this specification says to terminate an algorithm the user agent must terminate the algorithm after finishing the step it is on. Asynchronous read methods defined in this specification may return before the algorithm in question is terminated, and can be terminated by an abort() call.
整数 %a, %b に対する［ `max^op( %a, %b ) ／ `min^op( %a, %b ) ］は、 %a, %b の［ 最大値／最小値 ］を返す。 ◎ 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 [WebIDL]; in the case of max(6,4) the result is 6. This operation is also defined in ECMAScript [ECMA-262]. ◎ min(a,b) returns the minimum of a and b, and is always performed on integers as they are defined in WebIDL [WebIDL]; in the case of min(6,4) the result is 4. This operation is also defined in ECMAScript [ECMA-262]. ◎ Mathematical comparisons such as < (less than), ≤ (less than or equal to), and > (greater than) are as in ECMAScript [ECMA-262].
用語 `~Unix~epoch@ （ `Unix Epoch^en ）は、 UTC 1970年 1月 1日 午前 0時 0分 0秒を指す…† ◎ The term Unix Epoch is used in this specification to refer to the time 00:00:00 UTC on January 1 1970 (or 1970-01-01T00:00:00Z ISO 8601); this is the same time that is conceptually "0" in ECMA-262 [ECMA-262].
【† `HR-TIME$r に定義される`~Unix~epoch＠~HRTIME#dfn-unix-epoch$と同じ。 この用語を利用して時間を導出している箇所は、 おそらく同~仕様に定義される用語に基づくよう，更新されるべきであろう。 】
`~blobを切出す@ ~algoは、 所与の ⇒＃ `Blob$I %~blob, 整数 %始端（省略時は ~NULL ）, 整数 %終端（省略時は ~NULL ）, 文字列 %内容~型（省略時は ~NULL ） ◎終 に対し，次の手続きを走らす — これは、 次のような新たな `Blob$I ~objを返す：
- その`~byte列~data$は、 %~blob の`~byte列~data$の中の［ %始端 （ 0 から数える）から %終端 の直前まで ］の範囲を成す~byte列になる。
- その~MIME型（ `type$m 属性）は、 %内容~型 になる。
- %元の~size ~LET %~blob の `size$m ◎ Let originalSize be blob’s size.
- %始端 ~SET %始端 に応じて ⇒＃ ~NULL ならば 0 ／ 負ならば `max^op( ( %元の~size ~PLUS %始端 ), 0) ／ ~ELSE_ `min^op( %始端, %元の~size ) ◎ The start parameter, if non-null, is a value for the start point of a slice blob call, and must be treated as a byte-order position, with the zeroth position representing the first byte. User agents must normalize start according to the following: • If start is null, let relativeStart be 0. • If start is negative, let relativeStart be max((originalSize + start), 0). • Otherwise, let relativeStart be min(start, originalSize).
- %終端 ~SET %終端 に応じて ⇒＃ ~NULL ならば %元の~size ／ 負ならば `max^op( ( %元の~size ~PLUS %終端 ), 0 ) ／ ~ELSE_ `min^op( %終端, %元の~size ) ◎ The end parameter, if non-null. is a value for the end point of a slice blob call. User agents must normalize end according to the following: • If end is null, let relativeEnd be originalSize. • If end is negative, let relativeEnd be max((originalSize + end), 0). • Otherwise, let relativeEnd be min(end, originalSize).
- ~IF［ %内容~型 ~NEQ ~NULL ］~AND［ %内容~型 を成すどの文字も 範囲 { `0020^U 〜 `007E^U } に入る ］ ⇒ %内容~型 ~SET `~ASCII小文字~化する$( %内容~型 ) ◎ The contentType parameter, if non-null, is used to set the ASCII-encoded string in lower case representing the media type of the Blob. User agents must normalize contentType according to the following: • If contentType is null, let relativeContentType be set to the empty string. • Otherwise, 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 ASCII lowercase.
- ~ELSE ⇒ %内容~型 ~SET 空~文字列 ◎ ↑
- %~span ~LET `max^op( ( %終端 ~MINUS %始端 ), 0 ) ◎ Let span be max((relativeEnd - relativeStart), 0).
- %~data ~LET %~blob の`~byte列~data$の中の［ ~byte位置 %始端 から連続する %~span 個の~byte ］たちが成す`~byte列$ ◎ ↓
- ~RET `新たな~obj$( `Blob$I, %~blob に`関連な~realm$ ) — その ⇒＃ `~byte列~data$ ~SET %~data, `size$m 属性 ~SET %~span, `type$m 属性 ~SET %内容~型 ◎ Return a new Blob object S with the following characteristics: • S refers to span consecutive bytes from blob’s associated byte sequence, beginning with the byte at byte-order position relativeStart. • S.size = span. • S.type = relativeContentType.
【この訳に特有な表記規約】
◎表記記号`~Blob@ とは、 `Blob$I ~interfaceを実装する~objの略記である （したがって， `File$I ~objも含まれる）。
`~file入力~要素@ とは、 `input$e 要素のうち［ その `type^a 属性の状態 ~EQ `File$st ］を満たすものである。 `HTML$r
原文が参照している他の仕様の用語には、 今や，廃された／改称されたものもある。 この訳では、 その現在の仕様に揃うよう改めている：
- 原文の “`media type^en” に代えて、 “`~MIME型$（ `MIME type^en ）” を利用している。 `MIMESNIFF$r
- 原文が参照していた用語 `構文解析-可能な~MIME型@ は、 今や `MIMESNIFF$r から廃された。 おそらく，この用語を利用している箇所は、 `妥当な~MIME型~文字列$を利用するべきであろう。
3. `Blob^I ~interfaceと~binary~data
各`~Blob$は、 `~byte列~data@ を参照rする。 ~Blobの ⇒＃ `size$m 属性は，この~dataの総~byte数を表現する／ `type$m 属性は，この~dataの~MIME型を（~ASCII小文字に符号化された文字列として）表現する ◎ A Blob object refers to a byte sequence, and has a size attribute which is the total number of bytes in the byte sequence, and a type attribute, which is an ASCII-encoded string in lower case representing the media type of the byte sequence.
各`~Blob$は、 `~snapshot状態@ を内部的に有する — それは、 `~byte列~data$が下層~storageから得られた場合に限り， 当の~storageの状態に初期化するモノトスル 【他の場合、~snapshot状態は “無い” 】。 `~snapshot状態$についての更なる規範的な定義は、 § `File^I ~interface にて見出せる。 ◎ Each Blob must have an internal snapshot state, which must be initially set to the state of the underlying storage, if any such underlying storage exists. Further normative definition of snapshot state can be found for Files.
[ `Exposed$=(Window,Worker), `Serializable$]
interface `Blob@I {
`Blob$mc(
optional `sequence$<`BlobPart$I> `blobParts$V,
optional `BlobPropertyBag$I `options$V = {}
);
readonly attribute `unsigned long long$ `size$m;
readonly attribute `DOMString$ `type$m;
/*
~Blobから~byte範囲の~chunkを切出す
◎
slice Blob into byte-ranged chunks
*/
Blob `slice$m(
optional [`Clamp$] `long long$ %start,
optional [`Clamp$] `long long$ %end,
optional `DOMString$ %contentType
);
/*
~Blobから読取る。
◎
read from the Blob.
*/
[`NewObject$] `ReadableStream$I `stream$m();
[`NewObject$] `Promise$<`USVString$> `text$m();
[`NewObject$] `Promise$<`ArrayBuffer$> `arrayBuffer$m();
[`NewObject$] `Promise$<`Uint8Array$> `bytes$m();
};
enum `EndingType@I { `transparent@l, `native@l };
dictionary `BlobPropertyBag@I {
`DOMString$ `type$dm = "";
`EndingType$I `endings$dm = `transparent$l;
};
typedef (`BufferSource$ or `Blob$I or `USVString$) `BlobPart@I;
`Blob$I ~objは、 `直列化-可能$である： ◎ Blob objects are serializable objects.＼
-
その`直列化~手続き$は、 所与の ( %値, %直列形 ) に対し，次を走らす： ◎ Their serialization steps, given value and serialized, are:
- %直列形 . `SnapshotState^sl ~SET %値 の`~snapshot状態$ ◎ Set serialized.[[SnapshotState]] to value’s snapshot state.
- %直列形 . `ByteSequence^sl ~SET %値 の下層の~byte列 ◎ Set serialized.[[ByteSequence]] to value’s underlying byte sequence.
-
その`逆直列化~手続き$は、 所与の ( %値, %直列形, %宛先~realm ) に対し，次を走らす： ◎ Their deserialization step, given serialized and value, are:
- %値 の`~snapshot状態$ ~SET %直列形 . `SnapshotState^sl ◎ Set value’s snapshot state to serialized.[[SnapshotState]].
- %値 の下層の~byte列 ~SET %直列形 . `ByteSequence^sl ◎ Set value’s underlying byte sequence to serialized.[[ByteSequence]].
各`~Blob$ %~blob には、 `~streamを取得する@ ~algoが結付けられる — それは、 次の手続きを走らす： ◎ A Blob blob has an associated get stream algorithm, which runs these steps:
- %~stream ~LET `新たな~obj$( `ReadableStream$I, %~blob に`関連な~realm$ ) ◎ Let stream be a new ReadableStream created in blob’s relevant Realm.
- %~stream を`~byte読取り~support付きで設定しておく$RS() ◎ Set up stream with byte reading support.
-
この段は`並列的$に走らす： ◎ Run the following steps in parallel:
-
~WHILE［ %~blob 内にまだ読取っていない~byteがある ］： ◎ While not all bytes of blob have been read:
- %~byte列 ~LET %~blob から`~chunk$を［ 読取れるならば その結果を成す`~byte列$／ 読取れないならば `失敗^i ］ ◎ Let bytes be the byte sequence that results from reading a chunk from blob, or failure if a chunk cannot be read.
-
`大域~taskを~queueする$( `~file読取り~task~source$, %~blob に`関連な大域~obj$, 次の手続き ) ◎ Queue a global task on the file reading task source given blob’s relevant global object to perform the following steps:
手続きは： ◎ ↑
- ~IF［ %~byte列 ~EQ `失敗^i ］ ⇒＃ %~stream を`~errorにする$RS( `失敗~事由$ )； ~RET ◎ If bytes is failure, then error stream with a failure reason and abort these steps.
- %~chunk ~LET `~buffer~sourceを~byte列から作成する$( `Uint8Array$I, %~byte列, %~blob に`関連な~realm$ ) ⇒ 例外 %e が投出されたときは ⇒＃ %~stream を`~errorにする$RS( %e )； ~RET ◎ Let chunk be a new Uint8Array wrapping an ArrayBuffer containing bytes.＼ If creating the ArrayBuffer throws an exception, then error stream with that exception and abort these steps.
- %~stream に`~chunkを~enqueueする$RS( %~chunk ) ◎ Enqueue chunk in stream.
~Blobからの読取りが実際には何を行うか，起こり得る~errorは何かについて、 もっと具体的に指定する必要がある — たぶん，~chunk~sizeについての何か, 等々。 ◎ We need to specify more concretely what reading from a Blob actually does, what possible errors can happen, perhaps something about chunk sizes, etc.
-
- ~RET %~stream ◎ Return stream.
3.1. 構築子
`new Blob(blobParts, options)@m 構築子~手続きは：
- %~MIME型 ~LET 空~文字列
- %~byte列 ~LET 空~byte列
- ~IF［ %blobParts ~NEQ ε ］ ⇒ %~byte列 ~LET `~blobを成す各部を処理する$( `blobParts$V, `options$V )
- %type ~LET `options$V[ "`type$dm" ]
- ~IF［ %type ~NEQ ε ］~AND［ %type を成すどの文字も 範囲 { `0020^U 〜 `007E^U } に入る ］ ⇒ %~MIME型 ~SET `~ASCII小文字~化する$( %type )
- コレの ⇒＃ `~byte列~data$ ~SET %~byte列, `size$m ~SET %~byte列 の長さ, `type$m ~SET %~MIME型
`new Blob()$m 構築子は、 次を引数に呼出せる： ◎ 3.1.1. Constructor Parameters" The Blob() constructor can be invoked with the parameters below:
- `blobParts@V ⇒ 任意個数の要素たちが成す~IDL連列~型の引数 — 各~要素ごとに、 次のいずれかの型の値をとり得る ⇒ `BufferSource$I ／ `Blob$I ／ `USVString$I ◎ A blobParts sequence • which takes any number of the following types of elements, and in any order: •• BufferSource elements. •• Blob elements. •• USVString elements.
-
`options@V （省略可能, `BlobPropertyBag$I 型）は、 次の~memberを有する： ◎ An optional BlobPropertyBag • which takes these optional members:
- `type@dm
- `~Blob$の~MIME型を表現する，~ASCII小文字に符号化された文字列。 この~member用の規範的な条件は、 `new Blob()$m 構築子 にて与えられる。 ◎ type, the ASCII-encoded string in lower case representing the media type of the Blob. Normative conditions for this member are provided in the § 3.1 Constructors.
- `endings@dm
- 次のいずれかををとり得る ⇒ `transparent$l （既定の値）／ `native$l ◎ endings, an enum which can take the values "transparent" or "native".＼
- `native$l に設定された場合、 `blobParts$V 内の各 `USVString$I は，`~native行末に変換-$されることになる ◎ By default this is set to "transparent". If set to "native", line endings will be converted to native in any USVString elements in blobParts.
`~blobを成す各部を処理する@ ときは、 所与の ( `BlobPart$I 値たちが成す連列 %parts, `BlobPropertyBag$I 型の値 %options ) に対し，次を走らす： ◎ To process blob parts given a sequence of BlobPart's parts and BlobPropertyBag options, run the following steps:
- %~byte列 ~LET 空`~byte列$ ◎ Let bytes be an empty sequence of bytes.
-
%parts を成す ~EACH( %e ) に対し ⇒ %~byte列 に［ 次の手続きの結果 ］を付加する： ◎ For each element in parts:
手続きは、 %e の型に応じて，次を走らす： ◎ ↓
- `USVString$I ◎ If element is a USVString, run the following substeps:
-
- ~IF［ %options の `endings$dm ~member ~EQ `native$l ］ ⇒ %e ~SET `~native行末に変換する$( %e ) ◎ Let s be element. ◎ If the endings member of options is "native", set s to the result of converting line endings to native of element.
- ~RET `~UTF-8符号化する$( %e ) ◎ Append the result of UTF-8 encoding s to bytes.
- 注記： 渡された`~JS文字列$内の対を成さない（従って妥当でない）`~surrogate$は、 `USVString$I 型になるよう`~scalar値~文字列に変換する$ときに， `FFFD^U 置換~文字に置換される。 そのため、 `Blob$I 構築子においては，文字~並びの喪失や並び替わりに因る何らかの~data欠損も生じ得る。 ◎ Note: The algorithm from WebIDL [WebIDL] replaces unmatched surrogates in an invalid utf-16 string with U+FFFD replacement characters. Scenarios exist when the Blob constructor may result in some data loss due to lost or scrambled character sequences.
- `BufferSource$I
- ~RET %e に`保持された~byte列の複製を取得する$ ◎ If element is a BufferSource, get a copy of the bytes held by the buffer source, and append those bytes to bytes.
- `~Blob$
- ~RET %e が表現する~byte列 ◎ If element is a Blob, append the bytes it represents to bytes.
- %e の `type$m 属性は無視され、 返される`~Blob$の `type$m には影響しない。 ◎ Note: The type of the Blob array element is ignored and will not affect type of returned Blob object.
- ~RET %~byte列 ◎ Return bytes.
`~native行末に変換する@ ときは、 所与の ( `文字列$ %s ) に対し，次を走らす： ◎ To convert line endings to native in a string s, run the following steps:
- %CR ~LET `文字$ `000D^U CR ◎ ↓
- %LF ~LET `文字$ `000A^U LF ◎ ↓
- %~native行末 ~LET ［ 下層の~platform規約は 改行文字を［ %CR, %LF ］並びとして表現するならば その並び ／ ~ELSE_ %LF のみ ］が成す文字列 ◎ Let native line ending be the code point U+000A LF. ◎ If the underlying platform’s conventions are to represent newlines as a carriage return and line feed sequence, set native line ending to the code point U+000D CR followed by the code point U+000A LF.
- %結果 ~LET 空`文字列$ ◎ Set result to the empty string.
- %位置 ~LET %s の先頭を指している`位置~変数$ ◎ Let position be a position variable for s, initially pointing at the start of s.
-
~WHILE %位置↗ ~NEQ ε ◎ ＊不要 Let token be the result of collecting a sequence of code points that are not equal to U+000A LF or U+000D CR from s given position. ◎ Append token to result. ◎ While position is not past the end of s:
-
~IF［ %位置↗ ~IN { %CR, %LF } ］：
- %結果 に %~native行末 を付加する
- ~IF［ %位置↗ ~EQ %CR ］~AND［ ( %位置 ~PLUS 1 )↗ ~EQ %LF ］ ⇒ %位置 ~INCBY 1
- %位置 ~INCBY 1
- %結果 に次の結果を付加する ⇒ %s 内の %位置 から［ %LF, %CR ］でない`符号位置~並びを収集する$ ◎ Let token be the result of collecting a sequence of code points that are not equal to U+000A LF or U+000D CR from s given position. ◎ Append token to result.
-
- ~RET %結果 ◎ Return result.
構築子の用法： ◎ Examples of constructor usage follow.
/* 新たな `Blob^I ~objを作成する ◎ Create a new Blob object */ var %a = new Blob(); /* 1024 ~byteの `ArrayBuffer^I を作成する ◎ Create a 1024-byte ArrayBuffer */ /* ~bufferは `File^I 読取nからも得られる ◎ buffer could also come from reading a File */ var %buffer = new ArrayBuffer(1024); /* ~bufferに基づく `ArrayBufferView^I ~objを作成する ◎ Create ArrayBufferView objects based on buffer */ var %shorts = new Uint16Array(%buffer, 512, 128); var %bytes = new Uint8Array( %buffer, %shorts.byteOffset + %shorts.byteLength ); var %b = new Blob( ["foobarbazetcetc" + "birdiebirdieboo"], {type: "text/plain;charset=utf-8"} ); var %c = new Blob([%b, %shorts]); var %a = new Blob([%b, %c, %bytes]); var %d = new Blob([%buffer, %b, %c, %bytes]);
3.2. 属性
- `size@m
- 取得子は、［ `FileReader$I ／ `FileReaderSync$I ］~objにより読取られた，`~byte列~data$の総~byte数を返すモノトスル。 ◎ size, of type unsigned long long, readonly ◎ Returns the size of the byte sequence in number of bytes.＼ ◎ On getting, conforming user agents must return the total number of bytes that can be read by a FileReader or FileReaderSync object, or 0 if the Blob has no bytes to be read.
- `type@m
- `~Blob$の~MIME型を表現する，~ASCII小文字に符号化された文字列。 ◎ type, of type DOMString, readonly ◎ The ASCII-encoded string in lower case representing the media type of the Blob.＼
- 取得子は、 ~byte列に変換した結果が`構文解析-可能な~MIME型$になるような，~ASCII小文字に符号化された文字列 — ただし，`~Blob$の~MIME型を決定できない場合は 空~文字列（~byte列に変換されたときに 0 ~byteになる） — を返すモノトスル。 ◎ 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 byte sequence, it is a parsable MIME type, or the empty string – 0 bytes – if the type cannot be determined.
- `type$m 属性は、 ~Web~app自身からも［ 構築子／ `slice()$m ］の~callを通して設定できる。 これらの場合に更に適用される規範的な条件は、［ `new Blob()$m 構築子, `new File()$m 構築子, `slice()$m ~method ］にて与えられる。
- ~UAは — とりわけ `~byte列~data$が~disk上の~file由来のものである場合には — `type$m 属性を決定できる。 この場合に適用される更なる規範的な条件は、 `~file型~指針$にて与えられる。 ◎ The type attribute can be set by the web application itself through constructor invocation and through the slice() call; in these cases, further normative conditions for this attribute are in § 3.1 Constructors, § 4.1 Constructor, and § 3.3.1 The slice() method respectively. User agents can also determine the type of a Blob, especially if the byte sequence is from an on-disk file; in this case, further normative conditions are in the file type guidelines.
- 注記： `type$m 属性は、 それを表現している~ASCIIに符号化された文字列を~byte列に変換した結果を `~MIME型を構文解析する$~algoに渡した結果が `失敗^i でないとき，`構文解析-可能な~MIME型$であるものと見なされる。 ◎ Note: The type t of a Blob is considered a parsable MIME type, if performing the parse a MIME type algorithm to a byte sequence converted from the ASCII-encoded string representing the Blob object’s type does not return failure.
- 注記： `type$m 属性の利用は、 `~dataを梱包する$~algoに伝えられ，`~blob~URL$を`~fetch$する際の `Content-Type^h ~headerを決定する。 ◎ Note: Use of the type attribute informs the package data algorithm and determines the Content-Type header when fetching blob URLs.
3.3. ~method
`slice(start, end, contentType)@m ~method手続きは： ◎ 3.3.1. The slice() method ◎ The slice() method returns a new Blob object with bytes ranging from the optional start parameter up to but not including the optional end parameter, and with a type attribute that is the value of the optional contentType parameter. It must act as follows: • Let sliceStart, sliceEnd, and sliceContentType be null.
- ~IF［ %start ~EQ ε ］ ⇒ %start ~SET ~NULL ◎ If start is given, set sliceStart to start.
- ~IF［ %end ~EQ ε ］ ⇒ %end ~SET ~NULL ◎ If end is given, set sliceEnd to end.
- ~IF［ %contentType ~EQ ε ］ ⇒ %contentType ~SET ~NULL ◎ If contentType is given, set sliceContentType to contentType.
- ~RET `~blobを切出す$( コレ, %start, %end, %contentType ) ◎ Return the result of slice blob given this, sliceStart, sliceEnd, and sliceContentType.
`slice()$m の用例 — この例では、 `Blob$I ~interfaceを継承する `File$I ~interfaceを利用している： ◎ The examples below illustrate the different types of slice() calls possible. Since the File interface inherits from the Blob interface, examples are based on the use of the File interface.
/* ~DOMから得される `input$e 要素から， `File$I ~objを得る ◎ obtain input element through DOM */ var %file = document.getElementById('file').files[0]; if(%file) { /* %file を複製する — 次の 2 つの~callは等価 ◎ create an identical copy of file the two calls below are equivalent */ var %fileClone = %file.slice(); var %fileClone2 = %file.slice(0, %file.size); /* %file の後半を成す~chunkを切出す — 負な数を利用していることに注意 ◎ slice file into 1/2 chunk starting at middle of file Note the use of negative number */ var %fileChunkFromEnd = %file.slice(-(Math.round(%file.size/2))); /* %file の前半を成す~chunkを切出す ◎ slice file into 1/2 chunk starting at beginning of file */ var %fileChunkFromStart = %file.slice(0, Math.round(%file.size/2)); /* %file の［ 先頭から，末尾から 150 ~byte手前まで ］の部分を切出す ◎ slice file from beginning till 150 bytes before end */ var %fileNoMetadata = %file.slice(0, -150, "application/experimental"); }
`text()@m ~method手続きは： ◎ 3.3.3. The text() method ◎ The text() method, when invoked, must run these steps:
- %~stream ~LET コレの`~streamを取得する$() ◎ Let stream be the result of calling get stream on this.
- %読取器 ~LET %~stream 用の`読取器を取得する$RS() ⇒ 例外 %e が投出されたときは ⇒ ~RET `却下される~promise$( %e ) ◎ Let reader be the result of getting a reader from stream. If that threw an exception, return a new promise rejected with that exception.
- %~promise ~LET %読取器 から`すべての~byteを読取る$RSR() 【この段とそれに関係する処理nは、まだ `STREAMS$r による更新が`反映されていない$x。】 ◎ Let promise be the result of reading all bytes from stream with reader.
-
~RET `~promiseに反応する$( %~promise ) — `充足~手続き^i として次を与える下で： ◎ Return the result of transforming promise by a fulfillment handler＼
手続きは、 所与の ( %入力 ) に対し ⇒ ~RET `~UTF-8復号する$( %入力 ) ◎ that returns the result of running UTF-8 decode on its first argument.
注記： `readAsText()$m の挙動とは異なり、 これは， `Fetch$r による `text()＠~FETCH#dom-body-text$m の挙動に近く揃うようにしている。 特定的には、 この~methodは，符号化法として常に~UTF-8を利用する一方で、 `FileReader$I は，~blobの型, 渡された符号化法の名前に依存して異なる符号化法が利用され得る。 ◎ Note: This is different from the behavior of readAsText() to align better with the behavior of Fetch’s text(). Specifically this method will always use UTF-8 as encoding, while FileReader can use a different encoding depending on the blob’s type and passed in encoding name.
`arrayBuffer()@m ~method手続きは： ◎ 3.3.4. The arrayBuffer() method ◎ The arrayBuffer() method, when invoked, must run these steps:
- %~stream ~LET コレの`~streamを取得する$() ◎ Let stream be the result of calling get stream on this.
- %読取器 ~LET %~stream 用の`読取器を取得する$RS() ⇒ 例外 %e が投出されたときは ⇒ ~RET `却下される~promise$( %e ) ◎ Let reader be the result of getting a reader from stream. If that threw an exception, return a new promise rejected with that exception.
- %~promise ~LET %読取器 から`すべての~byteを読取る$RSR() 【この段とそれに関係する処理nは、まだ `STREAMS$r による更新が`反映されていない$x。】 ◎ Let promise be the result of reading all bytes from stream with reader.
-
~RET `~promiseに反応する$( %~promise ) — `充足~手続き^i として次を与える下で： ◎ Return the result of transforming promise by a fulfillment handler＼
手続きは、 所与の ( %入力 ) に対し ⇒ ~RET `~buffer~sourceを~byte列から作成する$( `ArrayBuffer$I, %入力, コレに`関連な~realm$ ) ◎ that returns a new ArrayBuffer whose contents are its first argument.
`bytes()@m ~method手続きは： ◎ 3.3.5. The bytes() method ◎ The bytes() method, when invoked, must run these steps:
- %~stream ~LET コレの`~streamを取得する$() ◎ Let stream be the result of calling get stream on this.
- %読取器 ~LET %~stream 用の`読取器を取得する$RS() ⇒ 例外 %e が投出されたときは ⇒ ~RET `却下される~promise$( %e ) ◎ Let reader be the result of getting a reader from stream. If that threw an exception, return a new promise rejected with that exception.
- %~promise ~LET %読取器 から`すべての~byteを読取る$RSR() 【この段とそれに関係する処理nは、まだ `STREAMS$r による更新が`反映されていない$x。】 ◎ Let promise be the result of reading all bytes from stream with reader.
-
~RET `~promiseに反応する$( %~promise ) — `充足~手続き^i として次を与える下で： ◎ Return the result of transforming promise by a fulfillment handler＼
手続きは、 所与の ( %入力 ) に対し ⇒ ~RET `~buffer~sourceを~byte列から作成する$( `ArrayBuffer$I, %入力, コレに`関連な~realm$ ) ◎ that returns a new Uint8Array wrapping an ArrayBuffer containing its first argument.
4. `File^I ~interface
`File$I ~objは、［ 文字列を値にとる `name$m 属性 ］も伴う， `Blob$I ~objである。 それは、 ~Web~appの中で構築子を通して作成されるか，あるいは 下層の~OS~file~systemからの~fileを成す`~byte列$への参照である。 ◎ A File object is a Blob object with a name attribute, which is a string; it can be created within the web application via a constructor, or is a reference to a byte sequence from a file from the underlying (OS) file system.
`File$I ~objの`~byte列~data$が~disk上の~file由来の`~byte列$である場合、 その`~snapshot状態$は，~objの作成-時点における~fileの状態を~~反映するべきである。 ◎ If a File object is a reference to a byte sequence originating from a file on disk, then its snapshot state should be set to the state of the file on disk at the time the File object is created.
注記： これは、 ~UAにとって実装するのは自明でない要件なので， “`〜するモノトスル^em” ではなく “`〜するベキ^em” とされている `RFC2119$r。 ~UAは、 `File$I ~objの`~snapshot状態$が［ 参照が得られた時点における~disk上の下層~storageの状態 ］に設定されるよう，努めるべきである。 その時点より後に~disk上の~fileが改変された場合、 `~snapshot状態$は，下層~storageの状態とは異なるものになる。 ~UAは、 改変~時刻印その他の仕組みを利用して，`~snapshot状態$を保守してもヨイが、 それについては実装の詳細~に委ねられる。 ◎ Note: This is a non-trivial requirement to implement for user agents, and is thus not a must but a should [RFC2119]. User agents should endeavor to have a File object’s snapshot state 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 File's snapshot state will differ from the state of the underlying storage. User agents may use modification time stamps and other mechanisms to maintain snapshot state, but this is left as an implementation detail.
`File$I ~objが~disk上の~fileを参照rしている場合、 ~UAは，［ ~objの `type$m 属性の取得子が［ 以下に与える `~file型~指針@ に従う~MIME型 ］を返す ］ようにするモノトスル： ◎ When a File object refers to a file on disk, user agents must return the type of that file, and must follow the file type guidelines below:
-
~MIME型は、 次のようにすること：
- ~fileの~MIME型を決定できる場合 ⇒ ［ ~byte列に変換した結果が`構文解析-可能な~MIME型$になる ］ような，~ASCII小文字に符号化された文字列
- 他の場合 ⇒ 空~文字列（~byte列に変換されたときに 0 ~byteになる）
- ［ `~Blob$の `type$m ~EQ `text/plain^l ］の場合 ⇒ ~MIME型の［ `~parameter群$ `MIMESNIFF$r にあたる部位 ］には、 ~charset~parameterを`付加しない^emこと。 ◎ 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 [MIMESNIFF].
- 経験則（統計的~手法も含む）により符号化法を決定するよう試みないこと。 ◎ User agents must not attempt heuristic determination of encoding, including statistical methods.
[`Exposed$=(Window,Worker), `Serializable$]
interface `File@I : `Blob$I {
`File$mc(【！原文引数抜け】
`sequence$<`BlobPart$I> `fileBits$V,
`USVString$ `fileName$V,
optional `FilePropertyBag$I `fileOptions$V = {}
);
readonly attribute `DOMString$ `name$m;
readonly attribute `long long$ `lastModified$m;
};
dictionary `FilePropertyBag@I : `BlobPropertyBag$I {
`long long$ `lastModified$dm;
};
`File$I ~objは、 `直列化-可能$である： ◎ File objects are serializable objects.＼
-
その`直列化~手続き$は、 所与の ( %値, %直列形 ) に対し，次を走らす： ◎ Their serialization steps, given value and serialized, are:
- %直列形 . `SnapshotState^sl ~SET %値 の`~snapshot状態$ ◎ Set serialized.[[SnapshotState]] to value’s snapshot state.
- %直列形 . `ByteSequence^sl ~SET %値 の下層の~byte列 ◎ Set serialized.[[ByteSequence]] to value’s underlying byte sequence.
- %直列形 . `Name^sl ~SET %値 の `name$m 属性の値 ◎ Set serialized.[[Name]] to the value of value’s name attribute.
- %直列形 . `LastModified^sl ~SET %値 の `lastModified$m 属性の値 ◎ Set serialized.[[LastModified]] to the value of value’s lastModified attribute.
-
その`逆直列化~手続き$は、 所与の ( %値, %直列形, %宛先~realm ) に対し，次を走らす： ◎ Their deserialization steps, given value and serialized, are:
- %値 の`~snapshot状態$ ~SET %直列形 . `SnapshotState^sl ◎ Set value’s snapshot state to serialized.[[SnapshotState]].
- %値 の下層の~byte列 ~SET %直列形 . `ByteSequence^sl ◎ Set value’s underlying byte sequence to serialized.[[ByteSequence]].
- %値 の `name$m 属性~値 ~SET %直列形 . `Name^sl に初期化する ◎ Initialize the value of value’s name attribute to serialized.[[Name]].
- %値 の `lastModified$m 属性~値 ~SET %直列形 . `LastModified^sl に初期化する ◎ Initialize the value of value’s lastModified attribute to serialized.[[LastModified]].
4.1. 構築子
`new File(fileBits, fileName, fileOptions)@m 構築子~手続きは： ◎ 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 steps:
- %~byte列 ~LET `~blobを成す各部を処理する$( `fileBits$V , `fileOptions$V ) ◎ Let bytes be the result of processing blob parts given fileBits and options.
-
%名前 ~LET `fileName$V ◎ Let n be the fileName argument to the constructor.
注記： ~file名に利用される規約は、 下層の~OS~file~systemに応じて異なる — 構築された~fileに対する~UTF-16の義務付けは、 ~file名が`~byte列$に変換されたときの多義性を起こり難くする。 ◎ Note: Underlying OS filesystems use differing conventions for file name; with constructed files, mandating UTF-16 lessens ambiquity when file names are converted to byte sequences.
- %~MIME型 ~LET 空~文字列 ◎ ↓
- %type ~LET `fileOptions$V[ "`type$dm" ] ◎ ↓
- ~IF［ %type ~NEQ ε ］~AND［ %type を成すどの文字も 範囲 { `0020^U 〜 `007E^U } に入る ］ ⇒ %~MIME型 ~SET `~ASCII小文字~化する$( %type ) ◎ Process FilePropertyBag dictionary argument by running the following substeps: • If the type member is provided and is not the empty string, let t be set to the type 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 ASCII lowercase.
- %日時 ~LET `fileOptions$V[ "`lastModified$dm" ] ◎ ↓
-
~IF［ %日時 ~EQ ε ］ ⇒ %日時 ~SET `~Unix~epoch$から現在の日時までを成す~milli秒数（ `Date.now()^c と等価） ◎ If the lastModified member is provided, let d be set to the lastModified dictionary member. If it is not provided, set d to the current date and time represented as the number of milliseconds since the Unix Epoch (which is the equivalent of Date.now() [ECMA-262]).
注記： `ECMA-262$r `Date$I ~objは， これと同じ結果に変換されるので、 `lastModified$dm ~member値には `Date^I ~objを渡すこともできる。 ◎ Note: Since ECMA-262 Date objects convert to long long values representing the number of milliseconds since the Unix Epoch, the lastModified member could be a Date object [ECMA-262].
- コレの ⇒＃ `~byte列~data$ ~SET %~byte列, `size$m ~SET %~byte列 の総~byte数, `name$m ~SET %名前, `type$m ~SET %~MIME型, `lastModified$m ~SET %日時 ◎ Return a new File object F such that: • F refers to the bytes byte sequence. • F.size is set to the number of total bytes in bytes. • F.name is set to n. • F.type is set to t. • F.lastModified is set to d.
`new File()$m 構築子は次の引数を伴って呼出され得る： ◎ 4.1.1. Constructor Parameters ◎ The File() constructor can be invoked with the parameters below:
- `fileBits@V ⇒ `blobParts$V と同じ。 ◎ A fileBits sequence • which takes any number of the following elements, and in any order: •• BufferSource elements. •• Blob elements, which includes File elements. •• USVString elements.
- `fileName@V （ `USVString$I 型） ⇒ ~fileの名前を表現する文字列。 この引数~用の規範的な条件は， `new File()$m 構築子にて与えられる。 ◎ A fileName parameter • A USVString parameter representing the name of the file; normative conditions for this constructor parameter can be found in § 4.1 Constructor.
-
`fileOptions@V （省略可能, `FilePropertyBag$I 型） ⇒ この引数は、 `BlobPropertyBag$I の~memberに加えて，~fileの更新日を表現する `lastModified@dm ~member（省略可能, `long long^c 型）を有する。 この~member用の規範的な条件は， `new File()$m 構築子にて与えられる。 ◎ An optional FilePropertyBag dictionary • which in addition to the members of BlobPropertyBag takes one member: •• An optional lastModified member, which must be a long long; normative conditions for this member are provided in § 4.1 Constructor.
【 原文の引数~名は %options だが、 `new Blob()$m 構築子の同じ名前の引数と紛らわしいので，名前を違えている。 】
4.2. 属性
`name@m 取得子~手続きは： ◎ name, of type DOMString, readonly
- ~IF［ ~UAは、 ~fileの名前の情報を可用にできる ］ ⇒ ~RET その名前 — ~file名には，下層の~OS~file~system間でいくつもの規約があるが、 これは~path情報の無い単なる~fileの名前である。 ◎ The name of the file. 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 file systems; this is merely the name of the file, without path information.＼
- ~RET 空~文字列 ◎ On getting, if user agents cannot make this information available, they must return the empty string.＼ ◎ ↓If a File object is created using a constructor, further normative conditions for this attribute are found in § 4.1 Constructor.
`lastModified@m 取得子~手続きは：
- ~IF［ ~UAは~fileの最終更新日の情報を可用にできる ］ ⇒ ~RET `~Unix~epoch$から その情報が表現する日時までを成す~milli秒数
- ~RET `~Unix~epoch$から現在の日時までを成す~milli秒数（ `Date.now()^c と等価）
構築子を利用して作成された `File$I ~objにおける， これらの属性に更に適用される規範的な条件は、 `new File()$m 構築子にて与えられる。 ◎ If a File object is created using a constructor, further normative conditions for this attribute are found in § 4.1 Constructor.
`File$I ~interfaceは、 `FileList$I 型の属性を公開する~objにて可用にされる。 その種の~objは~HTML `HTML$r にて定義されている。 `File$I ~objは、 `Blob$I を継承する変異-不能な~objであり， `読取n演算$が起動された時点で~memory内に読取n可能な~file~dataを表現する。 ~UAは、 読取n中に~fileが存在しなくなっていた場合には， `読取n~error$にするモノトスル — すなわち： ◎ The File interface is available on objects that expose an attribute of type FileList; these objects are defined in HTML [HTML]. The File interface, which inherits from Blob, is immutable, and thus represents file data that can be read into memory at the time a read operation is initiated. User agents must process reads on files that no longer exist at the time of read as errors,＼
- `FileReaderSync$I が （ Web Worker `WORKERS$r の下で） 利用されている場合 ⇒ `NotFoundError$E 例外を投出する ◎ throwing a NotFoundError exception if using a FileReaderSync on a Web Worker [Workers]＼
- 他の場合 ⇒ ［ `error$m 属性は `NotFoundError$E 例外を返す ］ようにした上で， `error$et `~eventを発火する$ ◎ or firing an error event with the error attribute returning a NotFoundError.
下の例では、 ~file~objからの~metadataが解る様に表示された上で， 名前と最終更新日が伴われた `File$I ~objが作成される： ◎ 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.
var %file = document.getElementById("filePicker").files[0];
var %date = new Date(%file.lastModified);
println(
"選択された~file: " + %file.name +
"~fileの最終更新日: " + %date.toDateString() + "."
);
...
/*
特定の最終更新日が伴われた~fileを生成する
◎
Generate a file with a specific last modified date
*/
var %d = new Date(2013, 12, 5, 16, 23, 45, 600);
var %generatedFile = new File(
["Rough Draft ...."],
"Draft1.txt",
{type: "text/plain", lastModified: %d}
);
...
5. `FileList^I ~interface
注記： `FileList^I ~interfaceは “~risk下にある” ものと見なされるべきである。 ~Web~platformでは、 この種の~interfaceを `ECMA-262$r における `Array$I ~platform~objに置換するのが，趨勢なので。 特に、 `filelist.item(0)^c の類の構文は~risk下にある。 他のほとんどの［ ~programにおける `FileList^I の利用 ］については、 最終的に `Array^I 型に移行されたとしても，およそ影響されないものと見込まれる。 ◎ Note: 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 [ECMA-262]. In particular, this means syntax of the sort filelist.item(0) is at risk; most other programmatic use of FileList is unlikely to be affected by the eventual migration to an Array type.
この~interfaceは、 `File$I ~objたちが成す`~list$を表現する。 以下、 この~listを指して，当の `FileList$I の~objの `~file~list@ と称する。 【この用語は、以下を明確化するため，この訳に導入している。】 ◎ This interface is a list of File objects.
[`Exposed$=(Window,Worker), `Serializable$]
interface `FileList@I {
getter `File$I? `item＠#dfn-item$(`unsigned long$ %index);
readonly attribute `unsigned long$ `length$m;
};
`FileList$I ~objは、 `直列化-可能$である： ◎ FileList objects are serializable objects.＼
-
その`直列化~手続き$は、 所与の ( %値, %直列形 ) に対し，次を走らす： ◎ Their serialization steps, given value and serialized, are:
- %直列形 . `Files^sl ~SET 空`~list$ ◎ Set serialized.[[Files]] to an empty list.
- %値 の`~file~list$を成す ~EACH( %~file ) に対し ⇒ %直列形 . `Files^sl に %~file の`下位-直列化$を`付加する$ ◎ For each file in value, append the sub-serialization of file to serialized.[[Files]].
-
その`逆直列化~手続き$は、 所与の ( %値, %直列形, %宛先~realm ) に対し，次を走らす： ◎ Their deserialization step, given serialized and value, are:
- %直列形 . `Files^sl を成す ~EACH( %~file ) に対し ⇒ %値 の`~file~list$に %~file の`下位-逆直列化$を`付加する$ ◎ For each file of serialized.[[Files]], add the sub-deserialization of file to value.
見本~codeにおいては、 概して，~form内の`~file入力~要素$への~DOM~access, および選択された~fileへの~accessが含められる。 ◎ Sample usage typically involves DOM access to the <input type="file"> element within a form, and then accessing selected files.
/* `uploadData^c は `form$e 要素 ／ `fileChooser^c は`~file入力~要素$ ◎ uploadData is a form element fileChooser is input element of type 'file' */ var %file = document.forms['uploadData']['fileChooser'].files[0]; /* 等価な構文 ◎ alternative syntax can be */ // var %file = document.forms['uploadData']['fileChooser'].files.item(0); if(%file) { /* ~fileを開く ◎ Perform file ops */ }
`length@m 取得子~手続きは ⇒ ~RET コレの`~file~list$の`~size$ ◎ Attributes ◎ length, of type unsigned long, readonly ◎ must return the number of files in the FileList object. If there are no files, this attribute must return 0.
`item(index)@m ~method手続きは：
- ~IF［ %index ~IN { コレが`~supportする~prop~index$ } ］ ⇒ ~RET コレの`~file~list$[ %index ]
- ~RET ~NULL
`FileList$I ~obj %O が`~supportする~prop~index$は、 0 以上［ %O の`~file~list$の`~size$ ］未満とする。
◎ 5.2. Methods and Parameters ◎ item(index) • must return the indexth File object in the FileList. If there is no indexth File object in the FileList, then this method must return null. • index must be treated by user agents as value for the position of a File object in the FileList, with 0 representing the first file. Supported property indices are the numbers in the range zero to one less than the number of File objects represented by the FileList object. If there are no such File objects, then there are no supported property indices.注記： `HTML$r における `FileList^I 型の読専~属性を有する~interfaceには、 `HTMLInputElement$I, `DataTransfer$I がある。 前者は，上の例でも~accessされている。 ◎ Note: 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.
6. ~dataの読取n法
6.1. ~file読取り~task~source
この仕様は、 新たな汎用`~task~source$として， `~file読取り~task~source@ を定義する。 それは、 この仕様にて［ `~Blob$が参照する`~byte列~data$を読取るために`~queueされ$る~task ］すべてから利用される。 それはまた、 ~binary~dataの非同期的な読取りに呼応して誘発される特能【~eventなど】用にも利用される。 ◎ This specification defines a new generic task source called the file reading task source, which is used for all tasks that are queued in this specification to read byte sequences associated with Blob and File objects. It is to be used for features that trigger in response to asynchronously reading binary data.
6.2. `FileReader^I ~API
[`Exposed$=(Window,Worker)]
interface `FileReader@I: `EventTarget$I {
`FileReader$mc();
/*
`非同期~読取n~method$
◎
async read methods
*/
`undefined$ `readAsArrayBuffer$m(`Blob$I %blob);
`undefined$ `readAsBinaryString$m(`Blob$I %blob);
`undefined$ `readAsText$m(`Blob$I %blob, optional `DOMString$ %encoding);
`undefined$ `readAsDataURL$m(`Blob$I %blob);
`undefined$ `abort()$m;
/*
状態
◎
states
*/
const `unsigned short$ `EMPTY@m = 0;
const `unsigned short$ `LOADING@m = 1;
const `unsigned short$ `DONE@m = 2;
readonly attribute `unsigned short$ `readyState$m;
/*
`File^I または `Blob^I ~data
◎
File or Blob data
*/
readonly attribute (`DOMString$ or `ArrayBuffer$)? `result$m;
readonly attribute `DOMException$I? `error$m;
/*
~event~handler内容~属性
◎
event handler content attributes
*/
attribute `EventHandler$I `onloadstart$m;
attribute `EventHandler$I `onprogress$m;
attribute `EventHandler$I `onload$m;
attribute `EventHandler$I `onabort$m;
attribute `EventHandler$I `onerror$m;
attribute `EventHandler$I `onloadend$m;
};
各 `FileReader$I には、 次に挙げるものが結付けられる： ◎ ↓
- `状態@fR ⇒ `empty^l ／ `loading^l ／ `done^l — 初期~時は `empty^l とする。 ◎ A FileReader has an associated state, that is "empty", "loading", or "done". It is initially "empty".
- `結果@fR ⇒ ~NULL ／ `DOMString$I ／ `ArrayBuffer$I — 初期~時は ~NULL とする。 ◎ A FileReader has an associated result (null, a DOMString or an ArrayBuffer). It is initially null.
- `~error@fR ⇒ ~NULL ／ `DOMException$I — 初期~時は ~NULL とする。 ◎ A FileReader has an associated error (null or a DOMException). It is initially null.
各 `FileReader$I %fr には `読取n演算@ が結付けられる — それは、 所与の ( %~blob, %種別, %符号化法の名前 （省略時は ε） ) に対し，次の手続きを走らす： ◎ A FileReader fr has an associated read operation algorithm, which given blob, a type and an optional encodingName, runs the following steps:
- ~IF［ %fr の`状態$fR ~EQ `loading^l ］ ⇒ ~THROW `InvalidStateError$E ◎ If fr’s state is "loading", throw an InvalidStateError DOMException.
- %fr の ⇒＃ `状態$fR ~SET `loading^l, `結果$fR ~SET ~NULL, `~error$fR ~SET ~NULL ◎ Set fr’s state to "loading". ◎ Set fr’s result to null. ◎ Set fr’s error to null.
- %~stream ~LET %~blob の`~streamを取得する$() ◎ Let stream be the result of calling get stream on blob.
- %読取器 ~LET %~stream 用の`読取器を取得する$RS() ◎ Let reader be the result of getting a reader from stream.
- %~byte列 ~LET 空な`~byte列$ ◎ Let bytes be an empty byte sequence.
-
%~chunk~promise ~LET %読取器 から`~chunkを読取る$RSR()
【 この段は、 引数, 返り値とも現在の定義に整合していない（以下に現れるそれも同様）。 ~chunkを読取る~algoは、 以前は `Fetch$r にて定義されていたが、 現在は `STREAMS$r へ移動され，その仕組みも改められている。 この手続きは、 この段~以降も含めて更新される必要がある。 】
◎ Let chunkPromise be the result of reading a chunk from stream with reader. - %最初の~chunkか ~LET ~T ◎ Let isFirstChunk be true.
-
この段は`並列的$に走らす： ◎ In parallel, while true:
- `(A)^i %~chunk~promise が［ 充足される／却下される ］まで待機する ◎ Wait for chunkPromise to be fulfilled or rejected.
-
~IF［ %~chunk~promise は %~obj で充足された ］： ◎ ↓
-
~IF［ %最初の~chunkか ~EQ ~T ］ ⇒ `~taskを~queueする$( `~file読取り~task~source$, 次の手続き ) ◎ If chunkPromise is fulfilled, and isFirstChunk is true, queue a task to＼
手続きは ⇒ `進捗~eventを発火する$( %fr, `loadstart$et ) ◎ fire a progress event called loadstart at fr.`XMLHttpRequest$I の挙動と揃えるため、 `loadstart$et は同期的に配送するよう変更するかもしれない。 `[ 課題 #119 ]＠https://github.com/w3c/FileAPI/issues/119$ ◎ We might change loadstart to be dispatched synchronously, to align with XMLHttpRequest behavior. [Issue #119]
- %最初の~chunkか ~SET ~F ◎ Set isFirstChunk to false.
-
~IF［ %~obj の `done^c ~prop ~EQ ~F ］： ◎ If chunkPromise is fulfilled with an object whose done property is false and＼
- ~Assert： %~obj の `value^c ~prop は `Uint8Array$I ~objである 【これは、原文では条件であるかのように記されているが，おそらく表明と解釈するべきであろう。】 ◎ whose value property is a Uint8Array object, run these steps:
- %~byte列 に［ %~obj の `value^c ~propが表現する`~byte列$ ］を付加する ◎ Let bs be the byte sequence represented by the Uint8Array object. ◎ Append bs to bytes.
-
~IF［ この手続きが最後に呼出されてから概ね 50ms ~~経過した ］ ⇒ `~taskを~queueする$( `~file読取り~task~source$, 次の手続き )
手続きは ⇒ `進捗~eventを発火する$( %fr, `progress$et )◎ If roughly 50ms have passed since these steps were last invoked, queue a task to fire a progress event called progress at fr. - %~chunk~promise ~SET %読取器 から`~chunkを読取る$RSR( ) ◎ Set chunkPromise to the result of reading a chunk from stream with reader.
- ~GOTO `(A)^i ◎ ↑↑
-
`~taskを~queueする$( `~file読取り~task~source$, 次の手続き ) ◎ Otherwise, if chunkPromise is fulfilled with an object whose done property is true, queue a task to run the following steps and abort this algorithm:
手続きは： ◎ ↑
- %fr の`状態$fR ~SET `done^l ◎ Set fr’s state to "done".
- %結果 ~LET %~blob の`~dataを梱包する$( %~byte列, %種別, %~blob の `type$m, %符号化法の名前 ) ◎ Let result be the result of package data given bytes, type, blob’s type, and encodingName.
-
~IF［ 前~段にて例外 %~error が投出された ］： ◎ If package data threw an exception error:
- %fr の`~error$fR ~SET %~error ◎ Set fr’s error to error.
- `進捗~eventを発火する$( %fr, `error$et ) ◎ Fire a progress event called error at fr.
-
~ELSE： ◎ Else:
- %fr の`結果$fR ~SET %結果 ◎ Set fr’s result to result.
- `進捗~eventを発火する$( %fr, `load$et ) ◎ Fire a progress event called load at the fr.
-
~IF［ %fr の`状態$fR ~NEQ `loading^l ］ ⇒ `進捗~eventを発火する$( %fr, `loadend$et ) ◎ If fr’s state is not "loading", fire a progress event called loadend at the fr.
注記： ［ `load$et ／ `error$et ］~event用の~event~handlerは別の読込nを開始することもでき、 それが起きた場合，この読込n用の `loadend$et ~eventは発火されない。 ◎ Note: Event handler for the load or error events could have started another load, if that happens the loadend event for this load is not fired.
-
-
~ELSE（ %~chunk~promise は %~error で却下された ） ⇒ `~taskを~queueする$( `~file読取り~task~source$, 次の手続き ) ◎ Otherwise, if chunkPromise is rejected with an error error, queue a task to run the following steps and abort this algorithm:
手続きは： ◎ ↑
- %fr の`状態$fR ~SET `done^l ◎ Set fr’s state to "done".
- %fr の`~error$fR ~SET %~error ◎ Set fr’s error to error.
- `進捗~eventを発火する$( %fr, `error$et ) ◎ Fire a progress event called error at fr.
-
~IF［ %fr の`状態$fR ~NEQ `loading^l ］ ⇒ `進捗~eventを発火する$( %fr, `loadend$et ) ◎ If fr’s state is not "loading", fire a progress event called loadend at fr.
注記： `error$et ~event用の~event~handlerは，別の読込nを開始することもでき、 それが起きた場合，この読込n用の `loadend$et ~eventは発火されない。 ◎ Note: Event handler for the error event could have started another load, if that happens the loadend event for this load is not fired.
【！この訳では、すべての箇所に明示的に与えているので不要】 ◎ Use the file reading task source for all these tasks.
6.2.1. ~event~handler内容~属性
~UAは、 `FileReader$I の~IDL【！~DOM】属性として， 次に挙げる`~event~handler内容~属性$ （および，それらに対応する`~event~handler~event型$） を~supportするモノトスル： ◎ The following are the event handler content attributes (and their corresponding event handler event types) that user agents must support on FileReader as DOM attributes:
| `~event~handler内容~属性$ | `~event~handler~event型$ |
|---|---|
| `onloadstart@m | `loadstart$et |
| `onprogress@m | `progress$et |
| `onabort@m | `abort$et |
| `onerror@m | `error$et |
| `onload@m | `load$et |
| `onloadend@m | `loadend$et |
6.2.2. `FileReader^I の状態
`FileReader$I ~objは、 次に挙げる 3 種の状態をとり得る。 ~objがどの状態にあるかは、 `readyState$m 属性から得られる： ◎ The FileReader object can be in one of 3 states. The readyState attribute tells you in which state the object is:
- `EMPTY$m （数値 0 ）
- ~objは構築-済みだが、 まだ読取n待ちは生じていない。 `読取n~method$は、 まだ一度も~callされていない。 ◎ The FileReader object has been constructed, and there are no pending reads. None of the read methods have been called.＼
- これが、 いずれかの`読取n~method$が~callされるまでの，新たに創出された `FileReader$I ~objにおける既定の状態である。 ◎ This is the default state of a newly minted FileReader object, until one of the read methods have been called on it.
- `LOADING$m （数値 1 ）
- `~Blob$は読取n中の状態にある。 `読取n~method$のいずれかが処理されていて，読取nにまだ~errorは生じていない。 ◎ A File or Blob is being read. One of the read methods is being processed, and no error has occurred during the read.
- `DONE$m （数値 2 ）
- `~Blob$の全体が~memory内に読取られたか, `または^em `読取n~error$が生じたか, `または^em 読取nは `abort()$m により中止された。 当の~objは、 それ以降は`~Blob$を読取らなくなる。 `readyState$m がこの値に設定された場合、［ 当の~objに対し，少なくともいずれかの`読取n~method$が~callされた ］ことを意味する。 ◎ The entire File or Blob has been read into memory, OR a file read error occurred, OR the read was aborted using abort(). The FileReader is no longer reading a File or Blob. If readyState is set to DONE it means at least one of the read methods have been called on this FileReader.
6.2.3. `File^I／`Blob^I の読取n法
`FileReader$I ~interfaceは、 ~fileを非同期的に~memory内に読取るためとして，次に挙げる `非同期~読取n~method@ を可用にする ⇒＃ `readAsArrayBuffer()$m, `readAsBinaryString()$m, `readAsText()$m, `readAsDataURL()$m ◎ The FileReader interface makes available several asynchronous read methods—readAsArrayBuffer(), readAsBinaryString(), readAsText() and readAsDataURL(), which read files into memory.
注記： これらの読取n~methodが，同じ `FileReader$I ~objに対し同時並行に重ねて~callされた場合、［ `readyState$m ~EQ `LOADING$m ］の間に生じたどの読取n~methodに対しても， `InvalidStateError$E が投出される。 ◎ Note: If multiple concurrent read methods are called on the same FileReader object, user agents throw an InvalidStateError on any of the read methods that occur when readyState = LOADING.
`FileReaderSync$I も，数種の`同期~読取n~method$を可用にする。 これらの［ 同期／非同期 ］な読取n~methodは、 `読取n~method@ と総称される。 ◎ (FileReaderSync makes available several synchronous read methods. Collectively, the sync and async read methods of FileReader and FileReaderSync are referred to as just read methods.)
`readAsBinaryString(blob)@m ~method手続きは ⇒ コレの`読取n演算$を起動する( %blob, `BinaryString^i ) ◎ 6.2.3.4. The readAsBinaryString() method • The readAsBinaryString(blob) method, when invoked, must initiate a read operation for blob with BinaryString.
注記： `readAsBinaryString()$m よりも `readAsArrayBuffer()$m の利用が選好される — 前者は後方-互換性を得るために供されている。 ◎ Note: The use of readAsArrayBuffer() is preferred over readAsBinaryString(), which is provided for backwards compatibility.
`abort()@m ~method手続きは： ◎ 6.2.3.5. The abort() method ◎ When the abort() method is called, the user agent must run the steps below:
- ~IF［ コレの`状態$fR ~IN { `enpty^l, `done^l } ］ ⇒＃ コレの`結果$fR ~SET ~NULL； ~RET ◎ If this's state is "empty" or if this's state is "done" set this's result to null and terminate this algorithm.
- ~Assert： コレの`状態$fR ~EQ `loading^l ◎ If this's state is "loading"＼
- コレの`状態$fR ~SET `done^l ◎ set this's state to "done" and＼
- コレの`結果$fR ~SET ~NULL ◎ set this's result to null.
- コレに提携して`~queueされ$た すべての`~task$を、 `~file読取り~task~source$から除去する ◎ If there are any tasks from this on the file reading task source in an affiliated task queue, then remove those tasks from that task queue.
- `読取n~method$が処理-中であれば、 それを`終了-$させる ◎ Terminate the algorithm for the read method being processed.
- `進捗~eventを発火する$( コレ, `abort$et ) ◎ Fire a progress event called abort at this.
- ~IF［ コレの`状態$fR ~NEQ `loading^l ］ ⇒ `進捗~eventを発火する$( コレ, `loadend$et ) ◎ If this's state is not "loading", fire a progress event called loadend at this.
6.3. ~dataの梱包-法
各 `Blob$I %~blob には、 `~dataを梱包する@ ~algoが結付けられる — それは、 所与の ⇒＃ %~byte列, %種別, %~MIME型 （省略時は ε）, %符号化法の名前 （省略時は ε） ◎終 に対し， %種別 に応じて次を走らす： ◎ A Blob has an associated package data algorithm, given bytes, a type, a optional mimeType, and a optional encodingName, which switches on type and runs the associated steps:
- `DataURL^i
-
~RET `~data_URL$としての %~byte列 — 次の考慮点を織り込む下で： ◎ Return bytes as a DataURL [RFC2397] subject to the considerations below:
- %~MIME型 は可用ならば†、 `~data_URL$ 仕様に従うように，それを~data_URLを成す一部に利用する。 【†すなわち、 %~MIME型 ~NEQ ε ？ 他にも必要な条件がある？】 ◎ Use mimeType as part of the Data URL if it is available in keeping with the Data URL specification [RFC2397].
- %~MIME型 は可用でないならば、 ~data_URLは `media-type^P を伴わない。 ◎ If mimeType is not available return a Data URL without a media-type. [RFC2397].
~data_URLがどう生成されるか，もっと良く指定する。 `[ 課題 #104 ]＠https://github.com/w3c/FileAPI/issues/104$ ◎ Better specify how the DataURL is generated. [Issue #104]
- `Text^i
-
- %符号化法 ~LET `失敗^i ◎ Let encoding be failure.
- ~IF［ %符号化法の名前 ~NEQ ε ］ ⇒ %符号化法 ~SET `~labelから符号化法を取得する$( %符号化法の名前 ) ◎ If the encodingName is present, set encoding to the result of getting an encoding from encodingName.
-
~IF［ %符号化法 ~EQ `失敗^i ］~AND［ %~MIME型 ~NEQ ε ］： ◎ If encoding is failure, and mimeType is present:
- %~MIME型 ~LET `~MIME型を構文解析する$( %~MIME型 ) ◎ Let type be the result of parse a MIME type given mimeType.
-
~IF［ %~MIME型 ~NEQ `失敗^i ］ ⇒ %符号化法 ~SET `~labelから符号化法を取得する$( %~MIME型 の`~parameter群$[ `charset^l ] ) ◎ If type is not failure, set encoding to the result of getting an encoding from type’s parameters["charset"].
%blob の `type$m 属性が `text/plain;charset=utf-8^c ならば、 `~labelから符号化法を取得する$ときには，~labelとして `utf-8^l を~~渡すことになる。 ~UAは、 符号化法の`~label^emを構文解析して， その~charset~parameterが成す部位を抽出しなければならないことに注意。 ◎ If blob has a type attribute of text/plain;charset=utf-8 then getting an encoding is run using "utf-8" 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［ %符号化法 ~EQ `失敗^i ］ ⇒ %符号化法 ~SET `~UTF-8$ ◎ If encoding is failure, then set encoding to UTF-8.
- ~RET `~Unicodeに復号する$( %~byte列, %符号化法 ) ◎ Decode bytes using fallback encoding encoding, and return the result.
- `ArrayBuffer^i
- ~RET `~buffer~sourceを~byte列から作成する$( `ArrayBuffer$I, %~byte列, %~blob に`関連な~realm$ ) ◎ Return a new ArrayBuffer whose contents are bytes.
- `BinaryString^i
- ~RET `同型に復号する$( %~byte列 ) ◎ Return bytes as a binary string, in which every byte is represented by a code unit of equal value [0..255].
6.4. ~event
この仕様に定義される すべての~eventは， `FileReader$I ~objがその~targetになるモノトスル。 ◎ The FileReader object must be the event target for all events in this specification.
`進捗~eventを発火する@ ときは、 所与の ( %~target, %~event名 ) に対し，次を走らすモノトスル ⇒ `~eventを発火する$( %~target, %~event名, `ProgressEvent$I ) （ `DOM$r による定義により，~eventの `bubbles^m, `cancelable^m 両~属性とも ~F になる） ◎ When this specification says to fire a progress event called e (for some ProgressEvent e at a given FileReader reader), the following are normative: • The progress event e does not bubble. e.bubbles must be false [DOM] • The progress event e is NOT cancelable. e.cancelable must be false [DOM]
6.4.1. ~event要覧
次の表tに， `FileReader$I ~objに向けて`発火-$される~eventを挙げる — どれも， `ProgressEvent$I ~interfaceを利用する： ◎ The following are the events that are fired at FileReader objects.
| ~event名 | 発火-時機 |
|---|---|
| `loadstart@et | 読取nが開始されるとき。 ◎ When the read starts. |
| `progress@et | ~blobを読取n中（および復号-中）の間 ◎ While reading (and decoding) blob |
| `abort@et | 読取nが中止されたとき。 例えば `abort()$m ~methodが呼出されたとき。 ◎ When the read has been aborted. For instance, by invoking the abort() method. |
| `error@et | 読取nが失敗したとき（`読取n~error$を見よ）。 ◎ When the read has failed (see file read errors). |
| `load@et | 読取nが成功裡に完了したとき。 ◎ When the read has successfully completed. |
| `loadend@et | 要請が完了したとき（成功／失敗のいずれでも）。 ◎ When the request has completed (either in success or failure). |
6.4.2. ~event不変則の要約
◎非規範的この仕様が与える非同期`読取n~method$に対する~eventの発火は、 次に挙げる不変則を満たす： ◎ The following are invariants applicable to event firing for a given asynchronous read method in this specification:
-
一度 `loadstart$et が発火された後、 読取n完了~時に，対応する `loadend$et が発火される。 `ただし^em、 次のいずれかが生じた場合を除く： ◎ Once a loadstart has been fired, a corresponding loadend fires at completion of the read, UNLESS any of the following are true:
- `abort()$m により`読取n~method$が取消され，新たに`読取n~method$が呼出された ◎ the read method has been cancelled using abort() and a new read method has been invoked
- ［ `load$et ／ `error$et ］~event用の~event~handler関数が，新たな読取nを起動した ◎ the event handler function for a load event initiates a new read ◎ the event handler function for a error event initiates a new read.
注記： 2 つの~event `loadstart$et と `loadend$et は、 一対一の組にされるわけではない。 ◎ Note: The events loadstart and loadend are not coupled in a one-to-one manner.
“読取nの連鎖”，すなわち “最初の” 読取n処理は継続しつつ，~event~handlerの中で別の読取nを起動する例を示す： ◎ This example showcases "read-chaining": initiating another read from within an event handler while the "first" read continues processing.
/* 次の類いの~codeにおいて … ◎ In code of the sort... */ %reader.readAsText(%file); %reader.onload = function(){%reader.readAsText(%alternateFile);} ..... /* … 最初の読取nに対しては `loadend^et ~eventは発火されてはナラナイ ◎ ... the loadend event must not fire for the first read */ %reader.readAsText(%file); %reader.abort(); %reader.onabort = function(){%reader.readAsText(%updatedFile);} /* … 最初の読取nに対しては `loadend^et ~eventは発火されてはナラナイ ◎ ... the loadend event must not fire for the first read */
- ~blobが~memory内に完全に読取られた時点で `progress$et ~eventが 1 回 発火されることになる。 ◎ One progress event will fire when blob has been completely read into memory.
- `loadstart$et より前に `progress$et ~eventが発火されることはない。 ◎ No progress event fires before loadstart.
-
所与の読取nに対し，［ `abort$et, `load$et, `error$et ］は：
- どれか一つだけ発火されるか，いずれも発火されない。
- 発火されたならば，その後に `progress$et ~eventが発火されることはない。
- `loadend$et の後に発火されることはない。
6.5. ~threadによる読取n法
`Web Workers^cite `WORKERS$r においては，`~Blob$に対する同期的な読取n~APIも利用できる。 その種の読取n~threadが~main~threadを阻むことはない。 この節では、 ~workerにて利用できる同期~APIを定義する。 ~workerには非同期~API（ `FileReader$I ~obj） `および^em 同期~API（ `FileReaderSync$I ~obj）が用意されている。 ◎ Web Workers allow for the use of synchronous File or Blob 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 [[Web Workers]]. Workers can avail of both the asynchronous API (the FileReader object) and the synchronous API (the FileReaderSync object).
6.5.1. `FileReaderSync^I ~API
この~interfaceは、 `~Blob$を~memory内に同期的に読取るための `同期~読取n~method@ を供する。 ◎ This interface provides methods to synchronously read File or Blob objects into memory.
[
`Exposed$=(DedicatedWorker,SharedWorker)]
interface `FileReaderSync@I {
`FileReaderSync$mc();
/*
同期的に文字列を返す
◎
Synchronously return strings
*/
`ArrayBuffer$ `readAsArrayBuffer$mS(`Blob$I %blob);
`DOMString$ `readAsBinaryString$mS(`Blob$I %blob);
`DOMString$ `readAsText$mS(`Blob$I %blob, optional `DOMString$ %encoding);
`DOMString$ `readAsDataURL$mS(`Blob$I %blob);
};
`readAsBinaryString(blob)@mS ~method手続きは ⇒ `~Blobを同期的に読取る$( %blob, `BinaryString^i ) ◎ 6.5.1.5. The readAsBinaryString() method The readAsBinaryString(blob) method, when invoked, must run these steps: • Let stream be the result of calling get stream on blob. • Let reader be the result of getting a reader from stream. • Let promise be the result of reading all bytes from stream with reader. • Wait for promise to be fulfilled or rejected. • If promise fulfilled with a byte sequence bytes: •• Return the result of package data given bytes, BinaryString, and blob’s type. • Throw promise’s rejection reason.
注記： `readAsBinaryString()$mS よりも `readAsArrayBuffer()$mS の利用が選好される — 前者は後方-互換性を得るために供されている。 ◎ Note: The use of readAsArrayBuffer() is preferred over readAsBinaryString(), which is provided for backwards compatibility.
`~Blobを同期的に読取る@ ときは、 所与の ( %~blob, %種別, %符号化法（省略時は ε ）) に対し：
- %~stream ~LET %~blob の`~streamを取得する$()
- %読取器 ~LET %~stream 用の`読取器を取得する$RS()
- %~promise ~LET 次の結果 ⇒ %読取器 から`すべての~byteを読取る$RSR() 【この段とそれに関係する処理nは、まだ `STREAMS$r による更新が`反映されていない$x。】
-
%~promise が［ 充足される／却下される ］まで待機する：
-
`~byte列$ %~byte列 で充足されたときは：
- %~MIME型 ~LET %~blob の `type$m 【取得子~手続きを遂行した結果】 【空~文字列になる場合は ε と見なす？】
- ~RET %~blob の`~dataを梱包する$( %~byte列, %種別, %~MIME型, %符号化法 )
- 事由 %r で却下されたときは ⇒ ~THROW %r を表現する例外【`失敗~事由$を見よ】
-
【 この手続きは、 各~methodに共通な記述を集約するために，この訳に導入している。 】
◎ ↑7. ~errorと例外
`読取n~error@ は下層の~file~systemから~fileを読取る際に生じ得る。 起こり得る~errorのいくつかを下に挙げる。 これらは `参考^em である。 ◎ File read errors can occur when reading files from the underlying filesystem. The list below of potential error conditions is informative.
- ~accessされている`~Blob$ 【が参照rしている~data】 は、［ `非同期~読取n~method$／`同期~読取n~method$ ］が~callされた時点では，存在しないかもしれない。 例えば、 その参照が獲得された後に移動されたか削除されたことに因り （例：他の~appにより同時並行に）。 `NotFoundError$E を見よ。 ◎ The File or Blob being accessed may not exist at the time one of the asynchronous read methods or synchronous read methods 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). See NotFoundError.
- `~Blob$は読取n不能かもしれない。 例えば、 `~Blob$への参照が獲得された後の許可~問題に因り （例：他の~appにより同時並行に~lockされたなど）。 あるいは，`~snapshot状態$が変化したかもしれない。 `NotReadableError$E を見よ。 ◎ A File or Blob may be unreadable. This may be due to permission problems that occur after a reference to a File or Blob has been acquired (e.g. concurrent lock with another application). Additionally, the snapshot state may have changed. See NotReadableError.
- ~UAは，一部の~fileについて ~Web~app内での利用を安全でないものと決定してもヨイ。 ~disk上の~fileは 元々の~file選択から変化し得るので、 読取n結果は無効なものになり得る。 加えて、 一部の~fileや~directory構造は，下層の~file~systemにおいて制約されていることもある。 例えば、 それらからの読取nは，~security違反と見なされ得る。 `§ ~securityの考慮点＠#security-discussion$, `SecurityError$E を見よ。 ◎ 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 underlying filesystem; attempts to read from them may be considered a security violation. See § 9 Security and Privacy Considerations and SecurityError.
7.1. 例外の投出-法／返される~error
この節は規範的である。 ◎ This section is normative.
`~error条件$は、 `~Blob$の読取n中に生じ得る。 ◎ Error conditions can arise when reading a File or a Blob.
`読取n演算$は、 `~Blob$の読取n中における`~error条件$に因り終了し得る。 `~streamを取得する$~algoを失敗させるような 特定0の`~error条件$は、 `失敗~事由@ と呼ばれ，下の表tの 2 列目に挙げるものがあり得る。 ◎ The read operation can terminate due to error conditions when reading a File or a Blob; the particular error condition that causes the get stream algorithm to fail is called a failure reason. A failure reason is one of NotFound, UnsafeFile, TooManyReads, SnapshotState, or FileLock.
- `同期~読取n~method$に対しては、 ある`失敗~事由$により~errorが生じた場合には， 下の表tの 1 列目に挙げる名前を伴う【！type】例外が投出される。 ◎ Synchronous read methods throw exceptions of the type in the table below if there has been an error owing to a particular failure reason.
- `非同期~読取n~method$に対しては、 `FileReader$I ~objの `error$m 属性が利用される。 それは、［ ある`失敗~事由$により~errorが生じた場合には， 下の表tの中で最も適切な名前を伴う `DOMException$I ~obj ／ ~ELSE_ ~NULL ］を返すモノトスル。 ◎ Asynchronous read methods use the error attribute of the FileReader object, which must return a DOMException object of the most appropriate type from the table below if there has been an error owing to a particular failure reason, or otherwise return null.
| ~error名 ◎ Type | `失敗~事由$とその記述 ◎ Description and Failure Reason |
|---|---|
| `NotFoundError$E |
次に該当する`失敗~事由$には、 この例外を利用するモノトスル：
|
| `SecurityError$E |
次に該当する`失敗~事由$には、 この例外を利用してもヨイ：
これは、 ~security~errorであり， 他の`失敗~事由$に該当しない状況に利用される。 ◎ If: • it is determined that certain files are unsafe for access within a Web application, this is the UnsafeFile failure reason. • it is determined that too many read calls are being made on File or Blob resources, this is the TooManyReads failure reason. ◎ For asynchronous read methods the error attribute may return a SecurityError exception and synchronous read methods may throw a SecurityError exception. ◎ This is a security error to be used in situations not covered by any other failure reason. |
| `NotReadableError$E |
次に該当する`失敗~事由$には、 この例外を利用するモノトスル：
|
8. `Blob^I ／ `MediaSource^I への~URL参照
この節では［ `~Blob$／ `MediaSource$I ~obj ］を指すために利用される`~URL$の`~scheme$urlを定義する。 ◎ This section defines a scheme for a URL used to refer to Blob and MediaSource objects.
8.1. 序論
◎非規範的`~blob~URL$は、 `blob:http://example.com/550e8400-e29b-41d4-a716-446655440000^l の様な~URLである。 これは、［ `img$e 要素など，~URLを利用するよう設計された他の~Web~API ］への［ `~Blob$／ `MediaSource$I ~obj ］の統合を可能化する。 `~blob~URL$は、［ ~navigateするとき／ ~localに生成された~dataの~downloadを誘発するとき ］にも利用できる。 ◎ Blob (or object) URLs are URLs like blob:http://example.com/550e8400-e29b-41d4-a716-446655440000. This enables integration of Blobs and MediaSources with other APIs that are only designed to be used with URLs, such as the img element. Blob URLs can also be used to navigate to as well as to trigger downloads of locally generated data.
この目的で、 `URL$I ~interfaceには， 2 つの静的~method — `createObjectURL()$m, `revokeObjectURL()$m — が公開される。 前者は `~URL$から `Blob$I への対応付けを作成し，後者は その対応付けを廃止する。 対応付けが存在する限り， `Blob$I は~garbage収集できないので、 参照が不要になり次第 ~URLを廃止するよう，【作者は】注意しておく必要がある。 どの`~blob~URL$も、 それを作成した大域~objが消去るに伴い，廃止される。 ◎ For this purpose two static methods are exposed on the URL interface, createObjectURL(obj) and revokeObjectURL(url). The first method creates a mapping from a URL to a Blob, and the second method revokes said mapping. As long as the mapping exist the Blob can’t be garbage collected, so some care must be taken to revoke the URL as soon as the reference is no longer needed. All URLs are revoked when the global that created the URL itself goes away.
8.2. ~model
~UAは、 `~blob~URL~store@ を保守するモノトスル — それは`~map$であり、 それを成す各~entryの：
-
`~key$mapは、 `~blob~URL@ である。 それは、 ~AND↓ を満たす文字列である：
- `妥当な~URL文字列$である
-
`~URL構文解析-$した結果の`~URL$は ~AND↓ を満たす：
- `~scheme$url ~EQ `blob^l
- `~host$urlは、 `空~host$である
- `~path$urlは、 次を満たす 1 個の~itemのみからなる ⇒ `妥当な~URL文字列$である
-
`値$mapは、 `~blob~URL~entry@ である。 それは、 次の組である：
- `~obj@bU ⇒ `Blob$I ~obj／ `MediaSource$I ~obj
- `環境@bU ⇒ `環境~設定群~obj$
注記： 各~仕様は、 `~blob~URL~entry$の`~obj$bUに~accessする際には， `~blob~objを得する$~algoを利用する必要がある。 ◎ Note: Specifications have to use the obtain a blob object algorithm to access a blob URL entry's object.
`~blob~objを得する@ ときは、 所与の ( `~blob~URL~entry$ %~blob~URL~entry, ［ `環境~設定群~obj$／ 定数 `~navi^i【！string "navigation"】 ］ %環境 ) に対し，次を遂行する — これは、［ `失敗^i ／ある`~obj$bU ］を返す： ◎ To obtain a blob object given a blob URL entry blobUrlEntry and an environment settings object or the string "navigation" environment, perform the following steps. They return an object.
-
~IF［ ~AND↓ ］…
- %環境 ~NEQ `~navi^i
- `同一-区分~blob~URLを利用しているか否か検査する$( %~blob~URL~entry, %環境 ) ~EQ ~F
…ならば ⇒ ~RET `失敗^i
◎ Let isAuthorized be true. ◎ If environment is not the string "navigation", then set isAuthorized to the result of checking for same-partition blob URL usage with blobUrlEntry and environment. ◎ If isAuthorized is false, then return failure. - ~RET %~blob~URL~entry の`~obj$bU ◎ Return blobUrlEntry’s object.
`新たな~blob~URLを生成する@ ときは、 次を走らす： ◎ To generate a new blob URL, run the following steps:
- %直列形 ~LET `生成元を直列化する$( `現在の設定群~obj$の`生成元$enV ) ◎ Let result be the empty string. ◎ Append the string "blob:" to result. ◎ Let settings be the current settings object ◎ Let origin be settings’s origin. ◎ Let serialized be the ASCII serialization of origin.
- ~IF［ %直列形 ~EQ `null^l ］ ⇒ %直列形 ~SET `実装定義$な値 ◎ If serialized is "null", set it to an implementation-defined value.
- ~RET 次を順に`連結する$ ⇒＃ 文字列 `blob:^l, %直列形, `0024^U SOLIDUS ( `/^c ), ~UUID `RFC4122$r を文字列として生成した結果 ◎ Append serialized to result. ◎ Append U+0024 SOLIDUS (/) to result. ◎ Generate a UUID [RFC4122] as a string and append it to result. ◎ Return result.
この~algoが生成し得る~blob~URLの例 ⇒ `blob:https://example.org/40a5fb5a-d56d-4a33-b4e2-0acf6a8e5f64^l ◎ An example of a blob URL that can be generated by this algorithm is blob:https://example.org/40a5fb5a-d56d-4a33-b4e2-0acf6a8e5f64.
`~blob~URL~storeに~entryを追加する@ ときは、 所与の ( %~obj ) に対し，次を走らす： ◎ To add an entry to the blob URL store for a given object, run the following steps:
- %~blob~URL ~LET `新たな~blob~URLを生成する$() ◎ Let store be the user agent’s blob URL store. ◎ Let url be the result of generating a new blob URL.
- ~UAの`~blob~URL~store$[ %~blob~URL ] ~SET 新たな`~blob~URL~entry$ — その ⇒＃ `~obj$bU ~SET %~obj, `環境$bU ~SET `現在の設定群~obj$ ◎ Let entry be a new blob URL entry consisting of object and the current settings object. ◎ Set store[url] to entry.
- ~RET %~blob~URL ◎ Return url.
`~blob~URL~storeから~entryを除去する@ ときは、 所与の ( `~URL$ %~URL ) に対し，次を走らす： ◎ To remove an entry from the blob URL store for a given url, run the following steps:
- %~URL文字列 ~LET `~URLを直列化する$( %~URL ) ◎ Let store be the user agent’s blob URL store; ◎ Let url string be the result of serializing url.
- ~UAの`~blob~URL~store$[ %~URL文字列 ] ~SET ε ◎ Remove store[url string].
8.3. ~blob~URL用の参照解決~model
【 参照解決（ `dereference^en ） — 参照を参照-先の~dataに解決する。 】
`~blob~URLを解決する@ ときは、 所与の ( `~URL$ %~URL ) に対し： ◎ To resolve a blob URL given a URL url:
- ~Assert： %~URL の`~scheme$url ~EQ `blob^l ◎ Assert: url’s scheme is "blob".
- %~URL文字列 ~LET `~URLを直列化する$( %~URL, `素片は除外する^i ) ◎ Let store be the user agent’s blob URL store. ◎ Let url string be the result of serializing url with the exclude fragment flag set.
- ~RET ［ 次の結果 ~NEQ ε ならば それ ／ ~ELSE_ `失敗^i ］ ⇒ ~UAの`~blob~URL~store$[ %~URL文字列 ] ◎ If store[url string] exists, return store[url string]; otherwise return failure.
`~blob~URL$用の［ 構文解析-法／~fetch法 ］~model用の更なる要件は、［ `URL$r ／ `Fetch$r ］仕様に定義される。 ◎ Futher requirements for the parsing and fetching model for blob URLs are defined in the [URL] and [Fetch] specifications.
8.3.1. ~blob~URLの生成元
◎非規範的`~blob~URL$が廃止されるまでは、［ その`生成元$url, それを作成した環境の`生成元$enV ］は常に同じになる。 これは `URL$r 仕様により達成される — ~URLの構文解析-時に`~blob~URL~store$内を検索して得られる~entryを利用して，正しい生成元を返すことにより。 ◎ The origin of a blob URL is always the same as that of the environment that created the URL, as long as the URL hasn’t been revoked yet. This is achieved by the [URL] spec looking up the URL in the blob URL store when parsing a URL, and using that entry to return the correct origin.
`~blob~URL$が廃止された場合でも，両~生成元の直列化は同じであり続けるが、 `不透明な生成元$は，それ自身とは別個になるかもしれない。 ~blob~URLは，廃止されて以降はどうやっても［ 解決できなく／~fetchできなく ］なるので、 この相違は観測-可能にならないが。 ◎ If the URL was revoked the serialization of the origin will still remain the same as the serialization of the origin of the environment that created the blob URL, but for opaque origins the origin itself might be distinct. This difference isn’t observable though, since a revoked blob URL can’t be resolved/fetched anymore anyway.
8.3.2. ~blob~URLへの~accessに対する制約
`~blob~URL$を~fetchできる環境は、 その`~storage~key$が［ 当の~URLを作成した環境の`~storage~key$ ］に合致するものに限られる。 `~blob~URL$への~naviは、 この制約の~subjectにはならない。 ◎ Blob URLs can only be fetched from environments where the storage key matches that of the environment where the blob URL was created. Blob URL navigations are not subject to this restriction.
`同一-区分~blob~URLを利用しているか否か検査する@ ときは、 所与の ( `~blob~URL~entry$ %~blob~URL~entry, `環境~設定群~obj$ %環境 ) に対し，次を遂行する — これは、 真偽値を返す： ◎ To check for same-partition blob URL usage given a blob URL entry blobUrlEntry and an environment settings object environment, perform the following steps. They return a boolean.
- %~blob~storage~key ~LET `非~storage目的~用に~storage~keyを得する$( %~blob~URL~entry の`環境$bU ) ◎ Let blobStorageKey be the result of obtaining a storage key for non-storage purposes with blobUrlEntry’s environment.
- %環境~storage~key ~LET `非~storage目的~用に~storage~keyを得する$( %環境 ) ◎ Let environmentStorageKey be the result of obtaining a storage key for non-storage purposes with environment.
- ~RET ~IS［ ( %~blob~storage~key, %環境~storage~key ) は`同等な~storage~key$である ］ ◎ If blobStorageKey is not equal to environmentStorageKey, then return false. ◎ Return true.
8.3.3. ~blob~URLの存続期間
この仕様は、 `文書~unload時の片付け手続き$を［ 所与の ( `文書$ %文書 ) に対し，次を走らす ］よう拡張する： ◎ This specification extends the unloading document cleanup steps with the following steps:
- ~UAの`~blob~URL~store$から，次を満たす~entryをすべて除去する ⇒ その`値$mapの`環境$bU ~EQ %文書 に`関連な設定群~obj$ ◎ Let environment be the Document's relevant settings object. ◎ Let store be the user agent’s blob URL store; ◎ Remove from store any entries for which the value's environment is equal to environment.
~workerの~unload時にも，類似な~hookを与える必要がある。 ◎ This needs a similar hook when a worker is unloaded.
8.4. ~blob~URLの作成-法と廃止-法
`~blob~URL$は， `URL$I ~objに公開される静的~methodを利用して作成され, 廃止される。 `~blob~URL$を廃止する（ `revoke^en する）ことにより、 それが参照rする資源と`~blob~URL$は切り離される。 廃止-後に参照解決するよう試みられた場合、 ~UAは，`~network~error$が生じたかのように動作するモノトスル。 ◎ Blob URLs are created and revoked using static methods exposed on the URL object. Revocation of a blob URL decouples the blob URL from the resource it refers to, and if it is dereferenced after it is revoked, user agents must act as if a network error has occurred.＼
この節では、［ `URL$r に対する補足的~interface ］および［ `~blob~URL$を［ 作成する, 廃止する ］ための~method ］を述べる。 ◎ This section describes a supplemental interface to the URL specification [URL] and presents methods for blob URL creation and revocation.
[`Exposed$=(Window,DedicatedWorker,SharedWorker)]
partial interface `URL$I {
static `DOMString$ `createObjectURL$m((`Blob$I or MediaSource) %obj);
static `undefined$ `revokeObjectURL$m(`DOMString$ %url);
};
`createObjectURL(obj)@m 静的~method手続きは ⇒ ~RET `~blob~URL~storeに~entryを追加する$( %obj ) ◎ The createObjectURL(obj) static method must return the result of adding an entry to the blob URL store for obj.
`revokeObjectURL(url)@m 静的~method手続きは： ◎ The revokeObjectURL(url) static method must run these steps:
- %~URL~record ~LET `~URL構文解析する$( %~URL ) ◎ Let urlRecord be the result of parsing url.
- ~IF［ %~URL~record の`~scheme$url ~NEQ `blob^l ］ ⇒ ~RET ◎ If urlRecord’s scheme is not "blob", return.
- %~entry ~LET %~URL~record の`~blob~URL~entry$ ◎ Let entry be urlRecord’s blob URL entry.
- ~IF［ %~entry ~EQ ~NULL ］ ⇒ ~RET ◎ If entry is null, then return.
- ~IF［ `同一-区分~blob~URLを利用しているか否か検査する$( %~entry, `現在の設定群~obj$ ) ~EQ ~F ］ ⇒ ~RET ◎ Let isAuthorized be the result of checking for same-partition blob URL usage with entry and the current settings object. ◎ If isAuthorized is false, then return.
- `~blob~URL~storeから~entryを除去する$( %~URL ) ◎ Remove an entry from the Blob URL Store for url.
注記： この~methodは，［ 登録-済みでない~URL／ 異なる~storage区分に属する環境【異なる`~storage~key$を利用する環境】から登録された~URL ］を廃止するよう試みたときには、 ~errorを投出することなく，黙って失敗する。 ~UAは、 これが起きたときには， ~error~consoleに~messageを表示することもできる。 ◎ Note: This means that rather than throwing some kind of error, attempting to revoke a URL that isn’t registered or that was registered from an environment in a different storage partition will silently fail. User agents might display a message on the error console if this happens.
注記： 廃止された %~URL を参照解決するよう試みた場合、 `~network~error$になる。 それでも、 %~URL が廃止される前に開始された要請は，成功するべきである。 ◎ Note: Attempts to dereference url after it has been revoked will result in a network error. Requests that were started before the url was revoked should still succeed.
次の例の %window1, %window2 は、 別々であるが`同一-生成元$であるとする — %window2 は、 %window1 の内側にある `iframe$e にもなり得る。 ◎ In the example below, window1 and window2 are separate, but in the same origin; window2 could be an iframe inside window1.
%myurl = %window1.URL.createObjectURL(%myblob); %window2.URL.revokeObjectURL(%myurl);
~UAが有する大域的な`~blob~URL~store$は一つだけなので、 ある~obj~URLを［ それを作成しなかった異なる~window ］から廃止することもアリになる。 `revokeObjectURL()$m を~callすれば、 次のようになることが確保される ⇒ ~UAは、［ それ以降に %myurl を参照解決した結果は，`~network~error$になる ］かのように動作する ◎ Since a user agent has one global blob URL store, it is possible to revoke an object URL from a different window than from which it was created. The URL.revokeObjectURL() call ensures that subsequent dereferencing of myurl results in a the user agent acting as if a network error has occurred.
8.4.1. ~blob~URLの作成と廃止を成す例
`~blob~URL$は、 `~Blob$を`~fetch$するために利用される文字列であり，［ `createObjectURL()$m を利用して それを創出した`文書$ ］に残り続け得る （`§ ~blob~URLの存続期間＠#lifeTime$を見よ）。 ◎ Blob URLs are strings that are used to fetch Blob objects, and can persist for as long as the document from which they were minted using URL.createObjectURL()—see § 8.3.3 Lifetime of blob URLs.
この節では、 説明を交えながら`~blob~URL$の作成と廃止の用法を示す。 ◎ This section gives sample usage of creation and revocation of blob URLs with explanations.
次の例では、 2 個の `img$e 要素 `HTML$r が，同じ`~blob~URL$を参照rする： ◎ In the example below, two img elements [HTML] refer to the same blob URL:
%url = URL.createObjectURL(%blob); %img1.src = %url; %img2.src = %url;
次の例では、 `revokeObjectURL()$m が明示的に~callされる： ◎ In the example below, URL.revokeObjectURL() is explicitly called.
var %blobURLref = URL.createObjectURL(%file); %img1 = new Image(); %img2 = new Image(); /* 次の両~代入とも期待したとおり働く： ◎ Both assignments below work as expected */ %img1.src = %blobURLref; %img2.src = %blobURLref; /* … body の読込nに後続して、 画像が 2 つとも読込まれたかどうか検査する ◎ ... Following body load Check if both images have loaded */ if(%img1.complete && %img2.complete) { /* 以降の~~参照では例外が投出されるようにする ◎ Ensure that subsequent refs throw an exception */ URL.revokeObjectURL(%blobURLref); } else { msg("Images cannot be previewed!"); /* 文字列に基づく参照を廃止する ◎ revoke the string-based reference */ URL.revokeObjectURL(%blobURLref); }
上の例では、 1 個の`~blob~URL$に対する複数回の参照が可能になる。 `~blob~URL$文字列は，画像~objがいずれも読込まれた後に廃止されている。 `~blob~URL$の利用回数が制約されない分，柔軟性は得られるが、 漏洩の可能性も高まる。 開発者は、 `revokeObjectURL()$m の~callと対にするべきである。 ◎ The example above allows multiple references to a single blob URL, and the web developer then revokes the blob URL string after both image objects have been loaded. While not restricting number of uses of the blob URL offers more flexibility, it increases the likelihood of leaks; developers should pair it with a corresponding call to URL.revokeObjectURL().
9. ~security／~privacyの考慮点
◎非規範的この仕様は、 ~Web内容が［ 下層の~file~systemから~fileを読取る ］ことを許容し，一意な識別子を通して~fileに~accessする手段を与えるが、 その種のものは~securityの考慮点になる。 この仕様は、［ 利用者は，首に~HTML~form内の`~file入力~要素$に対しヤリトリしていて、 `FileReader$I ~objから読取られるすべての~fileは， 最初に利用者の手により選択されたものである ］と見做している。 重要な~security上の考慮点には、 次が挙げられる ⇒＃ 悪意的な~file選択攻撃（選択looping）の防止-法, `~systemに敏感な~file$への~accessの防止-法, 選択-後の~disk上の~fileに対する改変からの防護-法 ◎ 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 [HTML], and that all files that are being read by FileReader 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.
- `選択looping@ の防止-法 ◎ Preventing selection looping
- ~file選択の間、 利用者は，`~file入力~要素$に結付けられた~file~pickerにより爆撃され得る （選択しない限り，~file~pickerが際限なく現れる “選択強制” ）。 ~UAは、 返される `FileList$I ~objの~sizeを 0 にすることにより，~file~accessを防止してもヨイ。 ◎ 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 FileList object returned be of size 0.
- `~systemに敏感な~file@ （ `system-sensitive files^en） ◎ System-sensitive files
- そのような~file （例： `/usr/bin/^c 内の~file, `password^c ~file, ~OSに~nativeな他の実行-可能~file）は、 概して，~Web内容に公開されるべきではないので、 `~blob~URL$を通して~accessされるべきではない。 ~UAは ⇒＃ `同期~読取n~method$用には `SecurityError$E 例外を`投出-$してもヨイ／ `非同期~読取n~method$用には `SecurityError$E 例外を返してもヨイ ◎ (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 blob URLs. User agents may throw a SecurityError exception for synchronous read methods, or return a SecurityError exception for asynchronous reads.
課題： この節は、 暫定的である。 後続な草案には、 さらなる~security考慮点が補足され得る。 ◎ This section is provisional; more security data may supplement this in subsequent drafts.
10. 要件と利用事例
この節では、 この~API用にどのような要件が課されるかについて, および 一部の利用事例についての~~説明を与える。 この~versionの~APIは、 すべての利用事例に応えるものではない。 それらに取組むことは後続な~versionに委ねられる。 ◎ This section covers what the requirements are for this API, as well as illustrates some use cases.＼ This version of the API does not satisfy all use cases; subsequent versions may elect to address these.
-
利用者からの許可を得たなら、 ~UAは，~local~fileからの~dataを ~program的に直に読取って構文解析する能を供するべきである。 ◎ Once a user has given permission, user agents should provide the ability to read and parse data directly from a local file programmatically.
例： 歌詞~viewer。 利用者は自身の plist ~file【プレイリスト】から楽曲の歌詞を読みたいとする。 利用者は plist ~fileを閲覧するとき、 ~fileは［ 開かれ, 読取られ, 構文解析され ］，~Web~appの中で［ ~sort可能, 動作~可能 ］な一覧として利用者に示される。 利用者は曲を選択してその歌詞を閲覧できる。 利用者は “~fileを閲覧する” ~dialogを利用する。 ◎ 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は後の利用のために~localに格納できるべきである。 それは~Web~appにおける~offline~data~accessに有用になる。 ◎ 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.
例： ~Calendar~app。 利用者の会社には予定表があり、 利用者は自身の~eventと会社の “多忙期間” として~markされた予定表との同期cを（個人-情報が漏れないように）とりたいとする。 利用者は、 一覧から~fileを探して選択する。 【~MIME型】 `text/calendar^c ~fileは、 ~browserにより構文解析され，単一の予定表~viewに併合できるようになる。 利用者は、 それを自分用の予定表~fileに保存することも（ “~~別名で保存-…” を利用して）， 統合された予定表~fileを非同期に送信して~serverに格納することもできる。 ◎ 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.
-
~UAは、 所与の~dataと~file名から，~program的に~local~fileに保存する能を供するべきである。 ◎ User agents should provide the ability to save a local file programmatically given an amount of data and a file name.
注記： この仕様は，~downloadを誘発させる明示的な~API~callは供さないが、 それは~HTML仕様にて取組まれている。 `a$e 要素の `download$a 属性 `HTML$r は、 ~downloadを起動させ， `File$I を指定された名前で保存する。 この~APIと `a^e 要素の `download^a 属性との組合nにより、 ~Web~appの中で~fileを作成して，~localに保存することが可能になる。 ◎ Note: 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 File 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.
例： ~spreadsheet~app。 利用者は、 ~formを通して何らかの入力を生成する。 その入力から~spreadsheetに組み入れられる CSV （ `Comma Separated Variables^en ）出力が生成され， “保存-…” が行われる。 生成された出力は、 ~Webに基づく~spreadsheetへ直に統合することも， 非同期に~uploadすることもできる。 ◎ 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.
-
~UAは、 今日における~formに基づく~uploadよりも効率的に働くような，［ ~fileから~dataを~remote~serverへ滞りなく送信する ］ための~program的な能を供するべきである。 ◎ 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.
例： 動画や写真の~upload~app。 利用者は~uploadに巨大な~fileを選択でき，~chunkごとに~serverに送信できる。 ◎ A Video/Photo Upload App.＼ User is able to select large files for upload, which can then be "chunk-transfered" to the server.
- ~UAは、 上に挙げた特能を可能にする~APIを~scriptに公開するべきである。 ~file~systemとのヤリトリに入るときは、 常に，~UIを通して利用者に通知される — あらゆる~transactionを［ 取消す／中止する ］能を利用者に与えるよう。 いかなる~file選択も，利用者に通知され、 利用者は，それを取消せる。 これらの~APIが、 利用者の介入を経ずに黙って呼出されることはない。 ◎ 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.
謝辞
この仕様は元々は SVG Working Group により開発された。 `Mark Baker^en, `Anne van Kesteren^en 両氏からの~feedbackに。 ◎ This specification was originally developed by the SVG Working Group. Many thanks to Mark Baker and Anne van Kesteren for their feedback.
元々の仕様の編集を行った `Robin Berjon^en, `Jonas Sicking^en, `Vsevolod Shmyroff^en 各氏に。 ◎ Thanks to Robin Berjon, Jonas Sicking and Vsevolod Shmyroff 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.
W3C WebApps WG, および [email protected] listserv の参加者達に。 ◎ Thanks to the W3C WebApps WG, and to participants on the [email protected] listserv