Hex Dump 뷰어

브라우저 hex 덤프 렌더링은 수십 KB 빠르지만 1 MB 넘으면 느려짐. 64 KB 제한으로 UI 응답성 유지 — 더 큰 파일은 커맨드라인 xxd 사용.

UTF-8. é 같은 문자는 2바이트(C3 A9)·ASCII 문자는 1바이트. 특정 인코딩 필요 시 미리 인코딩된 바이트를 파일로 업로드.

xxd 관례 — 인쇄 가능 ASCII 범위(0x20–0x7E) 밖 바이트는 .로 정렬 가독성 유지. hex 열은 정확한 바이트 표시.

아니요. FileReader API로 읽고 브라우저 내에서 덤프 계산.

확장자가 무엇이라고 주장하든 대개 실제 파일 형식을 알 수 있습니다. PNG는 89 50 4E 47 0D 0A 1A 0A로 시작하고 오른쪽 칸에 .PNG가 보입니다. PDF는 25 50 44 46 2D로 %PDF-로 읽힙니다. ZIP 위에 세워진 것들, 즉 .docx, .xlsx, .jar, .apk는 모두 50 4B 03 04로 시작해 PK가 보입니다. JPEG는 FF D8 FF, WAV는 52 49 46 46으로 RIFF, 마트로스카와 WebM은 1A 45 DF A3으로 시작합니다. 헤더가 확장자와 어긋나는 파일은 변환된 것이 아니라 이름만 바뀐 것입니다.

거의 언제나 볼 수 있고, 원인은 늘 같은 세 바이트입니다. 오프셋 0의 EF BB BF는 UTF-8 바이트 순서 표시(BOM)입니다. 어떤 텍스트 편집기에서도 보이지 않지만, 이를 건너뛰도록 지시받지 못한 파서는 첫 키나 첫 열 제목의 일부로 읽습니다. 오류 메시지가 아무 문제 없어 보이는 필드 이름을 가리키는 이유가 이것입니다. 오프셋 0이 FF FE나 FE FF라면 그 파일은 UTF-8이 아니라 UTF-16이고, 덤프에서 아스키 글자마다 사이에 00이 끼어 있는 것이 보일 것입니다.