예를 들어 해당 파일이 Windows의 MS949로 작성되었다면 MS949 인코딩 옵션(javc -encoding=ms949)으로 컴파일 해야 한다. MS949(=CP949)는 MS에서 만든거라, Unix에서 이 파일을 컴파일 할려면 MS949인코딩과 거의 호환되는 euc-kr을 인코딩 옵션으로 주어서 컴파일 해야만 한글이 깨지지 않고 unicode로 잘 바뀌어 클래스안에 살포시 예쁘게 들어간다.
이를테면 MS949로 “찦차타고 온 똠방각하”표현이 가능하지만 , euc-kr인코딩에는 “찦”, “똠”에 대한 인코딩 룰이 없으므로 euc-kr로 해당 파일을 읽어보면 “찦”, “똠” 글자는 깨진다. 해당 파일이 utf8로 인코딩되어 있다면 컴파일시에도 uf8인코딩으로 컴파일하면 된다. (javac 컴파일 할 때 encoding 옵션을 주지 않으면, jvm의 시스템 인코딩이 자동으로 세팅된다.)
오히려 실행환경의 인코딩과는 다른 별동의 인코딩을 준다면 한글이 깨진다.예를 들어 실행환경은 euc-kr이 인코딩으로 설정되어 있는데, -Dfile.encoding=utf8로 설정하여 java명령을 실행하는 경우, JVM이 byte code로 부터 한글을 읽어일일때 utf8로 읽어들여서 OS영역으로(console)로 넘겼는데, console에서는 넘겨받은 놈을 euc-kr 인코딩 방식으로 해석하려 들면서 한글이 깨지게 된다.
이 때 주의할점은 jvm 인코딩(-Dfile.encoding)과 OS의 인코딩이 일치한다하더라도 SSH 툴의 인코딩이 다르면 또한 한글이 깨질 수 있으며(SSH의 인코딩도 해당 툴 환경설정에서 일치시켜주자), 셋 다 일치시켰다 하더라도 해당 인코딩이 ISO-8859_1이라면 한글이 깨진다. 왜냐하면, ISO-8859_1에는 한글을 표현하는 문자셋이 없기 때문이다. 이 경우에는 한글을 표현할 수 있는 문자셋과 인코딩으로 OS인코딩을 변경한 후 3개의 인코딩을 일치시켜야 한다.
추가
하기처럼 코딩된 Java 파일의 인코딩 형식이 (Windows에서 작성된) MS949이며 ISO-8859_1환경의 Unix서버에서 컴파일되는 경우 컴파일 옵션을 ISO-8859_1로 주어야, runtime시 한글이 깨지지 않을 것이다.
System.out.println(new String( “한글”.getBytes(“ISO8859_1”), “EUC_KR” ));