euc-kr , UTF-8 에 대한 삽질의 결과

심플 결론  

JAVA 파일 인코딩	윈도우 환경 wirte	리눅스 환경 (스트링 write )
EUC-KR	EUC-KR 로 저장	LANG  환경에 의존적
UTF-8	UTF-8 로 저장 됨	LANG  환경에 의존적

즉 리눅스 환경에서 원하는 인코딩으로 파일 or 스트림    write 를 하고 싶은 경우는 only 스트림 처리로만 해야한다. 

왜냐하면 to_string() 으로 변하는 순간  JAVA 가 LANG 환경을 따라가려고 하기때문!

http://blog.daum.net/wooriaru/21 해결의 실마리의 글!

 

이글의 링크

 

길게 주저리 주저리 설멍 하는것 보다. 간단히 소스를 기입 하겠다.

 

//euc_kr_str - euc-kr 문자열

CharBuffer cbuffer = CharBuffer.wrap((new String(euc_kr_str, "EUC-KR")).toCharArray());

Charset utf8charset = Charset.forName("UTF-8");

ByteBuffer bbuffer = utf8charset.encode(cbuffer);

 

//변환된 UTF-8 문자열

String tmpDecode = new String(bbuffer.array());

 

 

 

# 참고 사이트

http://stackoverflow.com/questions/655891/converting-utf-8-to-iso-8859-1-in-java-how-to-keep-it-as-single-byte

 

# new String(str.getByte("euc-kr"), "utf-8))  변환이 안되는 이유는 아래 링크를 참조 하기 바란다.

http://airlee00.blogspot.kr/2013/10/charset-euc-kr-utf-8-ms949-cp933.html

http://mhhan.tistory.com/entry/Java-Character-Set%EC%9D%98-%EC%9D%B4%ED%95%B4

공감 MY공감 >

 

 

 

 

 

 

 

 

http://kldp.org/node/129659

 

0. 먼저, ANSI와 euckr은 다른 개념입니다. ANSI를 한국에서 확장한 것이 euckr입니다. 비슷하게 일본에서도 eucjp라는 확장이 존재하고요. 그래서 같은 데이터가 인코딩에 따라 다르게 보이는 문제를 해결하기 위해서 "모든 문자에 유일한 값을 배정하자"는 개념이 유니코드입니다.

1. 유니코드 자체는 ansi/euckr/utf8 등과 같은 '바이트 인코딩'이 아닙니다. 유니코드는 문자를 그냥 숫자 하나로 매핑하는 개념입니다. 예를 들어 'A'는 65, '가'는 44032에 매핑됩니다.

2. 그런데 우리는 보통 임의의 큰 숫자를 저장하는 게 아니라, 가령 8비트 숫자들만 다루게 됩니다. 그렇다면 44032라는 숫자를 어떻게든 끊어서 8비트 안에 담아야 할 겁니다. 이것을 utf-8이라고 부릅니다.
utf8로 44032를 담으면 (234, 176, 128)이라는 3바이트 배열이 됩니다. 16진수로 표현해보면 0xEA 0xB0 0x80이고요. http://ko.wikipedia.org/wiki/%EA%B0%80 이 url에서 나타나는 퍼센트 값들이 바로 이것입니다.

3. 마찬가지로 16비트 기반으로 데이터를 저장하면 utf-16이 됩니다. 그런데 또 주의해야 할 게 우리는 보통 데이터를 8비트로만 담기 때문에, 16비트 데이터는 8비트 두 개로 저장하게 됩니다. 여기에서 엔디안이 튀어나오게 되고요(little endian, big endian).

4. utf16이 '모든 문자의 크기가 같다'는 것은 오래 된 미신입니다. 16비트면 가능한 조합은 2^16 = 65536이 될텐데, 그렇다는 말은 65536을 넘어가는 유니코드 문자는 역시 16비트 두 개 이상이 필요하게 됩니다.
그런데 우리의 입장에서 이런 문자는 거의 만날 일이 없고, 그래서 그냥 유니코드 중 65535까지만 지원하는 인코딩이 있었습니다. 이건 UCS-2라고 부르고, 현재는 거의 사용하지 않습니다.

5. utf8의 강점은 ANSI와 상당히 호환된다는 것입니다. (ANSI로도 'A'는 65였죠.) utf16의 강점은.. 2^16 = 65536이니까 한글이 16비트 한 단위에 깔끔하게 들어가게 됩니다. 즉 2바이트만 소요되죠. utf8이라면 3바이트가 소요됩니다.
개인적으로 저는 용량 이점보다 엔디안의 복잡함 + ANSI와 호환안됨의 두 단점이 더 크다고 봅니다

 

나만의 방법으로 유니코드를 ansi 로 맵핑하는 글

http://blog.naver.com/declspec/10092640244