CUBRID 에서는 현재 문자 코드셋을 지원하지 않습니다. 관련된 질문들이 상당히 많아 간단히 정리합니다.
1. 입력되는 문자셋이 그대로 저장되어, 검색시 처음 입력한 문자셋으로 보여집니다. 이 과정에서 어떠한 변화도 이루어 지지 않습니다.
* 입력한 문자셋이 UTF-8 이면 검색시 문자셋도 UTF-8 이 됩니다. 간혹 검색시 문자가 깨져보이는 경우는 입력하는 곳과 검색하는 곳에서 관리하는 문자셋이 다르기 때문입니다. 응용에서의 문자셋 처리를 확인해 보실 필요가 있습니다.
2. 문자의 길이는 byte 단위를 기본으로 합니다. 한글에 대한 별도 처리가 없습니다. 즉, EUC-KR 이면 한글1자의 길이는 2이며, UTF-8 이면 3의 길이값을 가집니다.
3. 문자를 byte 단위로 처리하므로 substring 계열을 사용시 한글의 경우 짤릴 수가 있습니다. 따라서 응용에서 잘린 한글 1문자에 대한 처리를 해 줄 필요가 있습니다. 예를 들어 EUC-KR 의 경우 한글 한문자는 2개의 byte 로 이루어지며, 첫byte는 ascii 값이 127보다 큰값을 가지지만 두번째 byte 에 대한 규칙이 없습니다. 따라서 substring 10자인 경우 10자로 자른후 첫번째 byte 부터 ascii의 값을 확인하여 10번째 byte 가 한글 두번째 byte 인지를 확인해야 합니다.
추가적으로 UTF-8 로 저장된 문자열에 대하여 검색 방법 몇가지에 대한 글을 소개합니다.
UTF8 로 저장된 데이터를 매니저로 조회하는 방법
utf-8 데이터 like 검색 시 설정
1. 입력되는 문자셋이 그대로 저장되어, 검색시 처음 입력한 문자셋으로 보여집니다. 이 과정에서 어떠한 변화도 이루어 지지 않습니다.
* 입력한 문자셋이 UTF-8 이면 검색시 문자셋도 UTF-8 이 됩니다. 간혹 검색시 문자가 깨져보이는 경우는 입력하는 곳과 검색하는 곳에서 관리하는 문자셋이 다르기 때문입니다. 응용에서의 문자셋 처리를 확인해 보실 필요가 있습니다.
2. 문자의 길이는 byte 단위를 기본으로 합니다. 한글에 대한 별도 처리가 없습니다. 즉, EUC-KR 이면 한글1자의 길이는 2이며, UTF-8 이면 3의 길이값을 가집니다.
3. 문자를 byte 단위로 처리하므로 substring 계열을 사용시 한글의 경우 짤릴 수가 있습니다. 따라서 응용에서 잘린 한글 1문자에 대한 처리를 해 줄 필요가 있습니다. 예를 들어 EUC-KR 의 경우 한글 한문자는 2개의 byte 로 이루어지며, 첫byte는 ascii 값이 127보다 큰값을 가지지만 두번째 byte 에 대한 규칙이 없습니다. 따라서 substring 10자인 경우 10자로 자른후 첫번째 byte 부터 ascii의 값을 확인하여 10번째 byte 가 한글 두번째 byte 인지를 확인해야 합니다.
추가적으로 UTF-8 로 저장된 문자열에 대하여 검색 방법 몇가지에 대한 글을 소개합니다.
UTF8 로 저장된 데이터를 매니저로 조회하는 방법
utf-8 데이터 like 검색 시 설정
