Request 구간 정리

     브라우저에서 Form Post/Get할때 è WAS è JSP/Servlet Source 코드- Request.getParameter(“ID”) 까지 과정에서 영향을 미치는 환경설정값과 동작을 설명하고자 한다.

q브라우저에서 Static Page 호출

¤<a Href=“targetpage.jsp”..> link </a> 형태로 jsp / Servlet / html 호출시에는 http get 으로 link를 호출하게 된다.  이 경우 브라우저에서 WAS로 전달되는 데이터가 없으므로 Request 과정에는 별다르게 고려할 사항이 없다.

q브라우저에서 Form Post/Get할때 è WAS è Source 코드- Request.getParameter(“ID”) 까지 과정

1.브라우저에서 Form 데이터  Encoding (Form Data) 하는 단계

1.기본적으로 뒤에 따로 정리된 “Form 인코딩 방법”에 따라서 Form Encoding을 수행하지만, 브라우저 특성에 따라서 약간씩 다르게 Encoding 한다.

2.WAS에서 Form 데이터를 Request 객체에 반영하는 단계

1.WAS에서는 client.encoding.override에 따라서 인코딩하여 값을 Request에 반영한다.

2.client.encoding.override 값이 없다면 ISO-8859-1로 인코딩 하어 Request 객체에 Form 데이터를 반영한다.

3.소스코드에서 Request Encoding Type 재 변경하는 단계

1.doGet(),doPost() or JSP에서 Request 객체의 Encoding type을 강제로 변경하고 싶다면  Request.setCharacterEncoding( “EncodingType“)을 호출하면 된다. client.encoding.override 가 적절하게 설정되어 있다면 굳이 호출할 필요가 없다.

1. 브라우저에서 Form 데이터  Encoding

¤Chrome 및 IE Form Encoding 비교

¤IE8 Encoding Data ( CustomerID=한글똠펲123 )

¡http://localhost:9080/HelloJSP/FirstServlet?CustomerID=%C7%D1%B1%DB%26%2346624%3B%26%2354194%3B123

¡확장한글 변환 방식

¡확장한글은 Numeric character reference 방식의 유니코드로 변환된다.
http://en.wikipedia.org/wiki/Numeric_character_reference

¡똠=0xB620=46624 è %26%2346624%3B = &#46624;

¡유니코드 표기 형태로 변환되기 때문에 서버에서 어떻게 Encoding과정을 거치더라도IE에서는 확장한글이 정상적으로 표기된다.

¤Chrome Encoding Data ( CustomerID=한글똠펲123 )

¡http://localhost:9080/HelloJSP/getform.jsp?CustomerID=%C7%D1%B1%DB%8Cc%BC%84123

¡한글은 MS949코드값으로 Encoding된다.  

¤EUC-KR에 포함되지 않는 확장 한글이 서로 다르게 Encoding 처리한다.

¡Chrome은 W3의 가이드대로 Encoding 하지만, IE는 고유의 방식으로 인코딩한다.

¤Form Encoding 데이터가 다르기 때문에 JSP/Servlet에서 어떻게 처리해주는지에 따라서 브라우저마다 확장한글의 출력 결과가 다르게 나타날 수 있다.

                 (2013-10-22  추가) Form이 있는 JSP 파일의 Page encoding-type에 따라서 Form data encoding이 달라진다.. -_-; 
           위의 예는 <%@ page contentType="text/html; charset=euc-kr"%>형태로 euc-kr로 저장된 경우이고, 
           charset=ISO-8859-1이거나 따로 지정하지 않아서 default로 ISO-8859-1된는 경우의 파라미터 인코딩은 아래와 같다.
           동일하게  CustomerID=한글똠펲123을 form encoding한 결과는
         CustomerID=%26%2354620%3B%26%2344544%3B%26%2346624%3B%26%2354194%3B123+
           와 같다 모든 한글이 Numeric character reference 로 표현된다. IE 및 Chrome모두 동일한 결과이다. 
           참 이해가 안가는 동작이다.. -_-; form jsp파일 page encoding이 왜 영향을 미치는 것일까?
           WAS에서 생성된 html파일은 결국 같고 브라우저 단에서 form encoding이 발생되는데..
           왜 html을 생성하는 jsp 파일의 page encoding이 form encoding에까지 영향을 미치는지 신기하기만 하다.. -_-;
           html 파일 자체 및 header viewer로 header를 비교해봐도 차이점이 없는데..어떤값에 영향을 받는지..
           좀 더 탐구가 필요하다..

                 모든 한글은 numeric character reference로 표현되므로, action jsp 나 servlet에서 request.getParameter("ID")를
           하면 한글깨지는 현상없이 그냥 잘 얻어온다. 심지어 request.setCharacterEncoding("euc-kr") 를 호출할 필요도
           없고, 어떤 encoding type에서도 한글은 정상적으로 얻어올 수 있다.

2. WAS단에서는 Form 데이터를 Request 객체에 반영

¤client.encoding.override 값에 따라서 Encoding된 결과가 Request객체에 반영됨.

¤Form Test 문자열 “한글똠펲123”

 

client.encoding.overide  설정 값	Request.getParameter(“ID”) 결과
	IE	비고	Chrome	비고
EUC-KR	한글똠펲123		한글??123	확장한글은 깨짐
ms949	한글똠펲123		한글똠펲123	모두 정상 출력됨
ISO-8859-1 or 미설정	??똠펲123	Encoding변환으로  정상출력 가능함.	????123	Encoding변환으로  정상출력 가능함.
UTF-8	한글똠펲123	JSP파일은 1. <%@ page pageEncoding="UTF-8" contentType="text/html;charset=UTF-8" %> 로 지정 2. ISO-8859-1로 지정 3. pageEncoding 및 Charset을 지정하지 않아 Default로 ISO-8859-1로 지정 되도록.	한글똠펲123	1.의 경우 form jsp 및 action jsp파일모두 utf-8로 일치해야 함 2,3의 경우 form jsp에서  form data encoding시에 Numeric character reference으로 한글이 encoding된다.

¤client.encoding.overide 값이 없으면 ISO-8859-1 값이 Default 이다.

¤"ISO-8859-1 or 미설정"의 경우 아래와 같은 인코딩 변환으로 정상 출력이 가능하다.

¤Request.setCharacterEncoding(“ms949”) 호출 또는 String Encoding 변환.
String parameter = new String( Resquest.getParameter(“ID”).getBytes(ISO-8859-1), “ms949”);

3. 소스코드에서 Request Encoding Type 재 변경

¤client.encoding.override 값이 잘 설정되어 있다면 JSP 및 Servlet에서 굳이 Request.setCharacterEncoding을 호출할 필요가 없다.

¤예를 들어 client.encoding.override=ms949 이고 Request.setCharacterEncoding(“euc-kr”)을 호출한다면. 똠펲등의 확장한글은 모두 ?으로 변환된다. 그래서 Request.setCharacterEncoding를 호출할 때는 동작을 명확히 이해하고 호출해야 한다.

¤client.encoding.override 값이 미설정 상태라면 default로 ISO-8859-1이 된다.
정상적으로 한글을 출력하기 위해서는 Request.setCharacterEncoding(“ms949”)을 getParameter하기전에 호출해야 한다.  또는 String parameter = new String( Resquest.getParameter(“ID”).getBytes(ISO-8859-1), “ms949”); 코드로 변환하여도 정상적으로 한글 출력을 할수 있다. 하지만 개별 문자열을 변환하기 보다는 Request.setCharacterEncoding(“ms949”)를 호출하는것이 더 적절한 문자열 처리 방식이다.

¤당연히 client.encoding.override=ms949로 설정 했을때도 동일하다.

qForm 인코딩 방법, application/x-www-form-urlencoded  

¤This is the default content type. Forms submitted with this content type must be encoded as follows:

¤Control names and values are escaped. Space characters are replaced by `+', and then reserved characters are escaped as described in [RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', a percent sign and two hexadecimal digits representing the ASCII code of the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%0A').

¤The control names/values are listed in the order they appear in the document. The name is separated from the value by `=' and name/value pairs are separated from each other by `&'.

¤http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1

q Request data encoding ( servlet-2_5-mrel2-spec.pdf 에서 발췌)

Currently, many browsers do not send a char encoding qualifier with the Content-

Type header, leaving open the determination of the character encoding for reading

HTTP requests. The default encoding of a request the container uses to create the

request reader and parse POST data must be “ISO-8859-1” if none has been

specified by the client request. However, in order to indicate to the developer in this

case the failure of the client to send a character encoding, the container returns null

from the getCharacterEncoding method.

If the client hasn’t set character encoding and the request data is encoded with

a different encoding than the default as described above, breakage can occur. To

remedy this situation, a new method setCharacterEncoding(String enc) has

been added to the ServletRequest interface. Developers can override the

character encoding supplied by the container by calling this method. It must be

called prior to parsing any post data or reading any input from the request. Calling

this method once data has been read will not affect the encoding.