인코딩을 암호화로 오해하기
Base32, Base58, Base62, Base85, 16진수, Base64는 되돌릴 수 있는 표현 방식입니다. 결과를 받은 사람은 원문을 복원할 수 있으므로 기밀성이나 변조 탐지가 필요하면 인증된 암호화를 사용해야 합니다.
17가지 바이트, 웹, 메시지, 레거시 표현으로 텍스트를 인코딩·디코딩하거나, 검증한 PNG·JPEG·GIF·WebP 파일을 Base64로 변환합니다. 모든 텍스트 결과는 실제 역변환으로 왕복 검증하고, 비용이 큰 연산 전에 자원 한도를 적용하며, 입력값은 브라우저 밖으로 전송하지 않습니다.
관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.
암호 학습 워크벤치에서 XOR 바이트 원리를 눈에 보이게 확인합니다. 알려진 벡터를 재현하고 Hex와 Base64를 비교한 뒤 같은 키로 되돌리면서, 실제 비밀 보호라고 표현하면 안 되는 이유까지 기록합니다.
열기관련 도구UTF-8을 엄격하게 인코딩하고 Base64·Base64URL·Data URI·바이너리 바이트를 로컬에서 디코딩합니다.
열기관련 도구로컬 파일 바이트에서 BOM, 엄격한 UTF-8, Unicode 구조, ASCII 호환성, 바이너리 단서를 검사합니다.
열기관련 도구IDN 하나를 엄격하게 검증하며 유니코드와 퓨니코드 사이에서 변환합니다.
열기범주가 나뉜 메뉴에서 정확한 표현 방식을 고르고, 양방향 모드는 Encode 또는 Decode를 선택합니다.
입력 전에 변형, 바이트 순서, 엔티티 스타일, 이미지 출력 형태, UUEncode 메타데이터를 명시적으로 설정합니다.
이 도구가 서버로 업로드하지 않더라도 결과는 기밀이 아니므로, 화면이나 결과를 공유하기 전 비밀과 개인정보를 제거합니다.
한도 안의 텍스트 샘플을 붙여 넣거나 2,097,152바이트 이하 PNG·JPEG·GIF·WebP 파일 하나를 선택합니다.
Worker를 실행하고 모든 정규화 알림, 바이트 수, 문자 수, 디코딩된 파일명, 왕복 또는 이미지 서명 결과를 확인합니다.
전체 결과를 복사하거나 다운로드한 뒤 실제 수신 시스템에서 시험하고, 상호운용성을 확인할 때까지 원본을 보존합니다.
binary, hexadecimal, Base32, Base58, Base62, ASCII85, Z85 결과를 비교하면서 수신 API에 필요한 정확한 알파벳과 패딩 계약을 유지합니다.
알려진 엔티티 정책으로 HTML·XML 텍스트 문자를 인코딩하거나, 결과 마크업이나 스크립트를 실행하지 않고 문자 참조를 디코딩해 검토합니다.
엄격한 UTS #46 규칙으로 유니코드 호스트명을 바꾸고 DNS나 애플리케이션 허용 목록을 수정하기 전에 ASCII 레이블과 유니코드 표시형을 비교합니다.
정규화와 메타데이터를 확인하면서 quoted-printable 메일 본문, International Morse, Unicode escape, 레거시 UUEncode 블록을 준비합니다.
서명을 확인한 작은 래스터 이미지 하나를 fixture, CSS 테스트, 이메일 템플릿, API payload용 raw Base64 또는 데이터 URI로 만들고 목적지의 크기와 CSP 한도를 확인합니다.
Base32, Base58, Base62, Base85, 16진수, Base64는 되돌릴 수 있는 표현 방식입니다. 결과를 받은 사람은 원문을 복원할 수 있으므로 기밀성이나 변조 탐지가 필요하면 인증된 암호화를 사용해야 합니다.
디코더는 생성 측과 같은 알파벳, 바이트 순서, 패딩 정책, 문자 집합, 컨테이너 규칙을 알아야 합니다. 이 워크벤치의 Base62와 커스텀 이모지 표현은 범용 교환 표준이 아닙니다.
Latin-1은 Windows-1252가 아니고, BOM이 없는 UTF-16의 바이트 순서는 자동 판별할 수 없으며, 임의 바이트가 항상 유효한 UTF-8 텍스트인 것도 아닙니다. 텍스트가 아닌 페이로드는 바이트 중심 파일 흐름을 사용하세요.
왕복 성공은 같은 옵션을 사용한 이 구현이 결과를 되돌릴 수 있음을 뜻합니다. 다른 라이브러리가 같은 Base62 알파벳, HTML 엔티티 집합, IDNA 프로필, UUEncode 메타데이터 규칙을 쓴다는 보장은 아닙니다.
데이터 URI는 텍스트 크기를 늘리고 브라우저나 플랫폼 한도를 넘을 수 있으며 Content Security Policy의 영향을 받습니다. 이미지 서명 검증은 콘텐츠의 안전성, 적절성, 저작권, 메타데이터 유무를 판정하지 않습니다.
텍스트의 UTF-8 바이트를 완전한 옥텟으로 표시하고, 결과를 다시 디코딩한 뒤에만 성공으로 인정합니다.
Hi01001000 01101001Base32는 RFC 4648 알파벳과 정규 패딩을 사용하며, 소문자나 패딩 생략 입력을 디코딩할 때는 정규화 사실을 분명히 알립니다.
fooMZXW6===엄격한 UTS #46 처리로 유니코드 도메인을 변환하고, 잘못된 레이블을 임의 문자열 변환으로 우회하지 않고 거부합니다.
bücher.examplexn--bcher-kva.example이름 있는 HTML 엔티티는 문서화된 공통 집합으로 제한하고, 정확한 스칼라 값이 필요하면 16진 숫자 참조를 선택할 수 있습니다.
5 < 7 & ©5 < 7 & ©UUEncode 헤더에는 검증한 파일명과 8진 권한이 들어가고, 페이로드는 UTF-8 바이트를 제한된 길이의 줄로 구성합니다.
Hello, 파일명 data.txt, 권한 644begin 644 data.txt
%2&5L;&\`
`
endWorker가 MIME 선언과 PNG·JPEG·GIF·WebP 바이트 구조를 함께 확인한 뒤 raw Base64 또는 데이터 URI를 생성합니다.
로컬에서 선택한 PNG 파일data:image/png;base64,iVBORw0KGgo...텍스트 입력은 변환 전에 올바른 유니코드인지 확인하고 코드 포인트 수와 UTF-8 바이트 수를 함께 측정합니다. ASCII, binary, hexadecimal, Base32, Base58, Base62, ASCII85, Z85, Latin-1 hex, UTF-16 hex는 플랫폼 의존 문자열 지름길 대신 명시적인 바이트 알고리즘을 사용합니다.
RFC 4648 Base32는 알파벳, 패딩, 남은 0비트를 검증합니다. Bitcoin Base58과 문서화된 0-9/A-Z/a-z Base62는 선행 0바이트를 보존하지만 반복 진법 변환 비용이 크므로 인코딩·디코딩 양쪽에 8,192바이트 전용 한도를 먼저 적용합니다.
HTML 모드는 제한된 공통 이름 엔티티와 유효한 숫자 참조를 처리하고, XML 모드는 미리 정의된 다섯 엔티티와 XML 1.0 문자 범위를 따릅니다. Unicode escape는 짝이 없는 surrogate를 거부하고, Punycode는 엄격한 UTS #46 IDN 검증을 사용하며, 디코딩 결과를 마크업이나 JavaScript로 실행하지 않습니다.
Quoted-printable은 UTF-8을 76자 물리 줄로 인코딩하고, Morse는 대문자 정규화와 지원 알파벳을 밝히며, 이모지 형식은 문서화된 커스텀 16진 토큰 맵입니다. UUEncode는 파일명, 8진 권한, 줄 길이, 종료 줄을 검증하고 Latin-1과 UTF-16은 추측하지 않고 직접 선택합니다.
각 변환은 15초 시간 제한과 메모리 추정치를 가진 전용 Worker에서 실행합니다. 텍스트 변환 뒤에는 역코덱을 실행해 문서화된 정규화 규칙 아래 원문을 비교합니다. 이미지는 MIME 선언과 PNG·JPEG·GIF·WebP 기본 구조를 확인합니다. 분석 이벤트에는 모드, 안전한 옵션 이름, 시간, 바이트 수, 알림 수만 들어가며 원문과 결과는 포함하지 않습니다.
아닙니다. 인코딩은 표현을 바꿀 뿐 접근을 통제하지 않습니다. Base32, Base58, Base62, Base85, 16진수, 엔티티 참조, 유니코드 이스케이프, quoted-printable, UUEncode는 되돌릴 수 있습니다. 로컬 처리라는 이유만으로 비밀을 붙여 넣지 말고, 기밀성에는 검토된 암호화 체계를 사용하세요.
텍스트 모드는 같은 명시적 옵션으로 즉시 역연산을 수행하고 복원값을 비교합니다. Morse와 quoted-printable은 문서화된 대소문자 또는 줄바꿈 정규화를 적용합니다. 성공은 여러 구현·옵션 오류를 찾지만, 알 수 없는 외부 생성기와의 호환성을 인증하지는 않습니다.
Base58은 Bitcoin 알파벳을 사용합니다. Base62는 0-9, A-Z, a-z 순서이며 시스템마다 순서가 달라 비표준이라고 표시합니다. ASCII85는 Adobe 구분자가 필요하고, Z85는 완전한 4바이트 또는 5문자 블록이 필요합니다.
자동으로 추측하지 않습니다. Latin-1 모드는 U+0000부터 U+00FF까지만 허용하며 Windows-1252가 아닙니다. UTF-16은 little-endian 또는 big-endian을 직접 선택하고 BOM을 넣지 않습니다. 출처를 모르면 명세를 확인하거나 Charset Detector로 먼저 조사하세요.
선택한 파일은 전용 브라우저 Worker가 읽습니다. 선언한 형식을 PNG, JPEG, GIF, WebP 서명과 기본 컨테이너 구조에 대조하고 입력은 2 MiB로 제한합니다. 도구가 파일이나 생성 결과를 업로드하지는 않지만, Base64를 공유하면 이미지의 모든 바이트가 노출됩니다.
텍스트는 UTF-8 262,144바이트와 유니코드 코드 포인트 524,288개로 제한하며, 계산량이 큰 Base58·Base62에는 별도 8,192바이트 한도를 둡니다. 텍스트 출력은 2,097,152바이트, 이미지 원본은 2,097,152바이트, 이미지 Base64 출력은 3,145,728바이트까지입니다. Worker 시간 제한과 메모리 가드도 적용합니다.
관리 및 검수 SimpleWebUtils검토일
검증 방법: 검토에서는 수정하지 않은 “UTF-8 텍스트 필드용 RFC 4648 Base32 검증” 샘플을 인코딩 워크벤치에 불러왔습니다. “변환 전에 수신기 계약 작성하기”에서 “실제 수신기를 양방향으로 시험하기”까지의 흐름을 실행해 화면 또는 다운로드 결과를 예시와 비교했습니다. 별도 조사 항목은 “가장 짧은 출력만 고르기”, “모든 Base62·Base85가 같다고 가정하기”였습니다.
기대 결과: UTF-8 “café!”는 RFC 4648 계약에 따라 패딩을 포함한 MNQWNQ5JEE======로 인코딩됐고, 같은 계약으로 디코딩했을 때 원래 바이트가 복원됐습니다.
검증한 작업 가이드 열기도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.
암호 학습 워크벤치에서 XOR 바이트 원리를 눈에 보이게 확인합니다. 알려진 벡터를 재현하고 Hex와 Base64를 비교한 뒤 같은 키로 되돌리면서, 실제 비밀 보호라고 표현하면 안 되는 이유까지 기록합니다.
작업 가이드API, 데이터베이스 필드, DNS 레이블, 이메일 본문, 설정 파일, 레거시 전송 규칙이 Base32·Base58·Base62·Base85·16진수·엔티티·Punycode·quoted-printable·UTF-16·UUEncode를 요구하지만 변형을 충분히 설명하지 않을 때 사용하는 흐름입니다.
작업 가이드상품, 교정본, 포트폴리오 이미지 폴더를 검수된 공유용 묶음으로 만드는 흐름입니다. 원본을 보존하고 목적에 맞게 텍스트 또는 로고를 선택한 뒤 서로 다른 화면 비율에서 대비와 회전 위치를 시험하고, 지원하는 정적 파일만 처리해 다운로드 후 형식, 메타데이터, 이름, 화질을 확인합니다.
관리 중인 다른 작업 흐름을 이어서 사용해 보세요
UTF-8을 엄격하게 인코딩하고 Base64·Base64URL·Data URI·바이너리 바이트를 로컬에서 디코딩합니다.
로컬 파일 바이트에서 BOM, 엄격한 UTF-8, Unicode 구조, ASCII 호환성, 바이너리 단서를 검사합니다.
IDN 하나를 엄격하게 검증하며 유니코드와 퓨니코드 사이에서 변환합니다.
코드 포인트 근거와 호환 손실 경고를 제공하는 Unicode 정규화 도구입니다.
정확한 URL 컴포넌트, 전체 URL, 폼 값을 브라우저에서 인코딩·디코딩합니다.