많은 사람들이 이미 가지고 있기 때문에, MySQL에서 데이터 인코딩과 관련하여 문제가 있습니다. 보다 구체적으로, 테이블의 데이터 정렬은 utf8_general_ci 인 것으로 보입니다. 삽입 된 데이터는 잘 삽입되지만 선택이 완료되면 일부 문자가 잘못 번역됩니다.이상한 문자를 인코딩하는 MySQL
Marie-Thérèse가 Marie-Thérèse가됩니다.
이 문자를 선택하여 원래 값으로 되돌릴 수 있습니까, 아니면 불가능합니까? 필자의 경우 원래 테이블을 변경하는 것이 어렵 기 때문에 선택 쿼리에서이를 해결하려고합니다.
결국 문제는 마치 cronbjob을 통해 모든 것을 실행하는 것처럼 보입니다. 우리는 삽입 문을 생성하는 cronjob을 통해 스크립트를 실행합니다. 분명히 수동으로 스크립트를 실행하면 모든 것이 잘되지만 cronjob을 통해 동일한 스크립트를 실행하면 데이터가 엉망이됩니다. 이 기사로 해결했습니다 : http://www.logikdev.com/2010/02/02/locale-settings-for-your-cron-job/ etc/환경 파일에 변수 LANG을 추가해야했습니다.
phpmyadmin (또는 유사)을 사용하여 해당 항목을 볼 때 그 항목은 괜찮습니까?
업데이트 : 그렇지 않은 경우 삽입물에 이미 결함이있어 삽입 스크립트의 연결을 수정해야합니다.
그렇다면 기술적으로 MySQL의 잘못은 아니지만 소프트웨어에 연결하는 것입니다. 예를 들어 UTF-8 all the way through을 참조하십시오. 연결을 열 때/후에 일부 매개 변수를 설정해야합니다.
btw : 대조는 부적합해야합니다. http://dev.mysql.com/doc/refman/5.7/en/charset-general.html
요지는 다음과 같습니다. 일급 조합은 문자열을 주문/비교하는 방법을 알려주며, 독일어/프랑스어 등 특수 문자의 경우 주로 중요합니다. 현지/지역별 데이터 정렬은 다음과 같습니다. , ä은 - 주문 목적으로 - 정확하게 a (예)와 같으며, 다른 조합에서 ä은 a 이후 또는 심지어 z 이후 일 수 있습니다.
PHP를 사용하지 않습니다. MySQL Workbench에서 select 명령을 실행할 때 항목이 잘못되었습니다. 아마도 insert 문에서 인코딩이나 다른 것을 제공해야 할 것입니다. –
그럴 가능성이 있습니다. 내 게시물을 업데이 트, 일반적으로 그것은 단지 검색 ... – Jakumi
데이터를 수정할 수 있습니다. 그러나 먼저 데이터를 얼마나 나쁜지 샘플링하기 위해 SELECT col, HEX (col) FROM ...을 제공하십시오. 그리고'SHOW CREATE TABLE'을 제공하십시오. (여러 가지 시나리오가 있는데, 올바른 해결책을 찾기 전에 어떤 것을 찾아야합니까?) –