DataView是JavaScript中操作二进制数据的核心工具，它基于ArrayBuffer提供灵活的字节级读写能力，支持多种数据类型和字节序控制，尤其适用于解析混合类型的复杂二进制协议。与仅支持单一类型的TypedArray不同，DataView允许在同一个缓冲区中按指定偏移量读写不同类型的值（如int16、float32等），并通过littleEndian参数精确处理大小端问题，确保跨平台数据解析的正确性。两者共享底层ArrayBuffer，可协同使用，TypedArray适合高性能同构数据处理，而DataView胜在灵活性和协议解析能力。
DataView，简单来说，它就像是JavaScript世界里，我们用来精准操作二进制数据的一把瑞士军刀。它不直接存储数据，而是提供一个视图，让我们能以字节为单位，自由地读写
ArrayBuffer
中的任意位置、任意类型的数据，无论那是整数、浮点数，还是有符号无符号。
解决方案
处理二进制数据，光有一个
ArrayBuffer
是远远不够的。
ArrayBuffer
就像一块原始的、未加工的内存区域，它本身不提供任何读写机制，你甚至不知道里面存的是什么类型的数据。这时候，
DataView
就登场了。它提供了一套API，允许我们从
ArrayBuffer
中以特定的偏移量（offset）和数据类型（如8位整数、32位浮点数等）来读取或写入数据，并且还能灵活地处理字节序（endianness）。
想象一下，你拿到了一串二进制数据，它可能来自网络传输，也可能是一个文件。这串数据里，前两个字节代表一个ID，接着四个字节是一个时间戳，再后面是某个传感器的读数（可能是个浮点数）。如果直接用
TypedArray
，你可能需要创建多个不同类型的视图，并且每次都要确保它们对齐。但
DataView
则不同，它能让你在同一个
ArrayBuffer
上，像操作指针一样，跳到指定位置，然后告诉它：“从这里开始，给我读一个无符号16位整数。”或者“从这里开始，给我写一个32位浮点数。”这种灵活性，在处理复杂或混合类型的二进制协议时，简直是救命稻草。
// 假设我们有一个8字节的ArrayBufferconst buffer = new ArrayBuffer(8);// 创建一个DataView来操作这个bufferconst view = new DataView(buffer);// 写入数据// 在偏移量0处写入一个无符号16位整数 (0x1234)view.setUint16(0, 0x1234, false); // false表示大端字节序 (Big-Endian)// 在偏移量2处写入一个有符号32位整数 (-123456789)view.setInt32(2, -123456789, true); // true表示小端字节序 (Little-Endian)// 在偏移量6处写入一个无符号8位整数 (0xFF)view.setUint8(6, 0xFF);// 读取数据console.log('Uint16 at offset 0 (Big-Endian):', view.getUint16(0, false).toString(16)); // 1234console.log('Int32 at offset 2 (Little-Endian):', view.getInt32(2, true)); // -123456789console.log('Uint8 at offset 6:', view.getUint8(6).toString(16)); // ff// 尝试读取一个不存在的类型或越界try { view.getFloat64(7); // 只有1个字节了，尝试读取8字节的Float64会报错} catch (e) { console.error('Error when reading out of bounds:', e.message); // DataView.prototype.getFloat64: Offset is outside the bounds of the DataView}
为什么在处理二进制数据时需要DataView？
我最初接触二进制数据时，总觉得它像一团混沌，所有的信息都挤在一起，没有明确的边界。
ArrayBuffer
就像那团混沌本身，它只是一块内存，你不知道里面到底存了什么。而
DataView
，对我来说，就是那把能让我看清纹理、划分区域的放大镜和刻刀。
设想一下，你正在开发一个前端应用，需要解析一个从后端通过WebSocket传过来的二进制协议包。这个包里可能包含了多种数据类型：一个表示消息类型的字节，一个表示数据长度的短整数，接着是一个浮点数表示的温度，最后可能是一段UTF-8编码的字符串。如果每次都得把整个
ArrayBuffer
转换成
Uint8Array
，然后手动计算偏移量，再进行位运算来拼凑出完整的数值，那工作量和出错率都会大大增加。
DataView
的价值就在于它的“视图”特性和类型感知能力。它不要求你提前知道所有数据的类型和排列方式，而是允许你在运行时，根据协议的定义，灵活地从任何字节位置开始，以任何预期的类型去读取数据。比如，我知道消息类型是第一个字节，我就用
getUint8(0)
；我知道温度是第三个字节开始的四个字节，我就用
getFloat32(2)
。这种直观的操作方式，极大地简化了二进制协议的解析和构建过程。它避免了大量繁琐的位操作和字节序转换逻辑，让我们可以更专注于业务逻辑本身，而不是底层的数据处理细节。
DataView如何读写不同类型的数据？
DataView
的核心能力就体现在它提供了一系列以
get
和
set
开头的方法，用于读写不同长度和类型的数据。这些方法涵盖了从8位（字节）到64位（双精度浮点数）的各种整数和浮点数类型，而且还能指定字节序。
我写代码的时候，经常会遇到要从一个字节流里解析出不同长度、不同类型的数据，比如前两个字节是ID，后面四个字节是时间戳，再后面是温度值。
DataView
就是为这种场景而生的。
它的读写方法通常遵循这样的模式：
get(byteOffset, [littleEndian])
：从
byteOffset
位置开始，读取指定
Type
的数据。
set(byteOffset, value, [littleEndian])
：从
byteOffset
位置开始，写入
value
为指定
Type
的数据。
这里的
Type
可以是：
Int8
,
Uint8
: 8位有符号/无符号整数（一个字节）
Int16
,
Uint16
: 16位有符号/无符号整数（两个字节）
Int32
,
Uint32
: 32位有符号/无符号整数（四个字节）
Float32
: 32位浮点数（四个字节）
Float64
: 64位浮点数（八个字节）
byteOffset
参数是必填的，它指定了从
ArrayBuffer
开头算起的字节偏移量。
littleEndian
参数是可选的布尔值，默认为
false
（即大端字节序）。如果设置为
true
，则表示按小端字节序处理。
const buffer = new ArrayBuffer(16); // 16字节缓冲区const view = new DataView(buffer);// 写入数据view.setUint8(0, 255); // 写入一个无符号8位整数 (0xFF)view.setInt16(1, -32000, true); // 在偏移量1处写入一个有符号16位整数，小端序view.setFloat32(3, 3.14159, false); // 在偏移量3处写入一个32位浮点数，大端序view.setBigInt64(7, 1234567890123456789n, true); // 在偏移量7处写入一个64位大整数，小端序 (需要ES2020支持BigInt)// 读取数据console.log('Uint8 at offset 0:', view.getUint8(0)); // 255console.log('Int16 at offset 1 (Little-Endian):', view.getInt16(1, true)); // -32000console.log('Float32 at offset 3 (Big-Endian):', view.getFloat32(3, false)); // 3.141590118408203console.log('BigInt64 at offset 7 (Little-Endian):', view.getBigInt64(7, true)); // 1234567890123456789n
这里需要注意，
BigInt64
和
BigUint64
是较新的API，在使用时需要确保运行环境支持ES2020及以上标准。
DataView与TypedArray（类型化数组）有什么区别和联系？
这俩兄弟经常让人犯迷糊，但一旦你理解了它们各自的侧重点，你会发现它们是绝佳搭档，而不是相互替代的关系。
类型化数组（TypedArray），比如
Uint8Array
、
Int32Array
、
Float64Array
等，它们是针对特定数据类型优化的数组。当你创建一个
new Uint8Array(buffer)
时，你就告诉JavaScript：“我希望把这个
buffer
看作是一个由无符号8位整数组成的序列。”然后，你就可以像操作普通数组一样，通过索引
arr[0]
,
arr[1]
来访问这些8位整数。它的优点在于性能和直观性，特别适合处理同构的、连续的数据块。比如，图像的像素数据，音频的采样数据，这些通常都是统一的类型。
DataView，则是一个更底层的、更灵活的“通用视图”。它不关心
ArrayBuffer
里到底是什么类型的“数组”，它只提供一个“窗口”，让你能从任意字节位置开始，以你指定的任意类型去读写数据。它没有索引的概念，只有字节偏移量。
核心区别总结：
类型特异性：
TypedArray
是类型特异的（例如，
Int32Array
只能处理32位整数），而
DataView
是类型无关的，它能读取任何类型的数据。访问方式：
TypedArray
通过数组索引
arr[i]
访问元素，每个元素占据固定字节数。
DataView
通过字节偏移量
view.getUint8(offset)
访问，你可以指定任何类型，即使它跨越了多个字节。性能与灵活性：
TypedArray
在处理大量同构数据时通常性能更优，因为它对底层数据结构有更强的假设。
DataView
则提供了无与伦比的灵活性，尤其适合处理异构数据或复杂协议。
它们之间的联系：两者都操作同一个底层
ArrayBuffer
。你可以先用
DataView
从一个复杂的二进制流中解析出各个部分，然后将其中某个部分（例如，一个大的图像数据块）转换为
Uint8Array
进行进一步处理。反过来也一样，你可以将一个
Uint8Array
的数据写入
ArrayBuffer
，再用
DataView
去读取其中的特定数值。
const buffer = new ArrayBuffer(10); // 10字节缓冲区// 使用Uint8Array写入数据const uint8Array = new Uint8Array(buffer);uint8Array[0] = 0x11;uint8Array[1] = 0x22;uint8Array[2] = 0x33;uint8Array[3] = 0x44;// 现在用DataView来读取这些数据，但以不同的类型解释const view = new DataView(buffer);console.log('Uint8Array values:', uint8Array[0].toString(16), uint8Array[1].toString(16), uint8Array[2].toString(16), uint8Array[3].toString(16)); // 11 22 33 44// 从偏移量0开始，读取一个大端序的Uint32console.log('Uint32 from offset 0 (Big-Endian):', view.getUint32(0, false).toString(16)); // 11223344// 从偏移量0开始，读取一个小端序的Uint32console.log('Uint32 from offset 0 (Little-Endian):', view.getUint32(0, true).toString(16)); // 44332211
这段代码清晰地展示了，即使是同样的数据，通过
TypedArray
和
DataView
，或者通过
DataView
的不同字节序设置，都可以被解释成完全不同的值。这就是它们各自的魔力所在。
处理DataView中的字节序（Endianness）有什么讲究？
字节序这东西，初看有点玄乎，但一旦你踩过坑，就会发现它是处理二进制数据时绕不开的关键点。简单来说，字节序就是多字节数据（比如16位整数、32位浮点数）在内存中存储时，字节的排列顺序。
有两种主要的字节序：
大端字节序（Big-Endian）：最高有效字节（MSB）存储在最低内存地址。这就像我们写数字，从左到右，高位在前。网络传输通常默认采用大端字节序。小端字节序（Little-Endian）：最低有效字节（LSB）存储在最低内存地址。这就像我们倒着写数字，低位在前。大多数现代计算机（Intel x86架构）内部都采用小端字节序。
DataView
的
get
和
set
方法都有一个可选的
littleEndian
参数，默认为
false
，即大端字节序。这意味着如果你不指定，它就会按大端序处理。
什么时候需要特别关注字节序？
网络通信： 当你从网络接收二进制数据包时，通常需要按大端字节序解析，因为网络协议标准（如TCP/IP）通常规定使用大端序。文件格式： 很多文件格式（如PNG、JPEG、WAV等）内部都有自己的字节序规定，解析时必须遵循。跨平台数据交换： 如果你的前端应用需要和不同架构的后端服务器或者其他系统进行二进制数据交互，了解并正确处理字节序是避免数据错乱的关键。
我记得有一次，我从一个嵌入式设备读取传感器数据，设备是小端序，而我的JavaScript代码默认按大端序解析，结果所有读出来的数值都是错的，排查了好久才发现是字节序的问题。那种“啊哈！”的瞬间，真的让人印象深刻。
const buffer = new ArrayBuffer(4); // 4字节缓冲区const view = new DataView(buffer);// 假设我们要写入一个16位整数值 0x1234const value = 0x1234;// 1. 按大端字节序写入 (默认行为或 littleEndian: false)// 内存布局: [0x12, 0x34, 0x00, 0x00]view.setUint16(0, value, false);console.log('Big-Endian Bytes:', new Uint8Array(buffer).map(b => b.toString(16).padStart(2, '0'))); // ["12", "34", "00", "00"]console.log('Read as Big-Endian:', view.getUint16(0, false).toString(16)); // 1234console.log('Read as Little-Endian:', view.getUint16(0, true).toString(16)); // 3412 (字节颠倒了)// 清空bufferview.setUint32(0, 0);// 2. 按小端字节序写入 (littleEndian: true)// 内存布局: [0x34, 0x12, 0x00, 0x00]view.setUint16(0, value, true);console.log('Little-Endian Bytes:', new Uint8Array(buffer).map(b => b.toString(16).padStart(2, '0'))); // ["34", "12", "00", "00"]console.log('Read as Little-Endian:', view.getUint16(0, true).toString(16)); // 1234console.log('Read as Big-Endian:', view.getUint16(0, false).toString(16)); // 3412 (字节颠倒了)
通过这个例子，你可以清楚地看到，即使是写入相同的值，选择不同的字节序，底层内存中的字节排列也会完全不同。因此，在读写多字节数据时，务必清楚你正在处理的数据源或目标期望的字节序，并正确设置
littleEndian
参数。
以上就是什么是DataView？二进制数据的操作的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1516454.html
微信扫一扫 
支付宝扫一扫 
![Go语言接口与切片：如何识别和操作[]interface{}](https://cdn.chuangxiangniao.com/www/2025/12/176369856569294-1.jpg?imageMogr2/crop/480x300/gravity/center)
