Làm thế nào để sửa lỗi Lỗi không đúng giá trị chuỗi lỗi?

Sau khi nhận thấy một ứng dụng có xu hướng loại bỏ các email ngẫu nhiên do lỗi giá trị chuỗi không chính xác, tôi đã đi và chuyển nhiều cột văn bản để sử dụng bộ utf8ký tự cột và cột mặc định đối chiếu ( utf8_general_ci) để nó chấp nhận chúng. Điều này đã sửa hầu hết các lỗi và làm cho ứng dụng ngừng nhận lỗi sql khi nó cũng đánh vào các email không phải là tiếng Latin.

Mặc dù vậy, một số email vẫn khiến chương trình gặp lỗi không đúng giá trị chuỗi: (Incorrect string value: '\xE4\xC5\xCC\xC9\xD3\xD8...' for column 'contents' at row 1)

Cột nội dung là kiểu MEDIUMTEXTdữ liệu sử dụng bộ utf8ký tự cột và utf8_general_ciđối chiếu cột. Không có cờ nào tôi có thể chuyển đổi trong cột này.

Hãy nhớ rằng tôi không muốn chạm vào hoặc thậm chí nhìn vào mã nguồn ứng dụng trừ khi thực sự cần thiết:

• Điều gì gây ra lỗi đó? (vâng, tôi biết các email chứa đầy rác ngẫu nhiên, nhưng tôi nghĩ utf8 sẽ khá dễ dãi)
• Làm thế nào tôi có thể sửa chữa nó?
• Những ảnh hưởng có thể có của một sửa chữa như vậy là gì?

Một điều tôi đã cân nhắc là chuyển sang một varf utf8 ([một số lượng lớn]) với cờ nhị phân được bật, nhưng tôi không quen với MySQL và không biết liệu cách khắc phục đó có hợp lý không.

"\xE4\xC5\xCC\xC9\xD3\xD8"UTF-8 không hợp lệ. Đã kiểm tra bằng Python:

>>> "\xE4\xC5\xCC\xC9\xD3\xD8".decode("utf-8")
...
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-2: invalid data

Nếu bạn đang tìm cách để tránh các lỗi giải mã trong cơ sở dữ liệu, mã hóa cp1252 (còn gọi là "Windows-1252" hay còn gọi là "Windows Western European") là mã hóa được cho phép nhất - mỗi giá trị byte là một điểm mã hợp lệ.

Tất nhiên, nó sẽ không hiểu UTF-8 chính hãng nữa, cũng như bất kỳ mã hóa không phải cp1252 nào khác, nhưng có vẻ như bạn không quá quan tâm đến điều đó?

Tôi sẽ không đề xuất câu trả lời của Richies, vì bạn đang làm hỏng dữ liệu bên trong cơ sở dữ liệu. Bạn sẽ không khắc phục vấn đề của mình nhưng cố gắng "ẩn" nó và không thể thực hiện các hoạt động cơ sở dữ liệu thiết yếu với dữ liệu bị loại bỏ.

Nếu bạn gặp phải lỗi này, dữ liệu bạn đang gửi không được mã hóa UTF-8 hoặc kết nối của bạn không phải là UTF-8. Đầu tiên, xác minh rằng nguồn dữ liệu (một tệp, ...) thực sự là UTF-8.

Sau đó, kiểm tra kết nối cơ sở dữ liệu của bạn, bạn nên làm điều này sau khi kết nối:

SET NAMES 'utf8';
SET CHARACTER SET utf8;

Tiếp theo, xác minh rằng các bảng nơi dữ liệu được lưu trữ có bộ ký tự utf8:

SELECT
  `tables`.`TABLE_NAME`,
  `collations`.`character_set_name`
FROM
  `information_schema`.`TABLES` AS `tables`,
  `information_schema`.`COLLATION_CHARACTER_SET_APPLICABILITY` AS `collations`
WHERE
  `tables`.`table_schema` = DATABASE()
  AND `collations`.`collation_name` = `tables`.`table_collation`
;

Cuối cùng, hãy kiểm tra cài đặt cơ sở dữ liệu của bạn:

mysql> show variables like '%colla%';
mysql> show variables like '%charac%';

Nếu nguồn, vận chuyển và đích là UTF-8, vấn đề của bạn sẽ biến mất;)

Các loại utf-8 của MySQL không thực sự đúng utf-8 - nó chỉ sử dụng tối đa ba byte cho mỗi ký tự và chỉ hỗ trợ Mặt phẳng đa ngôn ngữ cơ bản (nghĩa là không có Emoji, không có mặt phẳng thiên văn, v.v.).

Nếu bạn cần lưu trữ các giá trị từ các mặt phẳng Unicode cao hơn, bạn cần mã hóa utf8mb4 .

Bảng và các trường có mã hóa sai; tuy nhiên, bạn có thể chuyển đổi chúng thành UTF-8.

ALTER TABLE logtest CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

ALTER TABLE logtest DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

ALTER TABLE logtest CHANGE title title VARCHAR(100) CHARACTER SET utf8 COLLATE utf8_general_ci;

Tôi đã giải quyết vấn đề này ngày hôm nay bằng cách thay đổi cột thành loại 'LONGBLOB', nơi lưu trữ các byte thô thay vì các ký tự UTF-8.

Nhược điểm duy nhất của việc này là bạn phải tự chăm sóc mã hóa. Nếu một khách hàng trong ứng dụng của bạn sử dụng mã hóa UTF-8 và một khách hàng khác sử dụng CP1252, bạn có thể gửi email với các ký tự không chính xác. Để tránh điều này, luôn luôn sử dụng cùng một mã hóa (ví dụ UTF-8) trên tất cả các ứng dụng của bạn .

Tham khảo trang này http://dev.mysql.com/doc/refman/5.0/en/blob.html để biết thêm chi tiết về sự khác biệt giữa TEXT / LONGTEXT và BLOB / LONGBLOB. Ngoài ra còn có nhiều tranh luận khác trên web thảo luận về hai điều này.

Trước tiên hãy kiểm tra xem default_character_set_name của bạn có phải là utf8 không.

SELECT default_character_set_name FROM information_schema.SCHEMATA S WHERE schema_name = "DBNAME";

Nếu kết quả không phải là utf8, bạn phải chuyển đổi cơ sở dữ liệu của mình. Đầu tiên bạn phải lưu một bãi rác.

Để thay đổi mã hóa bộ ký tự thành UTF-8 cho tất cả các bảng trong cơ sở dữ liệu đã chỉ định, hãy nhập lệnh sau vào dòng lệnh. Thay thế DBNAME bằng tên cơ sở dữ liệu:

mysql --database=DBNAME -B -N -e "SHOW TABLES" | awk '{print "SET foreign_key_checks = 0; ALTER TABLE", $1, "CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci; SET foreign_key_checks = 1; "}' | mysql --database=DBNAME

Để thay đổi mã hóa bộ ký tự thành UTF-8 cho chính cơ sở dữ liệu, hãy nhập lệnh sau tại dấu nhắc mysql >. Thay thế DBNAME bằng tên cơ sở dữ liệu:

ALTER DATABASE DBNAME CHARACTER SET utf8 COLLATE utf8_general_ci;

Bây giờ bạn có thể thử lại để viết ký tự utf8 vào cơ sở dữ liệu của bạn. Giải pháp này giúp tôi khi tôi cố tải lên 200000 hàng tệp csv vào cơ sở dữ liệu của mình.

Nói chung, điều này xảy ra khi bạn chèn chuỗi vào các cột có mã hóa / đối chiếu không tương thích.

Tôi đã gặp lỗi này khi tôi có TRIGGER, do kế thừa đối chiếu của máy chủ vì một số lý do. Và mặc định của mysql là (ít nhất là trên Ubuntu) latin-1 với đối chiếu Thụy Điển. Mặc dù tôi đã có cơ sở dữ liệu và tất cả các bảng được đặt thành UTF-8, tôi vẫn chưa đặt my.cnf:

/etc/mysql/my.cnf:

[mysqld]
character-set-server=utf8
default-character-set=utf8

Và điều này phải liệt kê tất cả các kích hoạt với utf8- *:

select TRIGGER_SCHEMA, TRIGGER_NAME, CHARACTER_SET_CLIENT, COLLATION_CONNECTION, DATABASE_COLLATION from information_schema.TRIGGERS

Và một số biến được liệt kê bởi điều này cũng nên có utf-8- * (không có Latin-1 hoặc mã hóa khác):

show variables like 'char%';

Mặc dù đối chiếu của bạn được đặt thành utf8_general_ci, tôi nghi ngờ rằng mã hóa ký tự của cơ sở dữ liệu, bảng hoặc cột thậm chí có thể khác nhau.

ALTER TABLE tabale_name MODIFY COLUMN column_name VARCHAR(255)  
CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL;

Tôi đã có một lỗi tương tự ( Incorrect string value: '\xD0\xBE\xDO\xB2. ...' for 'content' at row 1). Tôi đã cố gắng thay đổi bộ ký tự của cột thành utf8mb4và sau đó lỗi đã thay đổi thành 'Data too long for column 'content' at row 1'.
Hóa ra mysql chỉ cho tôi lỗi sai. Tôi quay lại bộ ký tự của cột thành utf8và thay đổi loại cột thành MEDIUMTEXT. Sau đó, lỗi biến mất.
Tôi hi vọng nó giúp ích cho ai đó.
Nhân tiện, MariaDB trong cùng một trường hợp (tôi đã kiểm tra cùng một INSERT ở đó) chỉ cần cắt một văn bản mà không gặp lỗi.

Lỗi đó có nghĩa là bạn có chuỗi có mã hóa không chính xác (ví dụ: bạn đang cố nhập chuỗi được mã hóa ISO-8859-1 vào cột được mã hóa UTF-8) hoặc cột không hỗ trợ dữ liệu bạn đang cố nhập.

Trong thực tế, vấn đề thứ hai là do triển khai MySQL UTF-8 chỉ hỗ trợ các ký tự UNICODE cần 1-3 byte khi được trình bày trong UTF-8. Xem "Giá trị chuỗi không chính xác" khi cố gắng chèn UTF-8 vào MySQL thông qua JDBC? để biết chi tiết.

Giải pháp cho tôi khi chạy vào giá trị chuỗi Không chính xác này: '\ xF8' cho lỗi cột sử dụng scriptcase là đảm bảo rằng cơ sở dữ liệu của tôi được thiết lập cho chung chung utf8 và các trường hợp đối chiếu của tôi cũng vậy. Sau đó, khi tôi thực hiện nhập dữ liệu của mình vào tệp csv, tôi tải csv vào UE Studio sau đó lưu tệp được định dạng là utf8 và Voila! Nó hoạt động như một lá bùa, 29000 hồ sơ trong đó không có lỗi. Trước đây tôi đã cố gắng nhập một excel tạo csv.

Tôi đã thử tất cả các giải pháp trên (tất cả đều mang lại điểm hợp lệ), nhưng không có gì hiệu quả với tôi.

Cho đến khi tôi thấy rằng ánh xạ trường bảng MySQL của tôi trong C # đang sử dụng một loại không chính xác: MySqlDbType.Blob . Tôi đã thay đổi nó thành MySqlDbType.Text và bây giờ tôi có thể viết tất cả các ký hiệu UTF8 mà tôi muốn!

ps Trường bảng MySQL của tôi thuộc loại "LongText". Tuy nhiên, khi tôi tự động tạo ánh xạ trường bằng phần mềm MyGeneration, nó sẽ tự động đặt loại trường là MySqlDbType.Blob trong C #.

Thật thú vị, tôi đã sử dụng loại MySqlDbType.Blob với các ký tự UTF8 trong nhiều tháng mà không gặp khó khăn gì, cho đến một ngày tôi đã thử viết một chuỗi với một số ký tự cụ thể trong đó.

Hy vọng điều này sẽ giúp một người đang đấu tranh để tìm ra lý do cho lỗi này.

Tôi đã thêm nhị phân trước tên cột và giải quyết lỗi bộ ký tự.

chèn vào các giá trị bảngA (chuỗi ký tự nhị phân1);

Xin chào, tôi cũng gặp lỗi này khi sử dụng cơ sở dữ liệu trực tuyến của mình từ máy chủ godaddy, tôi nghĩ rằng nó có phiên bản mysql từ 5.1 trở lên. nhưng khi tôi làm từ máy chủ localhost của tôi (phiên bản 5.7) thì tôi đã tạo được bảng từ máy chủ cục bộ và sao chép vào máy chủ trực tuyến bằng cách sử dụng mysql. Tôi nghĩ rằng vấn đề là do bộ ký tự

Ảnh chụp màn hình ở đây

Để khắc phục lỗi này, tôi đã nâng cấp cơ sở dữ liệu MySQL của mình lên utf8mb4, hỗ trợ bộ ký tự Unicode đầy đủ bằng cách làm theo hướng dẫn chi tiết này . Tôi khuyên bạn nên xem qua nó một cách cẩn thận, vì có khá nhiều gotchas (ví dụ: các khóa chỉ mục có thể trở nên quá lớn do các mã hóa mới mà sau đó bạn phải sửa đổi các loại trường).

Có câu trả lời tốt ở đây. Tôi chỉ thêm tôi vì tôi gặp phải lỗi tương tự nhưng hóa ra đó là một vấn đề hoàn toàn khác. (Có thể trên bề mặt giống nhau, nhưng một nguyên nhân gốc rễ khác.)

Đối với tôi, lỗi xảy ra cho trường sau:

@Column(nullable = false, columnDefinition = "VARCHAR(255)")
private URI consulUri;

Điều này cuối cùng được lưu trữ trong cơ sở dữ liệu như là một tuần tự nhị phân của URIlớp. Điều này đã không tăng bất kỳ cờ nào với thử nghiệm đơn vị (sử dụng H2) hoặc thử nghiệm tích hợp / CI (sử dụng MariaDB4j ), nó đã xuất hiện trong thiết lập giống như sản xuất của chúng tôi. (Mặc dù, khi đã hiểu được vấn đề, thật dễ dàng để thấy giá trị sai trong ví dụ MariaDB4j; nó không làm nổ tung bài kiểm tra.) Giải pháp là xây dựng một trình ánh xạ loại tùy chỉnh:

package redacted;

import javax.persistence.AttributeConverter;
import java.net.URI;
import java.net.URISyntaxException;

import static java.lang.String.format;

public class UriConverter implements AttributeConverter<URI, String> {
    @Override
    public String convertToDatabaseColumn(URI attribute) {
        return attribute.toString();
    }

    @Override
    public URI convertToEntityAttribute(String field) {
        try {
            return new URI(field);
        }
        catch (URISyntaxException e) {
            throw new RuntimeException(format("could not convert database field to URI: %s", field));
        }
    }
}

Được sử dụng như sau:

@Column(nullable = false, columnDefinition = "VARCHAR(255)")
@Convert(converter = UriConverter.class)
private URI consulUri;

Theo như Hibernate có liên quan, có vẻ như nó có một loạt các người lập bản đồ loại được cung cấp , bao gồm cho java.net.URL, nhưng không cho java.net.URI(đó là những gì chúng ta cần ở đây).

Nếu bạn tình cờ xử lý giá trị với một số hàm chuỗi trước khi lưu, hãy đảm bảo rằng hàm có thể xử lý đúng các ký tự đa dòng. Các hàm chuỗi không thể làm điều đó và, giả sử, cố gắng cắt bớt có thể phân tách một trong các ký tự đa chuỗi đơn ở giữa và điều đó có thể gây ra các tình huống lỗi chuỗi như vậy.

Trong PHP chẳng hạn, bạn sẽ cần phải chuyển từ substrsang mb_substr.

Trong trường hợp của tôi, đầu tiên tôi đã gặp một '???' trong trang web của tôi, sau đó tôi kiểm tra bộ ký tự của Mysql là tiếng Latin, vì vậy tôi đổi nó thành utf-8, sau đó tôi khởi động lại dự án của mình, sau đó tôi gặp lỗi tương tự với bạn, sau đó tôi thấy rằng tôi quên thay đổi bộ ký tự của cơ sở dữ liệu và thay đổi thành utf-8, boom, nó đã hoạt động.

Tôi đã thử hầu hết các bước được đề cập ở đây. Không có làm việc. Đã tải xuống mariadb. Nó đã làm việc. Tôi biết đây không phải là một giải pháp nhưng điều này có thể giúp ai đó nhanh chóng xác định vấn đề hoặc đưa ra giải pháp tạm thời.

Server version: 10.2.10-MariaDB - MariaDB Server
Protocol version: 10
Server charset: UTF-8 Unicode (utf8)

Trong trường hợp của tôi, vấn đề đó đã được giải quyết bằng cách thay đổi mã hóa cột Mysql thành 'binary' (kiểu dữ liệu sẽ được tự động thay đổi thành VARBINARY). Có lẽ tôi sẽ không thể lọc hoặc tìm kiếm với cột đó, nhưng tôi không cần điều đó.

Trong trường hợp của tôi, Incorrect string value: '\xCC\x88'...vấn đề là một o-umlaut đang ở trạng thái phân hủy. Câu hỏi và trả lời này đã giúp tôi hiểu sự khác biệt giữa o¨và ö. Trong PHP, cách khắc phục đối với tôi là sử dụng thư viện Trình chuẩn hóa của PHP . Ví dụ Normalizer::normalize('o¨', Normalizer::FORM_C).

1 - Bạn phải khai báo trong kết nối của mình bản sửa lỗi UTF8. http://php.net/manual/en/mysqli.set-charset.php .

2 - Nếu bạn đang sử dụng dòng lệnh mysql để thực thi tập lệnh, bạn phải sử dụng cờ, như: Cmd: C:\wamp64\bin\mysql\mysql5.7.14\bin\mysql.exe -h localhost -u root -P 3306 --default-character-set=utf8 omega_empresa_parametros_336 < C:\wamp64\www\PontoEletronico\PE10002Corporacao\BancoDeDadosModelo\omega_empresa_parametros.sql