UTF-16 2 바이트 UTF-8은 1 바이트를 필요를 요구한다.
이것은 두 가지 경우 모두 잘못되었습니다. UTF-8 및 UTF-16은 모두 가변 길이 인코딩입니다. 실제로 UTF-16의 전신 인 UCS-2를 생각해 볼 수도 있습니다. UTF-16은 실제로 2 바이트 만 사용했습니다 (코드 포인트는 U + FFFF까지만 가능했습니다).
UTF-8은 코드 포인트 U + 0000 - U + 007F에 대해 1 바이트, 코드 포인트 U + 0080 - U + 07FF에 2 바이트, U + 0800 - U + FFFF에 대해 3 바이트 및 코드 포인트 U + 10000 - U + 10FFFF입니다.
UTF-16은 코드 포인트 U + 0000 - U + FFFF에 2 바이트를 사용하고 코드 포인트 U + 10000 - U + 10FFFF에 4 바이트를 사용합니다.
및 USB는 8 비트 지향이므로 UTF-8은 더 자연 스럽습니다.
아니요. 위에서 언급 한 바이트 크기를 고려하면 UTF-16은 실제로 UTF-8보다 적은 코드 단위로 더 많은 코드 포인트를 처리합니다. 그러나 USB는 사람이 읽을 수있는 텍스트 데이터보다 바이너리 데이터를 더 중요하게 생각합니다. 유니 코드 문자열에도 문자 수가 아닌 바이트 수가 접두사로 붙습니다. 따라서 USB 설계자는 표준화 된 방식으로 원하는 인코딩을 사용할 수있었습니다. 그들은 UTF-16LE를 선택했습니다.
왜? 디자이너에게 물어보십시오. 내 은이라고 추측합니다. Microsoft가 USB 1.0 사양을 공동 작성하고 Windows 용 Microsoft의 선택 인코딩 인 UCS-2 (현재 UTF-16LE)가 포함되어 있기 때문에 호환성을 유지하려고했을 가능성이 있습니다. 많은 런타임 전환. 당시 Windows는 PC 시장의 거의 90 %를 차지하고 있었지만 다른 운영 체제, 특히 * Nix는 5 % 밖에 없었습니다. Windows 98은 USB가 OS에서 직접 구워진 최초의 Windows 버전 이었지만 (USB는 Windows 95의 선택적인 추가 기능이었습니다), 그러나 그때조차도 USB는 이미 PC에서 인기를 얻고 있었고 결국 Apple은 몇 년 후에 iMac에 USB 지원을 추가했습니다 후에.
게다가 UTF-8은 상대적으로 새로운 것이 었습니다 (USB 1.0이 작성되었을 때 겨우 몇 년 전이었습니다). UCS-2는 잠시 동안 주변에 있었고 기본 유니 코드 인코딩이었습니다. 시간 (유니 코드는 몇 년 동안 65536 코드 포인트를 초과하지 않을 것입니다). UTF-8 대신에 UCS-2 (나중의 UTF-16LE)를 사용하여 USB가 국제 텍스트를 지원할 수있게 된 것 같습니다. 그들이 8 비트 인코딩을 대신 결정했다면 ISO-8859-1은 아마도 UTF-8보다 더 의미가 있었을 것입니다 (그러나 오늘날의 표준에 따르면 ISO-8859-1은 더 이상이를 잘라 내지 못합니다).그리고 Unicode가 UCS-2의 65536 코드 포인트 한계를 마침내 깨뜨렸을 때 이전 버전과의 호환성을 저해하지 않으면 서 인코딩을 다른 것으로 변경할 수 없었습니다. 최소한 UTF-16은 UCS-2와 하위 호환이 가능합니다 (Windows가 UTF-16을 사용하고 UTF-8로 전환하지 않는 이유는 다른 OS와 비슷합니다).
UTF-8은 ASCII와 역 호환되며 UTF-16은 ASCII와 호환되지 않습니다.
True.
UTF-16에는 2 바이트가 필요하므로 엔디안 문제가있을 수 있습니다.
True. UTF-32와 동일합니다.