servlet 디코드 문제 해결

servlet에 대해 다들 잘 알고 계실 거예요. 오늘 다시 복습해 볼게요. 만약에 잘못 쓰거나 틀린 부분이 있으면 많은 네티즌들이 비판하고 지적해 주셨으면 좋겠어요.오늘은 get과post 두 가지 방식만 논의합니다. 그들 사이에는 많은 차이점이 있기 때문에 인코딩을 해결하는 방식도 달라질 수 있습니다.post의 디코딩 문제는 좀 잘 해결될 것입니다. 다음은 http 프로토콜을 간단하게 말해서 제가 원리적인 것과 그들 사이의 차이점을 더 잘 기억할 수 있도록 하겠습니다.
get 방식과post 방식은 모두 http 프로토콜을 바탕으로 하는 것으로 html 페이지를 발표하고 수신하는 방법을 제공하기 위해 클라이언트가 요청을 하고 서버 측이 응답하는 것을 목적으로 한다.
하나의 완전한 요청 메시지는 하나의 요청 줄, 약간의 메시지 헤더와 요청 실체 내용을 포함한다.
요청 줄은 요청 방식 (get 또는post), 자원 경로 (접근할 주소), http 버전 번호 (http1.1) 를 포함한다
몇몇 메시지 헤더 (예를 들어 브라우저의 핵 정보 (user-agent), 부모 페이지를 여는 사람 (refer) 등
요청 실체 내용과 메시지 헤더에 빈 줄이 있습니다. 메시지 헤더와 요청 실체 내용을 분리하고 실체 내용은 사용자가 제출한
완전한 응답 메시지는 상태 줄, 하나 이상의 응답 헤더, 빈 줄, 응답 실체를 포함한다.
상태 줄: http 프로토콜 버전 번호, 상태 코드와 원인 서술 포함
일반 상태 코드: 200 정상
404: 요청 리소스가 없습니다.
500: 서버 내부 오류
대충 http를 말하고 나면 get과post 방식의 차이점을 소개할 수 있습니다.
get 방식:
get 방식은 제출한 내용을 URL 뒤에 놓는 것입니다. 길이가 제한되어 있습니다.post와 get은 모두 http 프로토콜을 기반으로 합니다.get 방식은 요청 줄에 넣는 것입니다. 그 매개 변수는 URL에 있기 때문에post 방식은 요청 실체 내용에 넣는 것입니다.post 방식은 상대적으로 안전하고 브라우저는 캐시 정보를 보존하지 않으며 get 방식은 wk에서 캐시를 보존합니다. 브라우저의 역사 기록에서 제출한 내용을 볼 수 있습니다.그리고 get 방식의 길이는 제한이 있고post는 없습니다.
get 방식과post 방식으로 데이터를 제출할 때 http 프로토콜의 위치가 다르기 때문에 그들의 인코딩 방식을 해결하는 방법도 다르다
post 방식 디코딩 문제 해결:
servlet 서비스 방법 (doGet 또는 doPost 방법도 가능) 에서 리퀘스트 인코딩을 UTF-8로 설정합니다
　　

req.setCharacterEncoding("UTF-8");

이렇게 하면request의 인코딩은 문제가 없습니다. 그리고response의 인코딩도 UTF-8로 설정합니다.

resp.setCharacterEncoding("UTF-8");

이렇게 하면response의 인코딩도 문제가 없습니다. 그러나 이렇게 쓰면 브라우저에 문제가 발생할 수 있습니다. 브라우저는 당신의 인코딩 형식이 무엇인지 모르기 때문에 브라우저의 기본 형식에 따라 표시합니다. 따라서 브라우저를 표시할 때의 인코딩 방식도 UTF-8로 설정해야 합니다. 문장은 다음과 같습니다.

resp.setContextType("text/html;charset=utf-8");

또한 당신의 개발 도구 인코딩과 프로젝트의 인코딩이 일치해야 합니다. 그렇지 않으면 디코딩 문제가 발생할 수 있습니다. 여기는 모두 UTF-8을 예로 들 수 있습니다.
get 방식 부호화 문제 해결:
get 방식은 위의 작업 외에tomcat의conf 디렉터리에 있는 서버입니다.xml 프로필에 한 마디를 추가하면 다음 문장을 찾습니다.
　　　

 <Connector port="8080" protocol="HTTP/1.1"
        connectionTimeout="20000"
        redirectPort="8443" />

수정 후

 <Connector port="8080" protocol="HTTP/1.1"
        connectionTimeout="20000"
        redirectPort="8443" userBodyEncodingForURI="true" />

이러한 변경은 비교적 유연하여 URL의 인코딩 형식을 페이지의 인코딩 형식과 같이 고정된 형식으로 설정할 수 있다. 예를 들어

 <Connector port="8080" protocol="HTTP/1.1"
        connectionTimeout="20000"
        redirectPort="8443" EncodingForURI="UTF-8" />

이렇게 하면 기본적으로 아무런 문제가 없다. 만약에 문제가 있다면 String의 방법으로 페이지의 코드를 당신이 원하는 형식으로 바꾸어야 한다. 그러나 위의 방식이 모두 맞다면 이런 방식은 그다지 쓰지 않을 것이다.
위의 조작을 제외하고 데이터베이스의 인코딩 형식을 프로젝트와 똑같이 설정해야 한다. 여기는 바로 UTF-8로 바꾸는 것이다. 시간이 제한되어 있기 때문에 비교적 거칠게 썼고 많은 것도 생략되었지만 servlet의 인코딩 방식을 해결하는 것은 충분할 것이다.
호출할 때 js를 사용할 수 있습니다. 예:

function ceshi() {
	window.location.href = "UserServlet?uname=zhangsan&realname=" + encodeURIComponent(" ");
}

이렇게 하면 안녕하십니까? 더 이상 주소란에 한자를 표시하지 않을 것입니다. (이 말을 제출 단추에 연결하면) 상응하는 servlet에 제출할 수 있습니다.이런 디코딩 해결 방식도 jsp에 적용된다
참, servlet과 관련이 있는 것을 더 말해야 한다. 그것이 바로 forward와redirect이다. forward는 현재 프로젝트에서만 점프할 수 있다. redirect는 밖으로 점프할 수 있다. 물론 그들은 다른 차이가 있다. 여기서 나는 내가 중요하게 생각하는 것만 말한다. 그것은 어떤 것을 사용하든지 forward와redirect를 다 쓴 후에 반드시return을 추가해야 한다. 만약에 추가하지 않으면 뒤의 문장은 실행될 것이다.리턴을 추가하면 뒤에 있는 문장이 틀리게 표시되어 같은 페이지가 여러 번 돌아가는 것을 막습니다.싫어하는 네티즌이 잘못 뿌렸어요. 협조해 주셔서 감사합니다. 잘못 골라주신 네티즌께 감사드려요. 그래야 제가 계속 발전할 수 있으니까 진심으로 감사드려요.