헥스 덤프
텍스트나 파일을 바이트 오프셋, 16진수 바이트, ASCII 거터가 있는 xxd 스타일 헥스 덤프로 변환하고 다시 바이트로 되돌립니다 — 100% 브라우저에서 실행되며 업로드되지 않습니다.
00000000 ec 95 88 eb 85 95 ed 95 98 ec 84 b8 ec 9a 94 2c |...............,| 00000010 20 ec 84 b8 ea b3 84 21 20 f0 9f 94 92 | ......! ....|
🔒 브라우저에서 처리되며 업로드되지 않습니다.
오프셋·16진수 쌍·ASCII 거터
헥스 덤프는 입력하거나 붙여넣은 텍스트, 또는 열어 놓은 파일을 고전적인 16진수 덤프로 변환합니다. xxd나 hexdump -C 같은 명령줄 도구에서 보던 것과 같은 형식입니다. 각 행에는 8자리 16진수 바이트 오프셋이 있고, 이어서 그 행의 바이트가 8개씩 묶인 16진수 쌍으로 표시되며, 마지막에 | 막대 사이의 ASCII 거터가 나옵니다. 한 행은 기본 16바이트이고 1바이트부터 원하는 너비로 바꿀 수 있어, 4바이트 행은 구조체를 맞춰 보기 좋고 24바이트 행은 터미널을 채웁니다. 16진수는 기본이 소문자이며 대문자 16진수를 켜면 오프셋 열까지 함께 대문자가 됩니다. 표시 가능한 문자(바이트 32–126)는 그대로 보이고, 제어 코드나 여러 바이트 문자를 포함한 그 외의 바이트는 점으로 표시됩니다. 미리보기 문자로 이 범위를 넓힐 수 있습니다. 기본값 ASCII는 방금 설명한 그대로이고, Latin-1로 바꾸면 바이트 160~255도 é·ÿ 같은 Latin-1 글자로 찍혀 CP-1252나 ISO-8859 파일이 점의 벽 대신 읽히는 글로 나옵니다. 제어 바이트와 소프트 하이픈은 두 설정 모두 점으로 남습니다. 마지막 길이 줄을 켜면 xxd와 hexdump가 마지막에 찍는, 전체 길이를 담은 오프셋 줄이 한 줄 더 붙습니다. 덤프는 편집하는 즉시 갱신됩니다.
바이트를 세는 방식
입력한 텍스트는 덤프하기 전에 UTF-8로 인코딩됩니다. 따라서 일반 알파벳은 1바이트이고, 악센트가 있는 글자, 이모지, 한글·한자 같은 문자는 2~4바이트를 차지합니다. 즉 여기서 보는 16진수는 프로그램이 UTF-8 파일에서 읽어 들이는 바이트와 정확히 같습니다. 숨은 문자를 찾거나, 인코딩을 확인하거나, 보이지 않는 공백을 살펴보거나, 텍스트가 실제 바이트로 어떻게 대응되는지 배우는 데 유용합니다. 반면 파일을 열면 인코딩 과정 없이 디스크에 있는 원본 바이트가 그대로 덤프되므로, PNG나 컴파일된 클래스 파일, 펌웨어 이미지도 그 자체로 덤프됩니다.
자주 묻는 질문
바이트를 만들 때 어떤 인코딩을 사용하나요?
입력한 텍스트는 UTF-8입니다. 브라우저의 TextEncoder로 인코딩하므로 ASCII 문자는 1바이트, é·€·한 같은 문자는 각각 2~4바이트를 차지합니다. UTF-8 파일에서 찾을 수 있는 바이트와 동일합니다. 파일을 열면 인코딩 단계 없이 바이트 그대로 덤프됩니다.
바이너리 파일도 덤프하고 다시 되돌릴 수 있나요?
양방향 모두 됩니다. PNG·클래스 파일·ELF 바이너리 등 어떤 파일이든 열면 원본 바이트가 덤프됩니다. 덤프를 디코딩에 붙여넣으면 바이트가 그대로 돌아오며, 텍스트라면 화면에서 읽을 수 있고 텍스트가 아니라면 다운로드가 대체 문자가 아닌 원본 바이트 그대로 파일에 저장합니다.
왜 어떤 문자는 ASCII 열에서 점으로 표시되나요?
기본 설정에서는 거터가 표시 가능한 범위인 바이트 32부터 126까지만 출력합니다. 미리보기 문자를 Latin-1로 바꾸면 바이트 160부터 255까지도 함께 출력됩니다. 줄바꿈이나 탭 같은 제어 코드, 그리고 여러 바이트 문자의 나머지 바이트는 표시할 글자가 없어 열 정렬을 유지하기 위해 '.'으로 표시됩니다.
입력한 텍스트가 서버로 업로드되나요?
아니요. 헥스 덤프는 전적으로 브라우저 안에서 자바스크립트로 생성됩니다. 입력한 내용은 전송·저장·업로드되지 않습니다.