1. 为什么要把数据转成二进制流来传
做过接口联调的人多半遇到过这种场景：后端定义了一个上传接口，Content-Type 写的是application/octet-stream，然后甩过来一句"你直接把文件流发过来就行"。这时候如果你还在用 form-data 或者 JSON 去凑，大概率会收到 400 或者一堆乱码。二进制流传输不是什么高深技术，但它在文件上传、大文件分片、跨系统数据交换里出现的频率极高，尤其是当对方系统只认原始字节流、不接受任何包装格式的时候。
所谓"把数据转二进制流"，本质上是把内存里的字符串、对象、文件内容，按照某种编码规则（UTF-8、GBK、Base64 解码后的原始字节等）变成一串byte[]，再通过 HTTP 请求体直接写出去。它和普通 JSON 请求最大的区别在于：JSON 是文本协议，有明确的结构和字符集；而二进制流是"裸"的，接收方拿到什么就是什么，没有任何自描述信息。这就意味着发送端和接收端必须提前约定好编码方式、字节序、字段分隔规则，否则收到的就是一堆无法解析的字节。
这篇文章适合三类人看：一是刚接触接口联调、被octet-stream卡住的后端或测试同学；二是需要模拟客户端上传行为、用 PostMan 做接口验证的开发者；三是想搞清楚"流"到底是怎么回事、不想再靠复制粘贴混过去的人。我会从数据转换的底层逻辑讲起，一直讲到 PostMan 里怎么配置、怎么排查乱码和 400 错误，把踩过的坑都摊开说。
2. 二进制流传输的核心原理拆解
2.1 文本、字节、流的三角关系
要理解二进制流，先得把这三个概念理清楚。文本是给人看的，比如"hello"这五个字符；字节是给机器看的，"hello"用 UTF-8 编码后是 5 个字节68 65 6C 6C 6F；流则是字节的传输形式，它不关心内容是什么，只负责把字节从 A 搬到 B。
很多人卡在第一步，是因为把"字符串"和"字节数组"混为一谈。在 Java 里String.getBytes()得到的是byte[]，在 Python 里"abc".encode()得到的是bytes，在 JavaScript 里要用Buffer.from()或者TextEncoder。这些转换动作看起来简单，但编码选错了，后面全盘皆输。比如中文用 ISO-8859-1 编码，一个汉字会变成?，因为那个字符集根本不认识中文。
流的概念可以用水管来类比：你不需要知道水从哪里来、要到哪里去，只需要保证管子接对了、水压够、别漏水。HTTP 请求体就是那根管子，Content-Type: application/octet-stream就是在告诉对方"我管子里流的是原始字节，你自己按约定解析"。
2.2 为什么不用 JSON 或 form-data
有人会问，既然 JSON 这么方便，为什么还要费劲搞二进制流？答案在几个具体场景里：
- 文件上传：图片、视频、压缩包本身就是二进制，硬塞进 JSON 要 Base64 编码，体积膨胀 33%，大文件直接爆炸。
- 性能敏感场景：二进制省去了序列化和反序列化的开销，几 MB 的数据用流传输比 JSON 快一个数量级。
- 对接老系统：很多传统系统（比如某些金融、医疗接口）只认固定格式的字节流，字段按位排列，多一个空格都不行。
- 分片传输：大文件切成固定大小的块，每块作为独立的二进制流发送，接收端按顺序拼接。
反过来说，如果只是传几个结构化字段，用 JSON 完全够用，没必要为了"显得高级"去搞二进制。工具选型要看场景，不是越底层越好。
2.3 Content-Type 与请求体的约定
application/octet-stream是 HTTP 协议里最"模糊"的 Content-Type 之一，它的字面意思是"任意二进制数据"。这意味着接收方无法从请求头推断出内容格式，必须依赖双方事先约定。常见的约定方式有几种：
| 约定方式 | 说明 | 适用场景 |
|---|---|---|
| 固定字段顺序 | 按字节偏移量解析，如前 4 字节是长度，后面是内容 | 协议固定的老系统 |
| 前置元数据 | 请求体开头放一段 JSON 描述后续内容 | 自定义协议 |
| 文件名约定 | 通过 URL 参数或 Header 传递文件名和类型 | 文件上传 |
| 纯内容流 | 请求体就是文件本身，无额外包装 | 简单文件上传 |
我见过最多的坑是：后端说"你发二进制就行"，但没说编码是 UTF-8 还是 GBK，结果中文全乱。所以联调前一定要问清楚三件事：编码格式、字段排列规则、是否有长度前缀。这三样问明白了，后面基本不会出大问题。
3. 数据转二进制流的实操要点
3.1 字符串转字节数组的正确姿势
不同语言里字符串转字节的方式不一样，但核心都是"指定编码"。以 Java 为例：
String data = "订单编号:12345,金额:99.5"; // 正确做法：明确指定 UTF-8 byte[] bytes = data.getBytes(StandardCharsets.UTF_8); // 错误做法：依赖平台默认编码，跨系统必乱 byte[] badBytes = data.getBytes();Python 里更直接：
data = "订单编号:12345,金额:99.5" raw = data.encode('utf-8') # 得到 bytes # 如果要发十六进制，可以再转 hex_str = raw.hex()JavaScript 在 Node 环境用 Buffer：
const data = "订单编号:12345,金额:99.5"; const buf = Buffer.from(data, 'utf-8'); // 浏览器环境用 TextEncoder const encoder = new TextEncoder(); const uint8 = encoder.encode(data);这里有个细节值得说：Java 的getBytes()不带参数时会用系统默认编码，在 Windows 上可能是 GBK，在 Linux 上可能是 UTF-8。本地测试通过、部署到服务器就乱码，十有八九是这个原因。养成显式指定编码的习惯，能省掉大量排查时间。
3.2 结构化数据如何拼成字节流
如果数据不是简单字符串，而是多个字段，就需要自己定义拼接规则。常见的有两种：
定长字段拼接：每个字段占固定字节数，不足补空格或零。比如协议规定"姓名 20 字节 + 年龄 4 字节 + 金额 8 字节"，那就按这个规则拼：
ByteArrayOutputStream baos = new ByteArrayOutputStream(); baos.write(padRight(name, 20).getBytes(StandardCharsets.UTF_8)); baos.write(padLeft(age, 4).getBytes(StandardCharsets.UTF_8)); baos.write(padLeft(amount, 8).getBytes(StandardCharsets.UTF_8)); byte[] payload = baos.toByteArray();分隔符拼接：字段之间用特定字符（如|或\u0001）分隔，接收端按分隔符切分。这种方式灵活但要求分隔符不能出现在内容里，否则会解析错位。
提示：定长拼接时，中文字符的字节数取决于编码。UTF-8 下一个汉字占 3 字节，GBK 下占 2 字节。如果协议规定"姓名 20 字节"，用 UTF-8 最多只能放 6 个汉字，超了要么截断要么报错，这个边界一定要测。
3.3 文件读取为字节流的几种方式
文件本身就是二进制，读取时要注意别用文本模式打开。Java 里用Files.readAllBytes()最省事：
byte[] fileBytes = Files.readAllBytes(Paths.get("/path/to/file.pdf"));大文件不要一次性读进内存，用流式读取：
try (InputStream is = new FileInputStream(file)) { byte[] buffer = new byte[8192]; int len; while ((len = is.read(buffer)) != -1) { // 写入输出流或发送 } }Python 里读文件要加'rb'：
with open('/path/to/file.pdf', 'rb') as f: file_bytes = f.read()这里有个容易忽略的点：文件读取后如果要做 Base64 编码再传输，体积会膨胀，但如果接口要求的就是 Base64 字符串，那也没办法。判断标准是看接口文档里的 Content-Type，如果是application/octet-stream就直接发原始字节，如果是application/json且字段是字符串，那才需要 Base64。
4. PostMan 发送二进制流请求全流程
4.1 请求配置的关键三步
PostMan 发二进制流请求，核心就三步，但每一步都有坑。
第一步：选对 Method 和 URL。通常是 POST 或 PUT，URL 按接口文档填。这一步没什么好说的，但要注意有些接口对 URL 末尾的斜杠敏感，/api/upload和/api/upload/可能返回不同结果。
第二步：设置 Body 类型为 binary。在 PostMan 的 Body 选项卡里，有 none、form-data、x-www-form-urlencoded、raw、binary、GraphQL 几个选项。选binary，然后点击 "Select File" 选择要上传的文件。这是最直接的方式，PostMan 会把文件内容作为请求体原样发出。
但如果你要发的不是文件，而是自己拼的字节数据（比如前面说的定长字段拼接结果），PostMan 的 binary 模式就不够用了，因为它只支持选文件。这时候有两个办法：
- 把拼好的字节写到临时文件，再用 binary 模式选这个文件；
- 用 raw 模式，但 Content-Type 手动改成
application/octet-stream，然后在 raw 里填内容。
第二种方式有个陷阱：raw 模式下的内容会被 PostMan 当作文本处理，如果你填的是十六进制字符串，它发出去的就是这些字符的 ASCII 码，而不是你期望的字节。所以raw 模式只适合发纯文本内容的二进制流，真正的字节数据还是走文件方式靠谱。
第三步：设置 Content-Type 请求头。在 Headers 选项卡里加一行Content-Type: application/octet-stream。虽然 PostMan 选 binary 模式时会自动加这个头，但手动确认一下没坏处，有些接口对 Header 大小写敏感。
4.2 用 Pre-request Script 动态生成字节流
实际测试中，数据往往不是固定的，需要根据变量动态生成。PostMan 的 Pre-request Script 可以帮上忙。比如要把一个 JSON 对象转成 UTF-8 字节流写入文件：
const data = { orderId: "12345", amount: 99.5, remark: "测试订单" }; const jsonStr = JSON.stringify(data); // PostMan 的脚本环境里可以用 Buffer（基于 Node） const buf = Buffer.from(jsonStr, 'utf-8'); // 把字节转成十六进制字符串，方便后续处理 const hexStr = buf.toString('hex'); pm.environment.set("payloadHex", hexStr);但这里有个限制：PostMan 的脚本无法直接把字节写入请求体，binary 模式只认文件。所以动态生成字节流的实际做法通常是：脚本生成数据后，通过pm.sendRequest发到某个中转服务，或者干脆用 Newman（PostMan 的命令行工具）配合脚本文件来实现。
如果只是测试固定格式的字节流，更实用的做法是提前用代码生成好二进制文件，然后在 PostMan 里选这个文件发送。生成文件的代码可以写成一个小工具，每次改数据就重新生成一次。
4.3 验证请求是否发对了
发出去之后怎么知道对不对？三个地方看：
- PostMan 的 Console：点左下角 Console 按钮，能看到实际发送的请求头和请求体大小。如果 Body 大小是 0，说明文件没选上或者路径错了。
- 后端日志：让后端同学打印收到的字节长度和前几个字节的十六进制值，和你发送的对比。长度对不上说明传输过程中被截断或追加了内容。
- 响应内容：如果接口返回 200 但内容不对，多半是编码或字段顺序问题；如果返回 400，先检查 Content-Type 和 Body 是否为空。
我习惯在发送前用xxd命令（Linux/Mac）或十六进制编辑器看一眼文件内容，确认开头几个字节符合预期。比如 PDF 文件开头应该是25 50 44 46（即%PDF），如果看到的是别的，说明文件选错了。
5. 常见问题与排查技巧实录
5.1 乱码问题的三层排查法
乱码是二进制流传输里最高频的问题，排查要按层次来：
第一层：确认发送端编码。用十六进制工具看实际发出的字节。如果中文变成了3F（问号的 ASCII 码），说明编码时就已经丢了信息，问题在发送端。
第二层：确认传输过程无篡改。对比发送端和接收端拿到的字节长度，如果长度不一致，可能是中间有代理或网关做了转换。有些网关会把application/octet-stream当成文本处理，强行转码。
第三层：确认接收端解码方式。发送端用 UTF-8，接收端用 GBK 解，必然乱码。这种情况需要双方对齐编码，或者发送端在请求头里加charset信息（虽然application/octet-stream标准上不带 charset，但有些系统认这个）。
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 中文变问号 | 发送端编码不支持中文 | 检查getBytes()是否指定 UTF-8 |
| 中文变方块 | 接收端字体或解码问题 | 用十六进制对比字节 |
| 部分字段乱码 | 字段边界计算错误 | 检查定长拼接的字节数 |
| 整体乱码 | 编码方式不一致 | 双方统一为 UTF-8 |
| 末尾多出字符 | 流未正确关闭或缓冲区问题 | 检查流的 flush 和 close |
5.2 请求体为空或截断的处理
PostMan 发 binary 请求时，如果 Body 显示为空，常见原因有：
- 文件路径包含中文或空格，PostMan 读取失败。解决办法是把文件放到纯英文路径下。
- 文件被其他程序占用，比如 Excel 打开着 xlsx 文件。关掉再试。
- 文件大小为 0，选了个空文件。检查文件本身。
- PostMan 版本问题，某些老版本对 binary 模式支持不好。升级到最新版。
请求体截断则通常是服务端限制。Nginx 默认的client_max_body_size是 1MB，超过就返回 413。Spring Boot 的spring.servlet.multipart.max-file-size默认也是 1MB。这些限制在传大文件时一定要提前确认。
5.3 接口返回 400/415 的定位思路
400 Bad Request通常意味着服务端解析请求体失败。可能原因：Content-Type 不对、字节流格式不符合约定、必填字段缺失。排查时先看响应体里的错误信息，很多框架会返回具体的解析失败原因。
415 Unsupported Media Type则是 Content-Type 不被接受。比如接口只认application/octet-stream，你发了text/plain，就会 415。这种情况改 Header 即可。
还有一种隐蔽的情况：接口文档写的是application/octet-stream，但实际代码里用的是@RequestParam MultipartFile，这种接口其实要的是multipart/form-data。文档和实现不一致的情况太常见了，遇到 415 先和后端确认实际接收方式。
提示：联调时养成"先问三件事"的习惯——Content-Type 是什么、请求体格式是什么、有没有大小限制。这三个问题问清楚，能省掉 80% 的返工。
5.4 大文件传输的内存与超时问题
传大文件时，PostMan 本身会把整个文件读进内存，几百 MB 的文件可能让 PostMan 卡死。这种情况建议用命令行工具（如 curl）代替：
curl -X POST "http://example.com/api/upload" \ -H "Content-Type: application/octet-stream" \ --data-binary "@/path/to/largefile.bin"--data-binary和-d的区别在于，前者原样发送文件内容，后者会去掉换行符。传二进制必须用--data-binary。
超时方面，PostMan 默认的请求超时是 0（不限制），但服务端和网关可能有超时设置。大文件传输建议分片，每片控制在几 MB，既避免超时，也方便断点续传。
6. 从字节流到实际业务的落地经验
6.1 一个典型的文件上传接口联调过程
假设有个接口POST /api/v1/file/upload，文档写着 Content-Type 是application/octet-stream，请求体是文件内容，文件名通过 HeaderX-File-Name传递。联调步骤：
- 准备一个测试文件，比如
test.txt，内容写hello world。 - PostMan 新建请求，Method 选 POST，URL 填接口地址。
- Headers 里加
Content-Type: application/octet-stream和X-File-Name: test.txt。 - Body 选 binary，选中
test.txt。 - 点 Send，看响应。
如果返回成功，再换一个中文内容的文件测试编码。如果中文乱码，检查后端读取时用的编码。这个流程看起来简单，但实际联调时经常在 Header 名称大小写、文件名编码上卡住。比如X-File-Name里的中文文件名，有些框架默认用 ISO-8859-1 解码，需要额外配置。
6.2 二进制流在分片上传中的应用
大文件分片上传是二进制流的典型应用。思路是把文件按固定大小（如 5MB）切成 N 片，每片作为独立的二进制流发送，带上分片序号和总片数，服务端收齐后合并。
int chunkSize = 5 * 1024 * 1024; byte[] fileBytes = Files.readAllBytes(Paths.get(filePath)); int totalChunks = (int) Math.ceil((double) fileBytes.length / chunkSize); for (int i = 0; i < totalChunks; i++) { int start = i * chunkSize; int end = Math.min(start + chunkSize, fileBytes.length); byte[] chunk = Arrays.copyOfRange(fileBytes, start, end); // 发送 chunk，带上 i 和 totalChunks }分片的好处是单次请求体积小、超时风险低、失败可重传。但要注意分片顺序和合并时的边界处理，尤其是最后一片的大小计算，Math.min那行不能省，否则数组越界。
6.3 用脚本批量生成测试数据
手工造测试数据效率太低，写个脚本批量生成更实际。比如要测试一个接收定长字节流的接口，可以用 Python 生成一批测试文件：
import struct def build_payload(order_id, amount, remark): # 订单号 10 字节，金额 8 字节 double，备注 50 字节 order_bytes = order_id.ljust(10).encode('utf-8') amount_bytes = struct.pack('>d', amount) remark_bytes = remark.ljust(50).encode('utf-8')[:50] return order_bytes + amount_bytes + remark_bytes with open('test_payload.bin', 'wb') as f: f.write(build_payload('ORD12345', 99.5, '测试订单'))struct.pack('>d', amount)里的>表示大端序，d表示 double。字节序这个问题在跨平台传输时特别重要，x86 是小端，某些嵌入式设备是大端，不约定清楚就会解析出完全错误的数值。
生成好文件后，在 PostMan 里选这个文件发送即可。如果要批量测试，可以生成多个文件，用 PostMan 的 Collection Runner 依次发送。
6.4 接收端如何正确读取字节流
发送端搞定了，接收端也不能掉链子。以 Spring Boot 为例，接收application/octet-stream的写法：
@PostMapping(value = "/upload", consumes = MediaType.APPLICATION_OCTET_STREAM_VALUE) public String upload(@RequestBody byte[] body, @RequestHeader("X-File-Name") String fileName) { // body 就是原始字节数组 String content = new String(body, StandardCharsets.UTF_8); return "received " + body.length + " bytes"; }关键点是@RequestBody byte[]配合consumes指定类型。如果写成@RequestParam MultipartFile，那就变成 multipart 协议了，和 octet-stream 不兼容。
读取时如果数据量大，不要用byte[]一次性接收，改用InputStream：
@PostMapping(value = "/upload", consumes = MediaType.APPLICATION_OCTET_STREAM_VALUE) public String upload(InputStream inputStream) throws IOException { byte[] buffer = new byte[8192]; int total = 0; int len; while ((len = inputStream.read(buffer)) != -1) { total += len; // 处理 buffer 中的 len 个字节 } return "received " + total + " bytes"; }这样内存占用恒定，不会因为文件大而 OOM。
7. 几个容易被忽略的细节
7.1 换行符的坑
文本文件在不同系统上的换行符不一样：Windows 是\r\n（0D 0A），Linux 是\n（0A）。如果接口对字节内容敏感，换行符差异会导致校验失败。测试时最好用十六进制编辑器确认文件内容，别用记事本随便存。
7.2 空字节与填充
定长字段拼接时，不足的部分通常补0x00或空格。补0x00的话，接收端解析字符串时要注意截断，否则会带出一串不可见字符。Java 里可以用new String(bytes, StandardCharsets.UTF_8).trim()去掉尾部空格，但0x00用 trim 去不掉，需要手动处理。
7.3 PostMan 的环境变量与文件路径
PostMan 的 binary 模式选文件时，路径是写死在请求里的。如果团队协作，别人拉取你的 Collection 后文件路径对不上，请求就发不出去。解决办法是把测试文件放在项目仓库里，用相对路径，或者用 Newman 跑的时候通过命令行参数指定文件路径。
7.4 编码声明的传递
虽然application/octet-stream标准上不带 charset，但实际项目中可以通过自定义 Header 传递编码信息，比如X-Encoding: UTF-8。这样接收端就不用猜了。这个做法不是标准，但双方约定好就行，比事后排查乱码省事得多。
8. 我个人的实操体会
二进制流这东西，第一次接触会觉得别扭，因为看不到"结构"，全是字节。但用多了会发现它其实是最诚实的传输方式——你发什么，对方就收到什么，没有任何隐藏的转换。JSON 看起来友好，但序列化框架可能在背后做各种小动作，比如日期格式转换、null 值处理，反而容易出意外。
我踩过最深的坑是编码问题。早期做接口联调，本地用 Windows 开发，测试通过，部署到 Linux 服务器就乱码。查了半天才发现是getBytes()没指定编码，Windows 默认 GBK，Linux 默认 UTF-8。从那以后，凡是涉及字符串转字节的地方，我一律显式写StandardCharsets.UTF_8，再也没出过这类问题。
另一个体会是：联调前把约定问清楚，比事后排查省十倍时间。编码、字段顺序、长度前缀、大小限制，这四个问题问明白了，二进制流传输基本不会翻车。最怕的是双方都以为对方知道，结果一个用 UTF-8 一个用 GBK，来回折腾一整天。
PostMan 发二进制流请求本身不难，难的是理解背后的字节逻辑。把字符串、字节、编码、流这几个概念理清楚，剩下的就是配置问题。配置错了看 Console 和日志，对比字节长度和十六进制值，大部分问题都能定位。真正需要经验的是那些"文档没写、但实际必须遵守"的隐性约定，这些只能靠多问、多试、多记录来积累。
