웹에 대한 좋은 기사가 많이 있다고 생각하지만 여기에 간단한 요약이 있습니다.

UTF-8과 UTF-16은 모두 가변 길이 인코딩입니다. 그러나 UTF-8에서 문자는 최소 8 비트를 차지할 수 있지만 UTF-16에서 문자 길이는 16 비트로 시작합니다.

주요 UTF-8 전문가 :

• 숫자, 악센트가없는 라틴 문자 등과 같은 기본 ASCII 문자는 US-ASCII 표현과 동일한 1 바이트를 차지합니다. 이런 식으로 모든 US-ASCII 문자열이 유효한 UTF-8이되어 많은 경우에 하위 호환성을 제공합니다.
• null로 끝나지 않는 문자열을 사용할 수있는 null 바이트가 없으므로 이전 버전과의 호환성도 매우 뛰어납니다.
• UTF-8은 바이트 순서와 무관하므로 Big Endian / Little Endian 문제에 대해 걱정할 필요가 없습니다.

주요 UTF-8 단점 :

• 많은 공통 문자의 길이가 다르기 때문에 코드 포인트별로 인덱싱하고 코드 포인트 수를 계산하는 데 시간이 많이 걸립니다.
• 바이트 순서는 중요하지 않지만 때때로 UTF-8에는 텍스트가 UTF-8로 인코딩되었음을 알리고 ASCII 문자 만 포함하더라도 ASCII 소프트웨어와의 호환성을 손상시키는 BOM (바이트 순서 표시)이 여전히 있습니다 . 메모장과 같은 Microsoft 소프트웨어는 특히 UTF-8에 BOM을 추가하는 것을 좋아합니다.

주요 UTF-16 전문가 :

• 라틴어, 키릴 자모, 대부분의 중국어 (PRC가 BMP 이외의 일부 코드 포인트를 지원함)를 포함한 BMP (기본 다국어 평면) 문자, 대부분의 일본어는 2 바이트로 표현할 수 있습니다. 텍스트에 추가 문자가 포함 되지 않은 경우 색인 작성 및 코드 포인트 수를 빠르게합니다 .
• 텍스트에 보충 문자가 있어도 16 비트 값의 쌍으로 표시됩니다. 즉, 전체 길이는 여전히 2로 나눌 수 있으며 16 비트 char를 문자열의 기본 구성 요소로 사용할 수 있습니다 .

주요 UTF-16 단점 :

• US-ASCII 문자열에 널 바이트가 많으므로 널 (null)로 끝나는 문자열이없고 낭비되는 메모리가 많습니다.
• 고정 길이 인코딩으로 사용하면 많은 일반적인 시나리오 (특히 미국 / EU / 키릴 자모가있는 국가 / 이스라엘 / 아랍 국가 /이란 등)에서 “대부분 작동”하므로 종종 지원하지 않는 곳에서 지원이 중단됩니다. 이는 프로그래머가 서로 게이트 쌍을 인식하고 중요한 경우 올바르게 처리해야 함을 의미합니다!
• 가변 길이이므로 코드 포인트의 수를 계산하거나 인덱싱하는 데 비용이 많이 들지만 UTF-8보다 적습니다.

일반적으로 UTF-16은 BE / LE가 관련이없고 (기본 순서 만 사용) 인덱싱이 더 빠르기 때문에 (대리 쌍을 올바르게 처리하는 것을 잊지 마십시오) 일반적으로 인 메모리 표현에 더 좋습니다. 반면에 UTF-8은 BE / LE 문제가없고 널 종료가 종종 ASCII 호환뿐만 아니라 텍스트 파일 및 네트워크 프로토콜에 매우 유용합니다.

답변

static byte[] toBytes(String s){
        byte[] b=new byte[s.length()*2];
        ByteBuffer.wrap(b).asCharBuffer().put(s);
        return b;
    }