336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
웹개발을 하면서 한글은 매우 어려운 문제입니다. 제 경우에는 한글 문제만큼은 단기 학습을 통해서 해결이 되지 않았습니다. 온갖 문서를 읽어보고 실험해보고 했지만 정확히 이해하는 것은 매우 힘들었습니다. 또한 조금 이해한 것 같으면 계속해서 새로운 문제가 등장하였습니다. 지금도 여전히 깊은 이해는 없다고 생각합니다. 하지만 경험을 정리하면 누군가에게는 도움이 될수도 있으리란 기대에 내용을 정리해봅니다.
1. 서버 측면에서 POST와 GET의 처리의 차이점
저는 POST로 보내든 GET으로 보내든 request.setCharacterEncoding(CHARSET)만 호출해주면 자바 내에서의 한글처리는 완료된다고 알고 있었습니다. 하지만 실제로는 그렇지 않았습니다. request.setCharacterEncoding(CHARSET)는 POST방식에만 유효합니다. GET방식의 캐릭터셋 정의는 톰캣의 경우 server.xml의 Connector 설정쪽에 URIEncoding라는 옵션을 통해서 가능합니다. 이 옵션에 캐릭터셋을 정의하게 되면 GET방식으로 오는 파라메터에 대해서 해당 캐릭터셋을 이용하여 디코딩을 합니다.(만약 지정되어 있지 않다면 ISO-8859-1을 기본적으로 사용하게 됩니다.)
결론적으로 POST와 GET을 모두 정확하게 처리하려면 setCharacterEncoding뿐만 아니라 URIEncoding이 정의가 되어 있어야 합니다. 또한 GET방식은 브라우저에 따라서 자동으로 URL인코딩을 해주지 않는 경우가 있기 때문에 GET파라메터에 대해서는 항상 URL인코딩을 해주는 것이 좋을 것으로 보입니다.
2. 항상 setCharacterEncoding을 해주어야 하는 이유?
어느 순간 왜 항상 setCharacterEncoding을 해줘야 하는지에 대한 의문이 들었습니다. 송신측에서 내가 보내는 데이터가 어떤 타입인지 명시해주고 수신측에서 그 값에 따라 동적으로 처리해주면 좋을텐데라는 생각이 들었습니다. 처음에는 HTTP 해더를 살펴보면 뭔가 답이 있을 것이라 생각했습니다. 파이어폭스의 플러그인인 파이어버그를 이용하여 서버로 날아가는 HTTP 패킷을 살펴보았습니다. 비슷해 보이는 해더를 찾아볼 수가 없었습니다. HTTP RFC를 열심히 뒤져보았습니다. 그러나 요청에서 사용할 수 있는 해더 후보 목록 중에서는도무지 해당 내용을 찾아볼 수가 없었습니다. HTTP 1.1이 다국어에 대한 고려를 미처 하지 못해 지원이 안 되는구나라고 생각했습니다.
3. Connector의 useBodyEncodingForURI 옵션을 발견
그러던 중 톰캣의 useBodyEncodingForURI 라는 옵션의 명세를 보게됐습니다. 내용은 아래와 같았습니다.
This specifies if the encoding specified in contentType should be used for URI query parameters, instead of using the URIEncoding. This setting is present for compatibility with Tomcat 4.1.x, where the encoding specified in the contentType, or explicitely set using Request.setCharacterEncoding method was also used for the parameters from the URL. The default value is false.
그 중 위 밑줄 처친 부분이 심상치 않게 느껴졌습니다. 분명히 "contentType안에 명시된 인코딩"이라고 하고 있습니다. contentType이라는 해더가 분명히 있을 것이라 생각하게 되었습니다.
4. Content-type=application/x-form-urlencoded;charset=UTF-8 발견
문제에 대해 여러 지인들에게 질문을 던지던 중 제 사수이시기도 했던 선배분이 톰캣 소스를 보고 HTTP 해더에 "Content-type=application/x-form-urlencoded;charset=UTF-8"과 같이 보내주면 setCharacterEncoding을 하지 않아도 UTF-8로 파라메터가 읽혀진다는 것을 알려주었습니다. 정말 테스트해보니 아무것도 정의하지 않고 getCharacterEncoding을 하니 UTF-8이 반환되었습니다.
5. 그렇다면 어떤 근거로?
처음 가졌던 의문에 대한 답은 된 셈이였습니다. 하지만 찝찝합니다. 어떤 근거로 톰캣이 이렇게 구현을 했는지가 궁금했던 것이였습니다. 이것 때문에 (나름대로는)많은 시간을 들여서 찾아본 결과 해당 내용에 대해 다룬 내용을 찾을 수 있었습니다.
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms.http://tools.ietf.org/html/rfc2045#section-5
The purpose of the Content-Type field is to describe the data contained in the body fully enough that the receiving user agent can pick an appropriate agent or mechanism to present the data to the user, or otherwise deal with the data in an appropriate manner. The value in this field is called a media type.
즉 HTTP에서 데이터(Entities) 전송을 위해 MIME 사용이 가능합니다. 그리고 그 중 Content-Type은 수신측이 우리가 보내는 데이터를 정확히 해석하는 것을 도와주기 위해 사용됩니다. 즉 Content-Type은 위의 "Content-type=application/x-form-urlencoded;charset=UTF-8" 와 같이 여러 가지 정보를 기술하기 위해 사용 될 수 있는 것입니다.
6. 남은 부분
하지만 아직까지 남아있는 궁금증이 있습니다. 그것은 바로 "브라우저에서 해더에 Content-Type을 함께 보내게 하려면 어떻게 해야하나"라는 문제입니다. 이 방법을 알게되면 서버에서 획일적으로 하는 setCharacterEncoding을 완전히 제거할 수 있습니다. 대신 톰캣은 해더에서 정보를 읽어 상황에 따라 적절하게 요청을 읽을 수 있을 것입니다. 이것은 블로그의 트랙백과 같은 기능에서 유용하게 이용될 수 있을 것 같습니다. 트랙백은 여러 서비스들에서 보내며 그들의 인코딩은 다양할 수 있기 때문입니다.
이 부분을 찾아내기 위해여 여러 테스트를 해보았으나 아직 찾지 못했습니다. 그래서 우선은 알아낸 부분까지 기록하고 나중에 이 문제와 관련한 또다른 지식이나 이해가 생기게 되면 계속해서 이 포스트에 정리해나가도록 하겠습니다.
WRITTEN BY
- 차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!
,
