你不能在cookie的值字段中放入“;”，在大多数浏览器中，将设置的名称是“;”之前的字符串…

你不能在cookie的值字段中放入“;”，在大多数浏览器中，将设置的名称是“;”之前的字符串…

cookie规范有两个版本 1. 版本0 cookie，即Netscape cookie， 2. 版本1又名RFC 2965 cookie 在版本0中，cookie的名称和值部分是字符序列，如果不与双引号一起使用，则不包括分号、逗号、等号和空格 版本1要复杂得多，你可以在这里检查 在这个版本中，除了名称不能以$符号开头之外，名称值部分的规格几乎相同

最后我用了

cookie_value = encodeURIComponent(my_string);

and

my_string = decodeURIComponent(cookie_value);

这似乎对各种角色都适用。除此之外，我还遇到了一些奇怪的问题，即使是那些不是分号或逗号的字符。

根据古老的Netscape cookie_spec，整个NAME=VALUE字符串是:

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

应该可以工作，在我这里的浏览器中似乎是可以的;你在哪里有问题?

综上所述:

=是合法的，但可能有歧义。浏览器总是将字符串中的第一个=符号的名称和值分开，所以实际上你可以在value中放入=符号，而不是name。

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

either the NAME or the VALUE may be empty strings 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. 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 control characters (\x00 to \x1F plus \x7F) aren't allowed

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

在Opera和谷歌Chrome中，它们被编码为UTF-8的Cookie头; 在IE中，使用机器的默认代码页(特定于语言环境，从不使用UTF-8); Firefox(和其他基于mozilla的浏览器)单独使用每个UTF-16代码点的低字节(因此ISO-8859-1是OK的，但其他任何内容都是混乱的); Safari只是拒绝发送任何包含非ascii字符的cookie。

所以实际上你根本不能在cookie中使用非ascii字符。如果您想使用Unicode、控制码或其他任意字节序列，cookie_spec要求您使用自己选择的特别编码方案，并建议使用url编码(由JavaScript的encodeURIComponent生成)作为合理的选择。

就实际的标准而言，已经有一些试图编纂cookie行为的尝试，但迄今为止还没有一个能真正反映现实世界。

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 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 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令牌，这意味着您可以从字母加上:

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

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中的子集。

我认为这通常是特定于浏览器的。为了安全起见，base64编码了一个JSON对象，并将所有内容存储在其中。这样你只需要解码和解析JSON。base64中使用的所有字符在大多数浏览器(如果不是所有浏览器)中都可以正常运行。