Hex 디코딩
아래에 16진수 문자열을 붙여넣고 디코딩을 클릭하면 텍스트로 변환됩니다. 모든 처리는 브라우저에서 로컬로 수행됩니다.
공백, 콜론, 쉼표, 하이픈, 0x 접두사는 디코딩 전에 모두 제거됩니다.
복사됨!
16진수 디코딩이란?
16진수 디코딩은 16진수 문자열을 원래 바이트 표현으로 다시 변환한 후 텍스트로 변환합니다. 입력에는 16진수 쌍 사이에 공백, 콜론 또는 구분자가 없을 수 있습니다.
각 16진수 문자 쌍(00–ff)은 1바이트를 나타냅니다. 디코딩된 바이트는 UTF-8 텍스트로 해석됩니다.
공백, 콜론, 쉼표, 세미콜론, 마침표, 하이픈은 디코딩 전에 제거되므로 지문이나 덤프에서 그대로 복사한 16진수도 대개 손보지 않고 통과합니다. 바이트는 이후 UTF-8로 읽으며, 올바른 UTF-8이 아닌 것은 깨뜨리지 않고 알려 줍니다.
관련 도구
디코딩되지 않는 문제를 쫓고 계신가요?
디코딩되지 않는 페이로드는 대개 원인이 아니라 증상입니다. 파이프라인 어딘가의 이중 인코딩, 선언 대신 가정된 문자셋, 아무도 예상하지 않은 바이트 위에 서명된 토큰 같은 것들이죠. 저희는 바로 그런 일을 합니다. 연동과 API, 그리고 그 사이에서 데이터를 넘기는 시스템에서요.
어디가 깨지는지 알려 주세요자주 묻는 질문
제 16진수 문자열은 왜 디코딩되지 않나요?
대개 자릿수가 홀수이거나, 16진수가 아닌 문자가 섞여 있기 때문입니다. 한 바이트에는 정확히 두 자리가 필요하므로 홀수라는 것은 어딘가 잘렸거나 도중에 한 자리를 잃었다는 뜻입니다. 엉뚱한 문자는 흔히 1 대신 친 소문자 l, 0 대신 친 대문자 O, 또는 복사한 줄의 꼬리가 딸려온 것입니다.
공백이나 콜론, 0x 접두사가 있는 16진수를 붙여 넣어도 되나요?
공백, 콜론, 쉼표, 세미콜론, 마침표, 하이픈은 모두 디코딩 전에 제거되므로 인증서 지문이나 MAC 주소, 덤프에서 그대로 복사한 16진수도 대개 손보지 않고 통과합니다. 각 바이트 앞의 0x는 제거되지 않으니, 원본에 있다면 먼저 지워 주세요.
디코딩된 바이트가 텍스트가 아니면 어떻게 되나요?
그것은 오류가 아니라 정상적인 경우입니다. 16진수는 바이트를 적어 두는 방식이고, 그 바이트가 아예 텍스트가 아닌 일은 흔합니다. 이 페이지는 이를 UTF-8로 디코딩하며, 올바른 UTF-8이 아닐 때는 대체 문자를 늘어놓고 헷갈리게 하는 대신 그렇다고 분명히 말합니다. 텍스트를 기대했는데 얻지 못했다면 바이트가 압축되었거나 암호화되었는지 확인하세요.
그 바이트가 어떤 문자 인코딩인지 어떻게 아나요?
16진수만으로는 알 수 없습니다. 어떤 인코딩이 그것을 만들었는지 16진 문자열 안에는 아무 기록도 없습니다. 그 정보는 바이트 바깥, HTTP 헤더나 파일 형식, 프로토콜 명세에 있습니다. 이 페이지는 UTF-8을 가정하며, 압도적으로 많은 경우 그것이 맞습니다. 그래서 잘못된 시퀀스를 슬그머니 깨진 글자로 바꾸는 대신 이진 데이터라고 알립니다. 바이트가 다른 인코딩임을 안다면, 인코딩을 지정할 수 있는 도구로 디코딩하세요.
16진 디코딩은 되돌릴 수 있나요?
완전히 되돌릴 수 있습니다. 16진수는 바이트마다 문자 두 개를 놓는 단순 치환이라 잃는 것도 더해지는 것도 없고, 인코딩한 뒤 디코딩하면 처음의 바이트가 그대로 돌아옵니다. 늘 되돌릴 수 있는 것이 아닌 쪽은 그다음 단계입니다. 바이트를 다시 텍스트로 만들려면 올바른 인코딩이 필요하고, 그 인코딩에서 유효하지 않은 바이트 열은 아예 텍스트 형태가 없습니다.