通过AJAX向Java Socket传输Base64编码PDF时数据接收不全问题

我帮你梳理下这个问题的几个核心原因和对应的解决思路，你可以逐一排查验证：

1. 前端数据编码方式的坑 #

你现在用$.param()把数据转成application/x-www-form-urlencoded格式传输，但Base64字符串本身长度往往很长，经过表单编码后会进一步增加数据体积，而且部分Socket服务对这种长表单数据的处理逻辑容易出现截断。

调整方案： #

直接传递原始Base64字符串作为请求体，跳过表单编码步骤，同时设置正确的请求头：

$http({
  method: 'POST',
  url: 'http://localhost:84',
  data: dados.filebase64, // 直接传入原始Base64字符串
  headers: {
    'Content-Type': 'text/plain; charset=utf-8' // 明确内容类型和编码
  }
}).then(function (dados) {
  // 处理响应逻辑
});

2. Java Socket端读取流不完整 #

TCP是流式传输，数据会分批次到达Socket缓冲区。如果你的后端代码只调用了一次read()就停止读取，必然会拿到不完整的内容，甚至出现空值片段。

修复方案： #

循环读取输入流直到流结束，确保拿到全部数据。示例代码如下：

Socket socket = new Socket("localhost", 84);
InputStream inputStream = socket.getInputStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
byte[] buffer = new byte[4096]; // 用较大的缓冲区提升读取效率
int bytesRead;

// 持续读取直到流末尾
while ((bytesRead = inputStream.read(buffer)) != -1) {
    baos.write(buffer, 0, bytesRead);
}

// 转换为完整的Base64字符串
String fullBase64 = new String(baos.toByteArray(), StandardCharsets.UTF_8);

// 关闭资源
baos.close();
inputStream.close();
socket.close();

3. 数据长度与缓冲区限制 #

如果PDF文件较大，转换后的Base64字符串可能超出Socket默认缓冲区大小，导致部分数据被暂存但未被读取。

优化方案： #

• 后端读取时使用足够大的缓冲区（比如上面代码中的4096字节），配合循环读取逻辑，就能覆盖分块到达的数据；
• 若文件特别大，也可以考虑前端分块传输Base64，后端拼接后再处理，但这个复杂度较高，优先尝试前面的基础方案。

4. 字符编码不一致 #

如果前后端使用的字符编码不统一，会导致部分字符解析错误，表现为字符串中空值或乱码，看起来像是数据不完整。

统一编码： #

• 前端请求头明确指定charset=utf-8；
• 后端读取时强制使用UTF-8编码解析（如上面代码中的StandardCharsets.UTF_8）。

建议先从「前端修改传输方式」和「后端循环读取流」这两点入手，这是此类问题最常见的根源。

内容的提问来源于stack exchange，提问作者Jéssica Neves Machado