BOM (r20200302판)

문서 조회수 확인중...

1. 개요
2. 상세
3. Browser Object Model
4. Bill Of Material


1. 개요


U+FEFF.[1] 유니코드 문자의 하나.
이름은 ZERO WIDTH NO-BREAK SPACE이나, 실제로는 공백의 일종으로 쓰이지는 않고 바이트 순서 마크(byte order mark, BOM)로 쓰인다. zero width non-breaking space의 역할은 U+2060 WORD JOINER가 대신한다. 그리고 아랍 문자용 블럭인 Arabic Presentation Forms-B에 끼어 있다.

2. 상세


이 문자는 UTF-16으로 된 파일의 엔디언[2]이 올바르게 판단될 수 있도록 하기 위해서 파일의 맨 앞에 삽입된다. UTF-16의 처리 방식에는 빅 엔디언과 리틀 엔디언이 있다. 예를 들어 가(U+AC00)은 빅 엔디언에서는
AC 00
으로 저장되고 리틀 엔디언에서는
00 AC
로 저장된다.[3]
AC 00
이나
00 AC
라는 바이트만으로는 프로그램이 엔디언을 판단할 수 없기에, 파일의 맨 앞에 이 문자를 삽입해서 프로그램이 엔디언을 판단할 수 있도록 도와준다. 즉 이 문자가 파일의 맨 앞에 삽입될 경우, 프로그램이 파일을 읽어들였을 때 첫 두 바이트가
FE FF
이면 빅 엔디언,
FF FE
이면 리틀 엔디언임을 바로 판단할 수 있고, 파일을 올바르게 열 수 있다.
  • FF FE 00 AC
    → (U+FEFF) U+AC00 → 가
  • FE FF 00 AC
    → (U+FEFF) U+00AC → ¬[4]
  • FF FE AC 00
    → (U+FEFF) U+00AC → ¬
  • FE FF AC 00
    → (U+FEFF) U+AC00 → 가
UTF-8의 경우 이런 엔디언 문제가 없는데도 일부 텍스트 에디터는 강제로 이 문자를 삽입해서 문제를 일으키기도 한다. 다만 유니코드 보급율이 느리다보니 일반 유저를 대상으로 하는 텍스트 에디터들의 경우 BOM이 없으면 일단 완성형(및 각 언어별 코드페이지)으로 읽고보는 식으로 처리하는 경우가 상당수. 그러다보니 UTF-8 문서에도 BOM을 넣어두는게 편한 게 사실이다. 사실 유니코드 처리에 제대로 신경쓰지 않는 에디터 제작자들이 문제긴 하지만. UTF-8에서 BOM은
EF BB BF
와 같이 표기된다.
그런데 이게 유닉스 쪽까지 포함한다면 얘기가 달라진다. PHP의 경우 읽어들이는 내용이 PHP 소스로 되어 있으면 PHP로 실행하기 시작하고, 일반 텍스트로 되어 있으면 텍스트로 읽어들이기 시작하는데 PHP는 BOM을 인식하지 못한다. 그래서 일반 텍스트로 알고 보냈는데 PHP가 시작되니 오작동을 일으키는 것. 이외에 콘솔에서 텍스트 파일 합치는 데도 애로사항이 생길 수 있는 등, 개발자 입장에서는 BOM을 자동으로 넣어주는 프로그램이 오히려 욕먹는다. 이런 경우 저장 시 BOM을 추가할지 말지 선택할 수 있는 에디터 또는 IDE로 문서를 저장해야 한다. Notepad++, IntelliJ IDEA, Visual Studio Code, EditPlus 등의 개발 툴은 UTF-8에 BOM을 추가할지 여부를 선택할 수 있다.
대표적으로 BOM을 자동 삽입하는 텍스트 에디터가 Microsoft Windows의 보조 프로그램인 메모장#s-2이다. Windows 쪽 에디터 프로그램들은 BOM이 없으면 UTF-8이라는 것을 인식하지 못하는 경우가 종종 발생한다. 다만 Windows 10 19H1 빌드에서 기본 인코딩이 기존의 ANSI(=MBCS)에서 BOM 없는 UTF-8으로 바뀌었으며, 저장 시에 BOM을 붙일지 선택할 수 있게 바뀌었다. 비주얼 스튜디오에서는 소스 파일의 인코딩을 UTF-8 BOM으로 설정하면 한글이 정상 출력되지만, UTF-8으로 설정하면 파일을 ANSI로 인식해 에디터와 콘솔에서 한글이 전부 깨진 채로 나온다. 윈도우에서 한글을 출력시키기 위해 UTF-8에 BOM을 붙여 저장한 파일의 경우, 유닉스 계통 컴파일러(GCC, LLVM/Clang 등)와 공유해서 사용하면 BOM의 존재로 인하여 오작동을 일으킬 수도 있다.
U+FFFE에는 문자가 배당되어 있지 않고 앞으로도 배당될 일이 없기 때문에 U+FFFE가 실제로 쓰일 일은 없고, 따라서 U+FEFF가 U+FFFE와 혼동될 여지는 없다.

3. Browser Object Model


자바스크립트에서 브라우저 관련 기능을 조작할 수 있게 만든 객체 모델. window라는 객체로 접근하여 사용할 수 있다.


4. Bill Of Material


구매해야될 부품등을 하나로 모아놓은 주문 명세서.
주로 전자쪽에서 쓰이는 말이며 제품을 제작할때 이에 필요한 부속품등의 데이터를 하나의 파일로 모아서 만들어놓은것을 BOM이라고 한다. 회로 설계 단계에서 부품을 지정해 놓으면 ECAD쪽에서 BOM에 필요한 부품의 이름을 기록해 놓으며 후에 이 BOM을 들고 부품사이트에 가서 주문가능한 부품이 있나 확인후 최종주문을 하게된다.
[1] 인코딩 방식에 따라서 FF FE로 표기하기도 하나, 실제로 해석할 때에는 U+FEFF로 읽힌다. 따라서 U+FFFE라는 문자는 존재하지 않는다.[2] 프로그래밍에서 메모리 등의 1차원 공간에서 데이터를 어떻게 배열하는지의 방식. 걸리버 여행기소인국에서 "계란를 어느 쪽으로 깨먹는가?" 라는 논쟁으로 전쟁까지 벌이게 된 것에서 명칭이 유래되었다.[3] 이렇게 방식이 나뉘는 것은 두 방식 다 나름의 장점이 있기 때문이다. 한국어 위키백과엔디언 문서 참고.[4] not sign. 명제에서 부정을 나타내는 기호이다. 키보드로 입력할 수 없는 기호이기 때문에 보통 물결 기호(~) 혹은 느낌표(!)를 대신 사용한다.