본문 바로가기
SQL(DB)

UTF-8과 UTF-8(BOM)의 차이는?

by 즐코딩 2023. 8. 22.
반응형

UTF-8과 UTF-8(BOM)의 차이는?

 

지난 번 Heidi SQL을사용하여, CSV 파일로 DB 밀어넣기를 하는 과정을 정리해보았습니다.

일주일 정도 시간도 좀 흘렀겠다, 까먹기 전에 복습도 할겸 기억을 다시 소환해봅니다.

 

 

엑셀에서 CSV파일로 저장하는 방식은 2가지

 

엑셀에서 아래와 같은 Table 테이터를 CSV파일로 저장하려 하는데, 가만 살펴보니

 

Excel에서 CSV를 저장하는 데에는 아래와 같은 2가지 선택항목이 있습니다.

 

'CSV UTF-8(쉼표로 분리)'와 'CSV (쉼표로 분리)'의 차이는?

궁금하면 일단 해보는 거죠 뭐.

 

각각 파일을 저장한 후 메모장에서 열어보았더니, 대략 이런 차이를 보입니다.

 

 

그렇다면, 이제 확인 할 부분은 UTF-8(BOM)과 그냥 UFT-8의 차이점을 확인하는 것이겠죠?

 

 

UTF-8(BOM)과 그냥 UFT-8의 차이 ?

 

일반적인 사용자라면, 이 두 가지 형식에 대한 구분을 굳이 할 필요는 없을테지만, 즐코더라면 궁금한 건 못 참지...

 

BOM = Byte Order Mark

 

BOM이란 글자를 처음 보았을 때는, BOMB(폭탄)이 연상되어 괜히 무서웠지만, 컴퓨터는 깡통인데 무서울 게 뭐 있겠습니까? BOM은 Byte Order Mark의 약자로서 유니코드 문자 U+FEFF를 문서 가장 앞에 추가하여 해당 문서를 읽어 들이는 프로그램에 정보를 전달하는 방식이라고 합니다.

 

솔직히 아래 링크의 위키백과 내용을 읽어봐도, 통 무슨 소리인지 저는 잘 모르겠습니다.

https://ko.wikipedia.org/wiki/%EB%B0%94%EC%9D%B4%ED%8A%B8_%EC%88%9C%EC%84%9C_%ED%91%9C%EC%8B%9D

 

바이트 순서 표식 - 위키백과, 우리 모두의 백과사전

위키백과, 우리 모두의 백과사전. 바이트 순서 표시(Byte Order Mark, BOM)는 유니코드 문자 U+FEFF byte order mark로, 매직 넘버로서 문서의 가장 앞에 추가하여 텍스트를 읽는 프로그램에 여러 정보를 전

ko.wikipedia.org

 

아무튼, 원리를 요약하자면 각 문서 마다 사용하는 인코딩 방식이 다를 수 있으니, 문서를 읽어들일 때 인코딩 방식을 미리 파악하기 위한 목적으로 만들어진 방식이 UTF-8(BOM) 방식이라고 간단하게 이해해두면 될듯합니다.

 

방법 중 눈여겨볼 부분은 바로 문서 맨 앞에 '눈에 보이지 않는 특정 바이트를 넣는다'는 것입니다.

 

 

코딩 초보자라면?

 

일단 요 정도 개념으로 이해를 하고 넘어가면 되겠습니다.

 

유니코드는 Big Endian, Little Endian 등의 인코딩 방식이 존재한다.

원 리틀 인디안, 투 리틀 인디안... 으로 대충 개념을 머릿속에 남겨 두자.

 

 

학구파 코딩 초보자라면?

아래 개념을 추가로 더 이해해 두면 좋을듯합니다.

 

BOM은 아래와 같은 종류가 존재한다고 합니다.

인코딩 방식 BOM (Byte Order Mark)
UTF-8 EF BB BF
UTF-16 Big Endian FE FF
UTF-16 Little Endian FF FE
UTF-32 Big Endian 00 00 FE FF
UTF-32 Little Endian FF FE 00 00

 

재미있는 점은, UTF-16 이상인 경우에만 Big이냐 Little이냐에 따라 BOM이 존재합니다.

달리 말하면, UTF-8은 BOM이 1개로 고정되어 있습니다.

 

 

BOM의 문제점

 

일단 필요하니까, 규약을 정해서 BOM 형식을 만들었을텐데 일반인들의 상황보다 개발을 하는 사람 입장에서 곤란한 지점을 만들곤 합니다. 

 

UTF-8에는 BOM이 없는 것이 일반적입니다. 왜냐하면 UTF-8은 BOM이 1가지로 고정이라 인코딩 방식을 바로 알 수 있기 때문입니다. 그런데 윈도우 프로그램의 메모장 같은 것들은 UTF-8 파일을 생성할 때 자동으로 BOM을 꼬박꼬박 집어넣어줍니다. 어떻게 보면 윈도우는 규칙을 잘 따르는 범생인 셈이죠.

그런데 이게, 윈도우 환경 안에서는 별 탈없이 잘 돌아가지만, LINUX나 UNIX 계열의 환경으로 Data가 전달 될 때에는 많은 문제를 일으키는 원인이 되기도 합니다. BOM이 추가되면 글자 앞에 빈칸이 생기면서 구분을 하게 되는데 이러한 형태가  대개는 사람의 입장에서 눈으로 확인이 어렵다는 점이 있습니다.

 

 

마치며

 

이처럼 눈에 보이지 않는 정보로 인해 DB에서도 자주 문제가 발생하기도 하는데, BOM이 추가된 데이터와 BOM이 없는 UTF-8 인코딩 데이터를 비교하는 경우 사람의 눈에는 동일한 데이터로 보이지만, 비교연산을 해보면 컴퓨터는 서로 다른 데이터로 인식을 하기 때문임을 알 수 있는 기회가 되었습니다.


당연하게도 이는 문자열 앞에 눈에 보이지 않는 약 2~3 바이트의 BOM(Byte Order Mark)이 붙어있기 때문입니다.

무더운 여름에 BOM을 만나게 되었지만, 이참에 궁금증이 일어, 정리를 한번 하고 넘어가는 기회가 되었습니다.

 

오늘도 즐거운 코딩, 즐코딩.

KINcoding.

 

반응형

댓글