>  기사  >  데이터 베이스  >  mysql 중국어 잘못된 솔루션 컬렉션

mysql 중국어 잘못된 솔루션 컬렉션

黄舟
黄舟원래의
2016-12-19 16:32:361247검색

첫 번째 방법:
MySQL 4.1의 중국어 문자 깨짐 문제
최근 MySQL 4.0을 MySQL 4.1로 업그레이드하고 중국어 문자 깨짐 문제를 발견했습니다. 다음 내용이 모든 분들께 도움이 되기를 바랍니다.
1. MySQL 4.1에서는 문자 집합(Character Set)과 대조(Collation) 개념이 대폭 개선되었습니다.
2. MySQL 4.0에서는 일반 프로그램이 중국어 문자를 입력하더라도 결과는 여전히 라틴어로 설정된 텍스트 열에 저장됩니다. 이는 MySQL 4.0과 이전 프로그램의 차이점입니다. Gichu의 프로그램에는 문제가 되지 않습니다.
3. 그러나 MySQL 4.1의 시스템 인코딩은 기본적으로 UTF-8입니다. MySQL 4.0의 백업 파일을 MySQL 4.1로 복원하려고 하면 잘못된 문자가 나타납니다. 그 이유는 MySQL 4.1이 라틴 코드를 변환한 후 변환이 완전히 완벽하지 않아 소량의 텍스트가 왜곡되기 때문입니다.
MySQL 4.1에 액세스하는 PHP의 잘못된 문제 해결
인용문:
MySQL 4.1에서 도입된 다중 언어 지원은 정말 훌륭하며 일부 기능은 다른 데이터베이스 시스템을 능가했습니다. 그러나 테스트 도중 MySQL 4.1 이전 버전에 적합한 PHP 문을 사용하여 MySQL 데이터베이스를 작동하면 테이블 문자 집합이 설정되어 있어도 문자가 깨질 수 있다는 사실을 발견했습니다. 새로운 MySQL 온라인 매뉴얼의 10장 "문자 집합 지원"을 읽은 후 마침내 해결책을 찾고 테스트를 통과했습니다.
MySQL 4.1의 문자 집합 지원(Character Set Support)에는 문자 집합(Character set)과 정렬 방법(Collation)이라는 두 가지 측면이 있습니다. 문자 집합 지원은 서버, 데이터베이스, 테이블 및 연결의 네 가지 수준으로 세분화됩니다.
시스템의 문자 집합 및 정렬 설정을 보려면 다음 두 명령을 사용할 수 있습니다.
CODE:
mysql> SHOW VARIABLES LIKE 'character_set_%'; ------+------------------ ----+
| 변수 이름
+-------------+------ ---- ----+
| latin1 | latin1
| 문자세트_결과 | 라틴1 | 문자세트_시스템
| /usr/share/mysql/charsets/ ---- ------------+---------------+
7 세트의 행( 0.00초)
mysql> 'collation_%'와 같은 변수 표시
+---------+--- ---- ------------+
| 변수_이름
+--------- -+-- ----+
| collation_connection | latin1_swedish_ci | latin1_swedish_ci | +---- ------+------+
행 3개 set (0.00 초)
위에 나열된 값은 시스템 기본값입니다. 시스템이 스웨덴어 정렬 방법인 latin1을 기본값으로 사용하는 이유가 궁금하다면, 그 이유는 MySQL이 스웨덴 회사 T.c에 의해 개발되었기 때문입니다.
기존 방식으로 PHP를 통해 MySQL 데이터베이스에 접근하면, 테이블의 기본 문자셋을 utf8로 설정하고 UTF-8 인코딩을 통해 쿼리를 보내더라도 데이터베이스에 저장된 데이터는 다음과 같은 것을 알 수 있습니다. 여전히 왜곡되었습니다. 문제는 이 연결 계층에 있습니다. 해결 방법은 쿼리를 보내기 전에 다음 문장을 실행하는 것입니다.
SET NAMES 'utf8';
다음 세 가지 지침과 동일합니다.
CODE:
SET Character_set_client = utf8; SET Character_set_results = utf8;
SET Character_set_connection = utf8; 다시 시도해 보세요. 정상인가요?
연결 후 쿼리를 추가하면 됩니다.
CODE:
$this->query("SET NAMES 'utf8'")
설명서 10장을 읽어보니 가장 큰 문제는 다음과 같습니다. 문자 세트.
character_set_client, Character_set_results 및 Character_set_connection의 세 가지 작동 변수는 문자 깨짐을 유발하는 핵심입니다. mysql은 클라이언트가 제출한 쿼리를 Character_set_client에서 Character_set_connection
으로 변환합니다. 기본 웹 페이지에서 제출한 쿼리는 gb2312(양식 페이지 메타에서 볼 수 있음)이고 mysql은 이를 기본적으로 utf8로 처리하기 때문입니다(찾을 수 있음) 현재 char_set_client =utf8)이므로 왜곡되어야 합니다. 같은 방식으로 mysql에서 반환된 결과는 char_set_results 인코딩으로 변환되었습니다(테이블의 인코딩과 관련이 없습니다). 기본값은 utf8이고 웹 페이지에서는 이를 gb2312로 처리하므로 잘못된 필드가 있어야 합니다. 데이터베이스에서 읽은 제목 및 기타 필드와 같은 텍스트는 왜곡되지 않습니다.
위의 예는 utf8 문자 집합입니다. 이 방법을 사용하고 gbk로 설정하여 문제를 해결하세요.
세 번째 방법:
mysql 4.1 문자 왜곡에 대한 궁극적인 해결책
이 점에 유의하세요. 기사는 mysql 4.1에만 해당됩니다. 다른 버전의 mysql에 대해서는 다른 기사를 참조하세요. 자, 더 이상 고민하지 말고 이 문제를 단계별로 해결해 보겠습니다.
1. /etc/my.cnf 파일을 다음과 같이 수정합니다.
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=utf8
[mysql.server]
user=mysql
basedir=/var/lib
[ mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
참고: 방금 기본 문자 집합 =utf8을 추가했습니다.
2./etc/init.d/mysqld restart mysql을 다시 시작합니다.
3. phpmyadmin을 열고 lang을 "China simplified(zh-utf-8)"로 선택하고 "MySQL 연결 교정"을 "utf8_general_ci"로 선택합니다. ""Show MySQL running information" - "Variables"를 클릭하면 다음을 볼 수 있습니다:
문자 세트 클라이언트 utf8 utf8
문자 세트 연결 utf8 utf8
문자 세트 데이터베이스 utf8 utf8
문자 세트 결과 utf8 utf8
문자 집합 서버 utf8 utf8
문자 집합 시스템 utf8 utf8
조합 연결 utf8_general_ci utf8_general_ci
조합 데이터베이스 utf8_general_ci utf8_general_ci
조합 서버 utf8_general_ci utf8_general_ci
에서 여기에서 모든 문자가 utf8이 되는 것을 볼 수 있습니다. .
왜 utf8로 변경해야 하느냐고 묻는 사람이 있을 수 있습니다. GB2312로 변경은 불가능한가요?
설명은 다음과 같습니다.
utf8로 변경하고 싶지는 않지만 phpmyadmin2.6에서는 mysql4.1을 실행할 때 utf8만 사용하게 됩니다. 다른 페이지의 문자셋도 gb2312로 변경합니다. 확실히 문자가 깨질 수 있습니다. 우리는 phpmyadmin을 사용할 수 있습니다.
mysql3.23에서만 phpmyadmin은 gb2312의 추가 페이지 문자 세트를 갖게 되는데, 이는 현재로서는 정상적인 현상입니다.
3. 이전 mysql3 라이브러리 파일을 mysql4.1 라이브러리로 가져옵니다.
두 가지 상황이 있습니다.
하나는 phpmyadmin에서 가져오는 것입니다. 이때 왼쪽 하단에 주의해야 합니다. 라이브러리 파일을 선택하는 페이지입니다. 바닥글에 "파일의 문자 집합:"이 있습니다. 기본값은 utf8이며, 그렇지 않으면 가져오기가 깨집니다.
두 번째는 다음과 같습니다. Linux에서는 import를 수행해야 합니다. 이때 라이브러리 파일의 헤드에 다음 줄을 추가해야 합니다.
SET NAMES 'gb2312'; 끝에도 있습니다.
그런 다음 mysql -u 사용자 이름 -p 비밀번호 xxx.sql > 라이브러리 이름
가져오기가 완료된 후 phpmyadmin으로 열고 안에 있는 한자가 올바른지 확인합니다.
4. mysql4.1에서 라이브러리 파일 내보내기
1. phpmyadmin을 사용하여 내보내기
내보내는 것은 큰 문제가 되지 않습니다. phpmyadmin의 검색 페이지에 표시되는 중국어가 정상이라면 내보내기도 해야 합니다. Normal
2. Linux에서 내보내기
mysqldump로 내보낼 때 문자가 깨져도 상관없으니 iconv를 실행해서 변환하면 됩니다.
iconv -c -f UTF-8 -t GB2312 라이브러리 파일명 > New gb2312 라이브러리 파일 이름
요약하면 다음 사항에 주의해야 합니다.
1. 가져와야 하는 라이브러리 파일의 시작 부분에 SET NAMES 'gb2312'를 추가해 보세요. 가져오려는 파일이 gb2312 파일이라고 mysql에 알려주세요.
2. 필요할 수도 있습니다:
SET NAMES 'utf8';
mysql에 로그인한 후 사용하십시오. 문자의 일부 기본 매개변수를 utf8로 변경하면 일부 문제를 줄일 수 있지만 꼭 필요한 것은 아닙니다.
mysql에서 사용:
SHOW VARIABLES LIKE 'character_set_%'
현재 상태를 확인하세요.
3. 문자가 깨져도 걱정하지 마세요. 첫째, 원본 백업을 유지하는 데 주의하고, 둘째, iconv를 사용하여 변환하세요.
정상적으로 사용하기 전에 반드시 가져오기 및 내보내기 테스트를 수행하여 문제가 없는지 확인하세요.
다시 설명하자면, Mysql4.1은 업그레이드만 가능하고 다운그레이드는 불가능하다고 말하는 친구들이 많습니다. 또한 mysqldump를 사용하여 데이터베이스를 내보내고 --호환 매개변수를 추가하는 것을 잊지 마세요. -default-character-set=이 매개변수는 문자 집합을 설정합니다.
데모: mysqldump -uroot -pPassword -- Compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql
ok 이런 식으로 내보낸 파일은 Mysql4.0에서 사용할 수 있다..1.1부터 mysql의 중국어 지원 문제는 어떻게 만들어도 문자가 깨지는 문제가 있다. 새로운 시대의 mysql이지만 공식 웹사이트에서 다운로드하여 설치한 mysql5에는 여전히 문자가 깨져 있습니다. 이 현상에 대한 논의는 다음과 같습니다.
mysql의 소스 코드를 다운로드하여 컴파일하는 것이 좋습니다. 공식적으로 컴파일된 mysql의 인코딩은 라틴 문자 집합이므로 데이터베이스에서 볼 때 중국어 문자가 깨져 보입니다. MySQL을 컴파일할 때 withcharset= 인코딩을 사용하면 MySQL이 중국어 검색 및 정렬을 직접 지원할 수 있도록 mysql을 쉽게 컴파일할 수 있습니다. --with-extra-charsets 매개변수는 사용 가능한 다른 문자 집합을 지정합니다.
소스 코드 패키지를 다운로드하고 압축을 풀고 INSTALL-SOURCE를 엽니다. 여기에 Linux에서의 자세한 설치 방법이 있으므로 주의해야 할 것은 다음 구성 명령뿐입니다:
groupadd mysql
useradd -g mysql mysql
./configure --with-charset=gbk --with-collation=gbk_chinese_ci --with-extra-charsets=gb2312,big5,utf8,binary,ascii --prefix=/usr/local/mysql
make
make install
cp support-files/my-medium.cnf /etc/my.cnf
cd /usr/local/mysql
bin/mysql_install_db --user=mysql
chown -R root .
chown -R mysql var
chgrp -R mysql .
bin/mysqld_safe --user=mysql &
bin/mysql
mysql> 전역 문자 세트 매개변수는 모두 gbk이고 gb2312 문자 세트는 gbk에 포함되어야 하므로 이에 대해서는 논의하지 않겠습니다.
일반 mysql4.0과 동일한 PHP 작업을 수행하면 중국어 문자가 여전히 깨져 나타나는 것을 볼 수 있습니다.
여기서 설명해야 할 점은 mysql 4.1부터는 mysql 데이터베이스가 연결된 후 애플리케이션의 문자 집합을 설명해야 합니다. 그렇지 않으면 영어 이외의 문자가 포함된 텍스트 액세스를 해석하여 ? 기호로 변환할 수 없습니다. .
해결책은 mysql 새 버전의 요구 사항에 적응하는 것입니다.
mysql 데이터베이스에 연결한 후 set 문자 집합 문자 집합을 실행하면 이 명령은 최신 버전의 mysql 5에서 제외될 수 있습니다. 기본 문자 집합은 저장소와 일치합니다.
set char set gbk;
php에서는 다음과 같이 작성해야 합니다. mysql_query("set Character set gbk")
명령은 대문자 또는 소문자일 수 있습니다.
phpwind와 discuz는 국내 PHP 포럼에서 널리 사용되며 많은 친구가 이를 사용하고 있습니다. 위 단계를 이해한 후 포럼 소스 코드를 약간 수정하고 데이터베이스를 mysql5로 안전하게 업그레이드할 수도 있습니다.
포함 찾기 /db_mysql.php 함수 connect(...){. ....}
선택한 데이터베이스 mysql_select_db($dbname) 뒤에 mysql_query('set char set gbk'); 문장을 추가하고 저장합니다.
2. 파일 가져오기 및 내보내기: gbk가 아닌 문자를 저장하는 경우 가져온 파일의 머리 부분에 다음 줄을 추가해야 합니다. SET NAMES '문자 집합' 기호에 주의하세요. , 놓치지 마세요.
파일 가져오기 및 내보내기 실행
mysql -u 사용자 이름-p 비밀번호 데이터베이스 이름
mysqldump -u 사용자 이름-p 비밀번호 데이터베이스 이름>data.sql
mysqldump를 사용하여 데이터를 내보내면 문자가 깨져서 나타납니다. 상관없습니다. iconv를 실행하여 변환할 수 있습니다.
iconv -c -f utf8 -t gbk library file name>new gbk library file name
요약하면 다음 사항에 주의해야 합니다.
1. 가져와야 하는 라이브러리 파일의 시작 부분에 'gbk'라는 세트 이름을 추가해 보세요. gbk 파일을 가져오고 싶다고 mysql에 알리세요.
2. 현재 문자 세트 상태를 보려면 show 변수를 사용하거나 mysql에서 'character_set_%'와 같은 변수를 표시하십시오.
3. 왜곡된 문자가 나타나더라도 두려워하지 마십시오. 먼저 원본 백업을 유지하는 데 주의를 기울여야 하며, 두 번째로 iconv를 사용하여 변환해야 합니다.
#PHP 연결 문제:
MySQL 버전 4.1부터 비밀번호 해시 알고리즘 변경으로 인해 데이터베이스 연결 시 클라이언트가 인증 프로토콜을 지원하지 않는 문제가 발생할 수 있습니다.
이 문제는 mysql 5에서는 발생하지 않습니다. , mysql 5 다음 설정은 필요하지 않습니다.
다음 두 가지 방법을 통해 데이터베이스 사용자 비밀번호 불일치 문제를 해결할 수 있습니다.
첫 번째: mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd')
두 번째: mysql> ; mysql.user SET 비밀번호 업데이트 = OLD_PASSWORD('newpwd') 여기서 Host = 'some_host' AND User = 'some_user'
PHP 출력의 기타 잘못된 코드 문제:
mysql이 기본 인코딩 gbk로 컴파일되는 경우 GBK가 아닌 데이터를 직접 가져오면 UTF8에 저장된 일부 문자와 같은 문자가 깨질 수 있습니다. 대부분의 데이터가 UTF8 문자 세트에 있는 경우, 물론 MySQL을 UTF8의 기본 인코딩으로 컴파일해야 합니다. .
Mysql 4.1 출시 이후 🎜>DATABASE `mytest` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
단, 데이터베이스 교정을 utf-8로 변경하는 것만으로는 충분하지 않습니다. mysql 데이터베이스에 연결한 후: 이름 설정 'utf8'은 PHP 프로그램에서 올바르게 인코딩된 문자를 가져와 웹 페이지에 표시할 수 있습니다.
mysql_query("set names 'utf8'",$connection);
다시 설명하자면, 인터넷의 많은 친구들은 Mysql4.1은 업그레이드만 가능하고 다운그레이드는 불가능하다고 말합니다. 또한 mysqldump를 사용하면 됩니다. 내보내려면 데이터베이스에 --enabled 매개변수를 추가하십시오. 문자 세트를 설정하는 --default-character-set= 매개변수를 잊지 마십시오.
데모: mysqldump -uroot -pPassword -- Compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql
ok 이렇게 내보낸 파일은 Mysql4.0.X에서 사용할 수 있습니다. 그리고 Mysql.3.2에서 사용됩니다. 보고 싶지도 않지만 생각해 본 후에는 다음 네 가지 이유로 적어 두는 것이 좋습니다.
MySQL 4.1은 다중 언어 지원에 있어 큰 변화를 가져왔습니다(이로 인해 문제가 발생했습니다).
MySQL 3은 여전히 ​​대부분의 장소(개인 사용 및 호스팅 제공업체 모두)에서 지배적이지만 MySQL 4.1은 이미 MySQL에서 공식적으로 권장하는 데이터베이스입니다.
많은 PHP 프로그램이 MySQL을 기본 데이터베이스 관리 소프트웨어로 사용하지만 일반적으로 MySQL 4.1과 4.1 이하 버전을 구분하지 않습니다. xx 이상"은 설치 요구 사항을 충족할 수 있습니다.
latin1은 여러 곳에서 기본 문자 집합으로 사용되기 때문에(구체적인 위치는 아래에 자세히 설명됨) 많은 PHP 프로그램을 속이는 데 성공했습니다.
간단히 말하면 MySQL 자체와 MySQL을 사용하는 PHP 프로그램의 변경은 이를 무시하여 문제의 출현과 복잡성을 초래하며, 대부분의 사용자가 영어를 사용하기 때문에 이 문제는 발생하지 않습니다. 진지하게 받아들였습니다. 여기서 언급되는 PHP 프로그램은 주로 WordPress에 관한 것입니다.
MySQL 4.1의 문자 세트 지원 원칙은 MySQL 4.1의 문자 세트 사양을 머신, 데이터베이스 중 하나, 테이블 중 하나 및 하나의 시스템에 설치된 MySQL에 사용해야 하는 문자 세트로 세분화할 수 있습니다. 열의. 그러나 기존 웹 프로그램은 데이터베이스와 데이터 테이블을 생성할 때 이러한 복잡한 구성을 사용하지 않습니다. 그렇다면 기본 구성은 어디서 오는 것일까요?
MySQL을 컴파일할 때 기본 문자 집합은 latin1로 지정됩니다.
MySQL 설치 시 구성 파일(my.ini)에서 기본 문자 집합을 지정할 수 있습니다. 지정하지 않으면 이 값이 상속됩니다.
mysqld를 시작할 때 명령줄 매개변수에 기본 문자 집합을 지정할 수 있습니다. 지정하지 않으면 이 값은 구성 파일에서 상속됩니다.
이 때 Character_set_server는 다음으로 설정됩니다. 이 기본 문자 집합입니다.
새 데이터베이스를 생성할 때 명시적으로 지정하지 않는 한 이 데이터베이스의 문자 집합은 기본적으로 Character_set_server로 설정됩니다.
데이터베이스를 선택하면 Character_set_database는 이 기본 문자 집합으로 설정됩니다.
이 데이터베이스에 테이블을 생성할 때 테이블의 기본 문자 집합은 이 데이터베이스의 기본 문자 집합인 Character_set_database로 설정됩니다.
테이블에서 명시적으로 지정하지 않는 한 열을 설정할 때; , 이 열의 기본 문자 집합은 테이블의 기본 문자 집합입니다.
이 문자 집합은 데이터베이스에 데이터를 저장하는 데 실제로 사용되는 문자 집합이며, mysqldump가 생성하는 내용은 이 문자 집합 아래에 있습니다. 🎜>간단히 정리하면 아무것도 수정하지 않으면 모든 데이터베이스의 모든 테이블의 모든 필드가 latin1에 저장됩니다. 그러나 MySQL을 설치하면 일반적으로 다중 언어 지원, 즉 설치 프로그램을 선택하게 됩니다. 구성 파일에서 default_character_set을 UTF-8로 자동 설정합니다. 그러면 기본적으로 모든 데이터베이스에 있는 모든 테이블의 모든 필드가 UTF-8로 저장됩니다.
PHP 프로그램이 MySQL과 연결을 설정할 때 프로그램에서 MySQL로 보내는 데이터는 어떤 문자 집합을 사용합니까? MySQL은 알 방법이 없으므로(기껏해야 추측만 가능) MySQL 4.1에서는 클라이언트가 Character_set_client인 이 문자 집합을 지정하도록 요구합니다. MySQL의 이상한 점은 얻은 문자 집합이 즉시 문자 집합으로 변환되지 않는다는 것입니다. 해당 문자 세트에 저장되지만 먼저 Character_set_connection 변수에 의해 지정된 문자 세트로 변환됩니다. 연결 레이어가 어떤 용도로 사용되는지 잘 모르겠습니다. 그러나 Character_set_connection의 문자 세트로 변환한 후에는 다음과 같은 작업이 필요합니다. 즉, 데이터가 출력될 때 데이터베이스의 기본 문자 집합에서 Character_set_results에 지정된 문자 집합으로 변환되어야 합니다.
일반적인 환경은 내 컴퓨터에 설치된 MySQL 4.1을 예로 들었습니다. Apache 2, PHP 5 및 WordPress 1.5.1.3이 내 컴퓨터에 설치되어 있습니다. default_character_set은 MySQL 구성 파일에 지정되어 있습니다. 그래서 문제가 발생합니다.
WordPress는 기본적으로 설치되므로 모든 테이블은 UTF-8을 사용하여 데이터를 저장합니다.
WordPress에서 채택한 기본 검색 문자 집합은 UTF-8(옵션->읽기에서 설정)입니다. 따라서 모든 WP 페이지의 메타는 문자 세트가 utf-8임을 나타냅니다.
따라서 브라우저는 이러한 방식으로 모든 WP 페이지를 표시하고 Write의 모든 게시물과 댓글은 UTF-로 표시됩니다. 8 형식입니다. 브라우저는 이를 Apache로 보내고, Apache는 이를 PHP로 보냅니다.
따라서 WP는 모든 형식에서 가져오는 데이터를 변환 없이 MySQL로 직접 보냅니다.MySQL의 기본 Character_set_client와 Character_set_connection은 둘 다 latin1입니다. 이때 이상한 일이 발생했습니다. 실제로는 UTF-8 형식의 데이터였는데 "latin1로 변환"되었습니다... 그런데 실제로는 latin1로 변환되었습니다. 이 두 가지 변환 후에는 일부 utf-8 문자가 손실되어 ??가 됩니다. 최종 출력에서 ​​Character_set_results의 기본값은 latin1이며 이는 출력이 이상하다는 것을 의미합니다.
가장 놀라운 점은 WordPress가 GB2312 형식으로 읽도록 설정되어 있으면 WP에서 MySQL로 전송된 GB2312로 인코딩된 데이터가 "latin1"로 변환되어 이상한 형식으로 데이터베이스에 저장된다는 것입니다. 정말 이상한 형식입니다. mysqldump 다음에 찾을 수 있습니다. utf-8로 읽든 gb2312로 읽든 왜곡됩니다. 하지만 이 형식이 latin1로 출력되면 다시 GB2312로 변경할 수 있습니다!
어떤 현상이 나타날까요? WP가 MySQL 4.1 데이터베이스를 사용하는 경우 인코딩을 GB2312로 변경하면 정상이 됩니다. 불행하게도 이러한 정상성은 피상적일 뿐입니다.
문제 해결 방법 참을성이 없다면(거의 확실하게) Google에 검색해 보세요. 대부분의 답변은 이전에 쿼리를 실행하는 것입니다. SET NAMES 'utf8', 예, 이것이 해결책입니다. 하지만 이 글의 목적은 이것이 왜 해결책인지 설명하는 것입니다.
결과가 올바른지 확인하려면 데이터 테이블에 사용된 형식이 올바른지 확인해야 합니다. 즉, 최소한 모든 중국어 문자를 저장할 수 있는지 확인해야 합니다. 그러면 gbk 또는 utf-8의 두 가지 선택만 가능합니다. 아래에서 utf-8의 상황에 대해 논의해 보겠습니다.
구성 파일에 설정된 default_character_set이 utf8이므로 기본적으로 utf-8을 사용하여 데이터 테이블이 생성됩니다. 이는 MySQL 4.1을 사용하는 모든 호스팅 제공업체가 채택한 구성이어야 합니다. 따라서 우리가 확인해야 할 것은 클라이언트와 MySQL 사이에 지정된 인코딩이 올바른지 확인하는 것뿐입니다.
클라이언트가 gb2312 형식으로 데이터를 보내거나 utf-8 형식으로 데이터를 보내는 두 가지 가능성만 있습니다.
gb2312 형식으로 보내는 경우:
SET Character_set_client='gb2312'
SET Character_set_connection='utf8' 또는
SET Character_set_connection='gb2312'
둘 다 허용되며 둘 다 데이터를 보장할 수 있습니다. 인코딩 변환 중에 손실이 발생하지 않습니다. 이는 올바른 콘텐츠가 데이터베이스에 저장된다는 것을 의미합니다.
올바른 콘텐츠가 검색되었는지 어떻게 확인하나요? 대부분의 클라이언트(WP 포함)에서 전송된 데이터의 인코딩은 수신하려는 데이터의 인코딩이므로
SET Character_set_results='gb2312'
는 브라우저에 표시되는 형식을 보장할 수 있습니다. 꺼내면 gb2312 입니다.
두 번째 경우라면 클라이언트가 utf-8 형식(WP의 기본값)으로 전송하는 경우 다음 구성을 사용할 수 있습니다.
SET Character_set_client='utf8'
SET Character_set_connection='utf8'
SET Character_set_results='utf8'
이 구성은 SET NAMES 'utf8'과 동일합니다.
WP가 수정해야 할 내용은 여전히 ​​동일한 문장입니다. 클라이언트가 데이터베이스에 어떤 코딩된 데이터를 보내려는지 정확히 알 수는 없습니다. 따라서 WP는 클라이언트에게 명확하게 설명할 수만 있습니다. MySQL의 경우 올바른 SET ...입니다. 보내는 가장 적절한 방법은 무엇입니까? 대만의 pLog 동료들은 다음과 같은 제안을 했습니다.
먼저 서버가 4.1 이상인지 테스트하고, 그렇다면 컴파일 중에 UTF-8 지원이 추가되었는지 테스트하세요.
그런 다음 데이터베이스가 저장되는 형식을 테스트하세요($ dbEncoding) ;
SET NAMES $dbEncoding
두 번째 점은 위의 일반적인 구성에 따라 WP를 사용하는 한 데이터베이스가 UTF-8로 저장되어야 하므로 WP의 상황이 다릅니다. GB2312인지 UTF-8인지는 브라우징(bloginfo('charset'))으로 판단할 수 있지만 이 값은 데이터베이스에 접속한 후에만 얻을 수 있으므로 가장 효율적인 방법은 SET로 설정하는 것이다. NAMES는 매번 쿼리하기 전에 설정할 필요 없이 데이터베이스에 연결한 후 이 구성에 따라 한 번만 설정하면 됩니다.
수정 방법은 다음과 같습니다. wp_includes/wp-db.php에 추가하세요.
function set_charset($charset)
{
// 먼저 mysql 버전을 확인하세요.
$serverVersion = mysql_get_server_info ($this->dbh);
$version =explore('.', $serverVersion);
if ($version[0] < 4) return
// utf8 지원 여부 확인;
$result = mysql_query("SHOW CHARACTER SET like 'utf8'",
$this->dbh)
if (mysql_num_rows($result) < = 0) return
if ($charset == 'utf-8' || $charset == 'UTF-8')
$charset = 'utf8';
@mysql_query("SET NAMES '$charset' ", $this->dbh);
}
wp-settings.php에서 require (ABSPATH . WPINC . '/vars.php')를 추가하세요:
$wpdb->set_charset (get_bloginfo(' charset'));

1. MySQL 4.1에서는 문자 집합과 대조 개념이 크게 향상되었습니다.
2. MySQL 4.0에서는 일반 프로그램이 중국어 문자를 입력하더라도 결과는 라틴어로 설정된 텍스트 열에 저장됩니다. 이는 MySQL 4.0과 MySQL 4.0의 경우 다릅니다. 문제 없습니다.
3. 그러나 MySQL 4.1의 시스템 인코딩은 기본적으로 UTF-8입니다. MySQL 4.0의 백업 파일을 MySQL 4.1로 복원하려고 하면 잘못된 문자가 나타납니다. 그 이유는 MySQL 4.1이 라틴 코드를 변환한 후 변환이 완전히 완벽하지 않아 소량의 텍스트가 왜곡되기 때문입니다.
4. 잘못된 코드 문제를 해결하는 것은 어렵지 않습니다. 먼저 MySQL 4.0 백업 시 모든 텍스트 필드를 바이너리 타입으로 변경한 후 일반 백업을 수행한다. 두 번째 단계에서는 MySQL 4.1에서 이전 백업을 복원할 수 있습니다. 마지막으로, 이전에 binay 유형으로 변경된 텍스트 필드를 다시 텍스트 유형으로 되돌립니다. 이런 식으로 중국어 인코딩 문제를 완전히 해결해야 합니다.
5. 텍스트 필드를 바이너리 형식으로 변경할 때 바이너리 열의 길이를 텍스트 필드의 길이보다 크거나 같게(>=) 설정해야 합니다. 그렇지 않으면 데이터가 손실됩니다.
6. 또한, 이렇게 업그레이드된 MySQL 데이터베이스는 MySQL 4.1에서도 정상적으로 작동하며, 어떠한 방법으로 백업 및 복원을 하여도 더 이상 문자가 깨지는 현상이 발생하지 않습니다.
저자: MySQL 출시일: 2005-12-14
mysql4.1은 꽤 짜증나고, 다국어 세부 설정을 지원하고, phpmyadmin2.6도 상대적으로 멍청해서 변경할 수 없습니다. 어떻게 만들어도 다 엉망이거든요.
알겠습니다. 이 문제를 단계별로 해결해 보겠습니다.
1. /etc/my.cnf 파일을 다음과 같이 수정합니다.
[mysqld]
datadir=/var/ lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=utf8
[mysql.server]
user=mysql
basedir=/var/ lib
[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
참고: 방금 default-character-set=를 추가했습니다. utf8.
2./etc/init.d/mysqld restart mysql을 다시 시작합니다.
3. phpmyadmin을 열고 lang을 "China simplified(zh-utf-8)"로 선택하고 "MySQL 연결 교정"을 "utf8_general_ci"로 선택합니다. ""Show MySQL running information" - "Variables"를 클릭하면 다음을 볼 수 있습니다:
문자 세트 클라이언트 utf8 utf8
문자 세트 연결 utf8 utf8
문자 세트 데이터베이스 utf8 utf8
문자 세트 결과 utf8 utf8
문자 집합 서버 utf8 utf8
문자 집합 시스템 utf8 utf8
조합 연결 utf8_general_ci utf8_general_ci
조합 데이터베이스 utf8_general_ci utf8_general_ci
조합 서버 utf8_general_ci utf8_general_ci
에서 여기에서 모든 문자가 utf8이 되는 것을 볼 수 있습니다. .
왜 utf8로 변경해야 하느냐고 묻는 사람이 있을 수 있습니다. GB2312로 변경은 불가능한가요?
설명은 다음과 같습니다.
utf8로 변경하고 싶지는 않지만 phpmyadmin2.6에서는 mysql4.1을 실행할 때 utf8만 사용하게 됩니다. 다른 페이지의 문자셋도 gb2312로 변경합니다. 확실히 문자가 깨질 수 있습니다. 우리는 phpmyadmin을 사용할 수 있습니다.
mysql3.23에서만 phpmyadmin은 gb2312의 추가 페이지 문자 세트를 갖게 되는데, 이는 현재로서는 정상적인 현상입니다.
3. 이전 mysql3 라이브러리 파일을 mysql4.1 라이브러리로 가져옵니다.
두 가지 상황이 있습니다.
하나는 phpmyadmin에서 가져오는 것입니다. 이때 왼쪽 하단에 주의해야 합니다. 라이브러리 파일을 선택하는 페이지에 "파일의 문자 집합:"이 있습니다. 기본값은 utf8이며, 그렇지 않으면 가져오기가 깨집니다.
두 번째는 Linux에서 가져오는 것입니다. , 이때 라이브러리 파일의 헤드에 다음 줄을 추가해야 합니다.
SET NAMES 'gb2312'; 끝에도 ;가 있다는 점에 유의하세요.
그런 다음 mysql -u 사용자 이름 -p 비밀번호 xxx.sql > 라이브러리 이름
가져오기가 완료된 후 phpmyadmin으로 열고 안에 있는 한자가 올바른지 확인합니다.
4. mysql4.1에서 라이브러리 파일 내보내기
1. phpmyadmin을 사용하여 내보내기
내보내는 것은 큰 문제가 되지 않습니다. phpmyadmin의 검색 페이지에 표시되는 중국어가 정상이라면 내보내기도 해야 합니다. Normal
2. Linux에서 내보내기
mysqldump로 내보낼 때 문자가 깨져도 상관없으니 iconv를 실행해서 변환하면 됩니다.
iconv -c -f UTF-8 -t GB2312 라이브러리 파일명 > New gb2312 라이브러리 파일 이름
요약하면 다음 사항에 주의해야 합니다.
1. 가져와야 하는 라이브러리 파일의 시작 부분에 SET NAMES 'gb2312'를 추가해 보세요. 가져오려는 파일이 gb2312 파일이라고 mysql에 알려주세요.
2. 필요할 수도 있습니다:
SET NAMES 'utf8';
mysql에 로그인한 후 사용하십시오. 문자의 일부 기본 매개변수를 utf8로 변경하면 일부 문제를 줄일 수 있지만 꼭 필요한 것은 아닙니다.
mysql에서 사용:
SHOW VARIABLES LIKE 'character_set_%'
현재 상태를 확인하세요.
3. 문자가 깨져도 걱정하지 마세요. 첫째, 원본 백업을 유지하는 데 주의하고, 둘째, iconv를 사용하여 변환하세요.
정상적으로 사용하기 전에 반드시 가져오기 및 내보내기 테스트를 수행하여 문제가 없는지 확인하세요.


MYSQL을 4.1.2로 업그레이드했고 phpmyadmin은 2.6.2를 사용합니다. 한자가 포함된 데이터 테이블의 중국어 필드가 모두 깨져 있고, 내보낸 데이터도 깨져 있습니다. 이전 2.5.7을 문제없이 사용했는데, 일반 한자가 표시되게 하려면 phpmyadmin 파일에서 어떤 설정을 변경해야 하나요?
다음 문자 관련 변수는 SQL과 밀접한 관련이 있습니다.
character_set_client
character_set_connection
character_set_results
또한 데이터베이스의 해당 필드에 대해 설정된 문자 집합입니다. not set , 기본값은 테이블의 문자 집합입니다. 테이블이 지정되지 않은 경우 기본값은 데이터베이스입니다.
위 세 변수의 기능은 다음과 같습니다. client는 클라이언트가 보낸 문자 집합을 나타내고 결과는 클라이언트로 보낸 문자 집합을 나타냅니다. 과거의 터미널이 반드시 동일한 클라이언트일 필요는 없습니다), 연결은 클라이언트와 데이터베이스 간의 연결 역할을 합니다.
구체적인 내용은 다음과 같습니다. 예를 들어 mysql 명령줄에서 클라이언트를 gbk로, 연결을 utf8로, 결과를 gbk로, 데이터베이스를 big5로 설정했습니다.
insert 문을 보낼 때. , 이 문은 gbk 코드로 사용되며 먼저 utf8 코드로 변환(연결)된 다음 big5(데이터베이스)로 변환되어 데이터베이스에 삽입됩니다.
select 문을 실행하면 데이터베이스에서 얻은 결과가 반대 과정인 big5에서 utf8, gbk를 거쳐 gbk라는 결과를 얻습니다.
그래서 가장 중요한 것은 클라이언트와 결과가 사용 중인 클라이언트와 일치하도록 만드는 것입니다. 예를 들어 웹페이지가 utf8로 인코딩된 경우 이 두 가지를 utf8로 설정해야 합니다.
mysql 명령줄을 사용할 때 2000을 사용하고 있는데 gbk로 설정해야 합니다.
우리가 사용하는 세트 이름 XXX는 실제로 이 세 변수를 동시에 XXX로 설정합니다.
이 경우, 위의 세 가지 설정이 정확하다면 데이터베이스의 다양한 테이블이나 필드를 동시에 다른 문자 집합으로 설정할 수 있습니다.
데이터베이스의 문자가 올바른 문자 집합을 사용했는지 주의하세요. 예를 들어 처음에 잘못 설정한 경우 데이터를 삽입한 후 데이터 자체의 인코딩이 올바르지 않게 됩니다. 설정이 다시 변경되면 올바른 표시가 불가능해집니다.
또 다른 것은 인코딩 간의 호환성입니다. gbk에는 문자가 있지만 utf8에는 없으면 gbk-》utf8-》gbk 과정에서 "?"가 됩니다. 구체적인 해결책에 대해 이야기해 보겠습니다.
먼저 업그레이드된 데이터베이스와 테이블 및 필드의 문자 집합을 지정해야 합니다. 일반적으로 우리는 gb2312 또는 utf8을 동시에 사용하지 않는 경우 지정하기만 하면 됩니다. 데이터베이스를 구축할 때 SQL을 사용할 수 있으며 해당 문자 세트도 phpMyAdmin에서 수정할 수 있습니다.
그런 다음 이전 데이터를 가져옵니다. 먼저 데이터 파일의 인코딩을 결정합니다. phpMyAdmin을 사용하여 가져오는 경우 인터페이스에 파일 인코딩 옵션이 있으며 이는 데이터 파일의 인코딩과 일치해야 합니다.
mysql 명령줄에서 가져오는 경우 위에서 언급한 세 가지 변수를 직접 설정해야 하며, 이름은 xxx로 설정해야 합니다.
다른 클라이언트 프로그램 사용 시 주의하세요.
이렇게 하면 새 데이터베이스로 전송된 후 이전 데이터의 인코딩이 정확해집니다. 이 단계가 잘못되면 나중에 올바른 표시를 얻을 수 없습니다.
그런 다음 연결한 후 웹페이지의 인코딩에 따라 세트 이름 xxx를 한 번 실행할 수 있습니다.
이것은 기본적으로 인코딩이 올바른지 확인합니다.
가져온 데이터의 인코딩이 올바르지 않을 가능성이 높습니다.

MYSQL 데이터베이스의 기본 언어는 GB2312 문자가 포함된 데이터베이스가 있습니다.
구조는 괜찮습니다. 왜 콘텐츠가 깨졌나요?
MySQL 4.1에서 도입된 다중 언어 지원은 정말 훌륭하고 일부 기능은 다른 데이터베이스 시스템을 능가합니다. 그러나 테스트 도중 MySQL 4.1 이전 버전에 적합한 PHP 문을 사용하여 MySQL 데이터베이스를 작동하면 테이블 문자 집합이 설정되어 있어도 문자가 깨질 수 있다는 사실을 발견했습니다. 새로운 MySQL 온라인 매뉴얼의 10장 "문자 집합 지원"을 읽은 후 마침내 해결책을 찾고 테스트를 통과했습니다.
MySQL 4.1의 문자 집합 지원(Character Set Support)에는 문자 집합(Character set)과 정렬 방법(Collation)이라는 두 가지 측면이 있습니다. 문자 집합 지원은 서버, 데이터베이스, 테이블 및 연결의 네 가지 수준으로 세분화됩니다.
시스템의 문자 집합 및 정렬 설정을 보려면 다음 두 명령을 사용할 수 있습니다.

mysql> SHOW VARIABLES LIKE 'character_set_%'; ---+---------------+
| 변수_이름 | 값
+-------------+------------ ---------------+
| latin1 | latin1 |
| >| 문자세트_서버 | 라틴1 | utf8 | 문자세트_디렉토리
+---------------+--------- ----- ------+
세트의 7개 행(0.00초)
mysql> 'collation_%'과 같은 변수 표시
+--------- --- -------+------------+
| 변수_이름
+------------ ----- -------+------+
| collation_connection | latin1_swedish_ci | collation_database | latin1_swedish_ci | latin1_swedish_ci |
+------------+--- --- +
3행 세트(0.00초)

위에 나열된 값은 시스템 기본값입니다. (시스템이 왜 latin1이라는 스웨덴어 정렬 방식으로 기본 설정되어 있는지 이상하네요)...
원래 방식대로 PHP를 통해 MySQL 데이터베이스에 접근하면, 테이블의 기본 문자셋이 utf8로 설정되어 있고, 인코딩을 통해 인코딩되어 있어도 UTF-8 쿼리를 보내면 데이터베이스에 저장된 데이터가 여전히 왜곡되어 있음을 알 수 있습니다. 문제는 이 연결 계층에 있습니다. 해결 방법은 쿼리를 보내기 전에 다음 문장을 실행하는 것입니다.
SET NAMES 'utf8';
다음 세 가지 명령과 동일합니다.
SET Character_set_client =
SET Character_set_results = utf8;
SET Character_set_connection = utf8;
다시 시도해 보세요. 정상인가요? ^_^ 즐겨보세요!
구체적으로
쿼리 앞에 다음 줄을 추가하세요.
mysql_query("SET NAMES 'gb2312';",$this->con)
정말 매뉴얼을 넣어야 합니다.
다음 문자 관련 변수는 SQL과 밀접한 관련이 있습니다.
character_set_client
character_set_connection
character_set_results
또한 데이터베이스의 해당 필드에 대해 설정된 문자 집합입니다. . 필드 설정이 없는 경우 기본값은 테이블의 문자 집합입니다. 테이블이 지정되지 않은 경우 기본값은 데이터베이스입니다.
위 세 변수의 기능은 다음과 같습니다. client는 클라이언트가 보낸 문자 집합을 나타내고 결과는 클라이언트로 보낸 문자 집합을 나타냅니다. 과거의 터미널이 반드시 동일한 클라이언트일 필요는 없습니다), 연결은 클라이언트와 데이터베이스 간의 연결 역할을 합니다.
구체적인 내용은 다음과 같습니다. 예를 들어 mysql 명령줄에서 클라이언트를 gbk로, 연결을 utf8로, 결과를 gbk로, 데이터베이스를 big5로 설정했습니다.
insert 문을 보낼 때. , 이 문은 gbk 코드로 사용되며 먼저 utf8 코드로 변환(연결)된 다음 big5(데이터베이스)로 변환되어 데이터베이스에 삽입됩니다.
select 문을 실행하면 데이터베이스에서 얻은 결과가 반대 과정인 big5에서 utf8, gbk를 거쳐 gbk라는 결과를 얻습니다.
그래서 가장 중요한 것은 클라이언트와 결과가 사용 중인 클라이언트와 일치하도록 만드는 것입니다. 예를 들어 웹페이지가 utf8로 인코딩된 경우 이 두 가지를 utf8로 설정해야 합니다.
mysql 명령줄을 사용할 때 2000을 사용하고 있는데 gbk로 설정해야 합니다.
우리가 사용하는 세트 이름 XXX는 실제로 이 세 변수를 동시에 XXX로 설정합니다.
이 경우, 위의 세 가지 설정이 정확하다면 데이터베이스의 다양한 테이블이나 필드를 동시에 다른 문자 집합으로 설정할 수 있습니다.
데이터베이스의 문자가 올바른 문자 집합을 사용했는지 주의하세요. 예를 들어 처음에 잘못 설정한 경우 데이터를 삽입한 후 데이터 자체의 인코딩이 올바르지 않게 됩니다. 설정이 다시 변경되면 올바른 표시가 불가능해집니다.
또 다른 것은 인코딩 간의 호환성입니다. gbk에는 문자가 있지만 utf8에는 없으면 gbk-》utf8-》gbk 과정에서 "?"가 됩니다. 구체적인 해결책에 대해 이야기해 보겠습니다.
먼저 업그레이드된 데이터베이스와 테이블 및 필드의 문자 집합을 지정해야 합니다. 일반적으로 우리는 gb2312 또는 utf8을 동시에 사용하지 않는 경우 지정하기만 하면 됩니다. 데이터베이스를 구축할 때 SQL을 사용할 수 있으며 해당 문자 세트도 phpMyAdmin에서 수정할 수 있습니다.
그런 다음 이전 데이터를 가져옵니다. 먼저 데이터 파일의 인코딩을 결정합니다. phpMyAdmin을 사용하여 가져오는 경우 인터페이스에 파일 인코딩 옵션이 있으며 이는 데이터 파일의 인코딩과 일치해야 합니다.
mysql 명령줄에서 가져오는 경우 위에서 언급한 세 가지 변수를 직접 설정해야 하며, 이름은 xxx로 설정해야 합니다.
다른 클라이언트 프로그램 사용 시 주의하세요.
이렇게 하면 새 데이터베이스로 전송된 후 이전 데이터의 인코딩이 정확해집니다. 이 단계가 잘못되면 나중에 올바른 표시를 얻을 수 없습니다.
그런 다음 연결한 후 웹페이지의 인코딩에 따라 세트 이름 xxx를 한 번 실행할 수 있습니다.
------------------
mysql 가져오기 잘못된 코드 문제점 - -
mysql이 mysqldump를 사용하여 4.1에서 데이터를 내보내고 4.0에서 가져올 때 sql 문 오류가 발생하고 모든 데이터가 깨집니다. 다음 매개변수를 사용하여 문제를 해결하세요.
mysqldump -uxunai -p -- Compatible=mysql40 --default-character-set=latin1 xunai>xunai.sql
mysql -uroot -p fmx < f --default-character-set=latin1

위 내용은 mysql 중국어 왜곡문자 해결방법 모음입니다. 더 많은 관련 내용은 PHP 중국어 홈페이지(www.php.cn)를 참고해주세요!


성명:
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
이전 기사:MySQL NULL 값 처리다음 기사:MySQL NULL 값 처리