cookie 中允许使用哪些字符? [英] What are allowed characters in cookies?

查看:37
本文介绍了cookie 中允许使用哪些字符?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

cookie 名称和值中允许的字符是什么?它们与 URL 相同还是一些常见的子集?

What are the allowed characters in both cookie name and value? Are they same as URL or some common subset?

我问的原因是我最近遇到了名称中带有 - 的 cookie 的一些奇怪行为,我只是想知道这是浏览器特定的问题还是我的代码有问题.

Reason I'm asking is that I've recently hit some strange behavior with cookies that have - in their name and I'm just wondering if it's something browser specific or if my code is faulty.

推荐答案

这是一个快手:

您可能认为它应该是,但实际上根本不是!

You might think it should be, but really it's not at all!

cookie 名称和值中允许的字符是什么?

What are the allowed characters in both cookie name and value?

根据古网景cookie_spec整个NAME=VALUE字符串是:

According to the ancient Netscape cookie_spec the entire NAME=VALUE string is:

不包括分号、逗号和空格的字符序列.

a sequence of characters excluding semi-colon, comma and white space.

所以 - 应该可以工作,而且在我这里的浏览器中似乎没问题;你在哪里遇到了问题?

So - should work, and it does seem to be OK in browsers I've got here; where are you having trouble with it?

以上暗示:

  • = 包含在内是合法的,但可能不明确.浏览器总是在字符串中的第一个 = 符号上拆分名称和值,因此实际上您可以在 VALUE 中放置一个 = 符号,而不是在 NAME 中.
  • = is legal to include, but potentially ambiguous. Browsers always split the name and value on the first = symbol in the string, so in practice you can put an = symbol in the VALUE but not the NAME.

没有提到什么,因为 Netscape 在编写规范方面很糟糕,但似乎一直受到浏览器的支持:

What isn't mentioned, because Netscape were terrible at writing specs, but seems to be consistently supported by browsers:

  • NAME 或 VALUE 都可以是空字符串

  • either the NAME or the VALUE may be empty strings

如果字符串中根本没有=符号,浏览器会将其视为空字符串名称的cookie,即Set-Cookie:fooSet-Cookie: =foo 相同.

if there is no = symbol in the string at all, browsers treat it as the cookie with the empty-string name, ie Set-Cookie: foo is the same as Set-Cookie: =foo.

当浏览器输出一个空名称的cookie时,它们会省略等号.所以 Set-Cookie: =bar 产生 Cookie: bar.

when browsers output a cookie with an empty name, they omit the equals sign. So Set-Cookie: =bar begets Cookie: bar.

名称和值中的逗号和空格似乎确实有效,但等号周围的空格被修剪

commas and spaces in names and values do actually seem to work, though spaces around the equals sign are trimmed

不允许使用控制字符(x00x1F 加上 x7F)

control characters (x00 to x1F plus x7F) aren't allowed

没有提到和浏览器完全不一致的是非 ASCII (Unicode) 字符:

What isn't mentioned and browsers are totally inconsistent about, is non-ASCII (Unicode) characters:

  • 在 Opera 和 Google Chrome 中,它们使用 UTF-8 编码为 Cookie 标头;
  • 在 IE 中,使用机器的默认代码页(特定于语言环境,从不使用 UTF-8);
  • Firefox(和其他基于 Mozilla 的浏览器)单独使用每个 UTF-16 代码点的低字节(所以 ISO-8859-1 没问题,但其他任何东西都被破坏了);
  • Safari 只是拒绝发送任何包含非 ASCII 字符的 cookie.

因此实际上您根本不能在 cookie 中使用非 ASCII 字符.如果您想使用 Unicode、控制代码或其他任意字节序列,cookie_spec 要求您使用您自己选择的临时编码方案并建议 URL 编码(由 JavaScript 的 encodeURIComponent 生成)作为一个合理的选择.

so in practice you cannot use non-ASCII characters in cookies at all. If you want to use Unicode, control codes or other arbitrary byte sequences, the cookie_spec demands you use an ad-hoc encoding scheme of your own choosing and suggest URL-encoding (as produced by JavaScript's encodeURIComponent) as a reasonable choice.

实际标准而言,已经有一些尝试对 cookie 行为进行编码,但迄今为止都没有真正反映现实世界.

In terms of actual standards, there have been a few attempts to codify cookie behaviour but none thus far actually reflect the real world.

  • RFC 2109 试图编纂和修复原始 Netscape cookie_spec.在此标准中,不允许使用更多特殊字符,因为它使用 RFC 2616 标记(a -仍然允许存在),并且只能在带有其他字符的带引号的字符串中指定值.没有任何浏览器实施过限制、对引用字符串的特殊处理和转义,或本规范中的新功能.

  • RFC 2109 was an attempt to codify and fix the original Netscape cookie_spec. In this standard many more special characters are disallowed, as it uses RFC 2616 tokens (a - is still allowed there), and only the value may be specified in a quoted-string with other characters. No browser ever implemented the limitations, the special handling of quoted strings and escaping, or the new features in this spec.

RFC 2965 是另一个尝试,整理 2109 并添加第 2 版 cookie"方案下的更多功能.也没有人实施任何这些.此规范与早期版本具有相同的标记和引用字符串限制,而且它同样是一堆废话.

RFC 2965 was another go at it, tidying up 2109 and adding more features under a ‘version 2 cookies’ scheme. Nobody ever implemented any of that either. This spec has the same token-and-quoted-string limitations as the earlier version and it's just as much a load of nonsense.

RFC 6265 是 HTML5 时代试图清除历史混乱.它仍然不完全符合现实,但比之前的尝试要好得多——它至少是浏览器支持的一个适当的子集,没有引入任何应该有效但无效的语法(如前面的引用字符串).

RFC 6265 is an HTML5-era attempt to clear up the historical mess. It still doesn't match reality exactly but it's much better then the earlier attempts—it is at least a proper subset of what browsers support, not introducing any syntax that is supposed to work but doesn't (like the previous quoted-string).

在 6265 中,cookie 名称仍指定为 RFC 2616 token,这意味着您可以从字母数字中进行选择:

In 6265 the cookie name is still specified as an RFC 2616 token, which means you can pick from the alphanums plus:

!#$%&'*+-.^_`|~

在 cookie 值中,它正式禁止(由浏览器过滤)控制字符和(不一致实现的)非 ASCII 字符.它保留了 cookie_spec 对空格、逗号和分号的禁止,此外为了与任何实际实现早期 RFC 的可怜的白痴兼容,它还禁止反斜杠和引号,除了引号包裹整个值(但在这种情况下,引号仍被视为值,而不是编码方案).所以这给你留下了字母加号:

In the cookie value it formally bans the (filtered by browsers) control characters and (inconsistently-implemented) non-ASCII characters. It retains cookie_spec's prohibition on space, comma and semicolon, plus for compatibility with any poor idiots who actually implemented the earlier RFCs it also banned backslash and quotes, other than quotes wrapping the whole value (but in that case the quotes are still considered part of the value, not an encoding scheme). So that leaves you with the alphanums plus:

!#$%&'()*+-./:<=>?@[]^_`{|}~

在现实世界中,我们仍在使用原始和最差的 Netscape cookie_spec,因此使用 cookie 的代码应该准备好遇到几乎任何事情,但是对于生成 cookie 的代码,建议坚持使用 RFC 中的子集6265.

In the real world we are still using the original-and-worst Netscape cookie_spec, so code that consumes cookies should be prepared to encounter pretty much anything, but for code that produces cookies it is advisable to stick with the subset in RFC 6265.

这篇关于cookie 中允许使用哪些字符?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆