如果你稍后使用变量，你会发现像path这样的东西实际上会让重音字符通过，但它实际上并不匹配浏览器路径。为此，您需要对它们进行URIEncode。比如这样:

  const encodedPath = encodeURI(myPath);
  document.cookie = `use_pwa=true; domain=${location.host}; path=${encodedPath};`

因此，“允许的”字符可能比规范中规定的要多。但为了安全起见，您应该遵守规范，并使用uri编码的字符串。

One more consideration. I recently implemented a scheme in which some sensitive data posted to a PHP script needed to convert and return it as an encrypted cookie, that used all base64 values I thought were guaranteed 'safe". So I dutifully encrypted the data items using RC4, ran the output through base64_encode, and happily returned the cookie to the site. Testing seemed to go well until a base64 encoded string contained a "+" symbol. The string was written to the page cookie with no trouble. Using the browser diagnostics I could also verify the cookies was written unchanged. Then when a subsequent page called my PHP and obtained the cookie via the $_COOKIE array, I was stammered to find the string was now missing the "+" sign. Every occurrence of that character was replaced with an ASCII space.

考虑到从那时起，我读到过许多类似的未解决的抱怨，描述这种情况，经常使用base64在cookie中“安全地”存储任意数据，我认为我应该指出问题，并提供我公认的笨拙的解决方案。

在你对一段数据做了任何你想做的加密之后，然后使用base64_encode使它“cookie安全”，通过这个运行输出字符串…

// from browser to PHP. substitute troublesome chars with 
// other cookie safe chars, or vis-versa.  

function fix64($inp) {
    $out =$inp;
    for($i = 0; $i < strlen($inp); $i++) {
        $c = $inp[$i];
        switch ($c) {
            case '+':  $c = '*'; break; // definitly won't transfer!
            case '*':  $c = '+'; break;

            case '=':  $c = ':'; break; // = symbol seems like a bad idea
            case ':':  $c = '='; break;

            default: continue;
            }
        $out[$i] = $c;
        }
    return $out;
    }

Here I'm simply substituting "+" (and I decided "=" as well) with other "cookie safe" characters, before returning the encoded value to the page, for use as a cookie. Note that the length of the string being processed doesn't change. When the same (or another page on the site) runs my PHP script again, I'll be able to recover this cookie without missing characters. I just have to remember to pass the cookie back through the same fix64() call I created, and from there I can decode it with the usual base64_decode(), followed by whatever other decryption in your scheme.

我可以在PHP中做一些设置，允许cookie中使用的base64字符串被传输回PHP而不会损坏。与此同时，这是可行的。“+”可能是一个“合法”的cookie值，但如果您希望能够将这样的字符串传输回PHP(在我的例子中是通过$_COOKIE数组)，我建议重新处理以删除违规字符，并在恢复后恢复它们。还有很多其他“饼干安全”的角色可供选择。

IE和Edge还有一个有趣的问题。名称中包含超过1个句点的cookie似乎会被无声地删除。 所以 如此:

cookie_name_a = valuea

而这个会被放弃

cookie.name.a = valuea

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

在ASP。在写入cookie之前，可以使用System.Web.HttpUtility对cookie值进行安全编码，并在读取时将其转换回原始形式。

// Encode
HttpUtility.UrlEncode(cookieData);

// Decode
HttpUtility.UrlDecode(encodedCookieData);

这将阻止&号和等号将一个值写入cookie时分割成一堆名称/值对。

这是简单的:

A <cookie-name> can be any US-ASCII characters except control characters (CTLs), spaces, or tabs. It also must not contain a separator character like the following: ( ) < > @ , ; : \ " / [ ] ? = { }. A <cookie-value> can optionally be set in double quotes and any US-ASCII characters excluding CTLs, whitespace, double quotes, comma, semicolon, and backslash are allowed. Encoding: Many implementations perform URL encoding on cookie values, however it is not required per the RFC specification. It does help satisfying the requirements about which characters are allowed for though.

链接:https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie指令