Cookie 与 JSON 互转
解析 Cookie 字符串为 JSON，也能反向拼回
Cookie 解析：请求头里只有键值，属性和限制不在这里
先分清两类 Cookie 字符串
这是最容易混淆的地方，因为两者格式不同、出现位置不同、用途完全不同：
| 请求头 Cookie | 响应头 Set-Cookie | |
|---|---|---|
| 方向 | 浏览器 → 服务器 | 服务器 → 浏览器 |
| 格式 | 只含 name=value，分号分隔 | 一个 name=value 加一串属性 |
| 含属性 | 不含 | 含 Path Domain Expires Max-Age Secure HttpOnly SameSite |
| 数量 | 一次请求一个头，合并所有 Cookie | 每个 Cookie 一个独立的头 |
所以从浏览器开发者工具里复制到的那行 session=abc; theme=dark，里面不会有 HttpOnly、Secure、SameSite 这些属性。想确认某个 Cookie 是不是 HttpOnly，要看响应头的 Set-Cookie，或者用 Application/存储面板的 Cookie 列表——请求头里从来没有这些信息。这个误解很常见，会导致"为什么我解析不出 HttpOnly"的困惑。
值里的编码问题
Cookie 值没有强制的编码规则，这是实践中麻烦的来源：
- 某些框架在写入时对值做 URL 编码（
%3D、%20之类），读取时自动解码；另一些不做。于是同一个值在不同栈里看到的形态不同。 - 如果值里出现了 URL 编码序列，而它本来就是要当字面量用的（比如 JWT 里不会出现，但 base64 值可能出现
%），自动解码会把数据改掉。 - 判断方法：解码一次看结果是否变得更有意义（出现
{"、s:这类结构标志）。如果是，那就该解码；如果解码后出现非法字符，说明原本就是字面量。
Cookie 值里不允许出现分号、逗号和空白（这些是结构与分隔字符）。所以复杂结构（JSON、对象）必须先编码或序列化再放进去。
常见的 Cookie 内容形态
| 形态 | 特征 | 能做什么 |
|---|---|---|
| 会话 ID | 长随机字符串，无结构 | 只能看，无法解读 |
| JWT | 两到三段以点号分隔的 base64url | 可解码看声明，但无法校验签名 |
| 序列化对象 | 如 a%3A1%3A%7B...%7D（PHP 会话格式） | 解码后可读，格式依语言而定 |
| 明文偏好设置 | 如 theme=dark | 直接可读，也可改 |
第二行要强调：能解码 ≠ 能伪造。JWT 的签名由服务端密钥保护，改了内容服务端会拒绝。不要因为"能看到内容"就以为它不安全，也不要因为它"看起来是编码的"就以为它保密——JWT 的负载是明文可读的。
大小与数量限制
- 单个 Cookie 约 4 KB（含名称、值、属性的总长）。超过就会被浏览器静默丢弃——没有报错，只是这个 Cookie 从此不出现。把大对象塞进 Cookie 是常见的坑。
- 每个域名约 50 个 Cookie（各浏览器略有差异），超出后按策略淘汰。
- 每个请求都会携带匹配的 Cookie，所以 Cookie 越大，每个请求的头部开销越大。只在确实需要"每次请求都自动带上"的小数据上使用。
另外有两个前缀约定值得知道：__Secure- 要求必须带 Secure，__Host- 要求必须是 Secure、无 Domain、且 Path=/。用这些前缀能让浏览器替你拒绝不安全的写法，是防御 Cookie 投毒的手段。
工具怎么用
把 Cookie 字符串粘进去解析成 JSON 对象（分号与空格分隔、重复名称、空值都能处理），或把对象拼回 Cookie 字符串以便贴进 curl、测试用例或 document.cookie。
安全提醒：生产环境的会话 Cookie 等同于账号凭证。不要把它粘贴到任何在线工具里——包括本工具。虽然本工具全程在本地运行、不发起任何请求，但凭证类数据应该养成不留痕的习惯，调试时用脱敏的假值代替，或者用本地脚本处理。
常见问题
像 Expires、Path 这种属性呢？
它们本质是带特殊值的"键"，也会被当成普通字段解析。本工具不涉及浏览器写 Cookie 的逻辑，只做纯文本转换。
没有等号的项怎么处理？
形如 Secure 的开关型标记，没有等号，解析时记为其值为 true。