BOM이 없는 utf-8과 utf-8의 차이점

BOM——바이트 순서 표시인 Byte Order Mark

UCS 인코딩에는 "ZERO WIDTH NO-break SPACE"라는 문자가 있는데, 인코딩은 FEFF입니다. FFFE는 UCS에 존재하지 않는 문자이므로 실제 전송에서는 나타나지 않아야 한다. UCS 사양에서는 바이트 스트림을 전송하기 전에 "ZERO WIDTH NO-break SPACE" 문자를 전송할 것을 권장합니다. 이런 식으로 수신기가 FEFF를 수신하면 바이트 스트림이 Big-Endian임을 나타내고, FFFE를 수신하면 바이트 스트림이 Little-Endian임을 나타냅니다. 따라서 "ZERO WIDTH NO-break SPACE" 문자를 BOM이라고도 합니다.

UTF-8에서는 바이트 순서를 나타내기 위해 BOM이 필요하지 않지만 BOM을 사용하여 인코딩 방법을 나타낼 수 있습니다. "ZERO WIDTH NO-break SPACE" 문자의 UTF-8 인코딩은 EF BB BF입니다. 따라서 수신기가 EF BB BF로 시작하는 바이트 스트림을 수신하면 해당 스트림이 UTF-8로 인코딩되었음을 알 수 있습니다.

UTF-8로 인코딩된 파일에서 BOM은 3바이트를 차지합니다. 메모장을 사용하여 텍스트 파일을 UTF-8 인코딩으로 저장하고 UE로 파일을 열고 16진수 편집 모드로 전환하면 처음에 FFFE를 볼 수 있습니다. 이는 UTF-8로 인코딩된 파일을 식별하는 좋은 방법입니다. 소프트웨어는 BOM을 사용하여 파일이 UTF-8로 인코딩되었는지 여부를 식별합니다. 또한 많은 소프트웨어에서는 읽기 파일에 BOM이 있어야 합니다. 하지만 아직도 BOM을 인식하지 못하는 소프트웨어가 많습니다.

Firefox 초기 버전에서는 확장 프로그램에 BOM이 없었으나, Firefox 1.5 이후 버전부터 BOM을 지원하기 시작했습니다. 이제 나는 PHP도 BOM을 지원하지 않는다는 것을 발견했습니다. PHP는 설계 시 BOM 문제를 고려하지 않았습니다. 즉, UTF-8로 인코딩된 파일 시작 부분에 있는 BOM의 세 문자를 무시하지 않는다는 의미입니다.

보블로그 위키에서 꼭 봐야하기 때문에 역시 PHP를 사용하는 보블로그도 BOM 때문에 고민이 됩니다. 또 다른 문제는 다음과 같습니다. "COOKIE 전송 메커니즘의 제한으로, 파일 시작 부분에 이미 BOM이 있는 파일에서는 COOKIE를 보낼 수 없습니다(COOKIE가 전송되기 전에 PHP가 이미 파일 헤더를 보냈기 때문입니다). 로그인 및 로그아웃 기능이 유효하지 않습니다. COOKIE 및 SESSION에 의존하는 모든 기능이 유효하지 않습니다. "실행된 파일에는 BOM이 포함되어 있으며 이 세 문자가 전송되므로 WordPress 배경에 빈 페이지가 나타나는 이유입니다. 쿠키에 대한 의존성과 세션 기능이 유효하지 않습니다.

해결 방법은 파일에 영어 문자(또는 ASCII 인코딩 문자)만 포함된 경우 파일을 ASCII 코드로 저장하는 것입니다. UE와 같은 편집기를 사용하는 경우 파일->변환->UTF-8을 ASCII로 클릭하거나 다른 이름으로 저장에서 ASCII 인코딩을 선택합니다. DOS 형식으로 끝나는 줄인 경우 메모장으로 열고 다른 이름으로 저장을 클릭한 다음 ASCII 인코딩을 선택하면 됩니다. 중국어 문자가 포함된 경우 UE의 다른 이름으로 저장 기능을 사용하고 "BOM 없는 UTF-8"을 선택할 수 있습니다.

UTF-8은 애초에 BOM을 추가해서는 안 됩니다. 편집자에게 UTF-8임을 알리는 것 외에는 아무 소용이 없습니다. 실제로 편집기는 많지 않은 인코딩 형식 중 특성을 기반으로 파일의 인코딩을 완벽하게 판단할 수 있습니다. 자동으로 인식할 수 없더라도 편집기에는 인코딩을 설정할 수 있는 장소가 있어야 합니다. 그래서 BOM은 utf-8에 중복된다고 생각합니다.

UTF-16에는 BOM만 추가하면 됩니다. 유니코드 순서로 인코딩되고 BMP 범위의 2바이트이므로 빅 엔디안 또는 리틀 엔디안으로 식별되어야 합니다.

사실 UTF-8이 크고 작은 엔디안이라는 개념을 도입하는 것은 너무 어리석은 일이라고 생각합니다. 그 표준 위원회에서는 어떻게 생각하는지 모르겠습니다. 크고 작은 엔디안의 존재 의미는 CPU의 처리 방식에 있습니다. CPU가 빅엔디안을 처리한다면 리틀엔디안의 경우 변환 레이어를 수행해야 하므로 효율성이 저하됩니다. 그러나 실제 애플리케이션에서 누가 엔디안을 신경쓰나요? 텍스트 인코딩은 바이트 순서 개념을 가져옵니다. 표준을 만드는 사람들은 너무 엄격하다고 말할 수 있습니다. UTF-16의 경우 전 세계가 바이트 순서 방식을 따르는 한 이를 표시하기 위해 BOM을 사용할 필요는 없다고 생각합니다.

그러나 PHP는 UTF-16으로 인코딩된 파일을 지원하지 않습니다. 예를 들어 $ 기호도 UTF-8의 2바이트이므로 PHP 디코더로 구문 분석할 수 없습니다. 내부 처리에 유니코드 개념이 도입된 이후 PHP6에서 이를 지원할지는 모르겠습니다.

코딩 문제는 간단해 보이지만 실제로는 매우 복잡합니다. 많은 프로그램에는 계층적 코딩이라는 개념이 있습니다. MySQL과 마찬가지로 클라이언트->연결->스토리지, 스토리지->연결->결과 등의 개념으로 나누어진다. 스토리지는 시스템, 데이터베이스, 테이블, 컬럼으로 구분됩니다. 가끔 이렇게 복잡하게 만들 필요가 있을까, TNND라는 생각이 들 때가 있어요. MySQL처럼 누가 그 기능을 사용합니까? 두 클라이언트가 서로 다른 인코딩 환경에서 작동하도록 허용되지 않는 한 클라이언트 인코딩을 분리할 필요가 없습니다. 대부분의 경우 바이너리 입력/바이너리 출력

위 내용은 관련 내용을 포함하여 utf-8과 BOM이 없는 utf-8의 차이점을 소개합니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.