Tại sao kiểu dữ liệu varchar cho phép các giá trị unicode?

Tôi có một bảng với một cột varchar. Nó đang cho phép Nhãn hiệu (™), bản quyền (©) và các ký tự Unicode khác như được hiển thị bên dưới.

Create table VarcharUnicodeCheck
(
col1 varchar(100)
)

insert into VarcharUnicodeCheck (col1) values ('MyCompany')
insert into VarcharUnicodeCheck (col1) values ('MyCompany™')
insert into VarcharUnicodeCheck (col1) values ('MyCompany░')
insert into VarcharUnicodeCheck (col1) values ('MyCompanyï')
insert into VarcharUnicodeCheck (col1) values ('MyCompany')

select * from VarcharUnicodeCheck

Nhưng định nghĩa của varchar nói, nó cho phép dữ liệu chuỗi không unicode. Nhưng các ký hiệu Nhãn hiệu (™) và Đã đăng ký (®) là các ký tự Unicode . Liệu định nghĩa có mâu thuẫn với thuộc tính của kiểu dữ liệu varchar không? Tôi đọc một vài liên kết như đầu tiên và thứ hai . Nhưng tôi vẫn không thể hiểu tại sao nó cho phép chuỗi unicode khi định nghĩa nói rằng nó chỉ cho phép các giá trị chuỗi không unicode.

Nhưng các ký hiệu Nhãn hiệu (™) và Đã đăng ký (®) là các ký tự Unicode.

Bạn đã sai ở đây. Chuỗi của bạn chỉ chứa các asciiký tự.

Dưới đây là một thử nghiệm đơn giản cho bạn thấy rằng các nhân vật của bạn đều là ascii (+ một số extended asciicó mã ascii trong khoảng từ 128 đến 255):

declare @VarcharUnicodeCheck table
(
col1 varchar(100)
)

insert into @VarcharUnicodeCheck (col1) values ('MyCompany')
insert into @VarcharUnicodeCheck (col1) values ('MyCompany™')
insert into @VarcharUnicodeCheck (col1) values ('MyCompany░')
insert into @VarcharUnicodeCheck (col1) values ('MyCompanyï')
insert into @VarcharUnicodeCheck (col1) values ('MyCompany')

select *,
        right(col1, 1)as last_char, 
        ascii(right(col1, 1)) as_last_char_ascii
from @VarcharUnicodeCheck;

Ở đây bạn có thể thấy rõ rằng tất cả các ký tự của bạn được mã hóa 1 byte:

Vâng, chúng không phải là các ký tự ascii thuần túy nhưng chúng là Extended ASCII .

Ở đây tôi cho bạn thấy ký tự unicode thực Trademark(™)và mã đại diện và mã nhị phân của nó:

declare @t table (uni_ch nchar(1), ascii_ch char(1));
insert into @t values (N'™', '™');

select unicode(uni_ch) as [unicode of ™], 
       ascii(ascii_ch) [ascii of ™], 
       cast(uni_ch as varbinary(10)) as [uni_ch as varbinary], 
       cast(ascii_ch as varbinary(10)) as [ascii_ch as varbinary]
from @t;

Cuối cùng, bạn có thể thấy Trademark(™)ký tự unicode có mã 8482 chứ không phải 153:

select nchar(8482), nchar(153)

Từ các ý kiến, tôi đồng ý "ASCII mở rộng" thực sự là một thuật ngữ tồi có nghĩa là một trang mã ánh xạ các ký tự / điểm mã trong phạm vi 128-255, vượt ra ngoài phạm vi điểm mã 0-127 tiêu chuẩn được xác định bởi ASCII.

SQL Server hỗ trợ nhiều trang mã thông qua các đối chiếu. Các ký tự không phải ASCII có thể được lưu trữ trong varchar miễn là đối chiếu cơ bản hỗ trợ ký tự.

Ký tự '™' có thể được lưu trữ trong các cột varchar / char khi trang mã đối chiếu SQL Server là 1250 trở lên. Dưới đây truy vấn sẽ liệt kê những điều sau đây:

SELECT COLLATIONPROPERTY(name, 'CodePage') AS code_page, name, description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'CodePage') >= 1250
ORDER BY name;

Nhưng chỉ một tập hợp con trong số này cũng hỗ trợ ký tự '©' nên việc đối chiếu cột sẽ cần phải là một trong những điều sau đây để hỗ trợ cả hai:

SELECT COLLATIONPROPERTY(name, 'CodePage') AS code_page, name, description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'CodePage') IN(
    1250
    ,1251
    ,1252
    ,1253
    ,1254
    ,1255
    ,1256
    ,1257
    ,1258
)
ORDER BY name;

Nhưng định nghĩa của varchar nói, nó cho phép dữ liệu chuỗi không unicode . Nhưng các ký hiệu Nhãn hiệu (™) và Đã đăng ký (®) là các ký tự Unicode . Liệu định nghĩa có mâu thuẫn với thuộc tính của kiểu dữ liệu varchar không?

Trong khi các câu trả lời khác không phải là không chính xác, tôi nghĩ nó sẽ giúp chỉ ra một sự nhầm lẫn trong thuật ngữ cơ sở. Tôi đã nhấn mạnh hai từ trong trích dẫn trên từ câu hỏi như một ví dụ về sự nhầm lẫn này. Khi tài liệu SQL Server nói về dữ liệu Unicode và phi Unicode , họ không nói về các ký tự . Họ đang nói về các chuỗi byte đại diện cho các ký tự nhất định. Sự khác biệt chính giữa các loại Unicode ( NCHAR, NVARCHAR, XML, và bị phản đối / ác NTEXT) và các loại phi Unicode ( CHAR, VARCHARvà bị phản đối / ác TEXT) là những gì loại của chuỗi byte họ có thể lưu trữ.

Các loại không Unicode lưu trữ một trong nhiều mã hóa 8 bit, trong khi các loại Unicode lưu trữ một mã hóa Unicode 16 bit duy nhất: UTF-16 Little Endian. Như các câu trả lời khác đã đề cập, những ký tự nào có thể được lưu trữ trong mã hóa 8 bit / không Unicode tùy thuộc vào trang mã, được xác định bởi Collation. Mặc dù những người khác đã lưu ý rằng giá trị byte của "ký tự" có thể khác nhau giữa các trang mã được tìm thấy trên đó, giá trị byte thậm chí có thể thay đổi trong cùng một trang mã khi xử lý một trong một số trang mã EBCDIC (các biến thể của Windows- 1252), vốn chỉ được tìm thấy trong các Bộ sưu tập SQL Server cũ hơn, không nên sử dụng (nghĩa là những cái có tên bắt đầu bằng SQL_).

Do đó, định nghĩa là chính xác: bất kỳ ký tự nào bạn có thể quản lý để lưu trữ trong loại không phải là Unicode luôn là 8 bit (ngay cả khi chúng sử dụng hai giá trị 8 bit kết hợp thành một "ký tự" duy nhất, đó là ký tự Double- Các trang mã bộ ký tự / DBCS cho phép). Và các kiểu dữ liệu Unicode luôn luôn là 16 bit, ngay cả khi đôi khi chúng sử dụng hai giá trị 16 bit kết hợp thành một "ký tự" duy nhất (nghĩa là một cặp thay thế đại diện cho một ký tự bổ sung).

VÀ, do SQL Server thực sự hỗ trợ mã hóa UTF-8 cho VARCHARvà CHARkiểu dữ liệu kể từ SQL Server 2019,

VARCHARkhông còn có thể được gọi là "không Unicode". Vì vậy, bắt đầu với phiên bản beta công khai đầu tiên của SQL Server 2019 vào tháng 9 năm 2018, chúng ta nên gọi VARCHARlà "kiểu dữ liệu 8 bit", ngay cả khi nói về các phiên bản trước SQL Server 2019. Thuật ngữ này đúng với cả 4 loại mã hóa có thể được sử dụng với VARCHAR:

1. ASCII mở rộng
2. Bộ ký tự nhân đôi (DBCS)
3. EBCDIC
4. UTF-8 (Unicode)

Chỉ có TEXTkiểu dữ liệu (không được dùng trong SQL Server 2005, vì vậy không sử dụng nó) là "không phải là Unicode", nhưng đó chỉ là một kỹ thuật và gọi nó là "kiểu dữ liệu 8 bit" là chính xác.

NVARCHAR, NCHARvà NTEXTcó thể được gọi là "UTF-16" hoặc "kiểu dữ liệu 16 bit". Oracle, tôi tin rằng, sử dụng thuật ngữ "chỉ dành cho Unicode" NVARCHAR, nhưng điều đó không loại trừ rõ ràng khả năng sử dụng UTF-8 (cũng là mã hóa Unicode), vì vậy có lẽ tốt nhất để sử dụng hai lựa chọn đầu tiên.

Để biết chi tiết về mã hóa UTF-8 mới, vui lòng xem bài viết của tôi:

Hỗ trợ UTF-8 bản địa trong SQL Server 2019: Tiên tri cứu rỗi hay sai?

PS Tôi đang dần dần tìm cách cập nhật tài liệu SQL Server để phản ánh những thay đổi này.

PPS Microsoft đã cập nhật một số trang với thông tin UTF-8, bao gồm tài liệu char và varchar được tham chiếu trong câu hỏi. Nó không còn chứa cụm từ "không Unicode". Nhưng đó chỉ là một FYI; nó không thay đổi câu hỏi vì đây là về mã hóa phi Unicode chứa các ký tự bị nhầm tưởng là chỉ Unicode.

Câu hỏi chứa một quan niệm sai lầm trung tâm về Unicode là gì. Bộ ký tự Unicode, cùng với các bảng mã của nó như UTF-8 và UTF-16, là một trong nhiều cách biểu diễn văn bản trong máy tính, và một mục tiêu là thay thế tất cả các bộ ký tự và mã hóa khác. Nếu "dữ liệu không phải là Unicode" có nghĩa là "các ký tự không có trong Unicode", thì không có văn bản nào tôi sử dụng trong câu trả lời này có thể được lưu trữ trong loại đó, bởi vì tất cả các chữ cái trong bảng chữ cái Latinh và dấu câu phổ biến được sử dụng trong tiếng Anh hàng ngày là bao gồm trong Unicode.

Các biểu diễn văn bản có thể được suy nghĩ rộng rãi thành hai phần: một bộ ký tự ánh xạ các ký tự khác nhau (chữ cái, chữ số, ký hiệu, v.v.) thành các số trên biểu đồ tham chiếu; và một mã hóa đại diện cho các số đó dưới dạng các mẫu của bit (trên đĩa, qua kết nối mạng, v.v.). Ở đây chúng tôi chủ yếu quan tâm đến phần đầu tiên: những nhân vật được liệt kê trên bảng xếp hạng cho một bộ ký tự cụ thể.

Vì Unicode nhằm mục đích có các số (mà nó gọi là "điểm mã") cho mọi ký tự trên thế giới, các tài liệu tham khảo như Wikipedia thường sẽ đề cập đến vị trí Unicode của một ký tự như một thông tin tham chiếu tiêu chuẩn. Tuy nhiên, điều đó không có nghĩa là các bộ ký tự khác cũng không có ánh xạ cho cùng một ký tự đó.

Một trong những bộ ký tự lâu đời nhất và đơn giản nhất (và mã hóa) vẫn được sử dụng là ASCII, có ánh xạ cho 128 ký tự khác nhau (0 đến 127), vì nó sử dụng 7 bit để mã hóa mỗi ký tự. Do loại trừ nhiều ký tự có dấu và ký hiệu phổ biến, các bảng mã sau này sử dụng 8 bit và ánh xạ 128 ký tự đầu tiên, thêm vào bộ ký tự bằng cách điền vào các vị trí 128 đến 255. Đáng chú ý trong số này là ISO 8859-1 và ISO 8859- 15 và Mã Windows cụ thể của Microsoft Trang 1252 .

Vì vậy, để trở về với MS SQL Server: một "Unicode string", như lưu trữ trong một nchar, nvarcharhoặc ntextcột, có thể đại diện cho tất cả các nhân vật ánh xạ trong bộ ký tự Unicode, vì nó sử dụng một Unicode mã hóa để lưu trữ dữ liệu. Một "non-Unicode chuỗi", như lưu trữ trong một char, varcharhoặc textcột, có thể đại diện cho những chữ số ánh xạ trong một số mã hóa khác . Bất cứ điều gì bạn có thể lưu trữ trong một cột không Unicode cũng có thể được lưu trữ trong một cột Unicode, nhưng không phải ngược lại.

Để biết chính xác những ký tự nào bạn có thể lưu trữ, bạn cần biết "đối chiếu" đang sử dụng, điều này chỉ ra những gì Microsoft gọi là "trang mã", như được giải thích trên trang tham khảo Microsoft này . Trong trường hợp của bạn, có thể bạn đang sử dụng Bộ luật rất phổ biến, mà tôi đã đề cập trước đó.

Các ký tự bạn đã đề cập tồn tại trong cả Unicode và Mã Trang 1252:

• Thương hiệu (™) xuất hiện bằng Unicode ở vị trí 8482 và ở CP1252 ở vị trí 153
• Đã đăng ký (®), như đã xảy ra, xuất hiện trong cả Unicode và CP1252 ở vị trí 174