nchar / nvarchar - это типы данных набора символов UNICODE UCS-2 фиксированной и гибкой длины в SQL Server.
Тогда возникает вопрос, какого чёрта это UCS-2? И согласно википедии, это позволит учесть 1,1 млн. Кодовых точек.
Следующее было скопировано из вики-статьи, так как я тупой мериканец, и я понял, что все это значит.
Кодовые точки от U + 0000 до U + D7FF и от U + E000 до U + FFFF
Первая плоскость (кодовые точки от U + 0000 до U + FFFF) содержит наиболее часто используемые символы и называется базовой многоязычной плоскостью или BMP. И UTF-16, и UCS-2 кодируют кодовые точки в этом диапазоне как единичные 16-битные кодовые единицы, которые численно равны соответствующим кодовым точкам. Кодовые точки в BMP являются единственными кодовыми точками, которые могут быть представлены в UCS-2. В этой плоскости кодовые точки от U + D800 до U + DFFF (см. Ниже) зарезервированы для суррогатов отведений и следов.
Кодовые точки U + 10000 до U + 10FFFF
Кодовые точки из других плоскостей (называемые дополнительными плоскостями) кодируются в UTF-16 парами 16-битных кодовых единиц, называемых суррогатными парами, по следующей схеме:
- 0x010000 вычитается из кодовой точки, оставляя 20-битное число в диапазоне 0..0x0FFFFF.
- Десять старших битов (число в диапазоне 0..0x03FF) добавляются к 0xD800, чтобы дать первую единицу кода или суррогатный вывод, который будет в диапазоне 0xD800..0xDBFF. (Предыдущие версии Стандарта Unicode называли их высокими суррогатами.)
- Десять младших битов (также в диапазоне 0..0x03FF) добавляются к 0xDC00, чтобы получить вторую единицу кода или суррогат следа, который будет в диапазоне 0xDC00..0xDFFF. (Предыдущие версии стандарта Unicode называли их низкими суррогатами.)
Поскольку диапазоны для суррогатов ведущих, суррогатов следов и действительных символов BMP не пересекаются, поиск упрощается: невозможно, чтобы часть одного символа соответствовала другой части другого символа. Это также означает, что UTF-16 самосинхронизируется с 16-битными словами: может ли кодовая единица начинать символ, может быть определено без проверки более ранних кодовых единиц. UTF-8 разделяет эти преимущества, но многие более ранние схемы многобайтового кодирования не допускают однозначного поиска и могут быть синхронизированы только путем повторного анализа с начала строки. UTF-16 не является самосинхронизирующимся, если один байт потерян или если обход начинается со случайного байта.
Поскольку все наиболее часто используемые символы находятся на базовой многоязычной плоскости, обработка суррогатных пар часто не проходит тщательного тестирования. Это приводит к постоянным ошибкам и потенциальным дырам в безопасности даже в популярных и проверенных прикладных программах (например, CVE-2008-2938, CVE-2012-2135).