如何转义 HTTP 标头中的换行文字？
在 HTTP 标头中，换行符是标头中分隔字段的标记。
但是，如果我不想在自定义字段中发送换行文字，我应该如何转义它？
In the HTTP header, line breaks are tokens to separate fields in the header.
But, if I wan't to send a line break literal in a custom field how should I escape it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您正在设计自己的自定义扩展字段，则可以使用 BASE64 或引用打印来转义（和取消转义）该值。
If you are designing your own custom extension field, you may use BASE64 or quoted-printable to escape(and unescape) the value.
这个问题的实际答案是没有编码换行符的标准。
您可以使用任何二进制到文本编码，例如 URL-编码或 Base64，但显然只有发送者和接收者都实现相同的方法才有效。
RFC 2616 确实允许“折叠”（即换行）标头值跨多行，但换行符被视为单个空格字符，而不是解析的字段值的一部分。
但是，该规范已被 RFC 7230 废弃，该规范禁止折叠式的：
HTTP 标头字段值中的换行符标准尚未建立，也从未建立。
The actual answer to this question is that there is no standard for encoding line breaks.
You can use any Binary-to-text encoding such as URL-Encoding or Base64, but obviously that's only going to work if both sender and receiver implement the same method.
RFC 2616 did allow to 'fold' (i.e. wrap) header values over multiple lines, but the line breaks were treated as a single space character and not part of the parsed field value.
However, that specification has been obsoleted by RFC 7230 which forbids folding:
A standard for line breaks in HTTP Header field values is not – and never was – established.
根据 RFC2616 4.2 消息头：
其中 SP 表示空格字符 (0x20)，HT 表示水平制表符 (0x09)。
According to RFC2616 4.2 Message Headers:
where SP means a space character (0x20) and HT means a horizontal tab character (0x09).
这个想法是，HTTP 是
ASCII- 仅限，而换行符等是不允许的。 如果发送者和接收者都可以解释您的编码，那么您可以根据需要编码任何内容。 这就是使用Host标头（称为 PUNYCODE）处理 DNS 国际名称的方式。简短的回答是：你不需要，除非你同时控制发送者和接收者。
The idea is, that HTTP is
ASCII-only and newlines and such are not allowed. If both sender and receiver can interpret YOUR encoding then you can encode whatever you want, however you want. That's how DNS international names are handled with theHostheader (it's called PUNYCODE).Short answer is: You don't, unless you control both sender and receiver.
如果它是自定义字段，您如何转义它完全取决于目标应用程序将如何解析它。 如果这是您创建的一些附加组件，您可以坚持使用 URL 编码，因为它经过了相当多的尝试和验证，并且许多语言都内置了编码/解码方法，因此您的 Web 应用程序将对其和您的插件（或您正在处理的任何内容）进行编码）将对其进行解码。
If it's a custom field how you escape it depends entirely on how the targetted application is going to parse it. If this is some add on you created you could stick with URL encoding since it's pretty tried and true and lots of languages have encoding/decoding methods built in so your web app would encode it and your plug in (or whatever you're working on) would decode it.