GGT의 개발 블로그

유니코드를 활용한 개발 일지

유니코드라는 단어는 많이들 들어봤지만 실제로 어떻게 사용되고 있고 어떤 존재인지 자세히 아는 경우는 드물다. (사실 내가 그랬다.) 현재 데이터를 다루는 일을 하고 있다보니까 문자열을 다

ggtan.tistory.com

위 글에서 나타났던 원인을 드디어 발견했다!

환경에 따라 Supplementary Character에 대해 replaceAll()이 수행이 되지 않는 경우가 존재해서

계속 원인이 무엇일까 하며 JDK 별 / 버전 별 자바 구현체 코드를 뜯어보았다.

뜯어본 JDK는 Oracle, OpenJDK - 8/11/16이며

정확히 16버전에서 자바 정규식 검사를 위한 Pattern 클래스 내 사소한 변화가 있는 것을 확인하였다.

이걸 토대로 관련 정보 구글링해보니 나오네.. 링크(https://bugs.openjdk.java.net/browse/JDK-8247546)

간단히 설명하자면

Supplementary Character들은 2개의 Char를 이용해 Surrogate Pair로 저장이 되는데

기존 JDK 16이전에서는 각각의 Pair에 대해 개별적으로 정규식 매칭이 가능했다.

(정확히는 High는 안되고 Low만 됨)

이러한 로직이 굉장히 일관적이지 못하다 생각하고 있었는데

사실 Low Surrogate만 되는게 의도한 것이 아니였으며

16부터는 해당 버그가 고쳐지게 되어서 Surrogate 개별적으로 매칭이 더이상 되지 않게 변경된 것!

따라서 Supplementary Character를 다룰때 정상적으로 로직을 구현하고자 한다면

Surrogate Pair를 개별적으로 값을 바꾼다거나 없앤다거나 하지 않는 것이 좋아보인다.

어차피 이 Pair는 결과적으로 자바의 char형이 2byte라는 태생적 한계를 극복하고자 만들어진 저장 수단이기 때문에

한 글자로 보는게 좋을 것 같다.

결국 스파크에서 나타난 문제로 인해서

스칼라 -> 자바 -> JDK 소스까지 뜯어본 후기..

GGT 블로그