tag 텍스트 ↔ Hex 변환기 star

텍스트-Hex 인코딩은 어떻게 작동하나요?

16진수(hexadecimal)는 16진법 위치 기수법입니다: 16개의 기호(0-9, 그리고 10-15를 나타내는 A-F)를 사용하며 각 자릿수의 위치는 16의 거듭제곱 값을 가집니다. 이것이 컴퓨팅과 자연스럽게 어울리는 이유는 16진수 한 자리가 정확히 4비트(하나의 "니블")를 나타내기 때문입니다 — 그래서 16진수 두 자리는 항상 정확히 1바이트(8비트)를 나타내며, 반올림이나 모호함이 없습니다. 이것이 바이트 값이 절대 두 개를 넘는 16진수 문자를 필요로 하지 않는 이유입니다: 0~255는 00~FF에 깔끔하게 대응됩니다.

이 도구는 텍스트를 이 표현 방식으로, 또는 그 반대로 변환합니다. 텍스트는 먼저 UTF-8을 사용해 원시 바이트로 변환되며(그 덕분에 터키어 문자와 이모지를 포함한 모든 문자가 왕복 변환에서도 손상되지 않습니다), 그다음 각 바이트가 두 자리 16진수 쌍으로 표기됩니다: "Hi"는 48 69가 됩니다. H는 72번째 바이트(0x48)이고 i는 105번째 바이트(0x69)이기 때문입니다. 비ASCII 문자가 포함된 구체적인 예로, "çay"는 C3 A7 61 79로 인코딩됩니다 — "ç" 하나만으로도 두 바이트(C3 A7)를 차지하는데, 이는 단일 바이트 ASCII 범위를 벗어나기 때문이며, "a"와 "y"는 각각 한 바이트입니다. 디코딩은 이 과정을 반대로 수행하며, 공백, 줄바꿈, "0x" 접두사는 무시됩니다.

텍스트, 바이트, 16진수 사이의 이러한 대응 관계 덕분에 이 도구는 단순한 호기심을 넘어 실용적으로도 유용합니다: 네트워크 스니퍼나 시리얼 콘솔에서 얻은 16진수 덤프를 붙여넣어 텍스트로 다시 읽거나, 짧은 바이너리 페이로드를 16진수로 JSON 문자열 안에 삽입하거나, 자신의 코드가 만들어낸 값이 사양 문서에 표시된 16진수와 일치하는지 다시 확인하는 일 — 이 모두는 실제 디버깅 작업에 인코딩/디코딩 방향을 적용한 것일 뿐입니다.

알아두어야 할 사항

• 16진수 인코딩은 암호화가 아닙니다: 데이터의 표현 방식만 바꿀 뿐, 기밀성을 부여하지 않습니다. 모든 16진수 문자열은 즉시, 결정적으로 원래 바이트로 디코딩됩니다 — 문자열을 가진 사람은 누구나 읽을 수 있습니다. 실제 기밀성이 필요하다면 인코딩이 아니라 실제 암호화(예: AES)를 사용하세요.
• 자릿수당 4비트가 중요한 이유: 니블(4비트)은 정확히 16개의 값을 가질 수 있으며(이진수로 0000~1111), 이는 16진수 한 자리에 남김없이 일대일로 대응됩니다 — 반면 이진수를 10진수로 변환하려면 숫자 전체에 걸친 산술 연산이 필요합니다. 이것이 색상 코드(#RRGGBB — 3바이트, 16진수 6자리), 메모리 주소, 저수준 디버깅에서 16진수가 등장하는 이유입니다: 원시 이진 데이터를 가장 간결하고 읽기 쉽게 표현하는 방법이기 때문입니다.
• UTF-8은 가변 폭입니다: ASCII 문자는 1바이트를 차지하지만, 악센트가 붙은 문자와 대부분의 비라틴 문자는 2바이트, 이모지는 흔히 4바이트를 차지합니다 — 그래서 비ASCII 텍스트가 포함되면 16진수 출력 길이가 단순히 "보이는 문자당 두 글자"가 되지 않습니다.
• 지원되는 입력 형식: 디코더는 공백이 있든 없든, 줄바꿈이 있든, "0x" 접두사가 있든 상관없이 16진수 쌍을 받아들입니다 — "48 69", "4869", "0x48 0x69" 모두 "Hi"로 디코딩됩니다.
• 디코딩 시 대소문자는 중요하지 않습니다: 16진수 문자 A-F는 대문자, 소문자, 또는 섞어서 써도 동일하게 디코딩됩니다. 둘 다 같은 4비트 값을 나타내기 때문입니다 — 중요한 것은 바이트 묶음과 순서뿐입니다.