ทำไมการค้นหา LIKE N '% %' ตรงกับอักขระ Unicode ใด ๆ และ = N' 'ตรงกับหลาย ๆ

DECLARE @T TABLE(
  Col NCHAR(1));

INSERT INTO @T
VALUES      (N'A'),
            (N'B'),
            (N'C'),
            (N'Ƕ'),
            (N'Ƿ'),
            (N'Ǹ');

SELECT *
FROM   @T
WHERE  Col LIKE N'%�%'

ผลตอบแทน

Col
A
B
C
Ƕ
Ƿ
Ǹ

SELECT *
FROM   @T
WHERE  Col = N'�' 

ผลตอบแทน

Col
Ƕ
Ƿ
Ǹ

การสร้าง "ตัวอักษร" สองไบต์ที่เป็นไปได้ทั้งหมดด้วยด้านล่างแสดงให้เห็นว่า=รุ่นตรงกับ 21,229 ของพวกเขาและLIKE N'%�%'รุ่นทั้งหมดของพวกเขา (ฉันได้ลองไบนารีไม่คู่เปรียบเทียบกับผลเดียวกัน)

WITH T(I, N)
AS 
(
SELECT TOP 65536 ROW_NUMBER() OVER (ORDER BY @@SPID),
                 NCHAR(ROW_NUMBER() OVER (ORDER BY @@SPID))
FROM master..spt_values v1, 
     master..spt_values v2
)
SELECT I, N 
FROM T
WHERE N = N'�'  

ทุกคนสามารถหลั่งน้ำตาแสงใด ๆ ที่เกิดขึ้นที่นี่?

ใช้COLLATE Latin1_General_BINแล้วจับคู่อักขระเดียวNCHAR(65533)- แต่คำถามคือเข้าใจว่ากฎใดที่ใช้ในกรณีอื่น มีอะไรพิเศษเกี่ยวกับอักขระ 21,229 ตัวที่ตรงกับ=และทำไมทุกอย่างจึงตรงกับสัญลักษณ์แทน ฉันคิดว่ามีเหตุผลบางอย่างที่ทำให้ฉันขาดหายไป

nchar(65534)[และอีก 21k] ทำงานได้ดีเช่นnchar(65533)กัน คำถามอาจถูกใช้nchar(502) เป็นคำพูดเท่า ๆ กัน�- มันทำงานเหมือนกันทั้งคู่LIKE N'%Ƕ%'(จับคู่ทุกอย่าง) และใน=กรณีนี้ นั่นอาจเป็นเบาะแสที่ค่อนข้างใหญ่

การเปลี่ยนแปลงSELECTในแบบสอบถามล่าสุดเพื่อSELECT I, N, RANK() OVER(ORDER BY N)แสดงว่า SQL Server ไม่สามารถจัดอันดับอักขระได้ ดูเหมือนว่าตัวละครใด ๆ ที่ไม่ได้รับการจัดการโดยการเปรียบเทียบนั้นถือว่าเทียบเท่ากัน

ฐานข้อมูลที่มีการLatin1_General_100_CS_ASเปรียบเทียบสร้างการแข่งขัน 5840 Latin1_General_100_CS_ASลดการ=แข่งขันค่อนข้างมาก แต่ไม่เปลี่ยนLIKEพฤติกรรม ดูเหมือนว่าจะมีตัวละครจำนวนหนึ่งที่มีขนาดเล็กลงในการเปรียบเทียบภายหลังซึ่งทั้งหมดเปรียบเทียบเท่ากันและจะถูกละเว้นในLIKEการค้นหาตัวแทน

ฉันกำลังใช้ SQL Server 2016 สัญลักษณ์�คืออักขระการแทนที่ Unicode แต่อักขระที่ไม่ถูกต้องเท่านั้นในการเข้ารหัส UCS-2 คือ 55296 - 57343 AFAIK และมีการจับคู่จุดรหัสที่ถูกต้องอย่างสมบูรณ์เช่นN'Ԛ'ที่ไม่ได้อยู่ในช่วงนี้

ทุกตัวอักษรเหล่านี้ทำตัวเหมือนสตริงว่างสำหรับและLIKE =พวกเขาประเมินว่าเทียบเท่า N'' = N'�'เป็นความจริงและคุณสามารถวางลงในการLIKEเปรียบเทียบช่องว่างเดียวLIKE '_' + nchar(65533) + '_'โดยไม่มีผลกระทบ LENการเปรียบเทียบให้ผลลัพธ์ที่แตกต่างกันดังนั้นจึงอาจเป็นเพียงฟังก์ชันสตริงเท่านั้น

ฉันคิดว่าLIKEพฤติกรรมนี้ถูกต้องสำหรับกรณีนี้ มันทำงานเหมือนค่าที่ไม่รู้จัก (ซึ่งอาจเป็นอะไรก็ได้) มันเกิดขึ้นกับตัวละครอื่น ๆ เหล่านี้ด้วย:

• nchar(11217) (เครื่องหมายไม่แน่นอน)
• nchar(65532) (อักขระการเปลี่ยนวัตถุ)
• nchar(65533) (ตัวละครทดแทน)
• nchar(65534) (ไม่ใช่ตัวละคร)

Latin1_General_100_CI_AS_SCดังนั้นถ้าฉันต้องการที่จะหาตัวอักษรทั้งหมดที่เป็นตัวแทนของความไม่แน่นอนที่มีเครื่องหมายเท่ากับผมจะใช้การเปรียบเทียบที่สนับสนุนตัวละครเสริมเช่น

ผมคิดว่าสิ่งเหล่านี้เป็นกลุ่มของ "ตัวละครที่ไม่ใช่ถ่วงน้ำหนัก" ที่กล่าวถึงในเอกสารการเปรียบเทียบและการสนับสนุน Unicode

วิธี "ตัวละคร" หนึ่งตัว (ซึ่งอาจประกอบด้วยหลายจุดรหัส: คู่ตัวแทนการรวมตัวอักษรและอื่น ๆ ) เปรียบเทียบกับที่อื่นจะขึ้นอยู่กับชุดของกฎที่ค่อนข้างซับซ้อน มันซับซ้อนมากเนื่องจากจำเป็นต้องพิจารณากฎทั้งหมด (และบางครั้ง "แปลกประหลาด") ที่พบในทุกภาษาที่แสดงในข้อกำหนดUnicode ระบบนี้ใช้กับการจัดเรียงที่ไม่ใช่ไบนารีสำหรับNVARCHARข้อมูลทั้งหมดและสำหรับVARCHARข้อมูลที่ใช้การจัดเรียง Windows และไม่ใช่การจัดเรียงเซิร์ฟเวอร์ SQL (เริ่มต้นด้วยSQL_) ระบบนี้ใช้ไม่ได้กับVARCHARข้อมูลโดยใช้ SQL Server Collation เป็นระบบที่ใช้การแม็พอย่างง่าย

ส่วนใหญ่ของกฎที่มีการกำหนดไว้ในเปรียบเทียบ Unicode อัลกอริทึม (UCA) บางส่วนของกฎเหล่านั้นและบางส่วนไม่ได้กล่าวถึงใน UCA ได้แก่ :

1. การสั่งซื้อ / น้ำหนักเริ่มต้นที่กำหนดในallkeys.txtไฟล์ (ระบุไว้ด้านล่าง)
2. มีการใช้ความไวและตัวเลือกใด (เช่นเป็นตัวพิมพ์เล็กหรือตัวพิมพ์เล็กหรือไม่และถ้าละเอียดอ่อนแล้วตัวพิมพ์ใหญ่หรือตัวพิมพ์เล็กก่อนหรือไม่)
3. การแทนที่ตามโลแคลใด ๆ
4. กำลังใช้เวอร์ชันของมาตรฐาน Unicode
5. ปัจจัย "มนุษย์" (เช่น Unicode คือข้อกำหนดไม่ใช่ซอฟต์แวร์และถูกปล่อยให้ผู้ขายแต่ละรายทำการติดตั้ง)

ฉันย้ำว่าประเด็นสุดท้ายเกี่ยวกับปัจจัยมนุษย์เพื่อให้ชัดเจนว่าเราไม่ควรคาดหวังให้ SQL Server ทำงาน 100% ตามข้อกำหนดเสมอ

ปัจจัยที่เอาชนะได้ที่นี่คือการถ่วงน้ำหนักที่กำหนดให้กับแต่ละจุดของรหัสและความจริงที่ว่าจุดรหัสหลาย ๆ สามารถแบ่งปันข้อมูลจำเพาะน้ำหนักเดียวกัน คุณสามารถค้นหาตุ้มน้ำหนักพื้นฐาน (ไม่มีการแทนที่เฉพาะโลแคล) ที่นี่ (ฉันเชื่อว่า100ชุด Collations คือ Unicode v 5.0 - การยืนยันอย่างไม่เป็นทางการในความคิดเห็นในรายการMicrosoft Connect ):

http://www.unicode.org/Public/UCA/5.0.0/allkeys.txt

จุดรหัสที่เป็นปัญหา - U + FFFD - ถูกกำหนดเป็น:

FFFD  ; [*0F12.0020.0002.FFFD] # REPLACEMENT CHARACTER

สัญกรณ์ดังกล่าวถูกกำหนดไว้ในส่วนที่9.1 รูปแบบไฟล์ Allkeysของ UCA:

<entry>       := <charList> ';' <collElement>+ <eol>
<charList>    := <char>+
<collElement> := "[" <alt> <weight> "." <weight> "." <weight> ("." <weight>)? "]"
<alt>         := "*" | "."

Collation elements marked with a "*" are variable.

บรรทัดสุดท้ายนั้นมีความสำคัญเนื่องจากจุดรหัสที่เรากำลังดูมีข้อมูลจำเพาะที่ขึ้นต้นด้วย "*" ในส่วนที่3.6 น้ำหนักที่เปลี่ยนแปลงได้มีการกำหนดพฤติกรรมที่เป็นไปได้สี่ประการโดยขึ้นอยู่กับค่าการกำหนดค่าการจัดเรียงที่เราไม่สามารถเข้าถึงได้โดยตรง ตัวพิมพ์ใหญ่ก่อนคุณสมบัติที่แตกต่างระหว่างVARCHARข้อมูลโดยใช้SQL_Collations และรูปแบบอื่น ๆ ทั้งหมด)

ฉันไม่มีเวลาที่จะทำการวิจัยอย่างเต็มรูปแบบเกี่ยวกับเส้นทางที่ถูกนำมาใช้และอนุมานว่ามีตัวเลือกใดบ้างที่ถูกใช้เพื่อให้มีการพิสูจน์ที่มั่นคงมากขึ้น แต่มันก็ปลอดภัยที่จะพูดว่า ถือว่า "เท่ากัน" จะไม่ใช้ข้อมูลจำเพาะแบบเต็มเสมอไป ในกรณีนี้เรามี "0F12.0020.0002.FFFD" และส่วนใหญ่เป็นเพียงระดับ 2 และ 3 ที่ใช้งานอยู่ (เช่น. 0020.0002 ) ทำ "นับ" ใน Notepad ++ สำหรับ ".0020.0002" พบการแข่งขัน 12,581 ครั้ง (รวมถึงตัวละครเสริมที่เรายังไม่ได้ติดต่อด้วย) การทำ "Count" กับ "[*" จะคืนค่า 4049 ที่ตรงกัน ทำ RegEx "Find" / "Count" โดยใช้รูปแบบของ\[\*\d{4}\.0020\.0002ส่งคืนการแข่งขัน 832 รายการ ดังนั้นในชุดค่าผสมนี้รวมถึงกฎบางอย่างที่ฉันไม่เห็นอีกทั้งรายละเอียดการใช้งานเฉพาะของ Microsoft คือคำอธิบายแบบเต็มของพฤติกรรมนี้ และเพื่อให้ชัดเจนพฤติกรรมจะเหมือนกันสำหรับอักขระที่ตรงกันทั้งหมดเนื่องจากทั้งหมดมีน้ำหนักเท่ากันเมื่อกฎถูกนำไปใช้ (ความหมายคำถามนี้อาจถูกถามเกี่ยวกับคำถามใดคำถามหนึ่งของพวกเขาไม่ใช่ นายจำเป็นต้อง�)

คุณสามารถดูด้วยแบบสอบถามด้านล่างและเปลี่ยนCOLLATEประโยคตามผลลัพธ์ด้านล่างแบบสอบถามว่าความไวต่างๆทำงานได้อย่างไรใน Collations ทั้งสองรุ่น:

;WITH cte AS
(
  SELECT     TOP (65536) ROW_NUMBER() OVER (ORDER BY (SELECT 0)) - 1 AS [Num]
  FROM       [master].sys.columns col
  CROSS JOIN [master].sys.objects obj
)
SELECT cte.Num AS [Decimal],
       CONVERT(VARBINARY(2), cte.Num) AS [Hex],
       NCHAR(cte.Num) AS [Character]
FROM   cte
WHERE  NCHAR(cte.Num) = NCHAR(0xFFFD) COLLATE Latin1_General_100_CS_AS_WS --N'�'
ORDER BY cte.Num;

จำนวนอักขระที่ตรงกันในการเปรียบเทียบที่แตกต่างกันอยู่ด้านล่าง

Latin1_General_100_CS_AS_WS   =   5840
Latin1_General_100_CS_AS      =   5841 (The "extra" character is U+3000)
Latin1_General_100_CI_AS      =   5841
Latin1_General_100_CI_AI      =   6311

Latin1_General_CS_AS_WS       = 21,229
Latin1_General_CS_AS          = 21,230
Latin1_General_CI_AS          = 21,230
Latin1_General_CI_AI          = 21,537

ในการเปรียบเทียบทั้งหมดที่ระบุไว้ข้างต้นN'' = N'�'จะประเมินเป็นจริง

UPDATE

ฉันสามารถทำการวิจัยเพิ่มเติมอีกเล็กน้อยและนี่คือสิ่งที่ฉันพบ:

มันควรจะทำงานอย่างไร

ใช้ICU Collation Demoฉันตั้งค่าภาษาเป็น "en-US-u-va-posix" ตั้งค่าความแข็งแกร่งเป็น "หลัก" ตรวจสอบการแสดง "คีย์เรียง" และแสดงใน 4 ตัวอักษรต่อไปนี้ที่ฉันคัดลอกมาจาก ผลลัพธ์ของข้อความค้นหาด้านบน (ใช้Latin1_General_100_CI_AICollation):

�
Ԩ
ԩ
Ԫ

และผลตอบแทนที่ได้:

Ԫ
    60 2E 02 .
Ԩ
    60 7A .
ԩ
    60 7A .
�
    FF FD .

จากนั้นตรวจสอบคุณสมบัติของอักขระสำหรับ " " ที่http://unicode.org/cldr/utility/character.jsp?a=fffdและดูว่าคีย์การเรียงระดับ 1 (เช่นFF FD) ตรงกับคุณสมบัติ "uca" การคลิกที่คุณสมบัติ "uca" จะนำคุณไปยังหน้าการค้นหา - http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3Auca%3DFFFD%3A%5D - แสดงการแข่งขันเพียง 1 รายการ และในไฟล์allkeys.txtน้ำหนักการจัดเรียงระดับ 1 จะแสดงเป็น0F12และมีเพียง 1 รายการที่ตรงกัน

เพื่อให้แน่ใจว่าเรากำลังตีความพฤติกรรมอย่างถูกต้องฉันดูตัวละครอื่น: GREEK Capital LETTER OMICRON กับ VARIA Ὸที่http://unicode.org/cldr/utility/character.jsp?a=1FF8ซึ่งมี "uca" ( คือระดับน้ำหนัก 1 เรียงลำดับ / องค์ประกอบเรียง) 5F30ของ คลิกที่ "5F30" พาเราไปที่หน้าค้นหา - http://unicode.org/cldr/utility/list-unicodeset.jsp?a=%5B%3Auca%3D5F30%3A%5D - แสดง 30 แมตช์, 20 จาก พวกเขาอยู่ในช่วง 0 - 65535 (เช่น U + 0000 - U + FFFF) มองในallkeys.txtไฟล์สำหรับรหัสจุด1FF8เราจะเห็นมีน้ำหนักจัดเรียงระดับ 12E01 ทำ "นับ" ใน Notepad ++ เปิด12E0. แสดงการจับคู่ 30 รายการ (ตรงกับผลลัพธ์ที่ได้จาก Unicode.org แม้ว่าจะไม่รับประกันว่าจะเป็นเพราะไฟล์สำหรับ Unicode v 5.0 และไซต์กำลังใช้ข้อมูล Unicode v 9.0)

ใน SQL Server เคียวรีต่อไปนี้ส่งคืนการจับคู่ 20 รายการเหมือนกับการค้นหา Unicode.org เมื่อลบอักขระเสริม 10 ตัว:

;WITH cte AS
(
  SELECT TOP (65535) ROW_NUMBER() OVER (ORDER BY (SELECT 0)) AS [Num]
  FROM   [master].sys.columns col
  CROSS JOIN [master].sys.objects obj
)
SELECT cte.Num AS [Decimal],
       CONVERT(VARCHAR(50), CONVERT(VARBINARY(2), cte.Num), 2) AS [Hex],
       NCHAR(cte.Num) AS [Character]
FROM cte
WHERE NCHAR(cte.Num) = NCHAR(0x1FF8) COLLATE Latin1_General_100_CI_AI
ORDER BY cte.Num;

และเพื่อให้แน่ใจว่าจะกลับไปที่หน้า ICU Collation Demo และแทนที่อักขระในกล่อง "Input" ด้วยอักขระ 3 ตัวต่อไปนี้ที่นำมาจากรายการผลลัพธ์ 20 รายการจาก SQL Server:

Ὂ
𝜪
Ὸ

แสดงให้เห็นว่าพวกเขาทั้งหมดมี5F 30น้ำหนักเรียงลำดับ 1 ระดับเดียวกัน(ตรงกับฟิลด์ "uca" บนหน้าคุณสมบัติอักขระ)

ดังนั้นมันจึงดูเหมือนกับว่าตัวละครตัวนี้ไม่ควรตรงกับสิ่งอื่นใด

มันใช้งานได้จริง (อย่างน้อยใน Microsoft-land)

ซึ่งแตกต่างจากภายใน SQL Server, .NET มีวิธีการแสดงที่สำคัญการจัดเรียงสตริงผ่านเป็นวิธี CompareInfo.GetSortKey ใช้วิธีนี้และผ่านในเวลาเพียงตัวอักษร U + FFFD 0x0101010100ก็จะส่งกลับคีย์การเรียงลำดับของ จากนั้นวนซ้ำอักขระทั้งหมดในช่วง 0 - 65535 เพื่อดูว่าอักขระใดมีคีย์การเรียงลำดับของการ0x0101010100แข่งขันที่ส่งคืน 4529 สิ่งนี้ไม่ตรงกับ 5840 ที่ส่งคืนใน SQL Server (เมื่อใช้Latin1_General_100_CS_AS_WSCollation) แต่มันใกล้เคียงที่สุดที่เราจะได้รับ (ตอนนี้) เนื่องจากฉันใช้ Windows 10 และ. NET Framework รุ่น 4.6.1 ซึ่งใช้ Unicode v 6.3.0 ตามแผนภูมิสำหรับCharUnicodeInfo Class(ใน "บันทึกถึงผู้โทร" ในส่วน "หมายเหตุ") ในขณะที่ฉันกำลังใช้ฟังก์ชั่น SQLCLR และดังนั้นจึงไม่สามารถเปลี่ยนรุ่น Framework ของเป้าหมายได้ เมื่อฉันมีโอกาสฉันจะสร้างแอปคอนโซลและใช้ Framework Framework รุ่น 4.5 ตามเป้าหมายที่ใช้ Unicode v 5.0 ซึ่งควรตรงกับ 100 Series Collations

สิ่งที่การทดสอบนี้แสดงให้เห็นคือแม้ว่าจะไม่มีการจับคู่ที่ตรงกันระหว่าง. NET และ SQL Server สำหรับ U + FFFD เป็นจำนวนเท่ากันมันก็ค่อนข้างชัดเจนว่านี่ไม่ใช่การทำงานเฉพาะของ SQL Server และไม่ว่าจะเป็นการจงใจหรือการกำกับดูแล โดย Microsoft ตัวละคร U + FFFD นั้นจะจับคู่กับตัวละครได้ไม่กี่ตัวแม้ว่ามันจะไม่เป็นไปตามข้อกำหนดของ Unicode ก็ตาม และเนื่องจากอักขระนี้ตรงกับ U + 0000 (null) อาจเป็นเพียงปัญหาของน้ำหนักที่หายไป

นอกจากนี้

เกี่ยวกับความแตกต่างของพฤติกรรมในการ=สืบค้นเทียบกับการLIKE N'%�%'สืบค้นนั้นเกี่ยวข้องกับอักขระตัวแทนและน้ำหนักที่หายไป (ฉันถือว่า) สำหรับ� Ƕ Ƿ Ǹอักขระ(เช่น) เหล่านี้ หากLIKEเงื่อนไขถูกเปลี่ยนให้เป็นเพียงแค่LIKE N'�'มันจะส่งคืน 3 แถวเดียวกันกับ=เงื่อนไข หากปัญหาเกี่ยวกับไวลด์การ์ดนั้นไม่ได้เกิดจากน้ำหนัก "หายไป" (ไม่มี0x00คีย์การส่งคืนโดยCompareInfo.GetSortKeybtw) อาจเป็นเพราะอักขระเหล่านี้อาจมีคุณสมบัติที่อนุญาตให้คีย์เรียงลำดับแตกต่างกันตามบริบท (เช่นอักขระโดยรอบ )