CONCLUSION

본문이 같은 두 CSV 중 BOM 표본은 정확히 3바이트 더 컸고 SHA-256이 달랐습니다. UTF-8 BOM은 텍스트 내용이 아니라 인코딩 힌트이지만 바이트 비교에서는 파일 일부입니다.

확인 방법

  1. name,city와 지유,서울 두 행을 UTF-8 CSV로 만들었습니다.
  2. 두 번째 파일의 맨 앞에 UTF-8 BOM 바이트 EF BB BF만 추가했습니다.
  3. wc와 shasum으로 크기와 SHA-256을 비교했습니다.

측정값은 정확히 3바이트 차이였다

BOM 없는 plain.csv는 24바이트, BOM을 붙인 bom.csv는 27바이트였습니다. SHA-256 앞 8자리는 각각 b35d6eae와 fd1cd11a로 달라졌습니다.

BOM 이후의 CSV 본문 바이트는 같았습니다. 프로그램이 BOM을 인코딩 표식으로 처리하면 화면의 셀 값도 동일하지만, 모든 파서가 같은 방식으로 처리한다고 가정해서는 안 됩니다.

UTF-8 BOM 유무에 따른 CSV 차이
표본시작 바이트크기SHA-256 앞 8자리
plain.csv6E 61 6D…24 Bb35d6eae
bom.csvEF BB BF 6E…27 Bfd1cd11a

UTF-8에서 BOM은 바이트 순서를 정하지 않는다

Unicode Consortium 설명에 따르면 UTF-8의 BOM은 바이트 순서 표시가 아니라 UTF-8임을 알리는 서명으로 사용됩니다. 상위 프로토콜에 따라 허용되거나 금지될 수 있으므로 무조건 붙이는 규칙은 안전하지 않습니다.

내보내기 전에 수신 프로그램을 정한다

CSV는 인코딩을 자체 선언하는 공통 헤더가 없습니다. 전달 대상이 Excel인지 데이터베이스 적재기인지, 업로드 API인지 확인하고 BOM 유무와 구분자, 줄바꿈을 함께 정해야 합니다.

  • 원본 UTF-8 파일 보존
  • 수신 프로그램에서 한글 왕복 확인
  • BOM 추가본은 별도 파일로 구분
  • 해시 기록 시 BOM 정책도 함께 기록

확인한 1차 자료

작성·검수

파일 처리 실험을 직접 재현하고, 측정값과 해석의 경계를 검수합니다. 전문 감정이나 법률 판단을 대신하지 않습니다.