Vous emmène découvrir l'API File, l'API Streams et l'API Web Cryptography en JavaScript.

Cet article vous apporte des connaissances pertinentes sur javascript, qui présente principalement le contenu pertinent de l'API File, de l'API Streams et de l'API Web Cryptography en JavaScript. J'espère qu'il sera utile à tout le monde.

【Recommandation associée : Tutoriel vidéo javascript】

1. Atomics et SharedArrayBuffer

Lorsque plusieurs contextes accèdent à SharedArrayBuffer, si des opérations sont effectuées sur le tampon en même temps, des problèmes de conflit de ressources peuvent survenir. L'API Atomics permet à plusieurs contextes de lire et d'écrire en toute sécurité un SharedArrayBuffer en forçant qu'une seule opération puisse être effectuée sur le tampon à la fois.
La nature des opérations atomiques exclut les optimisations (telles que la réorganisation des instructions) que le système d'exploitation ou le matériel informatique effectuerait normalement automatiquement. Les opérations atomiques rendent également impossible l'accès simultané à la mémoire. Si elles sont utilisées de manière inappropriée, elles peuvent ralentir l'exécution du programme. Pour cette raison, l'intention initiale de la conception de l'API Atomics est de créer des programmes JavaScript multithread complexes basés sur un minimum mais stable. comportement atomique.

2. Bases des opérations atomiques

1. Méthodes arithmétiques et d'opérations sur bits

L'API atomique fournit un ensemble de méthodes simples pour effectuer des opérations de modification sur place. Dans la spécification ECMA, ces méthodes sont définies comme des opérations AtomicReadModifyWrite. Sous le capot, ces méthodes lisent une valeur à partir d'un emplacement dans SharedArrayBuffer, effectuent des opérations arithmétiques et au niveau du bit, et enfin écrivent le résultat au même emplacement. La nature atomique de ces opérations signifie que les opérations de lecture, de modification et d'écriture décrites ci-dessus seront exécutées dans l'ordre et ne seront pas interrompues par d'autres threads.

//创建大小为1的缓冲区let sharedArrayBuffer = new SharedArrayBuffer(1);
//基于缓冲创建Unit8Arraylet typedArray = new Unit8Array(sharedArrayBuffer);
//所有ArrayBuffer全部初始化为0console.log(typedArray);
//Unit8Array[0]
//对索引0处的值执行原子加10Atomics.add(typedArray,0,10);
//Unit8Array[10]
//对索引0处的值执行原子减10Atomics.sub(typedArray,0,10);
//Unit8Array[0]

2. Lecture et écriture atomiques

Le compilateur JavaScript du navigateur et l'architecture du processeur elle-même ont le pouvoir de réorganiser les instructions pour améliorer l'efficacité de l'exécution du programme. Dans des circonstances normales, l'environnement monothread de JavaScript peut effectuer cette optimisation à tout moment, mais le réarrangement des instructions dans plusieurs threads peut entraîner des conflits de ressources et est extrêmement difficile à dépanner.
L'API Atomics résout ce problème de deux manières principales :

• L'ordre de toutes les instructions atomiques n'est jamais réorganisé les unes par rapport aux autres.

• L'utilisation de lectures et d'écritures atomiques garantit que toutes les instructions ne sont pas réorganisées par rapport aux lectures et écritures atomiques.

En plus de lire et d'écrire des valeurs de tampon, Atomics.load() et Atomics.store() peuvent également créer des « clôtures de code ». Le moteur JavaScript garantit que les instructions non atomiques peuvent être réorganisées localement par rapport à load() et store(), mais ce réarrangement ne violera pas les limites des lectures et écritures atomiques.

const sharedArrayBuffer = new SharedArrayBuffer(4);
const view = new Unit32Array(sharedArrayBuffer);
//执行非原子写view[0] = 1;
//非原子写可以保证在这个读操作之前完成，因此这里一定会读到1console.log(Atomics.load(view,0));
//1
//执行原子写Atomics.store(view,0,2);
//非原子读可以保证在原子写完成后发生，这里一定会读到2console.log(view[0]);
//2

3. Atomic Exchange

Afin d'assurer d'abord une lecture continue et ininterrompue, puis une écriture, l'API Atomics propose deux méthodes : Exchange() et compareExchange(). Atomics.exchange() effectue un échange simple qui garantit que les autres threads n'interrompront pas l'échange.

const sharedArrayBuffer = new SharedArrayBuffer(4);
const view = new Unit32Array(sharedArrayBuffer);
//在索引0处写入10Atomics.store(view,0,10);
//从索引0处读取值，然后在索引0处写入5console.log(Atomics.exchange(view,0,5));
//10
//从索引0处读取值console.log(Atomics.load(view,0));
//5

Dans un programme multithread, un thread peut vouloir écrire dans un tampon partagé uniquement si aucun autre thread n'a modifié la valeur depuis la dernière fois qu'elle a été lue. Si la valeur n'a pas été modifiée, ce thread peut écrire en toute sécurité la valeur mise à jour : si la valeur a été modifiée, effectuer une opération d'écriture détruira la valeur calculée par les autres threads. Pour ce type de tâche, l'API Atomics fournit la méthode compare-Exchange(). Cette méthode effectue l'opération d'écriture uniquement si la valeur à l'index cible correspond à la valeur attendue.

4. Fonctionnement et verrouillage d'Atomic Futex

Sans une sorte de mécanisme de verrouillage, les programmes multithread ne peuvent pas prendre en charge des exigences complexes. À cette fin, l'API Atomics fournit des méthodes qui imitent Linux Futex (mutex rapide de l'espace utilisateur). Ces méthodes, bien que très simples en elles-mêmes, peuvent servir de composants de base pour des mécanismes de verrouillage plus complexes.
Toutes les opérations atomiques Futex ne peuvent être utilisées que sur les vues Int32Array et uniquement dans les threads de travail.

3. Messagerie inter-contexte

La messagerie inter-documents, parfois également appelée XDM (messagerie inter-documents), est la possibilité de transférer des informations entre différents contextes d'exécution (tels que différents threads de travail ou pages provenant de différentes sources).

4. API d'encodage

L'API d'encodage est principalement utilisée pour convertir entre des chaînes et des tableaux stéréotypés.

5. API de fichier et API Blob

1. Type de fichier

L'API de fichier est toujours basée sur le champ de saisie du fichier dans le formulaire, mais ajoute la possibilité d'accéder directement aux informations du fichier. HTML5 ajoute une collection de fichiers au DOM pour les éléments d'entrée de fichiers. Lorsque l'utilisateur sélectionne un ou plusieurs fichiers dans le champ Fichier, la collection de fichiers contient un ensemble d'objets Fichier représentant les fichiers sélectionnés. Chaque objet Fichier possède des attributs en lecture seule.

2. Type FileReader

Le type FileReader représente un mécanisme de lecture de fichiers asynchrone Vous pouvez considérer FileReader comme similaire à XMLHttpRequest, sauf qu'il est utilisé pour lire des fichiers à partir du système de fichiers au lieu de lire des données à partir du serveur. Le type FileReader propose plusieurs méthodes pour lire les données des fichiers.

• readAsText(file,encoding);//Lire le contenu en texte brut du fichier et l'enregistrer dans l'attribut de résultat

• readAsDataURL(file);//Lire le fichier et enregistrer les données URI du contenu dans l'attribut de résultat

• readAsBinaryString(file);//Lire le fichier et enregistrer les données binaires de chaque caractère dans le résultat attribut Medium

• readAsArrayBuffer(file);//Lire le fichier et enregistrer le contenu du fichier dans l'attribut result sous la forme d'ArrayBuffer

3. Type FileReaderSync

Une version synchrone du type FileReader.

4. Blob et lecture partielle

Dans certains cas, vous devrez peut-être lire une partie du fichier au lieu du fichier entier. Pour cela, l'objet File fournit une méthode appelée slice(). La méthode slice() reçoit deux paramètres : l'octet de départ et le nombre d'octets dans la zone Yaodu. Cette méthode renvoie une instance de Blob, qui est en fait une superclasse de File.
Blob représente un gros objet binaire, qui est le type d'encapsulation de JavaScript pour les données binaires non modifiables. Des tableaux contenant des chaînes, des ArrayBuffers, des ArrayBufferViews et même d'autres blobs peuvent être utilisés pour créer des blobs. Le constructeur Blob peut recevoir un paramètre options et y spécifier le type MIME.

6. API Streams

1. Scénarios d'application

L'API Streams est née pour résoudre un problème simple mais fondamental : comment une application Web consomme-t-elle de petits blocs d'informations ordonnés au lieu de gros blocs d'informations ? Il existe deux principaux scénarios d'application pour cette fonctionnalité.

1. De grandes quantités de données peuvent ne pas être disponibles en même temps. La réponse à une requête réseau est un exemple typique. Les charges réseau sont transmises sous forme de paquets continus et le streaming permet aux applications de consommer les données au fur et à mesure qu'elles arrivent plutôt que d'avoir à attendre que toutes les données soient chargées.
2. De grandes données peuvent devoir être traitées en petites parties. Le traitement vidéo, la compression des données, l'encodage d'images et l'analyse JSON sont autant d'exemples de choses qui peuvent être traitées en petits morceaux sans avoir à attendre que toutes les données soient en mémoire.

2. Comprendre les flux

L'API Streams définit trois flux :

• Flux lisible : un flux qui peut lire des blocs de données via une certaine interface publique. Les données entrent dans le flux en interne à partir de la source sous-jacente et sont ensuite traitées par le consommateur.

• Flux inscriptible : un flux qui peut écrire des blocs de données via une certaine interface publique. Le producteur (consommateur) écrit des données dans le flux et les données sont transférées en interne vers l'emplacement de données sous-jacent (puits).

• Flux de conversion : il se compose de deux flux, le flux inscriptible est utilisé pour recevoir des données et le flux lisible est utilisé pour générer des données. Ces deux contrôles de qualité du flux sont des transformateurs qui peuvent inspecter et modifier le contenu du flux selon les besoins.

7. API de cryptographie Web

L'API de cryptographie Web décrit un ensemble d'outils de cryptographie qui standardise la façon dont JavaScript implémente le cryptage de manière sécurisée et conventionnelle. Ces outils incluent la génération, l'utilisation et l'application de paires de clés cryptographiques, le cryptage et le déchiffrement des informations et la génération fiable de nombres aléatoires.

De nombreuses personnes utilisent Math.random() lorsqu'elles ont besoin de générer des nombres aléatoires. Cette méthode est implémentée dans le navigateur en tant que générateur de nombres pseudo-aléatoires (PRNG, PseudoRandom Number Generator). Le soi-disant pseudo fait référence au processus de génération de valeurs qui n'est pas vraiment aléatoire. Les valeurs générées par PRNG ne simulent que des caractéristiques aléatoires. Le PRNG du navigateur n'utilise pas de véritable source aléatoire, mais applique uniquement un algorithme fixe à un état interne. A chaque fois que Math.random() est appelé, cet état interne est modifié par un algorithme, et le résultat est converti en un nouveau nombre aléatoire. Par exemple, le moteur V8 utilise un algorithme appelé xorshift128+ pour effectuer cette modification. Math.random()。这个方法在浏览器中是以伪随机数生成器（PRNG，PseudoRandom Number Generator）方式实现的。所谓的伪指的是生成值的过程不是真的随机。PRNG生成的值只是模拟了随机的特性。浏览器的PRNG并未使用真正的随机源，只是对一个内部状态应用了固定的算法。每次调用Math.random()，这个内部状态都会被一个算法修改，而结果会被转换为一个新的随机数。例如，V8引擎使用了一个名为xorshift128+的算法来执行这种修改。

由于算法本身是固定的，其输入只是之前的状态，因此随机数顺序也是确定的。xorshift128+使用128位内部状态，而算法的设计让任何初始状态在重复自身之前都会产生2¹²⁸-1个伪随机值。这种循环被称为置换循环，而这个循环的长度被称为一个周期。很明显，如果攻击者知道PRNG的内部状态，就可以预测后续生成的伪随机值。如果开发者无意中使用了PRNG生成了私有密钥用于加密，则攻击者就可以利用PRNG的这个特性算出私有密钥。

伪随机数生成器主要用于快速计算出看起来随机的数，不过并不适合用于加密算法，为解决这个问题，密码学安全伪随机数生成器（CSPRNG，Cryptographically Secure PseudoRandom Number Generator）,额外增加了一个熵作为输入，例如测试硬件时间或其它无法预计行为的系统特性，虽然速度上不及PRNG，但是生成的值更难预测了，就可以用于加密。

Web Cryptography API引入了CSPRNG，这个CSPRNG可以通过crypto.getRandomValues()在全局Crypto对象上访问。与Math.random()返回一个0到1之间的浮点数不同，getRandomValues()

Étant donné que l'algorithme lui-même est fixe et que son entrée n'est que l'état précédent, la séquence de nombres aléatoires est également déterminée. xorshift128+ utilise un état interne de 128 bits et l'algorithme est conçu de telle sorte que tout état initial produit 2¹²⁸-1 valeurs pseudo-aléatoires avant de se répéter. Ce type de boucle est appelé boucle de permutation et la longueur de cette boucle est appelée période. Il est évident que si l’attaquant connaît l’état interne du PRNG, il peut prédire les valeurs pseudo-aléatoires générées par la suite. Si le développeur utilise par inadvertance PRNG pour générer une clé privée pour le chiffrement, l'attaquant peut utiliser cette fonctionnalité de PRNG pour calculer la clé privée.

Le générateur de nombres pseudo-aléatoires est principalement utilisé pour calculer rapidement des nombres apparemment aléatoires, mais il ne convient pas aux algorithmes de cryptage, pour résoudre ce problème, un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG, Cryptographically Secure PseudoRandom Number Generator), un outil supplémentaire. l'entropie est ajoutée en entrée, comme le test du temps matériel ou d'autres caractéristiques du système avec un comportement imprévisible. Bien qu'elle ne soit pas aussi rapide que PRNG, la valeur générée est plus difficile à prédire et peut être utilisée pour le cryptage.

L'API Web Cryptography introduit CSPRNG, accessible sur l'objet global Crypto via crypto.getRandomValues(). Contrairement à Math.random() qui renvoie un nombre à virgule flottante compris entre 0 et 1, getRandomValues() écrit des valeurs aléatoires dans le tableau stéréotypé qui lui est passé en paramètre. La classe du tableau stéréotypé n'a pas d'importance car le tampon sous-jacent sera rempli de bits aléatoires.

🎜Carte mentale JavaScript🎜🎜🎜🎜

【Recommandations associées : tutoriel vidéo javascript, front-end web】

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!