Base32 / Base58 변환기

둘은 하나의 질문에 대한 두 답입니다: 텍스트를 실던 채널이 바이트를 실어 달라는 요구를 받았을 때. Base32와 Base58는 암호화도 아니고 해싱도 아닙니다 — 아무것도 숨기지 않고 아무것도 줄이지 않습니다. 바이트 문자열을 고정된 읽기 쉬운 문자 집합으로 다시 쓸 뿐이며, 어떤 집합인지 아는 누구나 곧바로 되돌릴 수 있습니다. 하나를 더 선호할 유일한 이유는 수신 측이 그 문자로 무엇을 하는가입니다.

두 계열이 그 재작성을 완전히 다른 방식으로 하며, 그 차이가 이 페이지의 거의 모든 놀라움을 설명합니다:

• 비트 묶기 — Base32, Base32 Hex, Crockford Base32, z-base-32. 바이트를 고정 묶음으로 자르고 5비트마다 문자 하나가 됩니다. 출력 길이는 입력 길이에서 예측 가능하고, 마지막 부분적으로 찬 묶음은 패딩 문자로 표시되거나 짧게 남습니다.
• 큰 수 변환 — 모든 Base58. 바이트 문자열 전체를 256진 큰 수 하나로 읽어 58진으로 다시 씁니다. 묶음도 패딩도 없고 길이는 무엇으로도 나누어 떨어지지 않으며, 선행 0 바이트마다 선행 0 심볼 하나가 됩니다.

모든 알파벳을 설명 대신 전부 인쇄합니다. 같은 이름 아래 다른 문자를 출력하는 두 도구는 레이블이 무엇이든 서로 맞지 않기 때문입니다. RFC 4648 행은 규범적이고 Crockford와 z-base-32 행은 형식 저자의 공개물을 따르며, 세 Base58 행은 표준이 아니라 널리 퍼진 관례라 따로 나열되어 있습니다.

이 알파벳은 I, L, O, U를 빼서 어떤 심볼도 다른 것으로 읽히지 않게 합니다. 나머지는 입력에서 대소문자를 무시합니다: i와 l은 숫자 1로, o는 숫자 0으로 읽히고 하이픈은 긴 문자열을 읽기 쉽게 하는 역할만 합니다. 그 위에 형식은 선택적 검증 심볼을 정의합니다. 심볼 문자열을 32진 수로 읽은 값을 모듈로 37으로 취하고, 32~36 값에는 5개의 추가 심볼을 씁니다.

검증 심볼은 바이트가 아니라 심볼 문자열에 대해 계산됩니다: 인코더가 마지막 묶음을 0으로 확장하기 때문에 같은 문자를 디코딩하면 언제나 같은 값으로 돌아옵니다. 그래서 표의 검증값은 인코딩된 열만으로 손으로 재현할 수 있습니다. 5개 추가 심볼은 값 32, 33, 34, 35, 36에 대해 *, ~, $, =, U입니다. 검증 심볼이 항상 숫자나 글자는 아닙니다.

z-base-32는 RFC 4648 Base32의 5비트 묶기를 유지하고 32 문자의 순서만 바꿉니다. 사람이 적어야 할 가능성이 큰 문자가 가장 쓰기 쉽고 혼동되기 어렵도록 순서가 정해졌습니다. 패딩이 없어 독자는 값이 몇 심볼이어야 하는지 알아야 합니다. 사람이 먼저 읽도록 설계된 형식의 대가입니다.

Base58 자체는 잘못 입력한 문자열과 올바른 것을 구별할 방법이 없습니다. 58 문자의 거의 모든 조합이 유효한 수이기 때문입니다. Base58Check는 데이터를 래퍼 안에 넣어 해결합니다: 버전 바이트 하나, 페이로드, 앞 두 부분에 SHA-256을 두 번 적용한 첫 4바이트. 수신 프로그램은 그 4바이트를 다시 계산해서 다르면 문자열을 거부합니다. 버전 바이트가 지갑에게 이것이 결제 주소인지 스크립트 주소인지 개인 키인지 알려 줍니다.

변환기 아래의 생성기는 버전 바이트와 페이로드를 16진수로 받아 Base58Check 문자열을 씁니다. 검증기는 문자열을 읽어 체크섬 4바이트를 분리하고 다시 계산해 찾은 값과 기대한 값을 모두 보고합니다. 여기서 잘못된 체크섬은 문자열이 잘못 입력되거나 변경되었다는 뜻입니다 — 페이로드는 해석되지 않고 실리기만 하므로 값 자체가 틀렸다는 뜻은 결코 아닙니다.

• "Base64는 암호화다." 아닙니다. 키도 비밀도 없고 누구나 출력을 되돌릴 수 있습니다. Base32와 Base58도 같은 위치이며, 값을 세 가지로 연달가 거친다고 보호가 추가되지도 않습니다.
• "Base58 문자열은 비트코인 주소다." Base58Check 체크섬을 통과하고 수신 소프트웨어가 아는 버전 바이트를 실을 때만입니다. Base58 문자열은 체크섬 없는 평범한 식별자를 포함해 다른 많은 곳에도 나타납니다.
• "세 Base58 알파벳은 서로 바꿔 쓸 수 있다." 같은 58 문자를 세 가지 순서로 쓰므로 같은 바이트가 세 가지 다른 문자열이 됩니다. 도구는 어느 것인지 들어야 하고 이 페이지는 언제나 자기가 쓴 것을 밝힙니다.
• "패딩은 값의 일부다." = 문자는 마지막 묶음만 표시합니다. 패딩만 다른 두 Base32 문자열은 같은 바이트를 기술하므로 디코더는 패딩이 잘린 문자열도 받습니다.
• "아무 문자나 된다." 각 알파벳은 고정 집합입니다. 밖의 문자는 값이 없어 디코더는 추측 대신 멈추고 문자와 위치를 알려 줍니다.

Base32는 왜 0-9가 아니라 2-7을 쓰나요? RFC 4648이 도메인 이름에 쓸 수 있는 문자 안에 머물고 소리 내어 읽기 쉽도록 알파벳을 그렇게 골랐기 때문입니다. 자연 정렬이 더 중요하면 Base32 Hex가 0-9 A-V를 씁니다.

Base58 문자열이 자주 1로 시작하는 이유는? 입력의 선행 0 바이트마다 선행 1(Bitcoin/Flickr 알파벳의 첫 문자)이 하나 됩니다. 버전 바이트 0x00이 0 바이트 하나라 대부분의 메인넷 비트코인 주소는 정확히 하나의 1로 시작합니다.

샘플 버튼은 뭘 불러오나요? 화면에 있는 방식과 방향에 속한 예제이지 고정 텍스트가 아닙니다. 인코더에는 그 방식 자체의 예제 텍스트가 주어집니다 — Base32/Base32 Hex는 RFC 4648 10절 벡터, Crockford는 12345, z-base-32는 위에 인쇄된 행 — 그리고 디코더에는 선택된 알파벳의 인코딩 문자열이 주어집니다. 그래서 샘플이 양방향으로 쓸 수 있습니다. 세 Base58 행은 일부러 같은 텍스트를 담아, 방식을 바꾸고 샘플을 다시 누르면 같은 58 문자의 세 배치를 나란히 볼 수 있습니다. Crockford 검증 심볼에 체크하면 디코더는 끝에 심볼이 붙은 값을 받습니다. 검증기가 하나를 수락하는 걸 볼 수 있는 유일한 방법입니다.

이 페이지는 제 데이터를 어디로 보내나요? 안 보냅니다. 모든 변환은 이 브라우저 탭에서 일어나고 페이지에는 어떤 종류의 네트워크 호출도 없습니다. 그래서 디스크에서 직접 열어도 동작합니다.

비밀에는 무엇을 써야 하나요? TOTP/HOTP 인증기 비밀키는 보통 수동 입력 때문에 RFC 4648 알파벳의 Base32입니다. 수신 소프트웨어가 요구하는 것을 쓰세요. 그리고 비밀 유지를 인코딩 자체에 의존하지 마세요.