저는 서버 클라이언트 아키텍처를 채택한 프로젝트를 진행하고 있습니다. 클라이언트와 서버간에 전송되는 메시지는 문자열과 바이트 배열의 조합입니다. 나는 전체 메시지의 크기를 미리 보내야합니다.소켓의 출력 스트림에 문자열 쓰기
바이트 배열의 바이트 크기를 찾는 것은 간단하지만 문자열에서는 그렇지 않습니다. 분명히, 나는 그 문자열들을 바이트 배열로 변환 할 수있다. 그러나이 문자열은 길어서 사본을위한 메모리를 할당하고 싶지 않습니다 (예 : getBytes()가 새 배열을 할당 함).
제 질문은 다음 중 가장 효율적인 메모리 사용 방법은 무엇입니까? 문자열
대하여 반복 문자열의 문자의 문자열을 작성
codePointAt()으로 전화하십시오. Codepoint range | UTF-8 bytes
-----------------------------
0 - 127 | 1
128 - 2047 | 2
2048 - 65535 | 3
65536 + | 4
을하지만 그렇게하기 전에이 정말 필요한 경우 먼저 확인해야합니다 : 코드 포인트에 따라 당신은 UTF-8로 인코딩 할 때 필요합니다 얼마나 많은 바이트 추론 할 수 있습니다. 어쨌든 소켓에 전달 된 String은 내부적으로 바이트 배열에 복사 될 가능성이 큽니다.
그 이유는 문자열을 일부 임시 입력 스트림에 쓰고 내가 작성한 바이트 수를 확인하고 그 임시 스트림을 소켓에 전달하는 방법을 찾고 있었던 이유입니다. 이 모든 것들이 물건을 복사하지 않고 일어난다면 ... 당신은 요점을 얻습니다. – mostruash
크기가 중요한 문제가 아닌 경우 문자열에 UTF16-BE 인코딩을 사용하십시오. 이 경우 크기는 문자열 길이 * 2가됩니다.
이 모드에서는 추가 처리 (유니 코드 하이 로우 사로 게이트 등)없이 Java 문자를 하나씩 작성할 수 있습니다.
+1 년 후에 답이 유용합니다. – mostruash
메시지를 패킷으로 항상 "끊을"수 있기 때문에 메시지의 일부분에 대한 계산 및 메모리 할당을 수행하고 다른 부분으로 반복하여 다시 수행 할 수 있습니다.
try DataOutputStream. javadoc 보이기 – andy
@andy 미리 쓰려고하는 문자열의 크기를 알 수 있습니까? – mostruash
얼마나 오래 "길다"며 실제로 복사에 필요한 공간/시간이 엄청 났음을 증명 했습니까? 'CharsetEncoder'를 사용하여이 작업을 수행하는 것이 타당 할 수도 있지만 (바이트 카운팅 부분은 비교적 간단합니다.)하지만 더 복잡한 작업을 수행하기 전에 가능한 가장 단순한 방법으로는 충분하지 않다는 것을 증명할 가치가 있다고 생각합니다. –