반응형
글깨짐 확인 소스..




1. charset의 의미
charset = "coded character set"
charset은 "컴퓨터에서 문자를 표현하기 위해, 각 문자를 정수값에 대응시켜 놓은 체계"를 의미합니다.

예를 들어, euc-kr charset이라면, 영숫자와 한글 그리고 일부 특수문자와 한자들을 정수값에 대응해 놓은 것입니다.
euc-kr환경에서 한글을 입력하면, 컴퓨터는 euc-kr charset에서 각 문자별로 지정한 정수값을 쓰게 됩니다.

2. charset이 달라진다면..
각 charset별로, 표현하고자하는 문자와 대응하는 정수값이 달라질 수 있습니다.
예를들어 euc-kr은 태국문자를 위한 정수값을 정의하지 않았으므로, 태국문자는 표현하거나 입력할 수 없습니다.

그리고, euc-kr charset에 맞춰 한글로 어떤 내용을 작성했는데,
이것을 iso-8859-1 charset 환경에서 열어본다면, 한글 대신에 엉뚱한 특수문자쌍들을 보게 될 것입니다.

이런 문제 때문에, 문자 데이터를 주고 받을 때는 서로 간에 charset을 일치시킬 필요가 있습니다. 그렇지
않으면, 원래 생각했는 내용 대신 "깨진 문자들"을 보게 될테니까요.
( 가끔 charset은 일치되었는데, 사용하는 폰트에 대응하는 문자가 없어서 깨져보이는 경우도 있습니다. )

서블릿 코딩시에, content type의 일부로 charset을 명시하는 것은 웹 브라우저에게 사용하는 charset을
알려주어 오해하지 않게 하기 위해서입니다.

3. 한글을 표현할 수 있는 charset
한글을 표현할 수 있도록 설계된 charset은 euc-kr외에도, ksc5601, cp933, cp949 등등 꽤 많습니다.
그리고, 전세계 모든 문자를 표현할 목적으로 설계된 unicode역시 한글을 지원합니다.
그러나, 한글을 지원하는 charset을 사용하더라도, 문서를 만들 때 사용한 charset과 읽을 때 사용하는
charset이 다르다면, 제대로 그 내용을 볼 수 없을 것입니다. 이 경우에는 따로 conversion로직을 사용하여
원하는 charset에 맞춰 데이터를 가공해야 할 것입니다.
( euc-kr, ksc5601 같은 경우는 거의 차이가 없어 호환가능합니다. )

3. 영문 OS에서 한글 표현
charset에 맞추어 문자데이터를 처리하는 것은 OS나 DBMS, 미들웨어 등 플랫폼이므로, 플랫폼에서
제공해주지 않는 charset을 사용할 수는 없습니다.
다행히도, 최근의 플랫폼 SW들은 다양한 charset 지원을 포함하고 있습니다. 만약 어떤 OS가 euc-kr모드로
작동하고 있다면, 설령 영문OS라 하더라도, 한글 처리에 문제가 없다고 볼 수 있습니다.
문제가 있다면 euc-kr모드로 작동하고 있는 것이 아니겠죠.

저 같은 경우, 영문 OS를 설치하고, 그 위에서 한글을 사용해 본 적이 있습니다.

4. encoding
charset과 비슷한 의미로 사용하는 단어로 encoding이 있습니다.
charset이 문자에 대해 정수값을 지정한 것이라면,
encoding은 "문자를 표현하는 정수값을 어떤 bit배열로 표현할 것"인지를 의미합니다.

대부분의 경우, charset과 encoding을 구별할 필요가 없습니다. 왜냐하면 정수값을 bit배열로 표현하는 방법은
하나만 있을테니까요. 그러나 unicode 경우에는 UTF-8, UTF-16 같이 몇 가지 다른 encoding을 사용합니다.
charset이 같다면, 그 charset을 지원하는 어떤 encoding을 사용하든지, 각 문자에 대응하는 논리적인 정수값은 동일합니다.
그러나 실제로 기록되는 bit배열은 encoding에 따라 달라질 수 있습니다. 이 경우, 제대로 데이터를 주고 받으려면, charset뿐 아니라 encoding까지도 맞춰야 합니다.
반응형
<출처: http://frogdaddy.tistory.com/entry/weblogic61에서charset변경작업 >
1. 작업 환경

OS: Windows2003 
웹브라우저 : ie7.0 
웹서버/WAS : weblogic6.1 
JAVA : jdk1.3
DB : EUC-KR charset 환경 
      ( DB 도 utf-8 로 바뀌어야 완벽한 작업이 될것으로 예상됨 , 
        나중에 기회가 되면 DB 의 charset 변경작업을 하게되면 blog 로 작성하겠음...)


2. 작업내용

(1) web.xml  파일 수정  : euc-kr 을 utf-8 로
<?xml version="1.0" encoding="UTF-8"?>
<!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>
  <context-param>
    <param-name>weblogic.httpd.inputCharset./*</param-name>
    <param-value>UTF-8</param-value>  
 </context-param>
</web-app>

(2) weblogic.xml  파일 수정  : euc-kr 을 utf-8 로
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 6.1//EN" "http://www.bea.com/servers/wls610/dtd/weblogic-web-jar.dtd">
<weblogic-web-app>
  <jsp-descriptor>
    <jsp-param>
      <param-name>encoding</param-name>
      <param-value>UTF-8</param-value>
    </jsp-param>
  </jsp-descriptor>
  <charset-params>  
    <input-charset>      
      <resource-path>./*</resource-path>      
      <java-charset-name>UTF-8</java-charset-name>    
    </input-charset>  
  </charset-params>
</weblogic-web-app>
 
(3) JSP 의 charset 지정 : euc-kr 을 utf-8 로
<%@ page language="java" contentType="text/html; charset=utf-8" %>

(4) HTML 의  meta tag 의 charset 지정 : euc-kr 을 utf-8 로
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">



3. 유의사항

* ultraediter, jbuilder 로 charset 을 변경한 후 저장하면, weblogic 에서 null pointer exception 오류가 발생함.
   웹셔핑으로 얻은 지식으로 여러가지 방법을 해보았으나, 잘 되지 않았음 ㅠㅠ'

   (utf-8 로 charset 을 지정하면 위 editor 가 file type 설정을 변경시키는듯 합니다. 
    BOM 의 영향이 있는것 같기도 하고.. 
    eclipse 에서 charset 을 utf-8 로 수정한후 저장한 파일을 ultraedit 에서 수정하면 위 오류 발생하지 않음)

* eclipse 에서 편집한후 저장하면 위 오류는 발생하지 않았음.
   ( 기존 jbuilder 에서 작업한 파일시스템을 eclipse 로 import 작업이 필요함)



4. 기존 File Directory ( 웹 directory ) 를  Eclipse 에서 작업하는 방법

(1) 기존 eclipse 의 프로젝트의 폴더의 '.project' , '.classpath' 를  eclipse 에서 작업할 웹 directory 폴더에 copy 한다.
( '.project' , '.classpath' 의 내용을 적당히 수정한다. 내용 수정없이도 import 가 되긴 했는데... ^^; )

(2) eclipse -> File -> Import 
-> General -> Existing Projects into Workspace 
-> 위에 '.project' , '.classpath' copy 된 폴더 선택
반응형

이기종의 플랫폼과 연동할 이슈가 발생하면, 네트웍을 통한 Byte Ordering과 더불어 스트링의 인코딩/디코딩도 이슈거리입니다.  아래는 자바 API 5의 java.nio.charset.Charset 에 나오는 내용입니다.

표준 캐릭터셋
Java 플랫폼의 구현은 모두 다음의 표준 캐릭터셋를 지원 할 필요가 있습니다. 지원 되고 있는 그 외의 캐릭터셋에 대해서는 구현의 릴리스 노트를 참조하십시오. 그러한 옵션의 캐릭터셋의 동작은 구현 마다 다를 가능성이 있습니다.

캐릭터셋           설명
US-ASCII          7 비트 ASCII (ISO646-US/Unicode 캐릭터셋의 Basic Latin 블록)
ISO-8859-1      ISO Latin Alphabet No. 1 (ISO-LATIN-1)
UTF-8                8 비트 UCS 변환 형식
UTF-16BE        16 비트 UCS 변환 형식, 빅 endian 바이트순서
UTF-16BE        16 비트 UCS 변환 형식, little endian 바이트순서
UTF-16             16 비트 UCS 변환 형식, 옵션의 바이트순서 마크로 식별되는 바이트순서

아래코드는 예제입니다.
class CharSetTest {

    static String aa = "a1";

    static void testAscii() {
        try {
            byte[] bytes = aa.getBytes("US-ASCII");
            for(int i=0; i < bytes.length; i++) {
                System.out.print(bytes[i]);
            }

            System.out.println("");
        }catch(java.io.UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }

    static void testUTF8() {
        try {
            byte[] bytes = aa.getBytes("UTF-8");
            for(int i=0; i < bytes.length; i++) {
                System.out.print(bytes[i]);
            }

            System.out.println("");
        }catch(java.io.UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }

    static void testUTF16() {
        try {
            byte[] bytes = aa.getBytes("UTF-16");
            for(int i=0; i < bytes.length; i++) {
                System.out.print(bytes[i]);
            }

            System.out.println("");
        }catch(java.io.UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }

    static void testUTF16BE() {
        try {
            byte[] bytes = aa.getBytes("UTF-16BE");
            for(int i=0; i < bytes.length; i++) {
                System.out.print(bytes[i]);
            }

            System.out.println("");
        }catch(java.io.UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }

    static void testUTF16LE() {
        try {
            byte[] bytes = aa.getBytes("UTF-16LE");
            for(int i=0; i < bytes.length; i++) {
                System.out.print(bytes[i]);
            }

            System.out.println("");
        }catch(java.io.UnsupportedEncodingException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        System.out.println("--- Ascii ---");
        CharSetTest.testAscii();
        System.out.println("--- UTF-8 ---");
        CharSetTest.testUTF8();
        System.out.println("--- UTF-16 ---");
        CharSetTest.testUTF16();
        System.out.println("--- UTF-16BE ---");
        CharSetTest.testUTF16BE();
        System.out.println("--- UTF-16LE ---");
        CharSetTest.testUTF16LE();
    }
}
아래 예는 화면결과 입니다.
--- Ascii ---
9749
--- UTF-8 ---
9749
--- UTF-16 ---
-2-1097049
--- UTF-16BE ---
097049
--- UTF-16LE ---
970490
< 출처: http://www.sjava.net/62 >

+ Recent posts