- 상위 문서 : 특수 문자
U+FEFF. 유니코드 문자의 하나.
이름은 ZERO WIDTH NO-BREAK SPACE이나, 실제로는 공백의 일종으로 쓰이지는 않고 바이트 순서 마크(byte order mark, BOM)로 쓰인다. zero width non-breaking space의 역할은 U+2060 WORD JOINER가 대신한다.
이 문자는 UTF-16으로 된 파일의 엔디언[1]이 올바르게 판단될 수 있도록 하기 위해서 파일의 맨 앞에 삽입된다. UTF-16의 처리 방식에는 빅 엔디언과 리틀 엔디언이 있다. 예를 들어 가(U+AC00)은 빅 엔디언에서는 AC 00으로 저장되고 리틀 엔디언에서는 00 AC로 저장된다[2]. 이 AC 00이나 00 AC라는 바이트만으로는 프로그램이 엔디언을 판단할 수 없기에, 파일의 맨 앞에 이 문자를 삽입해서 프로그램이 엔디언을 판단할 수 있도록 도와준다. 즉 이 문자가 파일의 맨 앞에 삽입될 경우, 프로그램이 파일을 읽어들였을 때 첫 두 바이트가 FE FF이면 빅 엔디언, FF FE이면 리틀 엔디언임을 바로 판단할 수 있고, 파일을 올바르게 열 수 있다.
- FF FE 00 AC → (U+FEFF) U+AC00 → 가
- FE FF 00 AC → (U+FEFF) U+00AC → ¬
- FF FE AC 00 → (U+FEFF) U+00AC → ¬
- FE FF AC 00 → (U+FEFF) U+AC00 → 가
UTF-8의 경우 이런 엔디언 문제가 없는데도 일부 텍스트 에디터는 강제로 이 문자를 삽입해서 문제를 일으키기도 한다. 다만 2013년 현재까지도 유니코드 보급율이 낮다보니 일반 유저를 대상으로 하는 텍스트 에디터들의 경우 BOM이 없으면 일단 완성형(및 각 언어별 코드페이지)으로 읽고보는 식으로 처리하는 경우가 상당수. 그러다보니 UTF-8 문서에도 BOM을 넣어두는게 편한 게 사실이다. 사실 유니코드 처리에 제대로 신경쓰지 않는 에디터 제작자들이 문제지만...
그런데 이게 유닉스 쪽까지 포함한다면 얘기가 달라진다. PHP의 경우 읽어들이는 내용이 PHP 소스로 되어 있으면 PHP로 실행하기 시작하고, 그냥 텍스트 파일로 되어 있으면 텍스트로 읽어들이기 시작하는데 PHP는 BOM을 인식하지 못한다. 그래서 일반 텍스트로 알고 보냈는데 PHP가 시작되니 오작동을 일으키는 것. 이외에 콘솔에서 텍스트 파일 합치는 데도 애로사항이 생길 수 있는 등, 개발자 입장에서는 BOM을 자동으로 넣어주는 프로그램이 오히려 욕먹는다. 이런 경우 저장 시 BOM을 추가할지 말지 선택할 수 있는 텍스트 에디터로 문서를 저장해야 한다.
U+FFFE에는 문자가 배당되어 있지 않고 앞으로도 배당될 일이 없기 때문에 U+FFFE가 실제로 쓰일 일은 없고, 따라서 U+FEFF가 U+FFFE와 혼동될 여지는 없다.