Я имею в виду the XML 1.1 spec.Java, JavaCC: как разбирать символы вне BMP?
Посмотрите на определение NameStartChar:
NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
Если интерпретировать это правильно, последний диапазон (#x10000-#xEFFFF) выходит за пределы диапазона utf16 из char типа Java. Так должно быть UTF32, правильно? Итак, мне нужно проверить пары char против этого диапазона, вместо одного char s, правильно?
Мои вопросы:
- Как проверить такой характер диапазонов, используя стандартные методы Java?
- Как определить такие диапазоны в JavaCC?
- JavaCC жалуется
\u10000и\uEFFFF
- JavaCC жалуется
Спасибо!
ПРИМЕЧАНИЕ:Не волнуйтесь, я не пытаюсь написать собственный XML-анализатор.
EDIT:Я пишу синтаксический анализатор, который проверял бы, будет ли текст ввода из разных текстовых форматов (не XML) соответствовать действительным именам XML.
Явы сокрушается * символ * был задуман (чтобы защитить Snafu Гослинг), когда Unicode еще не было на 3.1. Следовательно, 16-бит char SNAFU. Это стало беспорядочным, как только Unicode 3.1 вышел, потому что вся аббревиатура char [] «абстрагируется не намного больше. Как отметил Джон Скит, трюк заключается в работе с 32-битными кодовыми точками (Java * int * s) и вычислением отношения * char-to-codepoint * в классе String и других. Ситуация * не * хорошая. Это один из беспощадных аспектов Java (потому что он затрагивает сломанный примитивный тип, глубоко укоренившийся в языке). – SyntaxT3rr0r
Этот вопрос не имеет ничего общего с UTF-32. Такие обозначения, как '# x10FFFF' и' \ u10FFFF', представляют символы в реферате; UTF-16 и UTF-32 являются кодировками, которые сообщают компьютеру, как хранить символы в памяти.Java всегда использует UTF-16, поэтому символы вне BMP хранятся с использованием двух значений 'char' или суррогатной пары. Джон уже указал, как с ними справиться. –