Basic Auth 生成器
使用 UTF-8 凭据生成 HTTP Basic 请求头
安全与认证
🔒 100% 本地运行 — 你的数据不会离开当前页面由 Evan 维护•最近更新：2026年9月30日
选项模式
凭据
填用户名和密码后直接生成 Authorization 头；编码细节和排障场景可在高级模式查看。
Basic Base64 可逆，请通过 HTTPS 发送。本工具使用原样 UTF-8；非 ASCII 凭据需确认服务端字符集和规范化约定。
输出
输入用户名和密码后可生成 Basic Header
本地处理，不保存凭据草稿
页面阅读模式
完整说明还包括常见问题处理、操作示例、代码片段、FAQ 和相关工具，便于核对结果或排查问题。
工具说明
输入凭据并点击生成，工具会将 username:password 按 UTF-8 和标准 Base64 编码，输出凭据文本、Token、完整请求头行和 cURL 示例。明文密码默认遮罩，主动勾选后才显示，但 Base64 本身仍然可逆。默认保留两端空白，只有选中 Trim 才去除；用户名冒号和控制字符会被拒绝。本工具不发送认证请求，也不验证 htpasswd 记录；编码在本地完成，不保存凭据草稿。
生产可用片段
RFC 7617 示例与首个冒号边界
text
用户名：Aladdin
密码：open sesame
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
用户名 a:b：拒绝
用户名 a + 密码 b:c → 凭据 a:b:c
Base64 仍然可逆。常见问题
为什么拒绝用户名中的冒号？
RFC 7617 用第一个冒号分隔用户名和密码，因此用户名不能包含冒号，密码可以包含后续冒号；两者都不能含控制字符。
UTF-8 兼容所有 Basic 服务端吗？
不一定。RFC 7617 没有统一规定旧协议的默认字符集。charset=UTF-8 挑战表示 UTF-8 与 NFC 规范化约定；本工具保留原输入，请核对服务端的具体约定。
为什么默认不启用 Trim？
空格可能是凭据的一部分。只有确定要去除用户名和密码两端空白时才启用 Trim。
怎样使用生成的请求头？
完整行是 Authorization: Basic TOKEN。在键值式 HTTP 客户端中，键填 Authorization，值填 Basic TOKEN；使用 cURL 示例前需替换示例地址。
遮罩或 Base64 能保护密码吗？
遮罩只减少屏幕明文暴露。Base64 可逆，Token 本身就是凭据；应使用 HTTPS，避免分享生成的请求头。此工具不保存输入草稿。
继续浏览