当前位置：首页 > news >正文

JS文件相关✅

news 2024/11/22 22:38:45

ArrayBuffer和强类型数组

ArrayBuffer

在 JavaScript 中，“缓冲区” 通常是指一种用于处理和存储二进制数据的结构，ArrayBuffer 是用于表示这些数据的主要对象。
ArrayBuffer 是一个通用、固定长度的原始二进制数据缓冲区。它本身并不直接提供操作数据的接口，而是通过不同的视图（类型化数组和DataView）来进行数据处理。

const buffer = new ArrayBuffer(16); // 创建一个 16 字节的缓冲区
const view = new DataView(buffer); // 使用 DataView 视图来操作缓冲区
view.setInt32(0, 255, true); // 在偏移量为 0 的位置写入一个 32 位整数，使用小端字节序const view_2 = new Uint8Array(buffer); // 使用 Uint8Array 视图来操作缓冲区
view_2[1] = 255; // 设置第二个字节的值为 255

类型化数组

Js里普通的数组是的长度是动态的，元素的类型可以有多种，所以他在内存里占用的空间，单个个元素在内存里占用的空间都是动态的，内存的分配也会更加分散而且不紧凑。
而类型化数组的长度和元素类型都是静态的，由于底层实现结合了固定类型和连续的内存布局，所以内存访问速度更快，尤其是在处理大量数据时。适合高性能数据处理，常用于音频处理、图形处理等。
类型化数组只能包含特定类型的数值，无法存储其他类型（字符串和对象都不行），常见的类型化数组有以下这些：

Int8Array：8 位带符号整数。
Uint8Array：8 位无符号整数。
Uint8ClampedArray：8 位无符号整数，在超出范围时会被夹紧到 0-255。
Int16Array：16 位带符号整数。
Uint16Array：16 位无符号整数。
Int32Array：32 位带符号整数。
Uint32Array：32 位无符号整数。
Float32Array：32 位浮点数。
Float64Array：64 位浮点数。
BigInt64Array：64 位大整数（带符号）。
BigUint64Array：64 位大整数（无符号）。

常见的 ~~（我用过的）~~ 操作有这些：

// 创建一个长度为 10 的 Int32Array
const intArray = new Int32Array(10);
initArray[0] = 10;
initArray[100] = 10; // 这句代码不会报错，但也没有效果，因为initArray的长度写死了是10
// 从数组创建类型化数组
const typedArrayFromArray = new Uint8Array([1, 2, 3, 4, 5]);
// 从其他类型化数组创建
const anotherTypedArray = new Float32Array(typedArrayFromArray);

总之，在之后的学习中我们大可把ArrayBuffer想像成01串。

File对象和Blob对象

定义

写在最前：文件存储到磁盘最终都是二进制数据。当你上传文件时，浏览器会将文件读取为 File 对象，而这个对象内部实际上包含的是二进制数据。

File 是 Blob 的子类，也就是说，File 继承了 Blob 的所有功能。两者都用于表示文件的二进制数据。
File 对象一般用于表示用户在文件输入控件中选择的文件，它比Blob多提供了文件在磁盘上的信息（如名称、大小、类型、最后修改时间等）。
Blob 表示一段原始数据的不可变对象（这意味着一旦创建了 Blob，你就不能修改它的内容），通常用于处理二进制数据。在不涉及文件元数据的情况下，可以使用 Blob。

既然都是二进制，也可以将File和Blob的内容读取为ArrayBuffer：

// file和blob分别是File实例和Blob实例
// 方法1
console.log(await blob.arrayBuffer())
console.log(await file.arrayBuffer())// 方法2
const fileReader = new FileReader()
fileReader.onload = e => {console.log(fileReader.result)console.log(e.target.result)
}
fileReader,readAsArrayBuffer(file)

大文件分片上传

File上的slice方法 ~~（应该是原型上的方法，无需在意）~~ 可以返回Blob对象，将Blob对象按顺序进行拼接（这一块基本归后端管）又能忠实地还原这个File，这让文件分割成为了可能。简单的实现如下：

// 给input绑定一个change事件
function handleChange() {const fileData = this.files[0] // fileData的原型链：上一层是File，再上一层是Blobconst total = fileData.size // 文件的总大小const size = 1024 * 1024 // 单片的大小const num = Math.ceil(size / total) // 一共有多少片，向上取整const fileArray = []for (let i = 0; i <= total; ++i) {// File实例的slice可以分割出BlobfileArray.push(fileData.slice(i, i + size))}// 开始分片上传fileArray.forEach(async item => {// 但是在实际的开发中，应该告诉后端当前上传的是文件的第几片await upload(item)})
}// 挂载监听事件
const inputNode = document.getElementById('fileInput')
inputNode.addEventListener('change', handleChange)// 上传调用的接口
function upload(data) {const xhr = new XMLHttpRequest()xhr.open('POST', '上传地址')xhr.send(data)
}

关于分片上传这东西需要考虑的东西还有很多。

如果上传到一半出现了网络波动，或者断网了应该怎么办？处理这个问题需要用到一种被叫做「断点续传」的技术，它允许客户端在后续时间从中断的地方继续下载，而不是从零开始。要实现这种功能就要求在客户端要具备数据持久化存储的功能，首先想到的就是IndexDB（可以存储多种类型的数据，除非用户手动操作否则不会被清除，容量比localStorage大）。
如果在某一段时间内网速太慢要怎么办？比较有效的方法是根据当前所处的网络环境 ~~（没实现过）~~ 来动态地设置每一片Blob的大小，网速较慢的情况下我们可以减小每一片的体积，以加速请求和响应。
如果文件过大分片的过程可能十分耗时，甚至阻塞了浏览器，此时可以借助的是WebWorker来实现多线程，但务必注意WebWorker的使用事项。

BlobURL和DataURL

// 创建一个blob url
URL.createObjectURL(blob) // 传入一个Blob实例或者File实例
// 创建一个data url
FileReader.readeAsDataURL(file) // 传入一个Blob实例或者File实例

关于两者的区别：blob url指向浏览器内存中的二进制数据块（Blob），通常用于大型文件或者需要动态生成的数据。而data url包含了特定数据的Base64编码字符串，通常用于将小型数据直接嵌入到文档中，如图片或者小型文件。（这样可以减少网络数据请求的次数，但是转码后的字符串的大小会比原文件的size还大，原文件的size越大，这个“增大”的“现象”就越明显）.
所以，dataUrl的性能在处理较小的数据时较好，但不适合处理大型文件，因为它会增加页面大小和加载时间。blobUrl更适合处理大型数据，因为它不会将数据直接编码到URL中，而是在浏览器内存中动态生成数据块。
dataUrl常用于嵌入图像、音频、视频或其他小型文件到HTML文档中，例如通过img、audio或video标签。blobUrl通常用于在浏览器中生成临时文件、处理大型数据或者在页面中动态创建可下载的内容。选择使用哪种URL取决于你要处理的数据大小、性能需求以及具体的使用场景。