java.sql.BatchUpdateException: Data truncation: Incorrect string value: \xF0... [서비스네임].[테이블명].[컬럼명] at row 1
위와 같은 에러가 발생되었는데 MYSQL 전송시 이모지 데이터와 다르게 중국 간체자데이터로 인한 문제같은경우 좀 확인이 까다로운것 같음
찾아본 관련 내용을 정리해보면
- 잘못된 문자열 값이 항상 \xF0으로 시작됨
- 중국어 간체자(GB2312)
- 간자체(음과 뜻이 같은데 획이 간략화된 문자)
- 확장 중국어 문자는 4바이트 영역을 사용
- MYSQL 접속후에 'SHOW VARIABLES' 명령을 입력하여 언어셋 확인가능
- 테이블속성을 보면 Charset과 컬럼이 UTF8MB4
- Collation이 utf8mb4_unicode_ci나 general ci
- 하지만 조회된 character_set_*과 collation_*로 시작되는 언어셋이 다른경우 왠지 안되는것 같은 느낌
- set names은 mysql 도움말에 따르면 아래의 효과
- 타겟 서버와 설정이 어떤지 모르는경우 그냥 변경가능하는 듯
- GB2321은 중국어 간체, BIG5는 중국어 번체용 인코딩
- 쿼리 실행전에 'set names [언어셋]' 실행하면
- character_set_client|results|connection 언어셋 바뀌는 듯?
- 한중일 케릭터셋 리스트(CJK)은 MYSQL버젼에 따라 다를수 있다고 함
버그패치Bug #13577 HKSCS Characters problemBug #22691 HKSCS SupportHKSCS(Hong Kong Supplementary Character Set)HKSCS는 BIG5에 그냥 덧씌운 캐릭터셋다국어 사이트(화면)에서는 한글,영문,번체의 입력이 잘되는 경우 존재하는것 같음- utf8_general_ci는 매우 간단한 콜레이션
- utf8_unicode_ci는 예를 들어 expansions과 ligatures를 지원
- utf8_general_ci는 expansions과 ligatures를 지원 하지 않음
- 모든 언어에는 utf8_unicode_ci에 적합하다고 함
- utf8_unicode_ci의 단점은 약간 느린듯
- utf-8 캐릭터셋은 1~4바이트까지 저장이 가능한 설계
- Collation 정렬방식 latin1은 2바이트,utf8은 가변3바이트,utf8mb4는 가변4바이트 저장공간 크기
- 4바이트 문자열(Emoji 등)을 utf8에 저장하면 값이 손실되는 현상이 발생
- 캐릭터셋이 utf8, collation은 utf_general_ci환경에서 문제가 일으키는듯
- 2010.3.24에 utf8m4 charset을 mysql 5.5.3에 추가되었다고함
- utf8mb4가 utf8 + 확장속성
테스트
- JDBC Receiver채널 옵션 Batch Mode체크, sqlBindMode=true
- JDBC컨넥션에 ?useUnicode=ture&characterEncoding=utf8&serverTimezone=Asia/Seoul로 했을때 동일 에러발생
- ?useUnicode=ture&character_set_server=utf8m4&serverTimezone=Asia/Seoul로 했을때 한글과 중국데이터가 전송되나 데이터는 ???으로 확인
- 매핑에 'set names utf8mb4나 big5' 추가해도 똑같음
MySQL 캐릭터셋 변경되는것 보고 다시 전송테스트 해봐야될듯..
댓글 없음:
댓글 쓰기