인코딩 변환
Base64, URL 인코딩, HTML 엔티티, 유니코드 이스케이프, 16진수, JWT 파싱 — 여섯 탭에서 양방향 변환
六个标签页都只在你的浏览器里算：不提交表单、不请求接口、不写 localStorage 或网址参数。 Base64 与 JWT 里常常藏着密钥、token 或账号信息，编解码放在本地完成，是这页唯一的正确做法。
Base64 编解码
按 UTF-8 字节编码，所以中文与 emoji 都能正确往返。开「URL-safe」会把 + 换成 -、/ 换成 _（放进网址参数或文件名时用），开「去掉末尾的等号」会省略补位的 =。
URL 编码 / 解码
两种口径的差别只有一处保留字符：encodeURIComponent 不保留任何保留字符，空格编成 %20、/ 与 ? 与 & 与 = 都会被编码，适合编码「一个参数值」；encodeURI 保留 : / ? # & = + 与中文，只处理空格与非 ASCII，适合编码「一整条网址」。
HTML 实体编码 / 解码
编码默认只处理 5 个有特殊含义的字符：& < > " 与单引号，勾选后连非 ASCII（中文、emoji）也一并转成数字实体。解码同时认命名实体（& < 这类）与数字实体（{ 与 😀 两种写法）。
Unicode 转义互转
两种写法都认：BMP 内用 4 位十六进制的 \uXXXX（中文「中」= \u4E2D）；超出 BMP 的 emoji 用码点写法 \u{XXXXX} 才能一个转义表示一个字符，而 4 位写法必须写成代理对（😀 = \uD83D\uDE00）。本页按你的选择输出，解码时两种写法都能读回同一个字符。
文本 ↔ Hex 十六进制
一律以 UTF-8 字节为准：一个汉字是 3 个字节，所以「中文」= e4b8ad e69687，而一个 emoji 是 4 个字节。解析时忽略空格、换行、冒号与逗号，也认 0x 前缀；十六进制位数必须是偶数，否则会明确报错而不是猜。
JWT 解析
JWT 是三段用点号连接的字符串：header.payload.signature，前两段是 Base64URL 编码的 JSON，第三段是签名。本页只做 Base64URL 解码与 JSON 格式化，时间字段一律标注为 GMT+8。
这几种「编码」到底在解决什么问题
Base64 不是加密，只是「换个字母表」。每 3 个字节切成 4 个 6 位再查表，于是二进制变成只含 A-Z、a-z、0-9、+、/ 与补位 = 的纯文本，长度涨约三分之一。谁都能一步还原，所以它只解决「二进制进不了文本协议」，不解决保密。变体两个：URL-safe 用 - 与 _ 代替 + 与 /；补位 = 可省，解码端按长度补回即可。
URL 编码为什么必须存在。网址里 ? & = # 有语法含义，参数值含这些字符就会被当结构解析——搜「A&B」时服务端会收到两个参数。所以值里的保留字符写成 %XX，非 ASCII 先按 UTF-8 变字节再转义。编码一个参数值用 encodeURIComponent（把 / ? & = 都编码掉，最安全），编码一整条网址才用 encodeURI（保留分隔符）；表单口径的空格是 +，本页给了开关。
HTML 实体防的是注入。把用户内容直接拼进页面，一段含 script 的输入就会被执行（XSS）；转义 &、<、>、" 与单引号即变回纯文本。其中 & 必须第一个替换，否则刚生成的 < 会被再转一次成 &lt;。解码要同时认十进制 中 与十六进制 中 两种数字写法，以及命名实体。
Unicode 转义与代理对。JS 字符串以 UTF-16 为单位，\uXXXX 只能写到 FFFF；超出 BMP 的 emoji 占两个单位，所以 😀 的 4 位写法是 \uD83D\uDE00——两个转义合起来才是一个字符，只写 \uD83D 是半个字符；ES6 起可用码点写法 \u{1F600} 一次表示完。同理 '😀'.length 是 2 而不是 1。
Hex 与「字节」的关系。十六进制把每个字节写成两位，和 Base64 一样是编码不是加密，只是长两倍却更好核对。按 UTF-8 口径一个汉字占 3 字节，「中文」= e4b8ad e69687；同一个字按 GBK 是 d6d0，两边对不上时先确认编码口径，而不是怀疑工具。
JWT 三段结构与「解析不等于校验」。JWT 是三段 Base64URL：header 说算法与类型，payload 放声明（iss、sub、exp、iat、nbf 及业务字段），signature 是用密钥对前两段算出的签名。前两段只是编码，谁都能解开、也谁都能改，「解得开」和「没被改过」是两件事——真正的校验必须在服务端重算签名、防 alg 被改成 none、核对 iss 与 aud。
为什么这页坚持不上传。Base64 的原文常是密钥或证书、JWT 里一定带 token 与账号信息、URL 里常含回调地址与签名串。本页计算全是页面内的一段纯 JavaScript（写在源码的 PURE 区块里）：打开 Network 面板除静态资源外没有任何请求，也不写 localStorage、不把内容放进网址参数，关掉页面即消失。
자주 묻는 질문
암호화 아니고 그냥 부호화예요. Base64 열을 손에 넣은 사람은 아무나 열쇠 없이 한 단계로 되돌려요—비번이나 열쇠를 Base64 해서 데이터베이스나 설정파일에 넣는 건 평문과 같은 뜻이에요. 비밀 유지엔 진짜 암호화 (AES-GCM 등) 랑 열쇠 관리는 필수고, Base64 는 '이진 데이터를 텍스트 규격에 태우기' 같은 쓸모한정이어요.
Base64 는 3 바이트를 4 문자로 바꾸고, 3 의 배수 아닌 나머지는 = 로 끝을 채워요—그래서 등호는 맨 뒤에 0~2 개만 나와요.URL 매개변수·파일이름·JWT 등 많은 곳에서 등호를 빼고, 풀 때 길이로 채우면 돼요—이 페이지는 둘 다 읽어요. URL-safe 는 + 와 / 를 - 와 _ 로 바꾸는 방식인데, 두 문자가URL에서 풀어쓰기 되거나 경로 구분자로 오해받거든요.
매개변수 '값'은 encodeURIComponent—/ ? & = 까지 다 함께 바꿔서 질의열에 끼워도 구조 안 깨져요.URL '통째' 는 encodeURI—: / ? # & = 구분자를 살려줘요, 안 그럼URL가 구조 없는 덩어리 돼요. 참고로 폼 방식은 빈칸을 + 로 바꿔 놓아서, http body 열 풀 땐 '+ 를 빈칸으로' 체크가 자주 필요해요.
JavaScript 는 UTF-16 으로 굴러가서 \uXXXX 는 FFFF 까지만 되고, 😀 은 U+1F600 으로 범위 밖—UTF-16 단위 두 개 (맞짝 쌍) \uD83D\uDE00 로 짜야 해요. 한 글자 한 이스케이프는 코드포인트 표기 \u{1F600} 쓰시고요. 이 페이지는 바꿀 때 두 가지 고를 수 있고, 풀 땐 둘 다 😀 으로 읽어요.
아니요. header 랑 payload 는 Base64URL 로 싼 JSON 일 뿐—아무나 풀고 아무나 마음대로 고칠 수도 있어요. '풀린다' 는 건 JWT 모양이란 말밖에 안 증명해요. 유효 판단은 서버에서 열쇠로 서명 검증하고 알고리즘·발행자·기한까지 대조해야 해요. 이 페이지는 해석만 하고 검증 안 해요—화면의 '기한 안 지남' 표시도 서버 서명 검증 대신이 못 돼요.
exp / iat / nbf 자체는 UTC 의 Unix 시각표 (절대 시각)—보는 시간대에 무관해요. 이 페이지는 사이트 안 다른 도구랑 국내 운영 습관 맞춰 GMT+8 로 통일 표시하고 고정 +8 눈금을 쓰니, 기계 시간대 설정에 좌우 안 돼요. 지남·아직 안 됨 판단은 단말 현재 시각 기준 참고값일 뿐—진짜 판단은 서버가 하는 거예요.