JavaWEB에서 앞뒤 문자가 깨지는 문제 해결

다음 편집기는 javaWEB의 프론트엔드와 백엔드에서 발생하는 잘못된 문제에 대한 솔루션 요약을 제공합니다. 편집자님이 꽤 좋다고 생각하셔서 지금 공유하고 모두에게 참고용으로 드리도록 하겠습니다. 편집기를 따라 JAVA의 몇 가지 일반적인 인코딩 형식과 의미를 살펴보겠습니다.

ASCII 코드

컴퓨터를 공부한 사람들은 모두 ASCII 코드를 알고 있으며, 총 128개입니다. 7비트의 바이트, 0~31은 줄 바꿈, 캐리지 리턴, 삭제 등과 같은 제어 문자입니다. 32~126은 키보드를 통해 입력하고 표시할 수 있는 인쇄 문자입니다.

ISO-8859-1

128자는 분명히 부족하므로 ISO 조직에서는 ASCII 코드를 확장하기 위해 ASCII 코드를 기반으로 몇 가지 표준을 공식화했습니다. ISO-8859-1~ ISO-8859-15입니다. ISO-8859-1이 대부분의 서유럽 언어 문자를 다루는 가 가장 널리 사용됩니다. ISO-8859-1은 여전히 ​​단일 바이트 인코딩으로 총 256자를 나타낼 수 있습니다.

GB2312

전체 이름은 "정보 교환을 위한 중국어 인코딩 문자 세트 기본 세트"입니다. 전체 인코딩 범위는 A1-F7이며 그 중 A1-A9입니다. B0~F7까지 총 682개의 기호를 포함하는 기호 영역은 6763개의 한자를 포함하는 한자 영역이다.

GBK

전체 이름은 "한자 내부 코드 확장 사양"으로, Windows 95에 대해 국가기술감독국에서 제정한 새로운 한자 내부 코드 사양입니다. GB2312와 한자를 더 추가하면 인코딩 범위는 8140~FEFE(XX7F 제외)이며 총 23940개의 코드 비트를 나타낼 수 있습니다. 해당 인코딩은 GB2312와 호환되므로 GB2312로 인코딩된 한자를 디코딩할 수 있습니다. GBK를 사용하면 왜곡된 문자가 없습니다.

GB18030

전체 이름은 "정보 교환을 위한 중국어 코드 문자 집합"이며, 이는 우리나라의 필수 표준일 수 있습니다. 인코딩은 GB2312 인코딩과 동일하지만 이는 국가 표준이지만 실제 응용 시스템에서는 널리 사용되지 않습니다.

UTF-16

UTF라고 하면 유니코드(Universal Code)를 언급해야 합니다. ISO는 이 사전을 통해 세상의 모든 언어에 접근할 수 있습니다. .서로 번역하세요. 이 사전이 얼마나 복잡한지 짐작할 수 있을 것입니다. 유니코드에 대한 자세한 사양은 해당 문서를 참조하세요. 유니코드는 Java와 XML의 기초입니다. 다음은 컴퓨터에서 유니코드가 저장되는 형태에 대해 자세히 소개합니다. UTF-16은 컴퓨터에서 유니코드 문자에 액세스하는 방법을 구체적으로 정의합니다. UTF-16은 유니코드 변환 형식을 표현하기 위해 2바이트를 사용합니다. 이것은 어떤 문자이든 2바이트로 표현할 수 있으므로 UTF-16이라고 합니다. UTF-16은 문자를 나타내는 데 매우 편리합니다. 이는 문자열 작업 중 작업을 크게 단순화합니다. 이는 Java가 메모리에서 문자 저장 형식으로 UTF-16을 사용하는 매우 중요한 이유이기도 합니다.

UTF-8

UTF-16은 한 문자를 표현하기 위해 2바이트를 일률적으로 사용하지만 표현이 매우 간단하고 편리하지만, 한 문자로 많은 수의 문자를 표현할 수 있다는 단점도 있습니다. 이제 표현하는 데 2바이트가 필요하므로 저장 공간이 두 배로 늘어납니다. 오늘날의 네트워크 대역폭은 여전히 ​​매우 제한되어 있어 네트워크 전송 트래픽이 증가하므로 불필요합니다. UTF-8은 가변 길이 기술을 사용하며 각 인코딩 영역의 문자 길이가 다릅니다. 다양한 유형의 문자는 1~6바이트로 구성될 수 있습니다.

UTF-8 인코딩 규칙:

1. 바이트의 최상위 비트(8번째 비트)가 0이면 ASCII 문자(00 – 7F)를 의미합니다. 모든 ASCII 인코딩이 이미 UTF-8임을 알 수 있습니다. 2. 바이트가 11로 시작하는 경우 연속되는 1의 수는 이 문자의 바이트 수를 나타냅니다. 예를 들어 110xxxxx는 더블바이트 UTF-8 문자의 첫 번째 바이트임을 의미합니다.

3. 바이트가 10으로 시작하면 첫 번째 바이트가 아니라는 의미이며 현재 문자의 첫 번째 바이트를 기다려야 합니다

다양한 인코딩 형식 비교

GB2312와 GBK의 인코딩 규칙은 다음 네 가지를 처리할 수 있지만 GBK는 범위가 더 넓고 모든 한자를 처리할 수 있으므로 GB2312와 GBK를 비교할 때는 GBK를 선택해야 합니다. UTF-16과 UTF-8은 모두 유니코드 인코딩을 처리하며 인코딩 규칙은 동일하지 않습니다. 상대적으로 말하면 UTF-16 인코딩이 가장 효율적이고 문자를 바이트로 변환하는 것이 더 쉽고 문자열을 수행하는 것이 더 좋습니다. 운영. 로컬 디스크와 메모리 간 사용에 적합하며 문자와 바이트 간을 빠르게 전환할 수 있습니다. 예를 들어 Java의 메모리 인코딩은 UTF-16 인코딩을 사용합니다. 그러나 네트워크 전송은 바이트 스트림을 쉽게 손상시킬 수 있으므로 네트워크 간 전송에는 적합하지 않습니다. 바이트 스트림이 손상되면 복구가 어렵습니다. 이에 비해 UTF-8은 네트워크 전송에 더 적합하며 단일을 사용합니다. -ASCII 문자에 대한 바이트 저장 또한 단일 문자의 손상은 다른 후속 문자에 영향을 미치지 않습니다. 따라서 UTF-8은 인코딩 효율성과 인코딩 보안의 균형을 유지하며 이상적인 중국어 인코딩입니다. 방법.

중국어 문제 해결:

1. Tomcat의 자체 인코딩은 ISO-8859-1 형식이므로 중국어 인코딩과 호환되지 않습니다. 동일한 형식을 사용하여 수신(ISO-8859-1)한 다음 구문 분석 가능한 인코딩(utf-8)을 사용하여 변환합니다. 처리 후 프런트로 보내드립니다. 프론트 데스크로 보낼 때 다음을 설정해야 합니다:

res.setContentType("text/html;charset=utf-8");//페이지의 문자 인코딩을 설정하여 페이지에 표시되는 중국어 문자가 깨졌던 문제를 해결합니다. 인터페이스;

2.req.setCharacterEncoding("utf-8");//이런 방식으로 데이터를 읽으므로 먼저 작성해야 합니다. 그렇지 않으면 데이터가 잘못됩니다.

3.Spring은 문자 깨짐 문제를 해결하는 데 사용할 수 있는 CharacterEncodingFilter 필터를 제공합니다.

CharacterEncodingFilter를 사용할 때 다음 문제에 주의해야 합니다.

양식 데이터가 POST 모드로 제출됩니다.

웹에서 CharacterEncodingFilter 필터를 구성합니다.

<filter>
　　<filter-name>encodingFilter</filter-name>
　　<filter-class>
　　　　org.springframework.web.filter.CharacterEncodingFilter
　　</filter-class>
　　<init-param>
　　　　<param-name>encoding</param=name>
　　　　<param-value>UTF-8</param-value>
　　</init-param>
</filter>
<filter-mapping>
　　<filter-name>encodingFilter</filter-name>
　　<url-pattern>/*</url-pattern>
</filter-mapping>

위 내용은 정보를 검색하여 작성되었습니다. 그리고 코드를 작성하는 과정에서 제가 겪은 문제들을 요약해 보면 이렇습니다. 해결책도 있어야 합니다.

위 내용은 JavaWEB에서 앞뒤 문자가 깨지는 문제 해결의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!