서버에 붙여 넣지 않고 Base64 디코딩하기

Q: 두 가지 웹 주소 인코딩은 뭐가 다른가요?

값 하나냐, 주소 전체냐입니다. 값 하나를 인코딩하면 URL이 의미를 두는 모든 것 - 슬래시, 물음표, 앰퍼샌드 - 이 이스케이프되는데, 쿼리 문자열의 매개변수 하나에 원하는 것이 바로 그것입니다. URL 전체를 인코딩하면 주소는 계속 동작합니다. 슬래시와 ?는 남고, URL이 아예 실을 수 없는 문자만 이스케이프됩니다. 앞의 것을 주소 전체에 쓰면 주소가 깨지고, 뒤의 것을 값에 쓰면 값이 어디서 끝나는지 잃어버립니다.

이 약속을 직접 확인하는 방법

붙여 넣은 것은 나갈 곳이 없습니다. 이 페이지가 연결해도 되는 주소는 Content-Security-Policy에 모두 적혀 있는데, 그중 이 사이트 것은 하나도 없습니다. 붙여 넣은 토큰이 모일 만한 수신 지점이 없고, 설령 있더라도 거기로 무언가를 보낼 코드가 없습니다.

여기서는 아무것도 가져오지 않습니다. src/ 어디에도 fetch도, XMLHttpRequest도, sendBeacon도 없습니다. 모든 인코더와 모든 디코더는 문자열을 받아 문자열을 돌려주는 이 페이지 안의 함수입니다.

무언가 잘못되면 디코더가 말해 줍니다. 브라우저의 atob는 거부해야 할 입력을 받아 놓고 그럴듯한 것을 돌려줍니다. 여기의 Base64는 직접 손으로 쓴 것이고 RFC 4648의 테스트 벡터로 검증하며, 붙여 넣은 것이 Base64가 아니면 아니라고, 왜 아닌지까지 말합니다. tests/js/text-encode.test.js의 테스트가 정확히 그것을 확인합니다.

구글이 불러오는 것과, 구글에게 주지 않는 것. 광고와 측정 스크립트는 구글에서, 후원 버튼은 Buy Me a Coffee에서 옵니다. 어느 쪽에도 내 텍스트는 한 글자도 넘어가지 않습니다. 그것을 읽고 해석하고 쓰는 코드는 한 줄도 빠짐없이 이 출처에서 제공되고 저장소에 공개되어 있습니다.

오프라인에서도 동작합니다. 네트워크를 끊어도 도구는 그대로입니다. 애초에 네트워크를 쓰는 단계가 없었으니까요. 가장 간단한 증거입니다.

직접 확인해 보세요. 위에 적은 어느 것도 그냥 믿으실 필요는 없습니다. 이 페이지는 저장소 안의 템플릿과 설정을 빌드 스크립트가 찍어 낸 결과이고, 그 스크립트는 누구나 읽고 직접 돌려 볼 수 있습니다. 결과물은 dist 브랜치에 그대로 올라가 있고요. 그래서 실제로 제공되는 파일과 소스를 빌드한 결과를 나란히 놓고 비교해 보실 수 있습니다:

github.com/A-Box-of-Tools/website

먼저 읽어 볼 파일을 꼽자면, Content-Security-Policy는 config/site.toml, 그리고 src/encode.js를 보시면 됩니다. 여기의 Base64는 자기 자신이 아니라 RFC 4648의 테스트 벡터로 검증하고, atob처럼 그럴듯한 것을 돌려주는 대신 잘못된 입력을 거부합니다.

회사 보안 소프트웨어가 업로드를 경고한다면. 그것은 브라우저에서 파일이 선택되는 순간을 지켜보며, 페이지가 그것을 보낼 생각인지는 알 수 없습니다 — 그래서 고르는 순간에 경고합니다. 여기서는 아무것도 보내지 않습니다. 브라우저 개발자 도구를 열고 네트워크 탭으로 옮긴 뒤 파일을 골라 보세요. 그것을 실어 나르는 요청은 없고, 이 페이지 자체의 로컬 미리보기 말고는 요청 자체가 없습니다. 같은 확인을 IT 팀도 삼십 초면 할 수 있습니다.

1 인코딩 고르기

인코딩

어느 방향으로 인코딩 평문을 넣으면 인코딩된 것이 나옵니다. 디코딩 인코딩된 것을 넣으면 평문이 나옵니다.

2 붙여 넣기

여기에 파일을 놓으세요 또는 클릭해서 고르기. 아무 텍스트 파일이나 됩니다.

입력한 텍스트 비어 있음

3 결과 가져가기

Base64 텍스트를 Base64로, 또 그 반대로 바꿉니다. 입력의 줄바꿈은 무시하므로 여러 줄로 접힌 키도 그대로 붙여넣으면 됩니다. Base64, URL에 안전한 형태 같은 것인데 +와 / 대신 -와 _를 쓰고 채움 문자가 없습니다. JWT와 대부분의 토큰이 쓰는 방식입니다. 웹 주소, 값 하나 질의 문자열에 들어갈 값을 위한 퍼센트 인코딩입니다. URL이 뜻을 부여하는 것은 모두 이스케이프합니다. 웹 주소, 전체 URL 주소 자체는 그대로 동작하게 두는 퍼센트 인코딩입니다. 빗금과 ?, &는 남습니다. HTML 엔티티 마크업에서 반드시 이스케이프해야 하는 다섯 글자입니다. 디코딩할 때는 숫자 엔티티와 흔한 이름 엔티티도 읽습니다. 16진 바이트 텍스트의 UTF-8 바이트를 16진으로 적습니다. 디코딩할 때는 그 덤프가 어떤 구분자를 썼든 무시합니다. 역슬래시 이스케이프 JavaScript나 Java, JSON의 문자열 리터럴 모양입니다. \n, \t, 그리고 ASCII를 넘는 것에는 \uXXXX를 씁니다. <꺾쇠괄호>와 앰퍼샌드 &, 그리고 카페가 들어간 문자열. 파일을 읽는 중… 그 파일은 읽지 못했습니다: {why} 비어 있음 {n}줄 {n}줄 {n}자 {n}자 아직 아무것도 없습니다. 아무것도 나오지 않았습니다. {name}, 인코딩 — 입력 {in}, 출력 {out} {name}, 디코딩 — 입력 {in}, 출력 {out} 끝에 채움 문자가 두 개보다 많습니다. 채움 문자는 있는데 길이가 4의 배수가 아닙니다. Base64가 되기에는 한 글자 길거나 세 글자 모자랍니다. “{ch}”은 Base64가 쓰는 글자가 아닙니다. “{ch}”은 16진 숫자가 아닙니다. 16진 숫자의 개수가 홀수입니다. \u{…}에는 중괄호 안에 16진 숫자가 있어야 합니다. \{escape} 뒤에는 16진 숫자가 {width}개 있어야 합니다. \{escape}은 여기서 읽는 이스케이프가 아닙니다. “{escape}”은 완전한 퍼센트 이스케이프가 아닙니다. 그 퍼센트 이스케이프들은 올바른 UTF-8이 되지 않습니다. 그 바이트는 UTF-8 텍스트가 아니라서 보여줄 것이 없습니다. 문자열이 아니라 파일일 수 있습니다. {a}, {b} {n} B {n} KB {n} MB 텍스트는 어디로도 가지 않았습니다. 파일 {total}개를 불러왔습니다. {platform} 무언가가 {hosts}에 접속했는데, 이 도구는 절대 그러지 않습니다. {platform} 광고와 측정과 후원 버튼을 위한 이 사이트 자신의 스크립트가 호스트 {hosts}곳에서 왔습니다. 그중 어느 쪽도 그 한 글자도 받지 않았습니다. 광고와 측정과 후원 버튼을 위한 이 사이트 자신의 스크립트가 호스트 {hosts}곳에서 왔습니다. 그중 어느 쪽도 그 한 글자도 받지 않았습니다.

# Base64 인코더 · 디코더 — URL, HTML 엔티티, 16진수, 이스케이프까지 Base64, 퍼센트 인코딩, HTML 엔티티, 16진수, 역슬래시 이스케이프를 양방향으로. 남의 서버에 붙여 넣는 것은 없습니다. > Base64를 두 알파벳 모두로 인코딩·디코딩하고, URL을 퍼센트 인코딩하고, HTML 엔티티를 이스케이프하고, 16진수와 역슬래시 이스케이프를 읽습니다. 전부 브라우저 안에서 돌아가고 아무것도 업로드되지 않아서, 토큰이 내 기기를 떠날 일이 없습니다. 이 페이지는 브라우저 안에서만 동작하는 대화형 도구입니다(https://abox.tools/ko/base64-인코딩/). 도구에 넘긴 어떤 것도 업로드되지 않습니다. 아래는 이 페이지가 도구에 대해 글로 설명하는 내용 전부입니다. 도구를 쓰려면 이 주소를 여세요. ## 텍스트는 **절대 업로드되지 않습니다**. 서버가 아예 없으니까요. 여기의 모든 인코딩은 문자열을 두고 하는 산술이고, 여기 이 페이지에서 이루어집니다. 코덱은 직접 손으로 쓴 것이고 `src/encode.js`에 있으며, 그 밖의 것은 없습니다. 이 도구에는 네트워크 기능이 하나도 없어서 가져올 것도 보낼 것도 없고, 그 사실이 거의 다른 어디보다 여기서 더 중요합니다. 사람들이 온라인 Base64 디코더에 붙여 넣는 것은 토큰이고, 토큰을 남의 웹사이트에 붙여 넣는 것은 그것을 건네주는 일이니까요. - ✗ 업로드 없음 - ✗ 가입 없음 - ✗ 용량 제한 없음 - ✓ 오프라인 동작 - ✓ 오픈 소스 ## 업로드하지 않고 Base64를 인코딩하거나 디코딩하는 방법 1. **인코딩을 고릅니다.** 두 알파벳의 Base64, 값 하나 또는 URL 전체를 위한 퍼센트 인코딩, HTML 엔티티 다섯 가지, 16진수 바이트, 그리고 문자열 리터럴의 역슬래시 이스케이프. 메뉴 아래의 설명이 각각의 쓰임새를 말해 줍니다. 2. **방향을 고릅니다.** *인코딩*은 일반 텍스트를 받아 인코딩된 형태를 만들고, *디코딩*은 인코딩된 형태를 일반 텍스트로 되돌립니다. 결과는 타이핑을 따라오니 방향을 바꾸는 것은 클릭 한 번이고, 다시 입력할 것은 없습니다. 3. **붙여 넣거나, 파일을 놓습니다.** 선택해서 복사할 수 있는 것이면 무엇이든 됩니다. 선택 영역에 놓인 파일은 브라우저가 읽어 상자에 넣습니다. 빼놓을 업로드 단계 자체가 없어요. 4. **오류가 있으면 읽어 봅니다.** 여기서 실패하는 디코더는 무엇을 만났는지 말합니다. Base64가 쓰지 않는 문자, 잘못된 자리의 패딩, 텍스트가 아닌 바이트. 그럴듯하지만 틀린 것을 돌려주는 대신에요. 5. **결과를 가져갑니다.** 복사하거나 텍스트 파일로 내려받으세요. 상자 아래 카운터가 몇 바이트가 들어가서 몇 바이트가 나왔는지 알려 줍니다. ## 상자 속 다른 도구 - [텍스트·파일 공유](https://abox.tools/ko/텍스트-공유/): 공유는 이 열린 탭 안에서만 삽니다. 읽는 사람은 암호화된 내용을 당신의 브라우저에서 직접 받아 가고, 탭을 닫으면 끝납니다 - 어떤 서버에도 아무것도 남지 않습니다. - [QR과 바코드 생성](https://abox.tools/ko/qr코드-만들기/): 입력하면 코드가 됩니다. 만드는 데 아무것도 나가지 않습니다. - [QR과 바코드 스캔](https://abox.tools/ko/qr코드-스캔/): 코드에 카메라를 대거나, 찍어 둔 사진을 올려놓으세요. 읽는 일은 여기서만 일어납니다. - [해시와 체크섬](https://abox.tools/ko/체크섬-확인/): 받은 파일을 배포처가 적어 둔 숫자와 맞춰 봅니다. 어디로도 보내지 않고요. ## 자주 묻는 질문 ### 제 텍스트가 어딘가로 업로드되나요? 아닙니다. 이 페이지의 모든 인코더와 디코더는 내 기기에서, 내 브라우저 안에서 도는 함수입니다. 이 도구에는 네트워크 기능이 하나도 없어서 무언가를 가져오지도, 보내지도 않습니다. 이 페이지의 `Content-Security-Policy`에 연결해도 되는 주소가 전부 적혀 있는데, 그중 이 사이트 것은 하나도 없습니다. 액세스 토큰이나 세션 쿠키에 이 도구를 써야 하는 이유가 그것입니다. 그런 것을 남의 디코더에 붙여 넣는 것은 그들에게 그것을 주는 일이니까요. ### 여기 Base64는 다른 데의 Base64와 같은 것인가요? 같습니다. 자기 자신이 아니라 RFC 4648의 테스트 벡터에 맞춰 확인하니까요. 두 알파벳 모두 디코딩되므로 `-`와 `_`로 쓴 JWT도 `+`와 `/`로 쓴 것만큼 잘 읽히고, 64자로 접힌 입력은 대신 펴 드립니다. 인코딩은 UTF-8 바이트 기준이라 악센트가 붙은 글자나 이모지도 왕복을 견딥니다. ### Base64는 암호화인가요? 아니고, 그렇게 여기는 것이 고전적인 착각입니다. Base64는 표기법입니다. 같은 바이트를 URL과 이메일과 JSON 문자열에서 살아남는 알파벳으로 적은 것뿐이에요. 누구나 되읽을 수 있고 — 이 페이지는 1밀리초면 합니다 — 그러니 아무것도 숨기지 못하고 아무것도 지키지 못합니다. 가진 것이 비밀이라면 인코딩 전에 진짜 암호화가 필요합니다. 암호화 대신이 아니라요. ### 디코딩이 왜 실패했나요? 붙여 넣은 것이 코덱에 말해 준 그것과 정확히 같지 않아서이고, 오류가 어느 쪽이 문제인지 말해 줍니다. Base64 알파벳 밖의 문자, 잘못된 자리의 패딩, 뒤에 16진수 두 자리가 없는 퍼센트 기호, 또는 Base64에서는 풀리지만 UTF-8 텍스트가 아닌 바이트 — 마지막 경우는 대개 원본이 문자열이 아니라 파일이었다는 뜻입니다. 브라우저의 `atob`였다면 대신 그럴듯한 것을 돌려줬을 겁니다. 무엇이 문제인지 들을 수 있다는 것, 그게 디코더에 무언가를 붙여 넣는 이유의 전부입니다. ### 두 가지 웹 주소 인코딩은 뭐가 다른가요? 값 하나냐, 주소 전체냐입니다. *값 하나*를 인코딩하면 URL이 의미를 두는 모든 것 — 슬래시, 물음표, 앰퍼샌드 — 이 이스케이프되는데, 쿼리 문자열의 매개변수 하나에 원하는 것이 바로 그것입니다. *URL 전체*를 인코딩하면 주소는 계속 동작합니다. 슬래시와 `?`는 남고, URL이 아예 실을 수 없는 문자만 이스케이프됩니다. 앞의 것을 주소 전체에 쓰면 주소가 깨지고, 뒤의 것을 값에 쓰면 값이 어디서 끝나는지 잃어버립니다. ### 얼마나 큰 파일까지 다룰 수 있나요? 여기 정해 둔 제한은 없습니다. 그 값을 치를 서버가 없으니까요. 현실적인 한계는 기기 쪽입니다. 몇 메가바이트짜리 텍스트는 괜찮고, 아주 긴 문서라면 페이지가 키보드를 두고 다투는 대신 타이핑이 잠시 멎기를 기다렸다가 다시 인코딩합니다. ### 무료인가요? 가입해야 하나요? 무료이고 계정도, 로그인도, 체험판도 없으며 붙여 넣는 양에도 제한이 없습니다. 이 사이트는 광고로 유지되는데, 그 광고에도 내 텍스트에 관한 것은 넘어가지 않습니다. ### 오프라인에서도 되나요? 됩니다. 페이지를 한 번 불러온 다음 인터넷을 끊어도 계속 동작합니다. 아무것도 업로드되지 않는다는 가장 간단한 증명이기도 하고요. 텍스트를 어딘가로 보내서 디코딩해 오는 도구라면 선을 뽑는 순간 멈춰 버릴 테니까요. ## 이 약속을 직접 확인하는 방법 - **붙여 넣은 것은 나갈 곳이 없습니다.** 이 페이지가 연결해도 되는 주소는 Content-Security-Policy에 모두 적혀 있는데, 그중 이 사이트 것은 하나도 없습니다. 붙여 넣은 토큰이 모일 만한 수신 지점이 없고, 설령 있더라도 거기로 무언가를 보낼 코드가 없습니다. - **여기서는 아무것도 가져오지 않습니다.** `src/` 어디에도 `fetch`도, `XMLHttpRequest`도, `sendBeacon`도 없습니다. 모든 인코더와 모든 디코더는 문자열을 받아 문자열을 돌려주는 이 페이지 안의 함수입니다. - **무언가 잘못되면 디코더가 말해 줍니다.** 브라우저의 `atob`는 거부해야 할 입력을 받아 놓고 그럴듯한 것을 돌려줍니다. 여기의 Base64는 직접 손으로 쓴 것이고 RFC 4648의 테스트 벡터로 검증하며, 붙여 넣은 것이 Base64가 아니면 아니라고, 왜 아닌지까지 말합니다. `tests/js/text-encode.test.js`의 테스트가 정확히 그것을 확인합니다. - **구글이 불러오는 것과, 구글에게 주지 않는 것.** 광고와 측정 스크립트는 구글에서, 후원 버튼은 Buy Me a Coffee에서 옵니다. 어느 쪽에도 내 텍스트는 한 글자도 넘어가지 않습니다. 그것을 읽고 해석하고 쓰는 코드는 한 줄도 빠짐없이 이 출처에서 제공되고 저장소에 공개되어 있습니다. - **오프라인에서도 동작합니다.** 네트워크를 끊어도 도구는 그대로입니다. 애초에 네트워크를 쓰는 단계가 없었으니까요. 가장 간단한 증거입니다. **직접 확인해 보세요.** 위에 적은 어느 것도 그냥 믿으실 필요는 없습니다. 이 페이지는 저장소 안의 템플릿과 설정을 빌드 스크립트가 찍어 낸 결과이고, 그 스크립트는 누구나 읽고 직접 돌려 볼 수 있습니다. 결과물은 `dist` 브랜치에 그대로 올라가 있고요. 그래서 실제로 제공되는 파일과 소스를 빌드한 결과를 나란히 놓고 비교해 보실 수 있습니다: https://github.com/A-Box-of-Tools/website 먼저 읽어 볼 파일을 꼽자면, Content-Security-Policy는 `config/site.toml`, 그리고 `src/encode.js`를 보시면 됩니다. 여기의 Base64는 자기 자신이 아니라 RFC 4648의 테스트 벡터로 검증하고, `atob`처럼 그럴듯한 것을 돌려주는 대신 잘못된 입력을 거부합니다.

자주 묻는 질문

제 텍스트가 어딘가로 업로드되나요?

아닙니다. 이 페이지의 모든 인코더와 디코더는 내 기기에서, 내 브라우저 안에서 도는 함수입니다. 이 도구에는 네트워크 기능이 하나도 없어서 무언가를 가져오지도, 보내지도 않습니다. 이 페이지의 Content-Security-Policy에 연결해도 되는 주소가 전부 적혀 있는데, 그중 이 사이트 것은 하나도 없습니다. 액세스 토큰이나 세션 쿠키에 이 도구를 써야 하는 이유가 그것입니다. 그런 것을 남의 디코더에 붙여 넣는 것은 그들에게 그것을 주는 일이니까요.

여기 Base64는 다른 데의 Base64와 같은 것인가요?

같습니다. 자기 자신이 아니라 RFC 4648의 테스트 벡터에 맞춰 확인하니까요. 두 알파벳 모두 디코딩되므로 -와 _로 쓴 JWT도 +와 /로 쓴 것만큼 잘 읽히고, 64자로 접힌 입력은 대신 펴 드립니다. 인코딩은 UTF-8 바이트 기준이라 악센트가 붙은 글자나 이모지도 왕복을 견딥니다.

Base64는 암호화인가요?

아니고, 그렇게 여기는 것이 고전적인 착각입니다. Base64는 표기법입니다. 같은 바이트를 URL과 이메일과 JSON 문자열에서 살아남는 알파벳으로 적은 것뿐이에요. 누구나 되읽을 수 있고 — 이 페이지는 1밀리초면 합니다 — 그러니 아무것도 숨기지 못하고 아무것도 지키지 못합니다. 가진 것이 비밀이라면 인코딩 전에 진짜 암호화가 필요합니다. 암호화 대신이 아니라요.

디코딩이 왜 실패했나요?

붙여 넣은 것이 코덱에 말해 준 그것과 정확히 같지 않아서이고, 오류가 어느 쪽이 문제인지 말해 줍니다. Base64 알파벳 밖의 문자, 잘못된 자리의 패딩, 뒤에 16진수 두 자리가 없는 퍼센트 기호, 또는 Base64에서는 풀리지만 UTF-8 텍스트가 아닌 바이트 — 마지막 경우는 대개 원본이 문자열이 아니라 파일이었다는 뜻입니다. 브라우저의 atob였다면 대신 그럴듯한 것을 돌려줬을 겁니다. 무엇이 문제인지 들을 수 있다는 것, 그게 디코더에 무언가를 붙여 넣는 이유의 전부입니다.

두 가지 웹 주소 인코딩은 뭐가 다른가요?

값 하나냐, 주소 전체냐입니다. 값 하나를 인코딩하면 URL이 의미를 두는 모든 것 — 슬래시, 물음표, 앰퍼샌드 — 이 이스케이프되는데, 쿼리 문자열의 매개변수 하나에 원하는 것이 바로 그것입니다. URL 전체를 인코딩하면 주소는 계속 동작합니다. 슬래시와 ?는 남고, URL이 아예 실을 수 없는 문자만 이스케이프됩니다. 앞의 것을 주소 전체에 쓰면 주소가 깨지고, 뒤의 것을 값에 쓰면 값이 어디서 끝나는지 잃어버립니다.

얼마나 큰 파일까지 다룰 수 있나요?

여기 정해 둔 제한은 없습니다. 그 값을 치를 서버가 없으니까요. 현실적인 한계는 기기 쪽입니다. 몇 메가바이트짜리 텍스트는 괜찮고, 아주 긴 문서라면 페이지가 키보드를 두고 다투는 대신 타이핑이 잠시 멎기를 기다렸다가 다시 인코딩합니다.

무료인가요? 가입해야 하나요?

무료이고 계정도, 로그인도, 체험판도 없으며 붙여 넣는 양에도 제한이 없습니다. 이 사이트는 광고로 유지되는데, 그 광고에도 내 텍스트에 관한 것은 넘어가지 않습니다.

오프라인에서도 되나요?

됩니다. 페이지를 한 번 불러온 다음 인터넷을 끊어도 계속 동작합니다. 아무것도 업로드되지 않는다는 가장 간단한 증명이기도 하고요. 텍스트를 어딘가로 보내서 디코딩해 오는 도구라면 선을 뽑는 순간 멈춰 버릴 테니까요.