HttpServletResponse가 손상된 UTF-8 데이터를 생성합니다.

UBS-8 인코딩 된 응답을 생성하는 Jersey를 사용하여 RESTful 서비스를 만들고 있습니다. 유로 기호가 세 가지로 인코딩되어,HttpServletResponse가 손상된 UTF-8 데이터를 생성합니다.

[123, 34, 118, 97, 108, 117, 101, 34, 58, 34, -30, -126, -84, 34, 125]

참고 :

{"value":"€"}

또는 바이트 배열로 : 다음과 같은 답변을 생산하기로했다

public static class Data { 

    private String value; 

    public Data(String value) { 
     this.value = value; 
    } 

    public String getValue() { 
     return value; 
    } 

    public void setValue(String value) { 
     this.value = value; 
    } 
} 

@GET 
@Produces(MediaType.APPLICATION_JSON) 
public Response method() { 

    Data response = new Data("€"); 
    return Response.status(Response.Status.OK) 
        .type(MediaType.APPLICATION_JSON + ";charset=UTF-8") 
        .entity(response) 
        .build(); 
}

: 여기 는 코드입니다 바이트 -30, -126, -84 또는 0xe2 0x82 0xac

은 그러나, 바이트 어레이로 다음 반응

{"value":"â¬"}

또는 생산 :

[123, 34, 118, 97, 108, 117, 101, 34, 58, 34, -61, -94, -62, -126, -62, -84, 34, 125]

주 유로 기호는 여섯 바이트로 인코딩되는 현재 -61, -94, -62, -126, -62, -84 또는 0xc3 0xa2 0xc2 0x82 0xc2 0xac.

나는 UTF-8로 인코딩 된 데이터가 Latin1로 인코딩 된 데이터로 취급되는 일부 지점에서 이러한 손상을 초래하는 변환 시퀀스를 발견했습니다.

Data data = new Data("€"); 
org.codehaus.jackson.map.ObjectMapper mapper 
    = new org.codehaus.jackson.map.ObjectMapper(); 
try { 
    String strData = mapper.writeValueAsString(data); 
    System.out.println(strData); 
    byte[] rawData = mapper.writeValueAsBytes(data); 
    System.out.println(Arrays.toString(rawData)); 

    String asLatin1 = new String(rawData, "ISO-8859-1"); 
    byte[] brokenUtf8 = asLatin1.getBytes("UTF-8"); 
    System.out.println(Arrays.toString(brokenUtf8)); 
} catch (IOException e) { 
    System.out.println("Fail " + e.getMessage()); 
}

이 서비스는 두 개의 기계 아파치 - 톰캣-7.0.23에서 아파치 - 톰캣-7.0.30와 다른 하나에서 실행됩니다. 전자는 올바른 UTF-8 응답을 생성하지만 후자는 UTF-8을 손상시킵니다. 나는 행동의 차이를 일으키는 원인과 그 문제를 해결할 수있는 것을 발견 할 수 없다.

출처

2013-02-06 divanov

수신자가 latin1로 디코딩하고있는 것처럼 보입니다. 기본 인코딩을 사용하는 구성 문제 또는 코드에서 문제가 발생하는 것 같습니다. – Esailija

@Esailija : 수신자는 curl 명령 줄 유틸리티 또는 브라우저이며 모두 UTF-8을 사용하고 있습니다. 나는 그것이 수신기 문제가 아니라고 확신한다. – divanov

귀하의 게시물에서 알 수있는 것은 합법적 인 UTF-8을 다른 서버에 게시하는 서버가 있고 다른 서버가이를 해석하고 결과를 덤프하는 것입니다. – Esailija

이 문제는 매우 슬픈 이유가있어서 찾아 내기가 매우 어려웠습니다. 이 이클립스에 지어진 다른 배포가 개미로 구축 되었기 때문에 그것은 모든 유니 코드 문자를 손상 한 톰캣에서 일하는

<javac destdir="${classes}" includeantruntime="false" source="1.6" target="1.6" debug="true" encoding="ISO-8859-1" classpathref="main.classpath">

: 개미의 javac의 작업은 명시 적으로 인코딩을 설정했다.

출처

2013-02-06 15:05:56 divanov

7.0.30에서 작동하고 7.0.23에서 작동하지 않는 것이 아마도 발견되어 수정 된 버그일까요? Tomcat changelog을 확인해 거기에 무엇이 있는지 확인 했습니까?

출처

2013-02-06 12:56:33 jgm

버그가있는 Apache Tomcat 7.0.23의 확률로 인해 UTF-8 응답을 생성 할 수 없었으며, 심각하게 받아 들일 수 없을 정도로 저조하다는 것을 처음 알게되었습니다. – divanov

HttpServletResponse가 손상된 UTF-8 데이터를 생성합니다.

답변

관련 문제