JVM의 로케일 Charset과 관련한 오류사항 기록

현재 해결중인 사항이지만 오류사항이 되게 신선했어서 기록으로 남겨놓는다..

 

 

회사의 솔루션을 납품하면서 발생한 문제인데 꽤 오래전에 납품했는데 여태 오류가 없다가 최근에 발생이 되서 확인을 해보았다.

오류사항이 DB의 테이블에 설정한 컬럼크기보다 더 많은 양의 글자가 입력되어 발생이 된 오류였다.

 

일단 급한대로 부랴부랴 컬럼의 크기를 늘리는 것으로 해결을 했다.(당장 사용을 해야하는데 안되는 걸..)

---

[오류내용]

문제가 발생된 고객사는 해외고객사이며, 서버의 역시 해외에 있다. 또한 PC는 윈도우 서버를 사용하는 업체였다.

문제는 서버에서 발생이 된 것으로 추측이 된다. 현재 재직중인 회사의 솔루션은 대부분 한글, UTF-8를 사용을 하는 곳이 대부분 이었기에 크게 문제가 발생하지 않았었다.

 

그러면서 사용한 부분이 getBytes()메소드 였다.

 

getBytes 메소드는 String 매개변수를 받는 메소드와 받지 않는 메소드가 있다. 두개는 아래와 같은 차이가 있다

• 매개변수를 지정하는 메소드
  • 어떤 문자열로 getBytes를 진행할 지 Charset을 String에 지정해야 한다.
• 매개변수를 받지 않는 메소드
  • getBytes를 지정하나 위와 다르게 Charset을 defaultCharset으로 진행하게 된다.

 

회사의 솔루션에서 getBytes()를 진행하는 부분이 있었고, 매개변수를 넣지 않고 메소드를 사용하는 소스코드 였다.

defaultCharset이 UTF-8이면 상관이 없겠지만, defaultCharset은 OS레벨의 locale의 영향을 받고 그래도 없으면 UTF-8을 리턴한다.

 

문제는 locale의 영향을 받아버려 windows-1252라는 인코딩 타입이 설정이 되버린 것이다..

그로 인해 getBytes를 진행하면서 한글 바이트에 대한 계산이 엉망이 되고 DB에 삽입이 되지 못하는 오류가 발생하게 되었다.

---

현재 오류에 대한 수정은 getBytes를 사용하는 부분의 인코딩을 전부 수정해주는 쪽으로 진행을 해야할 것 같다.

이미 사용을 한지 기간이 오래되어 인코딩타입을 다시 지정해버리면 파일과 관련해서도 문제가 발생해버릴 가능성이 높아보여서다..

ㅠㅠ.... 

---

​​

추후에 프로젝트를 진행해보면 로케일을 고려한 프로젝트도 한번 해보는 것도 재밌어 보인다.

아래는 로케일에 따라 설정값을 바꿀수 있어 보이는 예제들을 미리 구해봤다.

시간될때 해봐야겠다 :)....

 

https://carrotweb.tistory.com/48

http://daplus.net/java-jvm%EC%97%90%EC%84%9C-%EA%B8%B0%EB%B3%B8-%EB%A1%9C%EC%BC%80%EC%9D%BC%EC%9D%84-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%84%A4%EC%A0%95%ED%95%A9%EB%8B%88%EA%B9%8C/