ajax结果中出现的138d、0等异常字符，通常指示http客户端在处理chunked传输编码时存在缺陷。这些字符是http协议层面的分块长度标识，而非实际数据。根据http/1.1规范，所有客户端必须能够正确解码此编码，因此，此类问题根源于客户端未能将分块数据重组为完整的消息体，导致原始协议信息泄露至应用层。
异常现象解析
在进行AJAX请求时，有时开发者可能会在预期的JSON或XML数据前后发现一些奇怪的字符，例如138d、0等。这些字符以十六进制表示，并伴随着换行符，它们并非数据内容的一部分，而是HTTP协议传输编码的遗留物。例如，一个原本应该返回JSON数据的AJAX请求，其结果可能呈现如下：
138d
{"feeds":[{"pubdate":"Sun, 28 Nov 2021 23:00:00 EST"}]}
0这种现象表明，HTTP客户端未能正确地解析和处理服务器响应的传输编码，将协议层面的控制信息暴露给了应用层。
HTTP传输编码机制详解
HTTP协议提供了多种机制来标识消息体的结束，以确保客户端能够准确接收完整的数据。主要有以下三种方式：
- 使用 Content-Length 头部：这是最简单直观的方式。服务器在响应头中包含 Content-Length 字段，明确告知客户端消息体的字节长度。客户端收到该长度的数据后，即可认为消息体接收完毕。这种方式的缺点是服务器必须在发送消息体之前就知道其完整大小。
- 使用 chunked 传输编码：当服务器无法在发送消息体之前确定其完整大小时（例如，动态生成内容、流式传输），chunked 传输编码就显得非常有用。它允许服务器将消息体分成若干个“块”发送，每个块都有自己的大小标识。这种方式极大地提高了HTTP连接的效率，尤其是在持久连接（Keep-Alive）下，允许在同一连接上进行多次请求-响应交换。
- 关闭套接字：这是最原始且效率最低的方式。服务器在发送完消息体后直接关闭TCP连接，以此作为消息体结束的信号。这种方式通常用于HTTP/1.0，或在HTTP/1.1中作为最后手段，因为它阻止了连接的重用。
在上述异常现象中，罪魁祸首正是第二种方式：chunked 传输编码。
分块传输编码的工作原理与示例
chunked 传输编码通过在HTTP响应头中添加 Transfer-Encoding: chunked 字段来声明。其消息体结构如下：
- 每个数据块由两部分组成：
- 十六进制表示的块大小（后跟CRLF，即回车换行）。
- 实际的数据块内容（后跟CRLF）。
- 当所有数据块发送完毕后，会发送一个大小为 0 的块，表示消息体结束（后跟CRLF）。
- 最后，通常会有一个空的CRLF行来结束整个传输编码消息。
以下是一个使用 chunked 传输编码的HTTP响应示例：
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/json
28
{"feeds":[{"pubdate":"Sun, 28 Nov 2021 23:00:00 EST"}]}
0
在这个例子中：
- 28 (十六进制) 表示第一个数据块的长度，转换为十进制是40。
- {"feeds":[{"pubdate":"Sun, 28 Nov 2021 23:00:00 EST"}]} 是第一个数据块的内容。
- 0 表示这是最后一个块，其内容为空，标志着消息体传输的结束。
一个符合HTTP/1.1规范的客户端在接收到这样的响应时，其职责是：
- 识别 Transfer-Encoding: chunked 头部。
- 逐个读取每个块的长度和数据。
- 将所有数据块拼接起来，形成完整的消息体。
- 当遇到长度为 0 的块时，停止读取并认为消息体已完整接收。
- 最终将重组后的完整消息体（在本例中即纯粹的JSON字符串）提供给应用层。
根源与解决方案：客户端的职责
根据RFC 2616（以及后续的RFC 7230等更新），所有HTTP/1.1应用程序必须能够接收和解码“chunked”传输编码。因此，如果在AJAX结果中看到了原始的分块标记（如138d、0），这明确指示了HTTP客户端存在一个bug。
解决方案的核心在于修复或更新HTTP客户端。
- 浏览器内置AJAX（XMLHttpRequest 或 fetch API）：现代浏览器通常都能正确处理 chunked 编码。如果出现此问题，首先应确保浏览器版本是最新的。极少数情况下，可能是浏览器扩展或代理干扰了正常的HTTP处理。
- 自定义HTTP客户端库：如果您在使用非浏览器原生的HTTP客户端库（例如，Node.js环境下的 http 模块、axios、request 等，或桌面应用、移动应用中的网络库），则需要检查该库的版本，并确保它已正确实现了 chunked 传输编码的解码逻辑。通常，更新到最新稳定版本可以解决此类问题。
- 网络代理或中间件：在某些复杂的网络环境中，可能存在HTTP代理或中间件，它们可能会错误地处理或修改HTTP响应，导致 chunked 编码未能被正确解码。排查这类问题通常需要检查网络配置或绕过代理进行测试。
- 服务器端配置（极少数情况）：虽然问题通常出在客户端，但理论上服务器也可能发送了格式错误的 chunked 编码。不过，对于标准的Web服务器（如Nginx, Apache, IIS等），这种情况非常罕见。
注意事项与总结
- 数据完整性：chunked 编码的目的是为了高效传输，而不是为了改变数据内容。正确解码后，客户端得到的数据应该与服务器实际发送的原始数据完全一致。
- 协议透明性：HTTP协议的传输编码机制对应用层应该是透明的。应用层不应该关心数据是如何被分块传输的，它只应接收到完整的、已重组的消息体。
- 调试思路：当遇到此类问题时，首先应确认HTTP响应头中是否存在 Transfer-Encoding: chunked。然后，检查您使用的HTTP客户端（浏览器、库等）是否是最新版本。如果问题依然存在，可能需要深入到客户端的网络请求处理逻辑中进行调试。
总之，AJAX结果中出现的神秘字符如138d和0，是HTTP客户端未能正确处理 chunked 传输编码的信号。解决此问题的关键在于确保您的HTTP客户端能够按照HTTP/1.1规范，正确地识别、解码并重组分块传输的消息体，从而向应用层提供干净、完整的预期数据。
