내가 알아 내지 못하는 문제가 발생했습니다. 문제의 정의는 다음과 같습니다. Db2/Linux 환경에서 BLOB 열에 데이터가 있습니다. Blob은 JDK 압축 (Linux 환경에서 실행되는 코드)을 사용하여 바이트 []가 압축 된 후에 DB2에 기록되었습니다. 이 데이터 중 일부를 읽으려면 (JDK 사용) 압축을 풀고 Windows 환경 (내 개발 환경)의 압축 해제 된 바이트 배열에서 String을 만드는 간단한 프로그램을 작성하려고합니다. 문제는 Blob (byte [])을 압축 해제 한 후 압축 해제 된 바이트 배열의 길이가 예상보다 일반적으로 1-3 바이트 길다는 것입니다. 예상 한대로 오프셋 및 길이 필드도 데이터베이스에 저장됩니다. 따라서이 경우 압축 해제 된 바이트 배열의 길이는 대개 데이터베이스에 저장된 길이보다 길며 단지 몇 바이트에 불과합니다. 따라서 압축 해제 된 바이트 배열에서 String 객체를 만들고 데이터베이스의 오프셋 및 길이 필드를 사용하여 substring (offset, length) 메서드를 사용하여 다른 String 객체를 만드는 경우 두 번째 String (substring 메서드를 사용하여 얻은 문자열)은 다음과 같습니다. 짧아.문제 Java에서 바이트 [|]이 팽창합니까?
예제는 다음과 같습니다 블롭 압축 해제 후 260,409 - 다른 입력 레코드를 들어
compressedByte[].length - 71,212
decompressedByte[].length - 260,412
new String(decompressByte[]).length() - 260,412
new String(decompressByte[]).subString(0, 260,409).length() - 260409
, 내가보고하고 차이가 사이에 어느 곳입니다 : 0, 길이 : 데이터베이스 레코드 오프셋, 블롭을 포함 1-3 바이트 길이.
저는이 문제에 의아해하고 있습니다. 누군가이 팁을 제안 할 수 있는지 궁금해하기 때문에이 문제를 해결하기 위해 더 많은 디버깅을 할 수 있습니다. 나는 이것이 어떻게 바이트가 리눅스 환경에서 저장되고 쓰여지는지와 어떻게 관계가있을 수 있는지 그리고 어떻게 그들이 윈도우에서 읽혀지고 있는지 궁금하다. 당신의 도움을 주셔서 감사합니다.
+1 Joels 기사를 언급합니다. – Daniel
그래, 이건 다르게 인코딩 된거야. 귀하의 답변에 감사드립니다. 새로운 String (byte [], "UTF-8")을 사용하여 문제가 해결되었습니다. 나는 오늘 그 기사를 읽을 것입니다 - 거기에 좋은 정보가 많이있는 것처럼 보입니다. 너무 평판이 나지 않아서이 답변을 투표 할 수 없습니다. – John
자신 만의 질문에 upvote 수 있습니다 (나는 생각합니다) 또한 큰 대답을이 대답을 허용 대답으로 표시 할 수 있습니다. Joels artical은 총 금과 기본적으로 필요한 독서입니다. –