Использование слова «символ» намеренно нечетко в стандарте Unicode, но в основном оно используется в техническом смысле: кодовая точка, обозначенная как назначенная кодовая точка символа. Это не полностью совпадает с интуитивным понятием характера. Например, интуитивный символ, состоящий из буквы i с макроном и серьезным акцентом, не существует как кодовая точка; в Юникоде он может быть представлен только как последовательность из двух или трех кодовых точек. В качестве другого примера, так называемые управляющие символы не являются символами в интуитивном смысле.
Когда другие стандарты и спецификации относятся к «символам Unicode», они относятся к кодовым точкам, обозначенным как назначенные кодовые точки символов. Набор символов Unicode зависит от стандартной версии Unicode, поскольку назначаются новые кодовые точки. Технически, файл UnicodeData.txt (по адресу ftp: //ftp.unicode.org/Public/UNIDATA/) указывает, какие кодовые точки являются символами.
U + 0000, условно обозначаемое NUL, является символом Unicode с самого начала.
Как вы заметили, спецификации XML во многих отношениях неточны в отношении символов. Но основным определением является создание BNF для «Char» и утверждение «процессоры XML ДОЛЖНЫ принимать любой символ в диапазоне, указанном для Char». Это означает, что в спецификациях XML концепция символа шире, чем символ Unicode. Диапазоны в производстве содержат неназначенные кодовые точки, на самом деле их огромное количество.
Комментарий к продукции «Char» в спецификациях XML лучше всего игнорировать. Это очень запутанно и даже неправильно. Производство «Char» просто относится к набору кодовых точек Unicode (разные наборы в разных версиях XML). Набор включает кодовые точки, которые вы никогда не должны использовать в символьных данных, а также кодовые точки, которых следует избегать по разным причинам. Но такие правила находятся на уровне, отличном от формальных правил XML и требований к реализациям XML.
При выборе или написании подпрограммы для проверки символьных данных зависит от приложения и цели, что следует принимать и что следует делать с кодовыми точками, которые не проходят тест. Даже суррогатные кодовые точки могут обрабатываться каким-то образом, а не просто отбрасываться; они вполне могут появиться из-за путаницы с кодировками (или, например, когда строка Java была наивно воспринята как строка символов Unicode - это просто последовательность 16-битных кодовых единиц).