HTTP Basic 认证生成器
把用户名与密码生成 Authorization: Basic 请求头，支持 UTF-8 中文凭据、从已有请求头反解，以及 curl / fetch 代码片段。
浏览器本地运行所有计算都在你的浏览器里完成，数据不会离开本机。
结果
这个工具能做什么
- 给接口调试、Swagger 或 Postman 补一个 `Authorization: Basic` 头，不用再手工拼字符串做 Base64。
- 从抓包或日志里粘贴一个已有的认证头反解出用户名密码，确认测试账号是不是配置错了。
- 直接拿到 curl 或 fetch 代码片段，复制到终端就能复现请求。
- 凭据里含中文或特殊符号时，确认编码用的是 UTF-8，并提醒服务端按同样方式解析。
示例
输入
user:pa$$w0rd
输出
Authorization: Basic dXNlcjpwYSQkdzByZA==
冒号是用户名与密码的分隔符，所以用户名里不能含冒号；这里的凭据全是 ASCII，任何服务端都能解。含中文时工具会按 UTF-8 编码并给出提示。
常见问题
Basic 认证安全吗？
凭据只是 Base64 编码，不是加密，任何人都能解回来。它的安全性完全依赖传输层：必须走 HTTPS，否则中间人可以直接读到用户名密码。Basic 只适合服务端到服务端、内网或加了一层 TLS 的场景，公网产品建议换成 Token 或 OAuth。
用户名里有冒号会怎样？
RFC 7617 规定第一个冒号之前是用户名，之后全部是密码。所以 `a:b:c` 会被解析成用户名 a、密码 b:c；用户名里出现冒号无法表达，工具生成时也不会阻止，但服务端解析出来一定不是你想要的。
密码含中文会出问题吗？
可能。工具按 UTF-8 编码凭据，并在检测到非 ASCII 字符时提示你；但 RFC 7617 原本只规定了 ISO-8859-1，部分老服务端会用别的字符集解码，导致认证失败。建议服务端显式声明 `charset="UTF-8"`，或者干脆避免在凭据里用非 ASCII 字符。
反解时能接受哪些写法？
三种都行：完整的 `Authorization: Basic xxx`（大小写不敏感）、只写 `Basic xxx`、以及一段裸 Base64。解出来如果缺少「用户名:密码」结构会报「不是合法的 Basic 认证头」，Base64 非法或解出的字节不是合法 UTF-8 也都有各自的提示。
密码会被发送出去吗？
不会。编码、反解和代码片段生成全部在浏览器里完成，页面不发任何网络请求，也不会把凭据写进 URL 或日志。请注意工具生成的 curl 片段里带着明文 Base64，粘贴到聊天工具或工单前先确认场合。
关键词：basic authauthorizationhttp 认证base64curlfetch认证头basic 认证生成