2 files changed, 293 insertions, 0 deletions
diff --git a/files/ru/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html b/files/ru/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html
new file mode 100644
index 0000000000..0e9312398c
--- /dev/null
+++ b/files/ru/orphaned/web/api/indexeddb_api/basic_concepts_behind_indexeddb/index.html
@@ -0,0 +1,214 @@
+---
+title: Basic concepts
+slug: orphaned/Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
+translation_of: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
+original_slug: Web/API/IndexedDB_API/Basic_Concepts_Behind_IndexedDB
+---
+<p>{{DefaultAPISidebar("IndexedDB")}}</p>
+
+<div class="summary">
+<p><strong>IndexedDB</strong> обеспечивает возможность постоянного хранения данных посредством браузера пользователя. Поскольку это наделяет создаваемые web-приложения с расширенными возможностями независимостью от доступа к сети, такие приложения получают возможность работы как online, так и offline. <strong>IndexedDB</strong> полезна для приложений, хранящих большое количество данных (например, каталог DVD библиотеки проката) и не нуждающихся в постоянном подключении к Интернету (например, почтовые клиенты, перечни запланированного to-do и заметки на память).</p>
+</div>
+
+<h2 id="Об_этом_документе">Об этом документе</h2>
+
+<p>В этом введении рассматриваются основные концепции и термины в IndexedDB. Оно содержит общую картину и объясняет ключевые понятия.</p>
+
+<p>Оно может стать полезным для:</p>
+
+<ul>
+ <li>Общего понимания дизайна и структуры IndexedDB, смотри <a href="#concepts">Big Concepts</a>.</li>
+ <li>Изучения большего о терминах в IndexedDB, смотри секцию <a href="#definitions">Definitions</a>.</li>
+ <li>Детального руководства как использовать API, смотри <a href="/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB" title="en/IndexedDB/IndexedDB primer">Using IndexedDB</a>.</li>
+ <li>Рекомендованной документации по IndexedDB API, ссылаясь на основные статьи по <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB API</a> и его подстраницы, описывающие, какие типы объектов используются в IndexedDB.</li>
+ <li>Получения больше информации о том, как браузер управляет сохранением данных в фоновом режиме, читай <a href="/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria">Browser storage limits and eviction criteria</a>.</li>
+</ul>
+
+<h2 id="Обзор_IndexedDB">Обзор IndexedDB</h2>
+
+<p>IndexedDB позволяет сохранять и извлекать объекты, проиндексированные с помощью "ключа". Все манипуляции над базой данных происходят при помощи транзакций. Как и большинство решений для web-хранилищ, IndexedDB следует <a class="external" href="http://www.w3.org/Security/wiki/Same_Origin_Policy" title="http://www.w3.org/Security/wiki/Same_Origin_Policy">same-origin policy</a>. Поэтому, если получить доступ к сохранённым данным в пределах домена можно, то вне его - нет.</p>
+
+<p>IndexedDB - <a href="/en/IndexedDB#Asynchronous_API" title="https://developer.mozilla.org/en/IndexedDB#Asynchronous_API">асинхронное</a> API, которое может быть использовано в большинстве контекстов, включая <a href="/ru/docs/Web/API/Web_Workers_API/Using_web_workers" title="https://developer.mozilla.org/En/Using_web_workers">Web Workers</a>. Раньше оно включало <a href="/en/IndexedDB#Synchronous_API" title="https://developer.mozilla.org/en/IndexedDB#Synchronous_API">синхронную</a> версию, для использования в web workers, но это было удалено из спецификации в связи с недостатком интереса внутри web-сообщества.</p>
+
+<p>Существует так же конкурирующая с IndexedDB спецификация, WebSQL Database, но W3C исключила её 18 ноября 2010. Хотя IndexedDB и WebSQL оба являются решением для хранилищ, они предоставляют различный функционал. WebSQL Database - реляционная система доступа к базам данных, когда IndexedDB - система индексированной таблицы.</p>
+
+<h2 id="concepts" name="concepts">Big concepts</h2>
+
+<p>Если у вас есть опыт работы с другими типами баз данных, то вы можете быть сбиты с толку в процессе работы с IndexedDB. Поэтому имейте в виду следующие важные понятия:</p>
+
+<ul>
+ <li>
+  <p><strong>IndexedDB databases store key-value pairs.</strong> The values can be complex structured objects, and keys can be properties of those objects. You can create indexes that use any property of the objects for quick searching, as well as sorted enumeration. Keys can be binary objects.</p>
+ </li>
+ <li>
+  <p><strong>IndexedDB is built on a transactional database model</strong>. Everything you do in IndexedDB always happens in the context of a <a href="#gloss_transaction">transaction</a>. The IndexedDB API provides lots of objects that represent indexes, tables, cursors, and so on, but each of these is tied to a particular transaction. Thus, you cannot execute commands or open cursors outside of a transaction. Transactions have a well-defined lifetime, so attempting to use a transaction after it has completed throws exceptions. Also, transactions auto-commit and cannot be committed manually.</p>
+
+  <p>This transaction model is really useful when you consider what might happen if a user opened two instances of your web app in two different tabs simultaneously. Without transactional operations, the two instances could interfere with each other's modifications. If you are not familiar with transactions in a database, read the <a class="link-https" href="https://en.wikipedia.org/wiki/Database_transaction" title="https://secure.wikimedia.org/wikipedia/en/wiki/Database_transaction">Wikipedia article on transactions</a>. Also see <a href="#gloss_transaction">transaction</a> under the Definitions section.</p>
+ </li>
+ <li>
+  <p><strong>The IndexedDB API is mostly asynchronous.</strong> The API doesn't give you data by returning values; instead, you have to pass a callback function. You don't "store" a value into the database, or "retrieve" a value out of the database through synchronous means. Instead, you "request" that a database operation happens. You get notified by a DOM event when the operation finishes, and the type of event you get lets you know if the operation succeeded or failed. This sounds a little complicated at first, but there are sanity measures baked in. It's not that different from the way that <a href="/en/DOM/XMLHttpRequest" title="https://developer.mozilla.org/en/xmlhttprequest">XMLHttpRequest</a> works.</p>
+ </li>
+ <li>
+  <p><strong>IndexedDB uses a lot of requests. </strong>Requests are objects that receive the success or failure DOM events that were mentioned previously. They have <code style="font-size: 14px;">onsuccess</code> and <code style="font-size: 14px;">onerror</code> properties, and you can call <code style="font-size: 14px;">addEventListener()</code> and <code style="font-size: 14px;">removeEventListener()</code> on them. They also have <code style="font-size: 14px;">readyState</code>, <code style="font-size: 14px;">result</code>, and <code style="font-size: 14px;">errorCode</code> properties that tell you the status of the request. The <code style="font-size: 14px;">result</code> property is particularly magical, as it can be many different things, depending on how the request was generated (for example, an <code style="font-size: 14px;">IDBCursor</code> instance, or the key for a value that you just inserted into the database).</p>
+ </li>
+ <li>
+  <p><strong>IndexedDB uses DOM events to notify you when results are available.</strong> DOM events always have a <code style="font-size: 14px;">type</code> property (in IndexedDB, it is most commonly set to <code style="font-size: 14px;">"success"</code> or <code style="font-size: 14px;">"error"</code>). DOM events also have a <code style="font-size: 14px;">target</code> property that indicates where the event is headed. In most cases, the <code style="font-size: 14px;">target</code> of an event is the <code style="font-size: 14px;">IDBRequest</code> object that was generated as a result of doing some database operation. Success events don't bubble up and they can't be canceled. Error events, on the other hand, do bubble, and can be cancelled. This is quite important, as error events abort whatever transactions they're running in, unless they are cancelled.</p>
+ </li>
+ <li>
+  <p><strong>IndexedDB is object-oriented.</strong> IndexedDB is not a relational database with tables representing collections of rows and columns. This important and fundamental difference affects the way you design and build your applications.</p>
+
+  <p>In a traditional relational data store, you would have a table that stores a collection of rows of data and columns of named types of data. IndexedDB, on the other hand, requires you to create an object store for a type of data and simply persist JavaScript objects to that store. Each object store can have a collection of indexes that makes it efficient to query and iterate across. If you are not familiar with object-oriented database management systems, read the <a class="external" href="https://en.wikipedia.org/wiki/Object_database" title="http://en.wikipedia.org/wiki/Object_database">Wikipedia article on object database</a>.</p>
+ </li>
+ <li>
+  <p><strong>IndexedDB does not use </strong><strong>Structured Query Language (<abbr>SQL</abbr>).</strong> It uses queries on an index that produces a cursor, which you use to iterate across the result set. If you are not familiar with NoSQL systems, read the <a class="external" href="https://en.wikipedia.org/wiki/NoSQL" title="http://en.wikipedia.org/wiki/NoSQL">Wikipedia article on NoSQL</a>.</p>
+ </li>
+ <li>
+  <p><a name="origin"><strong>IndexedDB adheres to a same-origin policy</strong></a>. An origin is the domain, application layer protocol, and port of a URL of the document where the script is being executed. Each origin has its own associated set of databases. Every database has a name that identifies it within an origin.</p>
+
+  <p>The security boundary imposed on IndexedDB prevents applications from accessing data with a different origin. For example, while an app or a page in <a class="external" href="http://www.example.com/app/" rel="freelink">http://www.example.com/app/</a> can retrieve data from <a class="external" href="http://www.example.com/dir/" rel="freelink">http://www.example.com/dir/</a>, because they have the same origin, it cannot retrieve data from <a class="external" href="http://www.example.com:8080/dir/" rel="freelink">http://www.example.com:8080/dir/</a> (different port) or <a class="link-https" href="https://www.example.com/dir/" rel="freelink">https://www.example.com/dir/</a> (different protocol), because they have different origins.</p>
+
+  <div class="note"><strong>Note</strong>: Third party window content (e.g. {{htmlelement("iframe")}} content) can access the IndexedDB store for the origin it is embedded into, unless the browser is set to <a href="https://support.mozilla.org/en-US/kb/disable-third-party-cookies">never accept third party cookies</a> (see {{bug("1147821")}}.)</div>
+ </li>
+</ul>
+
+<h2 id="definitions" name="definitions">Definitions</h2>
+
+<p>This section defines and explains terms used in the IndexedDB API.</p>
+
+<h3 id="database" name="database">Database</h3>
+
+<dl>
+ <dt><a name="gloss_database">database</a></dt>
+ <dd>A repository of information, typically comprising one or more <a href="#gloss_object_store" title="#gloss_object_store"><em>object stores</em></a>. Each database must have the following:
+ <ul>
+  <li>Name. This identifies the database within a specific origin and stays constant throughout its lifetime. The name can be any string value (including an empty string).</li>
+  <li>
+   <p>Current <a href="#gloss_version"><em>version</em></a>. When a database is first created, its version is the integer 1 if not specified otherwise. Each database can have only one version at any given time.</p>
+  </li>
+ </ul>
+ </dd>
+ <dt><a name="durable">durable</a></dt>
+ <dd>
+ <p>In Firefox, IndexedDB used to be <strong>durable</strong>, meaning that in a readwrite transaction {{domxref("IDBTransaction.oncomplete")}} was fired only when all data was guaranteed to have been flushed to disk.</p>
+
+ <p>As of Firefox 40, IndexedDB transactions have relaxed durability guarantees to increase performance (see {{Bug("1112702")}}), which is the same behaviour as other IndexedDB-supporting browsers. In this case the {{Event("complete")}} event is fired after the OS has been told to write the data but potentially before that data has actually been flushed to disk. The event may thus be delivered quicker than before, however, there exists a small chance that the entire transaction will be lost if the OS crashes or there is a loss of system power before the data is flushed to disk. Since such catastrophic events are rare, most consumers should not need to concern themselves further.</p>
+
+ <div class="note">
+ <p><strong>Note</strong>: In Firefox, if you wish to ensure durability for some reason (e.g. you're storing critical data that cannot be recomputed later) you can force a transaction to flush to disk before delivering the <code>complete</code> event by creating a transaction using the experimental (non-standard) <code>readwriteflush</code> mode (see {{domxref("IDBDatabase.transaction")}}.) This is currently experimental, and can only be used if the <code>dom.indexedDB.experimental</code> pref is set to <code>true</code> in <code>about:config</code>.</p>
+ </div>
+ </dd>
+ <dt><a name="gloss_object_store">object store</a></dt>
+ <dd>
+ <p>The mechanism by which data is stored in the database. The object store persistently holds records, which are key-value pairs. Records within an object store are sorted according to the <em><a href="#gloss_key">keys</a></em> in an ascending order.</p>
+
+ <p>Every object store must have a name that is unique within its database. The object store can optionally have a <em><a href="#gloss_keygenerator">key generator</a></em> and a <em><a href="#gloss_keypath">key path</a></em>. If the object store has a key path, it is using <em><a href="#gloss_inline_key">in-line keys</a></em>; otherwise, it is using <em><a href="#gloss_outofline_key">out-of-line keys</a></em>.</p>
+
+ <p>For the reference documentation on object store, see {{domxref("IDBObjectStore")}}.</p>
+ </dd>
+ <dt><a name="gloss_version">version</a></dt>
+ <dd>When a database is first created, its version is the integer 1. Each database has one version at a time; a database can't exist in multiple versions at once. The only way to change the version is by opening it with a greater version than the current one. This will start a <a href="/en-US/docs/Web/API/IDBVersionChangeRequest"><code>versionchange</code></a> <em>transaction</em> and fire an <a href="/en-US/docs/Web/Reference/Events/upgradeneeded_indexedDB"><code>upgradeneeded</code></a> event. The only place where the schema of the database can be updated is inside the handler of that event.</dd>
+ <dd>Note: This definition describes the <a class="external" href="http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html">most recent specification</a>, which is only implemented in up-to-date browsers. Old browsers implemented the now deprecated and removed <a href="/en-US/docs/IndexedDB/IDBDatabase#setVersion()" title="/en-US/docs/IndexedDB/IDBDatabase#setVersion()"><code>IDBDatabase.setVersion()</code></a> method.</dd>
+ <dt><a name="gloss_database_connection">database connection</a></dt>
+ <dd>An operation created by opening a <em><a href="#gloss_database">database</a></em>. A given database can have multiple connections at the same time.</dd>
+ <dt><a name="gloss_transaction">transaction</a></dt>
+ <dd>
+ <p>An atomic set of data-access and data-modification operations on a particular database. It is how you interact with the data in a database. In fact, any reading or changing of data in the database must happen in a transaction.</p>
+
+ <p>A database connection can have several active transactions associated with it at a time, so long as the writing transactions do not have overlapping <a href="#scope"><em>scopes</em></a>. The scope of transactions, which is defined at creation, determines which object stores the transaction can interact with and remains constant for the lifetime of the transaction. So, for example, if a database connection already has a writing transaction with a scope that just covers the <code>flyingMonkey</code> object store, you can start a second transaction with a scope of the <code>unicornCentaur</code> and <code>unicornPegasus</code> object stores. As for reading transactions, you can have several of them — even overlapping ones.</p>
+
+ <p>Transactions are expected to be short-lived, so the browser can terminate a transaction that takes too long, in order to free up storage resources that the long-running transaction has locked. You can abort the transaction, which rolls back the changes made to the database in the transaction. And you don't even have to wait for the transaction to start or be active to abort it.</p>
+
+ <p>The three modes of transactions are: <code>readwrite</code>, <code>readonly</code>, and <code>versionchange</code>. The only way to create and delete object stores and indexes is by using a <a href="/en-US/docs/Web/Reference/Events/versionchange_indexedDB"><code>versionchange</code></a> transaction. To learn more about transaction types, see the reference article for <a href="/en/IndexedDB" title="https://developer.mozilla.org/en/IndexedDB">IndexedDB</a>.</p>
+
+ <p>Because everything happens within a transaction, it is a very important concept in IndexedDB. To learn more about transactions, especially on how they relate to versioning, see {{domxref("IDBTransaction")}}, which also has reference documentation.</p>
+ </dd>
+ <dt><a name="gloss_request">request</a></dt>
+ <dd>The operation by which reading and writing on a database is done. Every request represents one read or write operation.</dd>
+ <dt><a name="gloss_index">index</a></dt>
+ <dd>
+ <p>An index is a specialized object store for looking up records in another object store, called the <em>referenced object store</em>. The index is a persistent key-value storage where the value part of its records is the key part of a record in the referenced object store. The records in an index are automatically populated whenever records in the referenced object store are inserted, updated, or deleted. Each record in an index can point to only one record in its referenced object store, but several indexes can reference the same object store. When the object store changes, all indexes that refer to the object store are automatically updated.</p>
+
+ <p>Alternatively, you can also look up records in an object store using the <a href="#gloss_key"> key</a><em>.</em></p>
+
+ <p>To learn more on using indexes, see <a href="/en/IndexedDB/Using_IndexedDB#Using_an_index" title="en/IndexedDB/Using_IndexedDB#Using_an_index">Using IndexedDB</a>. For the reference documentation on index, see <a href="../../../../en/IndexedDB/IDBKeyRange" rel="internal">IDBKeyRange</a>.</p>
+ </dd>
+</dl>
+
+<h3 id="key" name="key">Key and value</h3>
+
+<dl>
+ <dt><a name="gloss_key">key</a></dt>
+ <dd>
+ <p>A data value by which stored values are organized and retrieved in the object store. The object store can derive the key from one of three sources: a <em><a href="#gloss_keygenerator">key generator</a></em>, a <em><a href="#gloss_keypath">key path</a></em>, or an explicitly specified value. The key must be of a data type that has a number that is greater than the one before it. Each record in an object store must have a key that is unique within the same store, so you cannot have multiple records with the same key in a given object store.</p>
+
+ <p>A key can be one of the following types: <a href="/en/JavaScript/Reference/Global_Objects/String" title="https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String">string</a>, <a href="/en/JavaScript/Reference/Global_Objects/Date" title="en/JavaScript/Reference/Global Objects/Date">date</a>, float, a binary blob, and <a href="/en/JavaScript/Reference/Global_Objects/Array" title="en/JavaScript/Reference/Global Objects/Array">array</a>. For arrays, the key can range from an empty value to infinity. And you can include an array within an array.</p>
+
+ <p>Alternatively, you can also look up records in an object store using the <em><a href="#gloss_index">index</a>.</em></p>
+ </dd>
+ <dt><a name="gloss_keygenerator">key generator</a></dt>
+ <dd>A mechanism for producing new keys in an ordered sequence. If an object store does not have a key generator, then the application must provide keys for records being stored. Generators are not shared between stores. This is more a browser implementation detail, because in web development, you don't really create or access key generators.</dd>
+ <dt><a name="gloss_inline_key">in-line key</a></dt>
+ <dd>A key that is stored as part of the stored value. It is found using a <em>key path</em>. An in-line key can be generated using a generator. After the key has been generated, it can then be stored in the value using the key path or it can also be used as a key.</dd>
+ <dt><a name="gloss_outofline_key">out-of-line key</a></dt>
+ <dd>A key that is stored separately from the value being stored.</dd>
+ <dt><a name="gloss_keypath">key path</a></dt>
+ <dd>Defines where the browser should extract the key from in the object store or index. A valid key path can include one of the following: an empty string, a JavaScript identifier, or multiple JavaScript identifiers separated by periods or an array containing any of those. It cannot include spaces.</dd>
+ <dt><a name="gloss_value">value</a></dt>
+ <dd>
+ <p>Each record has a value, which could include anything that can be expressed in JavaScript, including <a href="/en/JavaScript/Reference/Global_Objects/Boolean" rel="internal" title="en/JavaScript/Reference/Global_Objects/Boolean">boolean</a>, <a href="/en/JavaScript/Reference/Global_Objects/Number" rel="internal" title="en/JavaScript/Reference/Global_Objects/Number">number</a>, <a href="/en/JavaScript/Reference/Global_Objects/String" title="https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/String">string</a>, <a href="/en/JavaScript/Reference/Global_Objects/Date" title="en/JavaScript/Reference/Global Objects/Date">date</a>, <a href="/en/JavaScript/Reference/Global_Objects/Object" title="en/JavaScript/Reference/Global Objects/Object">object</a>, <a href="/en/JavaScript/Reference/Global_Objects/Array" rel="internal" title="en/JavaScript/Reference/Global_Objects/Array">array</a>, <a href="/en/JavaScript/Reference/Global_Objects/RegExp" rel="internal" title="en/JavaScript/Reference/Global_Objects/RegExp">regexp</a>, <a href="/en/JavaScript/Reference/Global_Objects/undefined" title="en/JavaScript/Reference/Global_Objects/undefined">undefined</a>, and null.</p>
+
+ <p>When an object or array is stored, the properties and values in that object or array can also be anything that is a valid value.</p>
+
+ <p><a href="/en/DOM/Blob" title="en/DOM/Blob">Blobs</a> and files can be stored, cf. <a class="external" href="http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html">specification</a>.</p>
+ </dd>
+</dl>
+
+<h3 id="range" name="range">Range and scope</h3>
+
+<dl>
+ <dt id="scope"><a id="gloss_scope" name="gloss_scope">scope</a></dt>
+ <dd>The set of object stores and indexes to which a transaction applies. The scopes of read-only transactions can overlap and execute at the same time. On the other hand, the scopes of writing transactions cannot overlap. You can still start several transactions with the same scope at the same time, but they just queue up and execute one after another.</dd>
+ <dt id="cursor"><a id="gloss_cursor" name="gloss_cursor">cursor</a></dt>
+ <dd>A mechanism for iterating over multiple records with a <em>key range</em>. The cursor has a source that indicates which index or object store it is iterating. It has a position within the range, and moves in a direction that is increasing or decreasing in the order of record keys. For the reference documentation on cursors, see {{domxref("IDBCursor")}}.</dd>
+ <dt id="key_range"><a id="gloss_keyrange" name="gloss_keyrange">key range</a></dt>
+ <dd>
+ <p>A continuous interval over some data type used for keys. Records can be retrieved from object stores and indexes using keys or a range of keys. You can limit or filter the range using lower and upper bounds. For example, you can iterate over all values of a key between x and y.</p>
+
+ <p>For the reference documentation on key range, see {{domxref("IDBKeyRange")}}.</p>
+ </dd>
+</dl>
+
+<h2 id="limitations" name="limitations">Limitations</h2>
+
+<p>IndexedDB is designed to cover most cases that need client-side storage. However, it is not designed for a few cases like the following:</p>
+
+<ul>
+ <li>Internationalized sorting. Not all languages sort strings in the same way, so internationalized sorting is not supported. While the database can't store data in a specific internationalized order, you can sort the data that you've read out of the database yourself. Note, however, that <a href="/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Locale-aware_sorting">locale-aware sorting</a> has been allowed with an experimental flag enabled (currently for Firefox only) since Firefox 43.</li>
+ <li>Synchronizing. The API is not designed to take care of synchronizing with a server-side database. You have to write code that synchronizes a client-side indexedDB database with a server-side database.</li>
+ <li>Full text searching. The API<span style="direction: ltr;"> does not have an</span><span style="direction: ltr;"> equivalent of the <code>LIKE</code> operator in SQL. </span></li>
+</ul>
+
+<p>In addition, be aware that browsers can wipe out the database, such as in the following conditions:</p>
+
+<ul>
+ <li>The user requests a wipe out. Many browsers have settings that let users wipe all data stored for a given website, including cookies, bookmarks, stored passwords, and IndexedDB data.</li>
+ <li>The browser is in private browsing mode. Some browsers, have "private browsing" (Firefox) or "incognito" (Chrome) modes. At the end of the session, the browser wipes out the database.</li>
+ <li>The disk or quota limit has been reached.</li>
+ <li>The data is corrupt.</li>
+ <li>An incompatible change is made to the feature.</li>
+</ul>
+
+<p>The exact circumstances and browser capabilities change over time, but the general philosophy of the browser vendors is to make the best effort to keep the data when possible.</p>
+
+<h2 id="next" name="next">Next steps</h2>
+
+<p>With these big concepts under our belts, we can get to more concrete stuff. For a tutorial on how to use the API, see <a href="/en/IndexedDB/Using_IndexedDB" title="en/IndexedDB/IndexedDB primer">Using IndexedDB</a>.</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="http://www.w3.org/TR/IndexedDB/" title="http://www.w3.org/TR/IndexedDB/"><span style="direction: ltr;">Indexed Database API Specification</span></a></li>
+ <li><a href="/en/IndexedDB" title="https://developer.mozilla.org/en/IndexedDB">IndexedDB API Reference</a></li>
+ <li><a href="/en/IndexedDB/Using_IndexedDB" title="en/IndexedDB/IndexedDB primer">Using IndexedDB</a></li>
+ <li><a class="external" href="http://msdn.microsoft.com/en-us/scriptjunkie/gg679063.aspx" title="http://msdn.microsoft.com/en-us/scriptjunkie/gg679063.aspx">IndexedDB — The Store in Your Browser</a></li>
+</ul>
diff --git a/files/ru/orphaned/web/javascript/reference/errors/typed_array_invalid_arguments/index.html b/files/ru/orphaned/web/javascript/reference/errors/typed_array_invalid_arguments/index.html
new file mode 100644
index 0000000000..ab6bcf3748
--- /dev/null
+++ b/files/ru/orphaned/web/javascript/reference/errors/typed_array_invalid_arguments/index.html
@@ -0,0 +1,79 @@
+---
+title: 'TypeError: invalid arguments'
+slug: orphaned/Web/JavaScript/Reference/Errors/Typed_array_invalid_arguments
+tags:
+  - Error
+  - Errors
+  - JavaScript
+  - TypeError
+  - Ошибки
+translation_of: Web/JavaScript/Reference/Errors/Typed_array_invalid_arguments
+original_slug: Web/JavaScript/Reference/Errors/Typed_array_invalid_arguments
+---
+<div>{{jsSidebar("Errors")}}</div>
+
+<h2 id="Сообщение">Сообщение</h2>
+
+<pre class="syntaxbox">TypeError: invalid arguments (Firefox)</pre>
+
+<h2 id="Тип_ошибки">Тип ошибки</h2>
+
+<p>{{jsxref("TypeError")}}</p>
+
+<h2 id="Что_не_так">Что не так?</h2>
+
+<p>Конструкторы <a href="/ru/docs/Web/JavaScript/Typed_arrays">типизированных массивов</a> требуют либо</p>
+
+<ul>
+ <li>длину,</li>
+ <li>другой типизированный массив,</li>
+ <li>массивоподобные объекты,</li>
+ <li>итерируемые объекты либо</li>
+ <li>объект {{jsxref("ArrayBuffer")}}</li>
+</ul>
+
+<p>чтобы создать новый типизированный массив. Другие аргументы конструктора не создают допустимый типизированный массив.</p>
+
+<h2 id="Примеры">Примеры</h2>
+
+<p>Типизированные массивы, например {{jsxref("Uint8Array")}}, не могут быть построены из строки. На самом деле строки вообще не могут быть в типизированных массивах.</p>
+
+<pre class="brush: js example-bad">var ta = new Uint8Array("nope");
+// TypeError: invalid arguments
+</pre>
+
+<p>Различные способы создания допустимого {{jsxref("Uint8Array")}}:</p>
+
+<pre class="brush: js example-good"> // From a length
+var uint8 = new Uint8Array(2);
+uint8[0] = 42;
+console.log(uint8[0]); // 42
+console.log(uint8.length); // 2
+console.log(uint8.BYTES_PER_ELEMENT); // 1
+
+// From an array
+var arr = new Uint8Array([21,31]);
+console.log(arr[1]); // 31
+
+// From another TypedArray
+var x = new Uint8Array([21, 31]);
+var y = new Uint8Array(x);
+console.log(y[0]); // 21
+
+// From an ArrayBuffer
+var buffer = new ArrayBuffer(8);
+var z = new Uint8Array(buffer, 1, 4);
+
+// From an iterable
+var iterable = function*(){ yield* [1,2,3]; }();
+var uint8 = new Uint8Array(iterable);
+// Uint8Array[1, 2, 3]
+</pre>
+
+<h2 id="Смотрите_также">Смотрите также</h2>
+
+<ul>
+ <li><a href="/ru/docs/Web/JavaScript/Typed_arrays">Типизированные массивы</a></li>
+ <li>{{jsxref("ArrayBuffer")}}</li>
+ <li>{{jsxref("Uint8Array")}}</li>
+</ul>