Đối chiếu tốt nhất để sử dụng cho MySQL với PHP là gì? [đóng cửa]

Tôi tự hỏi liệu có sự lựa chọn "tốt nhất" nào cho việc đối chiếu trong MySQL cho một trang web chung mà bạn không chắc chắn 100% về những gì sẽ được nhập không? Tôi hiểu rằng tất cả các mã hóa phải giống nhau, chẳng hạn như MySQL, Apache, HTML và bất cứ thứ gì trong PHP.

Trước đây tôi đã đặt PHP thành đầu ra trong "UTF-8", nhưng đối chiếu nào phù hợp với điều này trong MySQL? Tôi nghĩ nó là một trong những UTF-8 người, nhưng tôi đã sử dụng utf8_unicode_ci, utf8_general_civà utf8_bintrước đó.

Sự khác biệt chính là sắp xếp độ chính xác (khi so sánh các ký tự trong ngôn ngữ) và hiệu suất. Điều đặc biệt duy nhất là utf8_bin dùng để so sánh các ký tự ở định dạng nhị phân.

utf8_general_cicó phần nhanh hơn utf8_unicode_ci, nhưng kém chính xác hơn (để sắp xếp). Các utf8 mã hóa ngôn ngữ cụ thể (như utf8_swedish_ci) có chứa quy tắc ngôn ngữ bổ sung mà làm cho họ chính xác nhất để sắp xếp cho những ngôn ngữ. Hầu hết thời gian tôi sử dụng utf8_unicode_ci(tôi thích độ chính xác cho các cải tiến hiệu suất nhỏ), trừ khi tôi có lý do chính đáng để thích một ngôn ngữ cụ thể.

Bạn có thể đọc thêm về các bộ ký tự unicode cụ thể trong hướng dẫn sử dụng MySQL - http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

Trên thực tế, bạn có thể muốn sử dụng utf8_unicode_cihoặc utf8_general_ci.

• utf8_general_ci sắp xếp bằng cách tước đi tất cả các dấu và sắp xếp như thể đó là ASCII
• utf8_unicode_ci sử dụng thứ tự sắp xếp Unicode, vì vậy nó sắp xếp chính xác trong nhiều ngôn ngữ

Tuy nhiên, nếu bạn chỉ sử dụng điều này để lưu trữ văn bản tiếng Anh, những điều này không nên khác nhau.

Hãy rất, rất ý thức về vấn đề này có thể xảy ra khi sử dụng utf8_general_ci.

MySQL sẽ không phân biệt giữa một số ký tự trong các câu lệnh chọn, nếu utf8_general_ciđối chiếu được sử dụng. Điều này có thể dẫn đến các lỗi rất khó chịu - đặc biệt là, ví dụ, nơi có tên người dùng. Tùy thuộc vào việc triển khai sử dụng các bảng cơ sở dữ liệu, vấn đề này có thể cho phép người dùng độc hại tạo tên người dùng khớp với tài khoản quản trị viên.

Vấn đề này phơi bày ít nhất ở các phiên bản 5.x đầu tiên - Tôi không chắc hành vi này có thay đổi sau này không.

Tôi không phải là DBA, nhưng để tránh vấn đề này, tôi luôn đi theo utf8-binthay vì một trường hợp không nhạy cảm.

Kịch bản dưới đây mô tả vấn đề bằng ví dụ.

-- first, create a sandbox to play in
CREATE DATABASE `sandbox`;
use `sandbox`;

-- next, make sure that your client connection is of the same 
-- character/collate type as the one we're going to test next:
charset utf8 collate utf8_general_ci

-- now, create the table and fill it with values
CREATE TABLE `test` (`key` VARCHAR(16), `value` VARCHAR(16) )
    CHARACTER SET utf8 COLLATE utf8_general_ci;

INSERT INTO `test` VALUES ('Key ONE', 'value'), ('Key TWO', 'valúe');

-- (verify)
SELECT * FROM `test`;

-- now, expose the problem/bug:
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get BOTH keys here! MySQLs UTF8 collates that are 
-- case insensitive (ending with _ci) do not distinguish between 
-- both values!
--
-- collate 'utf8_bin' doesn't have this problem, as I'll show next:
--

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Note that we get just one key now, as you'd expect.
--
-- This problem appears to be specific to utf8. Next, I'll try to 
-- do the same with the 'latin1' charset:
--

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_general_ci

-- next, convert the values that we've previously inserted
-- in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_general_ci;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected). This shows 
-- that the problem with utf8/utf8_generic_ci isn't present 
-- in latin1/latin1_general_ci
--
-- To complete the example, I'll check with the binary collate
-- of latin1 as well:

-- first, reset the client connection charset/collate type
charset latin1 collate latin1_bin

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET latin1 COLLATE latin1_bin;

-- now, re-check for the bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Again, only one key is returned (expected).
--
-- Finally, I'll re-introduce the problem in the exact same 
-- way (for any sceptics out there):

-- first, reset the client connection charset/collate type
charset utf8 collate utf8_generic_ci

-- next, convert the values that we've previously inserted in the table
ALTER TABLE `test` CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;

-- now, re-check for the problem/bug
SELECT * FROM test WHERE `value` = 'value';

--
-- Two keys.
--

DROP DATABASE sandbox;

Tốt nhất là sử dụng bộ ký tự utf8mb4với đối chiếu utf8mb4_unicode_ci.

Bộ ký tự utf8, chỉ hỗ trợ một lượng nhỏ điểm mã UTF-8, khoảng 6% ký tự có thể. utf8chỉ hỗ trợ Mặt phẳng đa ngôn ngữ cơ bản (BMP). Có 16 máy bay khác. Mỗi mặt phẳng chứa 65.536 ký tự. utf8mb4hỗ trợ tất cả 17 máy bay.

MySQL sẽ cắt bớt 4 ký tự UTF-8 byte dẫn đến dữ liệu bị hỏng.

Bộ utf8mb4ký tự được giới thiệu trong MySQL 5.5.3 vào ngày 2010-03-24.

Một số thay đổi bắt buộc để sử dụng bộ ký tự mới không phải là nhỏ:

• Thay đổi có thể cần phải được thực hiện trong bộ điều hợp cơ sở dữ liệu ứng dụng của bạn.
• Các thay đổi sẽ cần được thực hiện đối với my.cnf, bao gồm thiết lập bộ ký tự, đối chiếu và chuyển đổi innodb_file_format sang Barracuda
• Các câu lệnh SQL CREATE có thể cần bao gồm: ROW_FORMAT=DYNAMIC
  • NĂNG ĐỘNG là cần thiết cho các chỉ mục trên VARCHAR (192) và lớn hơn.

LƯU Ý: Chuyển sang Barracudatừ Antelope, có thể yêu cầu khởi động lại dịch vụ MySQL nhiều lần. innodb_file_format_maxkhông thay đổi cho đến khi dịch vụ MySQL được khởi động lại thành : innodb_file_format = barracuda.

MySQL sử dụng Antelopeđịnh dạng tệp InnoDB cũ . Barracudahỗ trợ các định dạng hàng động mà bạn sẽ cần nếu bạn không muốn gặp các lỗi SQL để tạo chỉ mục và khóa sau khi bạn chuyển sang bộ ký tự:utf8mb4

• # 1709 - Kích thước cột chỉ mục quá lớn. Kích thước cột tối đa là 767 byte.
• # 1071 - Khóa được chỉ định quá dài; độ dài khóa tối đa là 767 byte

Kịch bản sau đây đã được thử nghiệm trên MySQL 5.6.17: Theo mặc định, MySQL được cấu hình như thế này:

SHOW VARIABLES;

innodb_large_prefix = OFF
innodb_file_format = Antelope

Dừng dịch vụ MySQL của bạn và thêm các tùy chọn vào my.cnf hiện tại của bạn:

[client]
default-character-set= utf8mb4

[mysqld]
explicit_defaults_for_timestamp = true
innodb_large_prefix = true
innodb_file_format = barracuda
innodb_file_format_max = barracuda
innodb_file_per_table = true

# Character collation
character_set_server=utf8mb4
collation_server=utf8mb4_unicode_ci

Ví dụ câu lệnh SQL CREATE:

CREATE TABLE Contacts (
 id INT AUTO_INCREMENT NOT NULL,
 ownerId INT DEFAULT NULL,
 created timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
 modified timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
 contact VARCHAR(640) NOT NULL,
 prefix VARCHAR(128) NOT NULL,
 first VARCHAR(128) NOT NULL,
 middle VARCHAR(128) NOT NULL,
 last VARCHAR(128) NOT NULL,
 suffix VARCHAR(128) NOT NULL,
 notes MEDIUMTEXT NOT NULL,
 INDEX IDX_CA367725E05EFD25 (ownerId),
 INDEX created (created),
 INDEX modified_idx (modified),
 INDEX contact_idx (contact),
 PRIMARY KEY(id)
) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE = InnoDB ROW_FORMAT=DYNAMIC;

• Bạn có thể thấy lỗi # 1709 được tạo INDEX contact_idx (contact)nếu ROW_FORMAT=DYNAMICbị xóa khỏi câu lệnh CREATE.

LƯU Ý: Thay đổi chỉ mục để giới hạn ở 128 ký tự đầu tiên về contactviệc loại bỏ yêu cầu sử dụng Barracuda vớiROW_FORMAT=DYNAMIC

INDEX contact_idx (contact(128)),

Cũng lưu ý: khi nó nói kích thước của trường là VARCHAR(128), đó không phải là 128 byte. Bạn có thể sử dụng có 128, 4 ký tự byte hoặc ký tự 128, 1 byte.

Câu INSERTlệnh này phải chứa ký tự 'poo' 4 byte trong hàng 2:

INSERT INTO `Contacts` (`id`, `ownerId`, `created`, `modified`, `contact`, `prefix`, `first`, `middle`, `last`, `suffix`, `notes`) VALUES
(1, NULL, '0000-00-00 00:00:00', '2014-08-25 03:00:36', '1234567890', '12345678901234567890', '1234567890123456789012345678901234567890', '1234567890123456789012345678901234567890', '12345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678', '', ''),
(2, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', ''),
(3, NULL, '0000-00-00 00:00:00', '2014-08-25 03:05:57', 'poo', '12345678901234567890', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '123💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩💩', '', '');

Bạn có thể thấy lượng không gian được sử dụng bởi lastcột:

mysql> SELECT BIT_LENGTH(`last`), CHAR_LENGTH(`last`) FROM `Contacts`;
+--------------------+---------------------+
| BIT_LENGTH(`last`) | CHAR_LENGTH(`last`) |
+--------------------+---------------------+
|               1024 |                 128 | -- All characters are ASCII
|               4096 |                 128 | -- All characters are 4 bytes
|               4024 |                 128 | -- 3 characters are ASCII, 125 are 4 bytes
+--------------------+---------------------+

Trong bộ điều hợp cơ sở dữ liệu của bạn, bạn có thể muốn đặt bộ ký tự và đối chiếu cho kết nối của mình:

SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'

Trong PHP, điều này sẽ được đặt cho: \PDO::MYSQL_ATTR_INIT_COMMAND

Người giới thiệu:

• Hướng dẫn tham khảo Mysql 5.6: Giới hạn trên các bảng InnoDB
• Cách hỗ trợ Unicode đầy đủ trong cơ sở dữ liệu MySQL

Các bộ sưu tập ảnh hưởng đến cách sắp xếp dữ liệu và cách các chuỗi được so sánh với nhau. Điều đó có nghĩa là bạn nên sử dụng đối chiếu mà hầu hết người dùng của bạn mong đợi.

Ví dụ từ tài liệu cho bộ ký tự unicode :

utf8_general_cicũng thỏa đáng cho cả tiếng Đức và tiếng Pháp, ngoại trừ 'ß' bằng với 's' và không bằng 'ss'. Nếu điều này được chấp nhận cho ứng dụng của bạn, thì bạn nên sử dụng utf8_general_civì nó nhanh hơn. Nếu không, sử dụng utf8_unicode_civì nó chính xác hơn.

Vì vậy - nó phụ thuộc vào cơ sở người dùng dự kiến ​​của bạn và vào mức độ bạn cần sắp xếp chính xác . Đối với một cơ sở người dùng tiếng Anh, utf8_general_cinên đủ, đối với các ngôn ngữ khác, như tiếng Thụy Điển, các bộ sưu tập đặc biệt đã được tạo.

Về cơ bản, nó phụ thuộc vào cách bạn nghĩ về một chuỗi.

Tôi luôn sử dụng utf8_bin vì sự cố được đánh dấu bởi Guus. Theo tôi, khi có liên quan đến cơ sở dữ liệu, một chuỗi vẫn chỉ là một chuỗi. Một chuỗi là một số ký tự UTF-8. Một ký tự có biểu diễn nhị phân, vậy tại sao nó cần biết ngôn ngữ bạn đang sử dụng? Thông thường, mọi người sẽ xây dựng cơ sở dữ liệu cho các hệ thống với phạm vi cho các trang web đa ngôn ngữ. Đây là toàn bộ quan điểm của việc sử dụng UTF-8 làm bộ ký tự. Tôi là một người theo chủ nghĩa thuần túy nhưng tôi nghĩ rằng rủi ro lỗi lớn hơn nhiều so với lợi thế nhỏ mà bạn có thể có được khi lập chỉ mục. Bất kỳ quy tắc liên quan đến ngôn ngữ nên được thực hiện ở mức cao hơn nhiều so với DBMS.

Trong sách của tôi, "giá trị" không bao giờ nên trong một triệu năm bằng "valúe".

Nếu tôi muốn lưu trữ một trường văn bản và thực hiện tìm kiếm không phân biệt chữ hoa chữ thường, tôi sẽ sử dụng các hàm chuỗi MYSQL với các hàm PHP như LOWER () và hàm strtolower của hàm php ().

Đối với thông tin văn bản UTF-8, bạn nên sử dụng utf8_general_civì ...

• utf8_bin: so sánh các chuỗi theo giá trị nhị phân của từng ký tự trong chuỗi

• utf8_general_ci: so sánh các chuỗi sử dụng các quy tắc ngôn ngữ chung và sử dụng các so sánh không phân biệt chữ hoa chữ thường

aka nó sẽ làm cho việc tìm kiếm và lập chỉ mục dữ liệu nhanh hơn / hiệu quả hơn / hữu ích hơn.

Câu trả lời được chấp nhận khá dứt khoát đề nghị sử dụng utf8_unicode_ci và trong khi đối với các dự án mới tuyệt vời, tôi muốn liên hệ với trải nghiệm trái ngược gần đây của mình chỉ trong trường hợp nó giúp tiết kiệm thời gian cho bất cứ ai.

Vì utf8_general_ci là đối chiếu mặc định cho Unicode trong MySQL, nếu bạn muốn sử dụng utf8_unicode_ci thì cuối cùng bạn phải chỉ định nó ở nhiều nơi.

Ví dụ: tất cả các kết nối máy khách không chỉ có bộ ký tự mặc định (có ý nghĩa với tôi) mà còn có đối chiếu mặc định (nghĩa là đối chiếu sẽ luôn mặc định là utf8_general_ci cho unicode).

Có thể, nếu bạn sử dụng utf8_unicode_ci cho các trường của mình, các tập lệnh kết nối với cơ sở dữ liệu sẽ cần được cập nhật để đề cập đến đối chiếu mong muốn một cách rõ ràng - nếu không các truy vấn sử dụng chuỗi văn bản có thể thất bại khi kết nối của bạn đang sử dụng đối chiếu mặc định.

Kết quả cuối cùng là khi chuyển đổi một hệ thống hiện có ở bất kỳ kích thước nào sang Unicode / utf8, cuối cùng bạn có thể bị buộc phải sử dụng utf8_general_ci do cách MySQL xử lý mặc định.

Đối với trường hợp được đánh dấu bởi Guus, tôi thực sự khuyên bạn nên sử dụng utf8_unicode_cs (phân biệt chữ hoa chữ thường, khớp nghiêm ngặt, sắp xếp chính xác cho hầu hết các phần) thay vì utf8_bin (khớp nghiêm ngặt, đặt hàng không chính xác).

Nếu trường được dự định tìm kiếm, trái ngược với đối sánh cho người dùng, thì hãy sử dụng utf8_general_ci hoặc utf8_unicode_ci. Cả hai đều không phân biệt chữ hoa chữ thường, một người sẽ thua khớp ('ß' bằng với 's' và không bằng 'ss'). Ngoài ra còn có các phiên bản dành riêng cho ngôn ngữ, như utf8_german_ci trong đó kết quả khớp phù hợp hơn với ngôn ngữ được chỉ định.

[Chỉnh sửa - gần 6 năm sau]

Tôi không còn đề xuất bộ ký tự "utf8" trên MySQL và thay vào đó đề xuất bộ ký tự "utf8mb4". Chúng khớp gần như hoàn toàn, nhưng cho phép thêm một (rất nhiều) ký tự unicode.

Trên thực tế, MySQL nên cập nhật bộ ký tự "utf8" và các bộ sưu tập tương ứng để phù hợp với đặc điểm kỹ thuật "utf8", nhưng thay vào đó, một bộ ký tự riêng và các bộ sưu tập tương ứng để không ảnh hưởng đến chỉ định lưu trữ cho những người đã sử dụng bộ ký tự "utf8" chưa hoàn chỉnh của chúng .

Tôi tìm thấy những biểu đồ đối chiếu hữu ích. http://collation-charts.org/mysql60/ . Tôi không chắc chắn đó là utf8_general_ci được sử dụng mặc dù.

Ví dụ ở đây là biểu đồ cho utf8_swbur_ci. Nó cho thấy những ký tự mà nó diễn giải là giống nhau. http://collation-charts.org/mysql60/mysql604.utf8_swbur_ci.html

Trong tệp tải lên cơ sở dữ liệu của bạn, hãy thêm dòng theo dõi trước bất kỳ dòng nào:

SET NAMES utf8;

Và vấn đề của bạn nên được giải quyết.