引言

在 Web 开发中，HTTP 协议扮演着至关重要的角色。它是客户端和服务器之间传输数据的基础协议。通常，我们会将请求和响应中的各种信息以Header的形式进行传输。而在实际开发中，常常会遇到一个问题：能否在 HTTP Header 中直接传输中文字符？这个问题看似简单，但其实涉及到复杂的字符编码和协议规范。

1. HTTP Header 的基础知识

HTTP Header 是 HTTP 协议中用于传输元数据的部分，包括请求和响应的相关信息，如用户代理、缓存控制、内容类型、授权信息等。HTTP Header 的格式是由键值对组成的，例如：

Content-Type: application/json
Authorization: Bearer token123

在这些键值对中，键（字段名）和值（字段值）都需要遵循一定的格式和规则。为了确保跨平台和跨语言的一致性，HTTP 协议规定了 Header 中所传输的字符必须是ASCII 字符。这就为包含非 ASCII 字符（例如中文）的 Header 字段带来了挑战。

2. 为什么不能直接传输中文？

直接传输中文字符在 HTTP Header 中会引发一系列问题，这些问题主要源于以下几点：

2.1 协议历史和规范

HTTP/1.1 协议最初被设计时，为了保证与现有系统的兼容性，要求 Header 字段只能包含 ASCII 字符。ASCII 字符集仅包含英文字母、数字和控制字符，完全不包含中文、日文或其他非拉丁字符。因此，在 HTTP 协议的早期规范中，传输中文字符是被禁止的。

2.2 解析错误

如果直接在 HTTP Header 中传输中文字符，许多服务器、代理服务器、CDN 和客户端可能无法正确解析这些字符。因为 HTTP Header 的结构依赖于特定的字符分隔符（如冒号 : 和换行符），如果 Header 值中包含非 ASCII 字符，可能导致这些分隔符被误解或丢失，从而导致请求或响应无法正常解析。

2.3 乱码问题

不同的计算机系统、浏览器、服务器使用不同的字符编码（如 UTF-8、GBK、ISO-8859-1 等）。如果一个客户端（比如浏览器）使用 GBK 编码发送包含中文的 Header，而服务器期待的是 UTF-8 编码，就会产生乱码。乱码不仅影响用户体验，甚至可能导致安全漏洞。

2.4 安全性问题

直接传输未经编码的中文字符可能引发安全问题。例如，恶意用户可能通过特殊编码的 Header 攻击服务器或客户端。而通过标准化的编码方式，可以有效减少这种风险。

3. 正确的解决方案：编码传输

为了能够在 HTTP Header 中正确、安全地传输中文字符，社区制定了一些标准方法来对非 ASCII 字符进行编码。最主流和推荐的方式是使用RFC 5987标准。该标准专门规定了如何在 HTTP Header 中安全地传输包含非 ASCII 字符（包括中文）的字段。

3.1 RFC 5987 标准

RFC 5987是为了解决 Header 字段中包含非 ASCII 字符的问题而制定的标准。该标准通过将非 ASCII 字符进行编码，并通过指定字符集和语言信息，使得这些字符能够在不同平台间正确传输。

标准格式如下：

Header-name: param-name="value"; param-name*=charset'lang'encoded-value

• charset：字符编码方式，通常是 utf-8。
• lang：语言标识，可以为空。
• encoded-value：对字符串进行百分号编码后的结果。

**示例：**假设我们需要设置一个中文文件名为 简历.pdf，可以这样写：

// 错误的做法
Content-Disposition: attachment; filename="简历.pdf"

// 正确的做法 (RFC 5987)
Content-Disposition: attachment; filename="resume.pdf"; filename*=utf-8''%E7%AE%80%E5%8E%86.pdf

解释：

• filename="resume.pdf"：这是一个后备名称，如果客户端不支持 RFC 5987 标准，它会使用这个英文名。
• filename*=utf-8''%E7%AE%80%E5%8E%86.pdf：这是使用 RFC 5987 标准编码后的中文文件名。%E7%AE%80%E5%8E%86是“简历”这两个字经过 UTF-8 编码后再进行百分号编码的结果。

现代浏览器（如 Chrome、Firefox、Edge 等）支持该标准，会优先使用 filename* 字段来显示正确的中文文件名。

3.2 百分号编码（非标准做法）

在某些场景下，开发者可能直接将中文字符进行百分号编码，并直接传输。这种方法虽然简单，但并不是所有服务器和客户端都能完美支持，并且存在兼容性问题。因此，不推荐这种做法。

例如，直接用百分号编码：

Custom-Header: %E4%B8%AD%E6%96%87%E5%80%BC

这种方法的缺点是接收方必须知道这个字段是经过编码的，并且要使用正确的编码（通常是 UTF-8）来解码，否则会得到乱码。

4. 总结

我们可以通过以下表格来总结这两种常见方法：

方法	描述	建议
直接传输中文	Header: 中文值	禁止。会导致解析错误和乱码。
RFC 5987 标准	filename*=utf-8''encoded_value	强烈推荐。是官方标准，兼容性好。
百分号编码	Header: %E4%B8%AD%E6%96%87	不推荐。依赖实现，兼容性差。

结论：

HTTP Header 中不能直接传输中文字符，这不是因为技术上不可能，而是为了确保跨平台、跨语言的兼容性和安全性。为了能够正确地传输中文或其他非 ASCII 字符，应该使用RFC 5987标准对字符进行编码。通过这种方式，我们能够保证 HTTP Header 的规范性和兼容性，避免解析错误和乱码问题，同时提升安全性。

觉得有用的话点个赞 👍🏻 呗。
❤️❤️❤️本人水平有限，如有纰漏，欢迎各位大佬评论批评指正！😄😄😄

💘💘💘如果觉得这篇文对你有帮助的话，也请给个点赞、收藏下吧，非常感谢!👍 👍 👍

🔥🔥🔥Stay Hungry Stay Foolish 道阻且长,行则将至,让我们一起加油吧！🌙🌙🌙