UTF-8: ทั่วไปใช่ไหม Bin? Unicode?

ฉันกำลังพยายามหาการเปรียบเทียบที่ฉันควรใช้สำหรับข้อมูลประเภทต่างๆ เนื้อหา 100% ที่ฉันจะจัดเก็บนั้นเป็นแบบที่ผู้ใช้ส่ง

ความเข้าใจของฉันคือฉันควรใช้ UTF-8 General CI (ตัวพิมพ์เล็ก - ใหญ่) แทน UTF-8 Binary อย่างไรก็ตามฉันไม่สามารถค้นหาความแตกต่างที่ชัดเจนระหว่าง UTF-8 General CI และ UTF-8 Unicode CI

1. ฉันควรจัดเก็บเนื้อหาที่ผู้ใช้ส่งในคอลัมน์ UTF-8 General หรือ UTF-8 Unicode CI หรือไม่
2. ข้อมูลประเภทใดที่จะใช้กับ UTF-8 Binary?

โดยทั่วไปutf8_general_ciเร็วกว่าutf8_unicode_ciแต่ถูกต้องน้อยกว่า

นี่คือความแตกต่าง:

สำหรับการใด ๆ ชุดอักขระ Unicode การดำเนินการดำเนินการโดยใช้การเปรียบเทียบ _general_ci จะเร็วกว่าสำหรับการเปรียบเทียบ ตัวอย่างเช่นการเปรียบเทียบสำหรับการเปรียบเทียบ utf8_general_ci นั้นเร็วกว่า แต่ถูกต้องน้อยกว่าการเปรียบเทียบสำหรับ utf8_unicode_ci เหตุผลสำหรับสิ่งนี้คือ utf8_unicode_ci รองรับการแมปเช่นการขยาย นั่นคือเมื่อตัวละครตัวหนึ่งเปรียบเทียบเท่ากับการรวมกันของตัวละครอื่น ๆ ตัวอย่างเช่นในภาษาเยอรมันและภาษาอื่น ๆ “ ß” เท่ากับ“ ss” utf8_unicode_ci ยังรองรับตัวย่อและอักขระที่ละเว้น utf8_general_ci คือการเปรียบเทียบแบบดั้งเดิมที่ไม่รองรับการขยายตัวย่อหรือตัวอักษรที่เพิกเฉย มันสามารถทำการเปรียบเทียบแบบหนึ่งต่อหนึ่งระหว่างตัวละคร

อ้างอิงจาก: http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html

สำหรับคำอธิบายโดยละเอียดเพิ่มเติมโปรดอ่านโพสต์ต่อไปนี้จากฟอรั่ม MySQL: http://forums.mysql.com/read.php?103,187048,188748

สำหรับ utf8_bin: ทั้งutf8_general_ciและutf8_unicode_ciทำการเปรียบเทียบแบบคำนึงถึงขนาดตัวพิมพ์ ในconstrast utf8_bin จะคำนึงถึงขนาดตัวพิมพ์ (ในความแตกต่างอื่น ๆ ) เนื่องจากเป็นการเปรียบเทียบค่าไบนารีของอักขระ

คุณควรตระหนักถึงความจริงว่าด้วย utf8_general_ci เมื่อใช้ฟิลด์ varchar เป็นดัชนีที่ไม่ซ้ำกันหรือหลักที่ใส่ 2 ค่าเช่น 'a' และ 'á' จะให้ข้อผิดพลาดที่สำคัญซ้ำกัน

• utf8_binเปรียบเทียบบิตสุ่มสี่สุ่มห้า กรณีไม่พับไม่มีการลอกสำเนียง
• utf8_general_ciเปรียบเทียบหนึ่งไบต์กับหนึ่งไบต์ มันจะทำการพับและเน้นการลอก แต่ไม่มีการเปรียบเทียบ 2 ตัวอักษร: ijไม่เท่ากันijในการเปรียบเทียบนี้
• utf8_*_ciเป็นชุดของกฎเฉพาะภาษา unicode_ciแต่อย่างอื่นเช่น บางกรณีพิเศษ: Ç, Č, ch,ll
• utf8_unicode_ciปฏิบัติตามมาตรฐาน Unicode เก่าสำหรับการเปรียบเทียบ ij= ij, แต่ae! =æ
• utf8_unicode_520_ciเป็นไปตามมาตรฐาน Unicode ที่ใหม่กว่า ae=æ

ดูแผนภูมิการเปรียบเทียบเพื่อดูรายละเอียดเกี่ยวกับสิ่งที่เท่ากับในการเปรียบเทียบ utf8 ต่างๆ

utf8, ตามที่กำหนดโดย MySQLจะถูก จำกัด รหัส utf8 1- 3 ไบต์ นี่ทำให้ Emoji และจีนบางส่วนหมดไป ดังนั้นคุณควรเปลี่ยนไปใช้utf8mb4ถ้าคุณต้องการไปไกลกว่ายุโรปมาก

ประเด็นข้างต้นนำไปใช้กับutf8mb4หลังจากการเปลี่ยนแปลงการสะกดคำที่เหมาะสม ก้าวไปข้างหน้าutf8mb4และutf8mb4_unicode_520_ciเป็นที่ต้องการ

• utf16 และ utf32 เป็นตัวแปรใน utf8; แทบไม่มีประโยชน์อะไรเลยสำหรับพวกเขา
• ucs2 ใกล้เคียงกับ "Unicode" มากกว่า "utf8"; แทบไม่มีประโยชน์อะไรเลย

จริง ๆ แล้วฉันทดสอบค่าการบันทึกเช่น 'é' และ 'e' ในคอลัมน์ด้วยดัชนีที่ไม่ซ้ำกันและพวกเขาทำให้เกิดข้อผิดพลาดซ้ำกันทั้ง 'utf8_unicode_ci' และ 'utf8_general_ci' คุณสามารถบันทึกได้ในคอลัมน์ 'utf8_bin' ที่เรียงรวมเท่านั้น

และ mysql docs (ในhttp://dev.mysql.com/doc/refman/5.7/en/charset-applications.html ) แนะนำให้เป็นตัวอย่างการตั้งค่าการจัดเรียง 'utf8_general_ci' ตัวอย่าง

[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci

คำตอบที่ยอมรับนั้นล้าสมัยแล้ว

หากคุณใช้ MySQL 5.5.3+ ให้ใช้utf8mb4_unicode_ciแทนutf8_unicode_ciเพื่อให้แน่ใจว่าอักขระที่พิมพ์โดยผู้ใช้ของคุณจะไม่ทำให้เกิดข้อผิดพลาด

utf8mb4รองรับอีโมจิในขณะที่utf8อาจให้ข้อบกพร่องที่เกี่ยวข้องกับการเข้ารหัสหลายร้อยรายการเช่น:

Incorrect string value: ‘\xF0\x9F\x98\x81…’ for column ‘data’ at row 1