Java로 내보낸 잘못된 CSV에 대한 솔루션 소개

1. 문제

쿼리된 데이터를 xls 파일(UTF-8 인코딩)로 내보낼 때 데이터는 정상인데, CSV 파일로 내보낼 때 파일의 중국어 왜곡 문자도 UTF-입니다. 8로 인코딩되어 변경되었습니다. GBK 인코딩으로 내보낼 경우 중국어가 정상적으로 표시됩니다.

나중에 라틴 문자(예: ÀÆäàÌ)가 포함된 데이터를 내보낼 때 문제가 해결된 줄 알았는데, xls 파일로 내보낸 데이터가 정상적으로 표시되었습니다. "?".

다른 인코딩 방법으로 변경해 보았지만 나중에 온라인에서 이 문제에 대한 해결책을 찾았습니다.

2. 솔루션

CSV 모드로 내보낸 파일에는 기본적으로 BOM 정보가 포함되어 있지 않습니다. 이 문제는 출력할 콘텐츠에 대한 BOM 식별자(EF BB BF로 시작하는 바이트 스트림)를 설정하여 해결할 수 있습니다. 구체적인 방법은 다음과 같습니다. (권장: java 비디오 튜토리얼)

...
OutputStreamWriter outputStreamWriter = new OutputStreamWriter(response.getOutputStream(), "UTF-8");  
// 要输出的内容  
result = (String)contentMap.get(RESPONSE_RESULT);  
response.setHeader("Content-Disposition", "attachment;filename=test.csv");  
outputStreamWriter.write(new String(new byte[]{(byte) 0xEF, (byte) 0xBB, (byte) 0xBF}));  
outputStreamWriter.write(result);  
outputStreamWriter.flush();

OutputStream 스트림으로 구현하는 경우 매개변수는 다음과 같이 수정할 수 있습니다.

out = response.getOutputStream();     
//加上UTF-8文件的标识字符      
out.write(new byte []{(byte) 0xEF, (byte) 0xBB, (byte) 0xBF});

참고:

BOM: Byte Order Mark, 바이트 순서 마크 (다음은 바이두 백과사전에서 발췌)

UCS 인코딩에는 "Zero Width No-Break Space"라는 문자가 있는데, 이를 중국어로 "Zero Width No-Break Space"로 번역하면 해당 인코딩은 다음과 같습니다. 페프. FFFE는 UCS에 존재하지 않는 문자이므로 실제 전송에서는 나타나지 않아야 한다.

UCS 사양에서는 바이트 스트림을 전송하기 전에 "Zero Width No-Break Space" 문자를 전송할 것을 권장합니다. 이런 식으로 수신기가 FEFF를 수신하면 바이트 스트림이 Big-Endian임을 나타내고, FFFE를 수신하면 바이트 스트림이 Little-Endian임을 나타냅니다. 따라서 "Zero Width No-Break Space" 문자를 BOM이라고도 합니다.

UTF-8은 바이트 순서를 나타내는 데 BOM이 필요하지 않지만 BOM을 사용하여 인코딩을 나타낼 수 있습니다. "Zero Width No-Break Space" 문자의 UTF-8 인코딩은 EF BB BF입니다. 따라서 수신기가 EF BB BF로 시작하는 바이트 스트림을 수신하면 해당 스트림이 UTF-8로 인코딩되었음을 알 수 있습니다. Windows는 BOM을 사용하여 텍스트 파일의 인코딩을 표시합니다.

더 많은 Java 지식을 알고 싶다면 java 기본 튜토리얼 칼럼을 주목해주세요.

위 내용은 Java로 내보낸 잘못된 CSV에 대한 솔루션 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!