'UTF8'에 해당되는 글 3건


아마도 Open Source에 대해 공부하면서 Apache 웹서버 구축하고 Tomcat 어플리케이션서버와 연동해서

웹환경을 구현하다 보면 마무리시점에 부딪히는 문제가 아마도 아래내용이 아닐까 싶다.

1. 한글을 입력했을때 UTF-8로 처리하는 방법이 무었일까?

2. 다국어 웹사이트를 구축할려고 하면 제일 먼저 고려해야 될 사항이 무었일까?

   => Internationalization(I18N) and Localization(L10N)

 

Tomcat에서 UTF-8 (다국어)/ EUC-KR(한글)사용하기 | Tomcat/Resin 2006/06/26 15:25  
 
http://blog.naver.com/igilyong/150005627488 
아래(하나, 둘, 셋 - 5.X)와 같이 하면, JSP에 어떠한 코드를 넣지 않아도 UTF-8을 마음대로 사용가능.
물론 EUC-KR만 사용하길 원한다면 UTF-8을 EUC-KR로 바꾸기만 하면 그만!!

작성자 : 박병훈
Test 환경 
     - Tomcat : 5.0.28
     - JDK : J2SE 1.4.X
     -  DB : MySQL4.1.X (DB가 UTF-8을 사용하도록 설정)
     -  JDBC Driver : mysql-connector-java-3.1.11-bin.jar
         ( jdbc:mysql://localhost/warmpark?characterEncoding=UTF-8 )

하나. JSP Page설정 
       <%@page pageEncoding="UTF-8"%> : 페이지에 직접 입력된 한글 및 중국어  등을 인식하기 위해 필요

둘. Tomcat's %TOMCAT_HOME%\config\server.xml 의 <Connector .../> 모두 편집( URIEncoding="UTF-8"
추가 ). - Get 방식으로 전달되는 파라미터 인코딩 (Tomcat5.X때 반드시 필요)

<Connector port="8080"
               URIEncoding="UTF-8"
               .../>

셋. streaming(POST)방식으로 전달되는 파라미터 인코딩
셋 대안 1. request.setCharacterEncoding("UTF-8")을 명시적으로 사용
              response.setCharacterEncoding("UTF-8)을 명시적으로 사용

셋 대안 2.(추천) - Filter사용

/** Java Source Code **/

package filter;
import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

public class CharsetFilter implements Filter {
 private String encoding;

 public void init(FilterConfig config) throws ServletException {
  encoding = config.getInitParameter("requestEncoding");
  if (encoding == null)
   encoding = "UTF-8";
 }

 public void doFilter(ServletRequest request, ServletResponse response,
   FilterChain next) throws IOException, ServletException {
  request.setCharacterEncoding(encoding);
  response.setCharacterEncoding(encoding);
  next.doFilter(request, response);
 }

 public void destroy() {

 }
}

<!-- web.xml에 등록 코드 -->
<?xml version="1.0" ?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd">

<web-app>
   ...
 <!--CharsetFilter start-->
 <filter>
  <filter-name>Charset Filter</filter-name>
  <filter-class>filter.CharsetFilter</filter-class>
  <init-param>
   <param-name>requestEncoding</param-name>
   <param-value>UTF-8</param-value>
  </init-param>
 </filter>
 <filter-mapping>
  <filter-name>Charset Filter</filter-name>
  <url-pattern>/*</url-pattern>
 </filter-mapping>
 <!--CharsetFilter end-->
...

</web-app>

넷(선택사항). %TOAMCAT_HOME%bin\catalina.bat수정  java.exe를 시작할 때 -Dfile.encoding=UTF-8  -Dclient.encoding.override=UTF-8  을 사용하도록 수정

rem Execute Java with the applicable properties
if not "%JPDA%" == "" goto doJpda
if not "%SECURITY_POLICY_FILE%" == "" goto doSecurity
%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Dfile.encoding=UTF-8 -Dclient.encoding.override=UTF-8  -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
goto end
:doSecurity
%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% %DEBUG_OPTS% -Dfile.encoding=UTF-8 -Dclient.encoding.override=UTF-8  -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Djava.security.manager -Djava.security.policy=="%SECURITY_POLICY_FILE%" -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
goto end
:doJpda
if not "%SECURITY_POLICY_FILE%" == "" goto doSecurityJpda
%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xdebug -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Dfile.encoding=UTF-8 -Dclient.encoding.override=UTF-8  -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
goto end
:doSecurityJpda
%_EXECJAVA% %JAVA_OPTS% %CATALINA_OPTS% -Xrunjdwp:transport=%JPDA_TRANSPORT%,address=%JPDA_ADDRESS%,server=y,suspend=n %DEBUG_OPTS% -Dfile.encoding=UTF-8 -Dclient.encoding.override=UTF-8  -Djava.endorsed.dirs="%JAVA_ENDORSED_DIRS%" -classpath "%CLASSPATH%" -Djava.security.manager -Djava.security.policy=="%SECURITY_POLICY_FILE%" -Dcatalina.base="%CATALINA_BASE%" -Dcatalina.home="%CATALINA_HOME%" -Djava.io.tmpdir="%CATALINA_TMPDIR%" %MAINCLASS% %CMD_LINE_ARGS% %ACTION%
goto end

 

이하는 참고자료입니다.

1. JSP pages must include the header:

<%@ page contentType="text/html; charset=UTF-8" %> 
2. In the Catalina.bat (windows) catalina.sh (windows) apache$jakarta_config.com (OpenVMS), file there must be a switch added to the call to java.exe. The switch is:

-Dfile.encoding=UTF-8

I cannot find documentation for this environment variable anywhere or what it actually does but it is essential.

 

3. For translation of inputs coming back from the browser there must be a method that translates from the browser's ISO-8859-1 to UTF-8. It seems to me that -1 is used in all regions as I have had people in countries such as Greece & Bulgaria test this and they always send input back in -1 encoding. The method which you will use constantly should go something like this:

 /**
  * * Convert ISO8859-1 format string (which is the default sent by IE * to
  * the UTF-8 format that the database is in.
  */ 
 public String toUTF8(String isoString) { 
  String utf8String = null; 
  if (null != isoString && !isoString.equals("")) { 
   try { 
    byte[] stringBytesISO = isoString.getBytes("ISO-8859-1"); 
    utf8String = new String(stringBytesISO, "UTF-8"); 
   } catch(UnsupportedEncodingException e) { 
   }
  }
 }  
I have found that these three steps are all that is necessary to make your site accept any language that UTF-8 can work with. I extend my thanks to those of you on the Tomcat users list who helped me find these little gems.

(from the tomcat-user mailing list)

Alternative solution

The solution suggested above works fine with steps (1) and (2) only, but from the architecture perspective the correct way is to add a filter to the Tomcat that will do necessary correction for the application deployed without any additional changes to the rest of the code.

1. Make sure JSP header is set as suggested:

<%@ page contentType="text/html; charset=UTF-8"%> 
2. Example of filter:

import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;public class CharsetFilter implements Filter {
 private String encoding; public void init(FilterConfig config) throws ServletException {
  encoding = config.getInitParameter("requestEncoding");
  if (encoding == null)
   encoding = "UTF-8";
 } public void doFilter(ServletRequest request, ServletResponse response,
   FilterChain next) throws IOException, ServletException {
  request.setCharacterEncoding(encoding);
  next.doFilter(request, response); response.setCharacterEncoding("UTF-8");
 } public void destroy() {
 }                                                                                    

Corresponding portion of web.xml configuration will look like:

<!--CharsetFilter START-->
<filter>
 <filter-name>Charset Filter</filter-name>
 <filter-class>CharsetFilter</filter-class>
 <init-param>
  <param-name>requestEncoding</param-name>
  <param-value>UTF-8</param-value>
 </init-param>
</filter>
<filter-mapping>
 <filter-name>Charset Filter</filter-name>
 <url-pattern>/*</url-pattern>
</filter-mapping>
<!--CharsetFilter end-->
 
The suggested solution originates from  Sergey Astakhov (all texts are in russian) (sergeya@comita.spb.ru)

last edited 2005-06-22 21:24:14 by Alexander Ivanyukovich

출처 : http://wiki.apache.org/tomcat/Tomcat/UTF-8


Tomcat/JSP와 한글 이미 okjsp에 잔뜩 올라왔던 내용인데요, 걍 총정리 차원에서 올려봅니다.

Tomcat 한글 설정하기 일반적으로 웹 어플리케이션이 GET과 POST 방식으로 파라미터를 넘겨 받을 때
request.setCharacterEncoding()을 통한 문자셋 인코딩이 필요하다.

## Tomcat 4.x 단순히 JSP 혹은 서블릿의 최 상단에
request.setCharacterEncoding("euc-kr");을 하면 된다.

GET과 POST 방식에 상관없이 인코딩을 해준다.

## Tomcat 5.x POST 방식은 request.setCharacterEncoding("euc-kr");로 계속 하면된다.

하지만 GET 방식은 server.xml의
<Connector>
 설정 부분을 바꿔줘야만 한다.

 <Connector port="8080" maxThreads="150" minSpareThreads="25"
  maxSpareThreads="75" enableLookups="false" redirectPort="8443"
  acceptCount="100" debug="0" connectionTimeout="20000"
  disableUploadTimeout="true" URIEncoding="euc-kr" />

 위에서 URIEncoding="euc-kr" 부분이다.

 결론적으로 Tomcat 4.x와 Tomcat 5.x 는 모두 request.setCharacterEncoding()이
 필요하다는 사실에는 변함이 없다.

 ## 한글 파라미터를 가진 링크를 만들 때 JSP페이지에서 링크를 생성할 때, 한글이 됐든 공백이나 특수문자를 가진 영어가
 됐든, 순수하게 영어와 숫자, 밑줄 등으로만 이뤄진게 아닌 모든 파라미터를 넘길 때는 무조건 URLEncoding을
 해야한다고 봐도 된다.

 Web Container에 따라 URLEncoding을 안하고 넘겨도 작동하는 경우가 있는데, 동일한 웹 컨테이너라도
 버전에 따라 한글을 제대로 인식하지 못하는 경우도 있고, 또 다른 컨테이너에서는 URLEncoding이 안된 한글을 전혀
 인식하지 못할 수도 있다.

 그러므로 무조건 표준을 따라서 java.net.URLEncoder.encode()메 소드를 사용해 인코딩해서 넘기도록
 한다. 디코드 작업은 request.setCharacterEncoding()에 의해서 자동으로 이뤄지므로 해줄것이
 없다.(Tomcat 3.x대- JSP Spec 1.1 -에서는 request.setCharacterEncoding()이
 없으므로 String.getBytes()를 이용해 직접 디코딩을 해줘야만 했다)

 ## <%@ include file="test.jspf"%> 에서의 한글 위와 같이 test.jspf를 static
 include 할 경우에 test.jspf에 있는 한글이 모두 깨질 수 있다. test.jspf에도 한글 설정이 필요한데,
 이 경우에는 test.jspf의 최 상단에 다음을 추가하면 된다.

 <%@page pageEncoding="euc-kr"%>

 * static include : JSP 페이지를 컴파일하는 시점에 해당 jspf 파일의 내용을 문자열 그대로 현재
 jsp에 삽입하여 컴파일 하는 것. static include 방식에서 include 되는 대상 jsp의 확장자는
 .jspf로 하는 것이 표준이다. .jspf 는 단독 실행을 위한 것이 아니라 항상 다른 JSP에 포함되어 쓰이는 목적으로
 만들어졌기 때문에 완전한 JSP의 형태를 갖추고 있지 않다. *
 <jsp:include page="" />
 이 방식은 동적 include 방식으로, JSP 페이지가 실행되는 중간에 page에 지정된 jsp를 실행한 결과를 삽입하는
 방식이다. 이 방식에서는 include 되는 JSP 페이지가 원래부터 페이지 인코딩 정보 등을 포함한 완전한 JSP 형태를
 갖추고 있어야만 한다

 

출처 : http://www.okjsp.pe.kr/bbs?act=VIEW&seq=57865&bbs=bbs4&keyfield=content&keyword=&pg=2
 

출처 : Tong - 스킬부족님의 JSP/Servlet통

블로그 이미지

희망잡이

,


아키텍쳐관점에서 필요기술을 접목하여 구현가능한 방법을 제시하고자 한다.

자료출처는 인터넷환경에 존재하는 검색엔진( 구글 : 80%, 네이버 : 20% )의 도움을 받았다.

 

시스템아키텍쳐 구성은 아래와 같다.

클라이언트 단은 웹브라우저를 사용하고, 프리젠테이션 단은 JSF를 사용하여 간단하게 구현하고자 한다.

 

WAS는 Tomcat을 사용하고, 개발툴은 Eclipse를 이용하였다.

프로그램언어는 자바언어이고, 다국어지원을 위해 I18N과 L10N에서 지원하는 패키지를 사용한다.

Encoding CharacterSet은 UTF-8을 사용한다.

ResourceBundle에서 가져올 Message는 한국어, 영어 , 일어, 중국어로 구성된 파일을 만든다.

 

ReourceBundle을 막상 작성할려고 하면 번거로운데... 플러그인이 존재한다.

사용법 : 자바 ResourceBundle사용하기 http://decoder.tistory.com/48

플러그인 사이트 : ResourceBundle Editorhttp://www.resourcebundleeditor.com/wiki/ResourceBundleEditor

금방 플러그인설치하고 사용해봤는데 예상외로 기능이 탁월한 것으로 보입니다.

 

스트럿츠 프레임워크에서의 메시지 처리

스트럿츠를 사용하면서 메시지 파일을 매번 native2ascii로 컴파일하기 짜증나고 귀찮으셨죠?

build.xml에 걸어놔도 결국 똑같은 파일이 2개씩 유지되는게 왠지 찜찜하지 않으신가요?

이것은 스트럿츠에서 메시지 파일을 읽어올때 사용하는 Java의 Properties 클래스가 ISO 8859-1만 지원해서 생기는 문제로, 스트럿츠의 MessageResourcesFactory를 상속받아 메시지 파일을 UTF-8로 읽도록 구현하면 해결할 수 있습니다. UTF-8은 단일 문자셋으로 여러 언어를 지원하므로 한국어 뿐만 아니라 다른 언어를 사용할때도 번거롭게 native2ascii를 사용할 필요가 없게 됩니다.

 

Ant에서 native2ascii 사용하기

 <target name="native2ascii" depends="javadoc">
  <native2ascii encoding="UTF-8" src="${src.dir}" dest="${class.dir}" includes="**/*.properties">
  </native2ascii>
 </target>

 사용결과물은 test.txt파일에 金起燮! 내용을 저장하고, result.txt로 변환하면 결과는 아래와 같다.

 \ufffd\ufffd\ufffd\ufffd\ufffd!

 

결론적으로 위의 플러그인은 native2ascii 을 편하게 사용하기 위해서 만든것으로 보인다.

 

생각에 대한 결론

1. 웹화면에서 Request로 웹서버에 요청할때 파라미터 값은 필터링에서 적용한 Encoding Type에 따라변환될 것이다.

2. 웹서버에서 Response되어서 웹화면에 나타날때는 Page 태그에 적용된 Encoding Type에 따라 변환될것이다.

3. 자원(Resource)파일들은 저장시에 native2ascii를 사용하여 웹화면에서 사용하는 Page 태그에 해당하는 Encoding Type

   으로 변환하여 저장할 필요가 있다. 화면에서 문자가 깨지지 않는다. 다국어인 경우에는 UTF-8 이 해답일 것이다.


블로그 이미지

희망잡이

,


자바는 문자를 처리하는 코드로 유니코드(Unicode)를 사용한다. 유니코드는 2byte를 사용하여 한 문자를 처리하는 방식으로 거의 모든 나라의 언어를 처리할 수 있다.

 

*UTF-8은 무엇인가?
UCS와 Unicode는 무엇보다도 단시 문자에 정수 숫자를 할당한 코드 테이블일
뿐이다. 이러한 문자들의 순서를 어떻게 할 것인가? 또는 이 문자들의 정수 값을
어떻게 바이 트 순서로 표현할 것인가에 대해서는 여러가지 방법이 존재한다.
Unicode 문자열을 저장하는 확실한 표현방법은 2 또는 4 바이트 순서로 표현하는
두가 지 방법이 존재한다. 이러한 표현방법의 공식적인 이름은 UCS-2와
UCS-4이다. 그리고, 특별히 확정지을 필요없없지만, Bigendian 표현방법을
따른다.(작은 수가 먼저 나온다.) ASCII와 Latin-1 화일은 ASCII 바이트의 첫번째
0x00 바이트 부터 삽입함으로 해서 UCS-2 포맷으로 간단하게 변환시킬 수 있다.
만약 UCS-4 화일을 사용하기를 원한다면, ASCII 바이트를 삽입하기 전에 세개의
0x00 바이트를 모든 코드에 삽입해야 한다.
Unix에서 UCS-2나 UCS-4를 사용하기 위해서는 매우 심각한 문제가 발생된다. UCS
표현방법을 사용하는 문자열은 화일 이름이나 C 라이브러리의 함수 매개 변수에서
''이나 '/'과 같이 특별한 의미를 가지는 많은 wide character를 가질 수 있다.
그리고, UNIX 도구들의 대부분은 ASCII 파일이고, 중요한 변화없이 16 비트
워드를 한 문자로 읽을 수가 없다. 이러한 이유는 UCS-2는 화일 이름이나 텍스트
화일, 환경변수에서 적절한 Unicodei의 외부 표현방법이 아니기 때문이다.
ISO 10646-1에 정의된 UTF-8 Annex R 과 RFC 2279표현 방법은 이러한 문제점을
가지고 있지 않다. UTF-8은 Unix와 같은 운영체제에서 Unicode를 사용하는데
확실한 방법 이다.
UTF-8은 다음과 같은 성질을 가지고 있다:
UCS 문자 U+0000 부터 U+007F(ASCII)들은 0x00 부터 0x7F 바이트 까지로 간단하게
표현된다(ASCII 호환성). 이 것의 의미는 7-bit ASCII 문자들을 화일과
문자열들도 ASCII와 UTF-8양 코드 집합에서 모두 같은 방식의 표현 방법을
사용한다는 것이다.
모든 UCS 문자 >U+007F들은 대부분 특정 비트 집합인, 몇 바이트의 시퀀스로 표현
된다. 그러므로 ASCII 바이트(0x00-0x7F)는 어떤 다른 문자집합의 부분으로
나타낼 수 있다.
ASCII 문자가 아닌 것을 표현하는 다중 바이트 집합의 첫번째 바이트는 항상 0xC0
부타 0XFD이고, 이 부분은 이 문자 뒤에 얼마나 많은 바이트가 존재할지를 가르킨
다. 다중 바이트 집합에서 모든 다음 바이트의 범위는 0x80부터 0xBF이다. 이것은
쉬운 재매칭을 가능케 하고, 표현의 안정성을 얻어 낼 수 있으며, missing bytes
에 대해 완벽성을 기해준다.(쩝 번역 이상!!)
모두 231개의 UCS 코드가 표현 가능하다.
UTF-8로 표현된 문자들은 이론적으로 6바이트가 될 수 있다. 그러나, 16 비트 BMP
문자들은 단지 3 바이트이면 된다.
Bigendian UCS-4 바이트 문자열의 정렬방법은 정해져 있다.
0xFE와 0xFF 바이트는 UTF-8에서는 사용되지 않는다.
다음의 바이트 순서는 문자를 표현하는데 사용된다. 다음의 순서는 Unicode의
문자수에 의존적으로 사용된다:
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
10xxxxxx
xxx로 표현되어 있는 비트들은 바이너리 표현에서 문자 코드 수의 비트 로
표현된다. 가장 오른쪽의 x 비트는 least-significant(??) 비트이다. 가장 짧게
표현 가능한 다중 바이트 표현은 각 문자가 사용하는 코드 숫자의 표현이다. 다중
바이트 표현에서 가장 중요한 것은, 첫번째 바이트에서 1비트로 표현되어 있는
코드의 의미는 전체 코드가 표현할 수 있는 바이트의 갯수와 같다는 점이다.
Examples: Unicode 문자 U+00A9 = 1010 1001 (copyright sign) 은 UTF-8에서는
다음과 같이 표현된다.
11000010 10101001 = 0xC2 0xA9
그리고 Unicode 문자 U+2260 = 0010 0010 0110 0000 (not equal to)은 다음 과
같이 표현된다:
11100010 10001001 10100000 = 0xE2 0x89 0xA0
이 표현 방법의 공식 이름은 UTF-8이고 이 약어의 정확한 이름은 UCS
Transformation Format이다. 그리고, 이 이름은 utf8이다 UTF_8과 같이 다른
방법으 로 문서나 그외의 다른 방법으로 표현하지 않기를 권한다.
UTF-8 표현을 다루는 개발자들을 위한 중요한 노트: 안전을 위해, 좋은 UTF-8
복호기(decoder)는 문자를 encode 하기 위해 필요한 크기 이상의 UTF-8 문자열은
받아들여서는 안된다. 예를 들어, 문자 U+000Ai (line feed)는 꼭 0x0A의
영역에서 UTF-8 코드를 받아들여야 하고, 아래와 같은 5개와 같이 보다 긴 형식은
받아 들여서는 안된다:
0xc0 0x8A
0xe0 0x80 0x8A
0xf0 0x80 0x80 0x8A
0xf8 0x80 0x80 0x80 0x8A
0xfc 0x80 0x80 0x80 0x80 0x8A
임의의 목적 코드보다 큰 UTF-8 문자은 encoding하는데 필요한 가장 작은 코드
부분만 을 사용하는 UTF-8 하부 문자열 테스트에서는 그냥 통과될 수 있다.
필요이상으로 큰 모든 UTF-8 문자는 다음과 같은 바이트 패턴을 가지고 시작된다:
1100000x (10xxxxxx)
11100000 100xxxxx (10xxxxxx)
11110000 1000xxxx (10xxxxxx 10xxxxxx)
11111000 10000xxx (10xxxxxx 10xxxxxx 10xxxxxx)
11111100 100000xx (10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx)

블로그 이미지

희망잡이

,