다양한 멀티바이트 문자 집합이 널리 사용됨에 따라 소프트웨어 개발 분야에서 영어를 사용하는 프로그래머 중 상당수가 멀티바이트 문자에 대해 잘 알지 못합니다. 이것이 최근 몇 년간 멀티바이트가 원인인 이유입니다. 이 기사의 저자는 MySQL의 문자 집합 아키텍처의 역할에 대한 자신의 견해에 대해 이야기합니다. 지난 몇 달 동안 MySQL을 사용할 때마다 저는 거의 항상 다음과 같은 생각을 했습니다. MySQL의 현재 계층적 문자 집합 아키텍처가 정말 유용한가?
MySQL 문자 집합 처리
요청 보내기
클라이언트(character_set_client)=》데이터베이스 연결(character_set_connection)=》스토리지(테이블,컬럼)
반품요청
스토리지(테이블, 컬럼)=》데이터베이스 연결(character_set_connection)=》클라이언트(character_set_results)
초기가 아닌 각 노드에서는 이전 노드에서 현재 노드로 문자 집합 변환 작업이 수행됩니다. 예를 들어 다음 환경을 고려해보세요.
◆ Character_set_connection utf-8
◆ Character_set_results gbk
◆ Character_set_client gb2312
◆ 테이블 A가 있고, 필드 문자셋은 모두 BIG5이다.
요청을 보낼 때 데이터는 먼저 gbk에서 utf-8로 변환된 다음 BIG5로 변환된 다음 저장됩니다.
요청을 반환할 때 데이터는 먼저 BIG5에서 utf-8로 변환된 다음 gb2312로 변환된 다음 클라이언트로 전송됩니다.
건축의 역할
1. 서로 다른 클라이언트가 서로 다른 문자 집합을 갖도록 허용합니다. 일반적인 예는 UTF-8 문자 집합 클라이언트가 있는 클라이언트인 UTF-8 사이트가 있다는 것입니다. 동시에 다른 클라이언트인 gbk 터미널에서 데이터베이스를 읽고 써야 할 수도 있지만 해당 문자 집합은 gbk입니다.
2. 데이터베이스를 통해 파일 시스템을 운영할 경우 파일 경로를 파일 시스템의 문자셋으로 변환해야 합니다. 예를 들어 내 클라이언트는 gbk이고 서버 파일 시스템은 utf-8입니다. "/A Slice/Rina.rmvb" 작업은 전송된 데이터 중 "slice"의 데이터가 서버와 다릅니다. 이때 GBK의 "슬라이스"를 utf-8로 변환하는 방법이 필요합니다. 여기서 MySQL은 이를 달성하기 위해 Character_filesystem이라는 것을 도입합니다.
그 외에는 현재로서는 다른 용도가 생각나지 않습니다. 하지만 잘 생각해 보세요. 과연 이런 치료가 필요한 걸까요? 많은 웹사이트는 단지 자신의 데이터가 원하는 대로 나올 수 있기를 바랍니다. 여기에는 두 가지 상황이 더 있습니다.
1. 데이터를 기반으로 유사한 작업을 정렬하거나 수행할 수 있기를 바랍니다. 먼저 정렬에 대해 이야기해 보겠습니다. 중국어가 포함된 필드의 경우 문자 집합을 기준으로 정렬하는 개념은 쓸모가 없습니다. 중국어 간체를 정렬할 때 일반적으로 병음으로 정렬하는 것이 좋습니다. 저는 MySQL의 검증을 실제로 이해하지 못했지만 제가 접촉한 프로그램으로 판단하면 이러한 유형의 정렬이 필요한 경우 정렬을 위해 병음을 저장하기 위해 특별히 필드가 생성됩니다. 병음에는 다성 문자도 있습니다. UTF-8이라면 중국, 일본, 한국이 동시에 일정 범위의 중국어를 공유하는 상황도 있다. 구현하기가 그리 쉽지 않기 때문에 GBK나 MySQL의 UTF-8 체크셋 모두 Pinyin을 구현해서는 안 됩니다. MySQL을 사용하는 중국의 대부분의 웹사이트는 현재 단지 바이트 정렬인 체크 세트를 사용하고 있다고 감히 말씀드릴 수 있습니다. 바이트 정렬을 사용하면 문자 세트를 전혀 사용할 필요가 없습니다. 따라서 중국 사이트의 경우 MySQL 문자 확인은 정렬에 의미가 없습니다.
그러나 유사한 작동 측면에서는 약간의 의미가 있습니다. 예를 들어 '%a%'를 좋아한다면 특정 부분에 a가 포함된 한자를 매칭하는 것이 가능합니다. 물론 UTF-8에서는 이러한 상황이 발생하지 않습니다. 왜냐하면 UTF-8의 저장 형식은 a가 a만 될 수 있고 멀티바이트 문자의 일부가 될 수 없음을 의미하기 때문입니다. 하지만 이 문제는 다른 문자 집합에서 발생할 수 있습니다. 결국 좋아요는 주문과 동일해져서 검증이 의미가 없게 됩니다. 희미한.
2. 데이터 정렬이나 전체 텍스트 검색 등이 필요하지 않은 경우 char, varchar, text 등의 사용을 중지하세요. 바이너리, varbinary, BLOB가 올바른 선택입니다. Binary 등은 저장 및 검색 시 문자셋 변환을 수행하지 않지만, 정렬 시에는 바이너리 내용에 따라서만 정렬되므로 char, varchar, text에 비해 효율성이 훨씬 높습니다.
이 경우 문자 집합이 필요하지 않습니다. 그러나 현재 MySQL 아키텍처에 따르면 클라이언트와 연결 간의 문자 집합 작업은 필드 유형을 무시하고 이 두 노드 간에는 계속 수행됩니다.
또한 PHP의 문자 세트 설정을 언급하십시오. mysql_query("set names utf8")와 같은 명령문 사용을 중지하십시오. mysql_set_charset()은 가장 완벽한 문자 집합 설정 방법입니다. 후자는 전자보다 하나 더 많은 설정을 갖고 있는데, 이는 MySQL 구조체의 charset 멤버를 설정하는 것입니다. 이 멤버 변수는 특히 ""를 문자의 일부로 사용하는 GBK와 같은 인코딩 형식의 경우 이스케이프에서 매우 중요한 역할을 합니다. mysql_query("set names XXX")만 사용하는 경우 일부 문자 집합에는 주요 보안 허점이 발생하여 mysql_real_escape_string이 추가 래시만큼 안전하지 않게 됩니다.
-