Ruby 3.2 引入的 IO::Buffer 为底层二进制数据操作提供了连续内存缓冲，适合网络协议解析、文件预读和高频 I/O 场景。get_string 方法负责按照字节偏移和长度把缓冲内容取出来形成 String，其第三个参数可以指定目标字符串的编码标签。初看简单，但实际使用中很多人会发现返回的字符串编码并不是自己预期的 UTF-8，或者中文内容出现乱码。这些问题通常不是 get_string 本身出错，而是对字节、编码标签和转码三个概念混淆造成的。本文从基础调用入手，逐步拆解编码参数的作用、多字节偏移边界和实际协议解析中的用法。

一、get_string 的基础调用：offset 与 length 的单位是字节

创建一个 IO::Buffer 最直接的办法是调用 IO::Buffer.for，它可以把已有字符串的内存包装成缓冲区；也可以使用 IO::Buffer.new 先分配指定字节数的空缓冲，再通过 set_string 写入数据。get_string 的签名是 get_string(offset, length, encoding = nil)，前两个参数分别是起始偏移和读取长度。必须明确的是，offset 和 length 的单位都是字节而不是字符。对于 ASCII 文本，字节和字符一一对应，不容易出错；一旦涉及中文、日文等 UTF-8 多字节字符，这个差异就非常关键。例如字符串“你好”在 UTF-8 编码下占用 6 个字节，如果想读取完整内容，length 必须传 6，而不是 2。

如果不传第三个编码参数，get_string 返回的字符串编码是 ASCII-8BIT，也就是 Ruby 中的二进制字符串编码。ASCII-8BIT 表示原始字节序列，不假设任何字符集。这种设计符合 IO::Buffer 的定位：它主要面向二进制数据，尽量避免在读取阶段引入编码转换开销。下面的代码演示从缓冲区读取 5 个字节，可以看到返回值的 encoding 是 ASCII-8BIT。

buffer = IO::Buffer.for("Hello")
str = buffer.get_string(0, 5)
puts str.inspect          # 输出 "Hello"
puts str.encoding.name    # 输出 ASCII-8BIT

还有一点需要留意：get_string 是复制操作，它会把指定范围内的字节复制到一个新字符串里。后续修改这个字符串不会影响缓冲区中的原始数据，反之亦然。了解这一点有助于判断多次调用 get_string 的性能成本。对于小缓冲或低频解析，这个复制开销可以忽略；但在热路径中频繁调用时，就需要考虑是否能让 offset 和 length 一次读取完整数据，减少不必要的中间字符串。

二、编码参数只是给结果字符串打标签，并不执行转码

get_string 的第三个参数 encoding 常常被误解成“把读到的字节转换成指定编码”。实际上它做的是给返回的字符串打上这个编码标签，等价于调用一次 String#force_encoding。如果缓冲区中的字节本来就是 UTF-8 编码，那么传 Encoding::UTF_8 自然能得到合法、可正常显示的中文；但这并不代表 get_string 在内部做了任何转换工作。

下面这段代码展示了正确而简单的用法。用 IO::Buffer.for 包装一个 UTF-8 字符串，然后按编码读取。注意读取长度用的是 buffer.size，它返回字节数，正好对应整个字符串的 UTF-8 字节长度。执行后 valid_encoding? 返回 true，说明字节和编码标签是匹配的。

buffer = IO::Buffer.for("你好")
puts buffer.size                # 输出 6
utf8_str = buffer.get_string(0, buffer.size, Encoding::UTF_8)
puts utf8_str                   # 输出 你好
puts utf8_str.encoding.name     # 输出 UTF-8
puts utf8_str.valid_encoding?   # 输出 true

当源数据不是 UTF-8 而仍然指定 UTF-8 时，问题就显现了。例如缓冲区里放的是 GBK 编码的“你好”两个汉字，GBK 中每个汉字占 2 字节，共 4 字节。如果读取时指定 Encoding::UTF_8，返回的字符串编码是 UTF-8，但字节内容根本不是合法 UTF-8 序列，因此 valid_encoding? 为 false。很多乱码和 Encoding::InvalidByteSequenceError 异常都源于这个误区。下面的示例完整对比了错误用法与正确用法。

gbk_type = Encoding.find("GBK")
gbk_bytes = "你好".encode(gbk_type)
buffer = IO::Buffer.for(gbk_bytes)
bad_str = buffer.get_string(0, buffer.size, Encoding::UTF_8)
puts bad_str.valid_encoding?    # 输出 false
puts bad_str.encoding.name      # 输出 UTF-8
raw_gbk = buffer.get_string(0, buffer.size, gbk_type)
utf8_str = raw_gbk.encode(Encoding::UTF_8)
puts utf8_str.valid_encoding?   # 输出 true
puts utf8_str                   # 输出 你好

如果需要把 GBK 字节转换成 UTF-8 字符串，必须分两步：先用 get_string 以 GBK 编码标签读取，让 Ruby 知道这些字节应该按 GBK 解释；再调用 String#encode 显式转码成 UTF-8。把编码转换的工作交给 encode，而不是 get_string，是保持代码行为可控的重要原则。对于 UTF-8 到其他编码的转换同理，先保证源字符串编码标签正确，再调用 encode 指定目标编码。

三、多字节字符与偏移量：如何避免截断和编码错误

使用 get_string 处理多字节文本时，offset 和 length 的字节单位会带来截断风险。假设缓冲区中有“你好”两个 UTF-8 汉字，每个汉字 3 字节。如果只读取前 3 个字节，正好落在第一个汉字的中间，返回的字符串虽然带 UTF-8 编码标签，但内容是不完整的字节序列。直接用这个字符串做正则匹配、大小写转换或写入文件，都可能触发编码异常。

下面的代码演示了这种截断情况，并展示了如何用 scrub 方法把无效字节替换成安全字符。需要注意的是，scrub 只是兜底方案，适用于确实存在损坏字节的场景；如果边界计算正确，完全不应该依赖 scrub。

buffer = IO::Buffer.for("你好")
partial = buffer.get_string(0, 3, Encoding::UTF_8)
puts partial.valid_encoding?   # 输出 false
puts partial.bytesize          # 输出 3
safe = partial.scrub
puts safe                       # 输出替换字符
puts safe.valid_encoding?       # 输出 true

在二进制协议解析中，通常的做法是先读取固定长度的长度头，再根据长度头中记录的字节数读取正文。偏移量必须按字节累计：头部字段占 4 字节，那么正文的起始偏移就是 4；正文长度也必须使用 bytesize 而不是字符数量。下面模拟一个简单的消息格式，头部用 4 字节 ASCII 数字表示正文长度，正文使用 UTF-8。读取正文时第三个参数指定 UTF-8，可以保证后续字符操作不会因为编码标签错误而失败。

buffer = IO::Buffer.new(64)
message = "你好，Ruby"
length = message.bytesize
buffer.set_string(length.to_s.ljust(4), 0)
buffer.set_string(message, 4)
header = buffer.get_string(0, 4, Encoding::ASCII)
body_len = header.to_i
body = buffer.get_string(4, body_len, Encoding::UTF_8)
puts body  # 输出 你好，Ruby

如果协议中的 body 可能是任意二进制数据，就不应该指定文本编码；只有确认是文本且知道字符集时，才传入对应编码。对于混合内容，最简单的策略是在二进制层全部使用 ASCII-8BIT，到文本处理边界再根据协议约定 force_encoding 或 encode。get_string 的 offset 和 length 只负责切割字节，字符边界校验应由上层根据业务规则完成。

四、get_string 与 IO::Buffer 其他方法配合的实践建议

除了 get_string，IO::Buffer 还提供了 set_string、get_value、set_value 等方法，可以按照二进制布局读写不同类型的数据。在解析网络数据包或文件格式时，通常先使用 IO::Buffer.new 创建缓冲区，把从 IO 读到的数据写入，然后用 get_string 按偏移提取字段。这种方式的优势是内存布局清晰，所有偏移都是显式的，比直接对字符串做切片再编码转换更不容易出错。

以一个简单场景为例：假设套接字上到达一帧数据，前 2 字节是消息类型，接下来 4 字节是长度，再后面是 UTF-8 正文。可以先把整个帧读进 IO::Buffer，然后用 get_value 读取类型和长度，再用 get_string 读取正文。这样每一段数据都有明确边界，代码读起来接近协议文档的描述。下面代码省略真实套接字读取，重点展示缓冲区内部的字段提取方式。

buffer = IO::Buffer.new(32)
body_text = "订单已确认"
body_bytes = body_text.bytesize
buffer.set_string("01", 0)                         # 2 字节消息类型
buffer.set_string(body_bytes.to_s.ljust(4), 2)     # 4 字节长度头
buffer.set_string(body_text, 6)                    # 正文从偏移 6 开始
type = buffer.get_string(0, 2, Encoding::ASCII)
length = buffer.get_string(2, 4, Encoding::ASCII).to_i
body = buffer.get_string(6, length, Encoding::UTF_8)
puts type   # 输出 01
puts body   # 输出 订单已确认

从性能角度看，get_string 创建的字符串是一次完整复制，因此不建议在循环中反复读取同一个字节区域。如果只需要检查某个偏移上的字节值，可以使用 get_value(:U8, offset) 返回整数，避免生成字符串对象。如果必须得到字符串，可以先把整块数据一次读取出来，再用 Ruby 字符串方法 byteslice 和 force_encoding 切割，减少对 IO::Buffer 的重复复制。不过对于应用层协议解析，通常数据量不大，get_string 的清晰性比微观性能更重要。

最后强调编码一致性。项目中一旦确定协议文本使用 UTF-8，就应在读取文本字段时统一传 Encoding::UTF_8，不要有的地方传、有的地方不传。如果底层库返回的 buffer 来自不可信输入，读取后最好调用 valid_encoding? 做一次校验，必要时用 scrub 或 reject 策略处理。把字节边界和编码边界显式分开，能有效减少 Ruby 程序在处理 I/O 数据时出现未知编码异常的概率。