Đầu tiên, tôi nên nói rằng tôi không sử dụng MySQL nhưng tôi biết về Trình điều khiển ODBC. Trong ODBC có các API khác nhau cho unicode và ansi. Các API ansi kết thúc bằng A và các API unicode kết thúc bằng W (ví dụ:SQLPrepareA và SQLPrepareW). Các API ansi chấp nhận byte / octet cho các chuỗi ký tự và do đó chỉ có thể xử lý các chrs 0-255. Các API unicode chấp nhận SQLWCHAR là 2 byte điểm mã unicode được mã hóa UCS-2 (các phiên bản MS SQL Server mới hơn có thể xử lý các chuỗi được mã hóa UTF16) và do đó có thể xử lý khoảng 65000 điểm mã đầu tiên trong unicode.
Vì vậy, nếu bạn cần lưu trữ dữ liệu unicode, bạn không có lựa chọn nào để sử dụng trình điều khiển.
Tôi sẽ không để những nhận xét về tốc độ từ Carnangel khiến bạn ngừng sử dụng trình điều khiển unicode và trong mọi trường hợp, nhận xét của anh ấy không bao gồm bất kỳ sự kiện nào. Anh ấy có thể đang đề cập đến:
Nếu bạn lưu trữ dữ liệu unicode trong MySQL, nó sẽ được mã hóa UTF-8 và chuyển qua mạng của bạn dưới dạng UTF-8. Ở cuối máy khách, trình điều khiển ODBC sẽ phải chuyển đổi dữ liệu được mã hóa UTF-8 thành UCS-2 vì đây là những gì ODBC cần. Rõ ràng là điều ngược lại được áp dụng.
Nếu bạn viết ứng dụng ANSI ODBC (đó là ứng dụng sử dụng apis ansi ODBC) với trình điều khiển ODBC unicode thì trình quản lý Trình điều khiển ODBC sẽ phải chuyển đổi UCS-2 trình điều khiển trở về 8 bit (lossy) và chuyển đổi 8 bit dữ liệu bạn chuyển cho trình điều khiển đến UCS-2. Vì vậy, đừng làm điều đó.
Những ngày này, tôi sẽ rất ngạc nhiên nếu có ai đó vẫn đang sử dụng trình điều khiển ANSI ODBC.
