CSV 파일의 한글이 깨지는 문제를 고쳐도 상품코드 ‘00123’의 앞자리 0은 사라질 수 있다. 문자를 읽는 인코딩을 맞춘 뒤에도 코드 열을 숫자와 문자 중 무엇으로 다룰지 정해야 한다. BOM이 붙은 UTF-8 파일이라고 해서 상품코드 열에 ‘문자’라는 속성이 저장되는 것은 아니다.
같은 가상 상품 목록을 UTF-8, BOM을 붙인 UTF-8, CP949로 각각 저장해 비교했다. 사람의 이름·연락처나 실제 주문정보는 넣지 않았다. 올바른 인코딩으로 읽고 CSV 형식으로 나누면 세 파일 모두 같은 문자열을 돌려줬다. 이번 비교는 파일의 바이트와 문자열 검사이며 Excel의 실제 실행 결과는 포함하지 않는다.
99바이트 파일은 96바이트 파일 앞에 표식만 더했다
예제의 UTF-8 파일은 96바이트, BOM 포함 파일은 99바이트였다. 뒤의 파일에서 맨 앞 세 바이트 EF BB BF를 제외한 나머지는 96바이트 파일과 완전히 같았다. 상품코드 ‘00123’과 우편번호 ‘04524’도 두 파일에 그대로 있었다. CP949 파일은 같은 내용을 77바이트로 저장했다. 이 크기는 이번 예제의 측정값이며 모든 CSV의 용량 비율을 뜻하지 않는다.
Microsoft의 UTF-8 CSV 안내는 BOM이 있으면 UTF-8 CSV를 정상적으로 열 수 있다고 설명한다. BOM이 없을 때는 데이터 가져오기의 텍스트/CSV 경로나 텍스트 가져오기 마법사를 안내한다. 한글이 깨진다고 해서 원본 파일의 글자까지 이미 파괴됐다고 단정할 수는 없다.
직접 대조할 예제 파일: UTF-8 96바이트 · UTF-8 BOM 99바이트 · CP949 77바이트. 세 파일은 인코딩만 다르며, 아래 시연도 같은 바이트를 브라우저 안에서 읽는다.
같은 파일을 다르게 읽어 보기
제공한 가상 예제만 사용하는 시연이다. 파일을 올리는 기능은 없다. 숫자 선택은 JavaScript 변환 예시이며 Excel의 실제 가져오기 화면을 재현하지 않는다.
시연을 준비하고 있습니다. 스크립트가 꺼져 있어도 위 설명과 예제 파일은 이용할 수 있습니다.
Excel에서 가져올 때는 코드 열을 텍스트로 지정한다
Windows 데스크톱 Excel을 기준으로, 빈 통합 문서의 ‘데이터 → 텍스트/CSV에서’를 사용한다. 미리보기에서 원본에 맞는 인코딩과 쉼표 구분을 확인한 뒤, ‘데이터 변환’으로 들어가 상품코드·우편번호 열을 텍스트로 다룬다. 메뉴 이름은 버전·환경에 따라 다를 수 있다.
Microsoft의 앞자리 0 보존 안내도 가져오기 과정에서 열을 텍스트로 지정하는 방법을 설명한다. Power Query의 자동 형식 감지로 ‘변경된 유형’ 단계가 값을 숫자로 바꿨다면, 0이 남아 있는 원본 단계에서 형식 추론을 고치거나 그 자동 단계를 제거한 뒤 텍스트로 지정해야 한다. 123이 된 값의 표시 형식만 나중에 텍스트로 바꿔서는 원래 코드가 00123인지 000123인지 알 수 없다.
최근 Excel의 ‘자동 데이터 변환’ 옵션은 앞자리 0 제거와 긴 숫자 처리 등을 조절한다. 옵션의 적용 범위와 내 버전의 메뉴 존재 여부를 확인해야 한다. 모든 PC가 같은 설정이라고 가정해 CSV를 배포하기보다는, 수신자에게 해당 열을 텍스트로 불러오도록 알려 주는 편이 분명하다.
저장된 파일의 0이나 한글까지 바뀌었다면 다시 받은 원본이나 백업과 대조해야 한다. BOM을 추가해도 이미 잃은 값은 복구되지 않는다. 확장자만 바꾸는 것도 인코딩 변환이 아니다. 이는 PNG 사진의 이름만 JPG로 바꿔도 내부 데이터가 그대로인 사례와 같은 구분이다.
비밀번호나 고객 명단이 담긴 CSV는 공개 변환 사이트에 올려 시험하지 않는다. 특히 크롬에서 내보낸 비밀번호 CSV는 평문 내용의 취급과 삭제까지 따로 관리해야 한다.