2011-01-06 3 views
2

내가 알아 내지 못하는 문제가 발생했습니다. 문제의 정의는 다음과 같습니다. 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 바이트 길이.

저는이 문제에 의아해하고 있습니다. 누군가이 팁을 제안 할 수 있는지 궁금해하기 때문에이 문제를 해결하기 위해 더 많은 디버깅을 할 수 있습니다. 나는 이것이 어떻게 바이트가 리눅스 환경에서 저장되고 쓰여지는지와 어떻게 관계가있을 수 있는지 그리고 어떻게 그들이 윈도우에서 읽혀지고 있는지 궁금하다. 당신의 도움을 주셔서 감사합니다.

답변

3

기본 인코딩이 두 시스템간에 서로 다른 것으로 판단됩니다.

// on the linux box 
byte [] blob = str.getBytes("UTF-8"); 

// in your code 
String str = new String(blob, "UTF-8"); 

또는 적어도 기본 인코딩이 리눅스 박스가 뭔지 알아

1.

A가 여기 일이있을 수 있는지 정말 좋은 examplation이 켜져있는 (정상 UTF-8)와 건너 단계입니다 Joel on software

+0

+1 Joels 기사를 언급합니다. – Daniel

+0

그래, 이건 다르게 인코딩 된거야. 귀하의 답변에 감사드립니다. 새로운 String (byte [], "UTF-8")을 사용하여 문제가 해결되었습니다. 나는 오늘 그 기사를 읽을 것입니다 - 거기에 좋은 정보가 많이있는 것처럼 보입니다. 너무 평판이 나지 않아서이 답변을 투표 할 수 없습니다. – John

+0

자신 만의 질문에 upvote 수 있습니다 (나는 생각합니다) 또한 큰 대답을이 대답을 허용 대답으로 표시 할 수 있습니다. Joels artical은 총 금과 기본적으로 필요한 독서입니다. –

2

String은 바이트의 일반적인 소유자가 아닙니다. 당신은 의심 할 여지없이 당신의 db2/Linux 환경과 당신의 Windows 환경 사이에서 서로 다른 기본 문자 인코딩을 가질 것이고, 이것은 바이트와 문자 사이에서 앞뒤로 변환을 일으킬 것입니다.