# 编码 / 解码 URL: https://discuvr.org/encode-decode/?hl=zh-hans Last updated: 2026-11-07 MCP tool: `encode_decode_text` 边输入边编码或解码 Base64、Base64URL、URL 百分号编码、HTML 实体和十六进制。完整支持 UTF-8，提示缺失的填充，不保存任何内容。 日志里的令牌、重定向里的查询字符串、满是 & 的邮件正文,工作中到处都会遇到编码过的文本。粘贴到这里,选择格式,边输入边看到编码或解码的结果。 ## 功能说明 - Base64、Base64URL(JWT 风格,无填充)、URL 百分号编码、HTML 实体和十六进制。 - 完整支持 UTF-8:中文、印地语、带重音的字母和 emoji 往返转换都不会损坏。 - 缺失的 Base64 填充会被补上并提示,绝不悄悄修正。 - 不是文本的字节以十六进制显示,而不是一堆乱码。 - 一键把输出作为输入,反向转换。 ## 工作原理 1. 选择格式,以及编码还是解码。 2. 粘贴文本,结果会随输入实时更新。 3. 复制输出,或把它作为下一次的输入。 ## 实例:读取 JWT JSON Web Token 由三段 Base64URL 用点连接而成:头部、载荷和签名。粘贴中间那段,选择 Base64URL 并解码,就能看到 JSON 声明,例如用户 id 和过期时间 exp(一个 Unix 时间戳,可以用 Unix 时间戳转换工具读取)。解码不等于验证:任何人都能读出 JWT 的载荷,只有服务器上的签名校验才能证明它没有被改动。 ## 工作中容易踩的坑 有些系统为节省空间会去掉 Base64 的填充,这样的数据在严格的解码器里会失败;本工具会补上缺失的 = 号并告诉你。很多服务器把查询字符串里的 + 当作空格,所以未经编码直接粘进链接的 Base64 值到达时已被破坏;请把它按 URL 组件编码,或改用 Base64URL。被编码了两次的文本会显示为 %2520 或 &amp;,需要解码两次。 ## 各解码方式接受哪些输入 Base64 解码会忽略空格和换行，所以像邮件里那样被折成多行的值，粘贴后可直接解码。Base64URL 解码也接受 + 和 /，但普通 Base64 不接受 - 和 _，因此 JWT 的各段需要选 Base64URL。十六进制解码会跳过空格、冒号、逗号、短横线和 0x 前缀，所以 48:65:6c:6c:6f 和 0x48 0x65 都能解码。URL 解码会把 + 变成空格，所以真正的加号必须写成 %2B。HTML 编码会转义 & < > " 和 ' 这五个字符；HTML 解码能识别 HTML5 的所有命名实体，例如   和 …，以及数字实体，例如表示卢比符号的 ₹。 ## 实例：每种格式输出什么 这里的 URL 编码针对单个值，例如一个查询参数，因此所有保留字符都会被转义：https://example.com/a b?x=1&y=2 会变成 https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2。只编码要放进链接的那个值，不要编码整个链接。ASCII 以外的文字按 UTF-8 字节编码：café ₹ 会变成 caf%C3%A9%20%E2%82%B9，十六进制显示的是同样的字节，é 为 c3 a9，₹ 为 e2 82 b9。user:pass 的 Base64 是 dXNlcjpwYXNz，正是 HTTP Basic Authorization 请求头携带的值（RFC 7617），所以任何看到该请求头的人都能读出密码。 ## 问题 **为什么解码后的文本出现 é 这样的怪字符?** 这些字节本来是 UTF-8,但在编码之前被某个环节当成 Latin-1 或 Windows-1252 读取了。这里的解码如实显示字节,问题需要在生成它们的系统里修复。 **可以解码整个文件吗?** 最多可粘贴 200,000 个字符的文本。对于图片等二进制文件,解码后的字节以十六进制显示,而不会生成下载文件。 **Base64 是加密吗?** 不是。Base64 只是改变字节的书写方式,让它们能通过只接受纯文本的系统。任何人都能解码,切勿用它来隐藏密码或机密。 **Base64 和 Base64URL 有什么区别?** Base64URL 把 "+" 和 "/" 换成 "-" 和 "_",通常还去掉 "=" 填充,因此结果可以安全地放进 URL 和文件名。JSON Web Token 使用的就是它。 **我的文本会被保存吗?** 不会。文本在同一次请求中转换并返回,从不写入数据库或日志。 **为什么 URL 编码结果和 JavaScript 的 encodeURIComponent 不一样？** 本工具还会转义 ! ' ( ) 和 *，而 encodeURIComponent 会保留它们，所以 it's (50%) off! 会变成 it%27s%20%2850%25%29%20off%21。两种写法解码后是同一段文字，在查询参数值里转义这些字符总是安全的。空格变成 %20 而不是 +；+ 的写法来自 HTML 表单编码，这里的解码器两种都能识别。 **如何在命令行中进行 Base64 编码或解码？** 在 Linux 或 Mac 上，echo -n 'Hello, World' | base64 得到 SGVsbG8sIFdvcmxk，echo 'SGVsbG8sIFdvcmxk' | base64 --decode 再把它还原成文本。如果省略 -n，echo 会多加一个换行符并一起编码，结果变成 SGVsbG8sIFdvcmxkCg==：这是两个工具结果不一致最常见的原因。在 PowerShell 中，[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')) 用于编码，[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) 用于解码。本页按 UTF-8 精确编码你粘贴的字符，不会额外添加换行符。 **如何解码 Base64 图片或 data URI？** 只粘贴逗号后面的部分：在 data:image/png;base64,iVBORw0KGgo... 中就是 iVBORw0KGgo...，因为 data:image/png;base64, 前缀不是 Base64，整串粘贴会被拒绝。选择 Base64 和 Decode。不是文本的字节会以十六进制显示，而不是画成图片，但这足以判断文件类型：PNG 以 89 50 4e 47 开头，JPEG 以 ff d8 ff 开头，完整的 .docx、.xlsx 或其他基于 ZIP 的文件以 50 4b 03 04 开头。想看图片本身，把完整的 data URI 粘贴到浏览器地址栏即可。输入上限为 200,000 个字符，约合 150,000 字节的文件。 **为什么 Base64 比原文长约三分之一？** Base64 把每 3 个字节写成 4 个字符，最后一组用 = 补齐到 4 的倍数（RFC 4648），所以输出是输入字节数的 4/3，向上取整。Hello, World 是 12 字节，变成 16 个字符 SGVsbG8sIFdvcmxk。计算的是 UTF-8 字节而不是字数：café 是 4 个字符但有 5 字节，结果为 Y2Fmw6k=；₹100 是 6 字节，结果为 4oK5MTAw。一个汉字在 UTF-8 中通常占 3 字节，所以中文文本的 Base64 比字数长得多。电子邮件附件还会再大一点，因为 MIME 会把 Base64 按每行最多 76 个字符断行（RFC 2045）；本页解码时会忽略这些换行。不带填充的 Base64URL 只省下 = 号。 ## 更多开发者工具 - [Unix 时间戳转换器](https://discuvr.org/timestamp-converter/?hl=zh-hans) - [系统架构图生成器](https://discuvr.org/system-diagram/?hl=zh-hans) - [JSON 格式化工具](https://discuvr.org/json-formatter/?hl=zh-hans) - [Python Formatter](https://discuvr.org/python-formatter/?hl=zh-hans) ## 常一起使用 - [密码生成器](https://discuvr.org/password-generator/?hl=zh-hans) --- Part of Discuvr (https://discuvr.org/): Discuvr is a collection of free, focused tools for day-to-day professional work - office and data utilities, legal and compliance helpers, privacy and security checks, and developer formatters. Every tool has its own page, and most can also be called from ChatGPT or Claude over MCP.