Base64 / URL 编解码
四个动作共用一片输入:Base64 编码 / 解码、URL 编码 / 解码。全部按 UTF-8 处理 —— 中文和 emoji 都不会乱码,而这一步恰恰是大多数在线工具出错的地方。
输出
—
—
Base64 不是加密
它只是把字节换一种写法,任何人都能解回来,没有任何密钥。所以看到一串 5L2g5aW9 不要以为它是密文 —— 贴进这里按一下解码就出来了。要保护内容得用真正的加密,Base64 保护不了任何东西。
为什么很多工具的中文会乱码
浏览器自带的 btoa() 只认 Latin-1,直接喂汉字当场抛错;而不少实现为了绕开它,先把字符串按 UTF-16 拆成字节 —— 于是解回来是一堆乱码。正确顺序是 文本 → UTF-8 字节 → Base64,解码反过来。这一页走的就是这条正确的路。
URL 编码编的是"组件",不是整条网址
这一页用的是 encodeURIComponent,它会把 : / ? & = 也一并编码掉 —— 这正是编码一个参数值时该做的。想编码一整条网址,应当用 encodeURI,它的保留字符不会被动。两者混用是链接坏掉最常见的原因,所以这里只说清一个口径。
常见问题
因为那串 Base64 里装的不是文本。 图片、压缩包、加密后的字节解出来都不是合法的 UTF-8,很多工具会把坏字节换成 � 接着显示,看起来像"解开了,只是有点怪"。这一页选择直接说清楚:它解出来了,但解出来的东西不是文字。
大约 4/3,也就是长三分之一。每 3 个字节编成 4 个字符,不足 3 个的用 = 补齐。所以 Base64 只适合"把二进制塞进只接受文本的地方",不适合拿来压缩。
%20 是百分号编码的标准写法,空格就是 %20;而 + 表示空格是 application/x-www-form-urlencoded (表单提交)那一套的约定。这一页输出 %20 —— 它在 URL 的任何位置都成立,而 + 只在查询串的某些解析器里才等于空格。
没有硬限制,但输入太长时页面会明显变卡:编码是在主线程上一口气做完的,几 MB 的文本会让按钮按下去之后停顿一下。日常的链接、配置、密钥都在几 KB 以内,不会感觉到。
