Сравнение символа к кодовой точке?
Если экземпляр нетривиального типа структуры хранится в доступном для записи месте хранения (не readonly поле, локальная переменная, слот массива и т. Д.), Все его поля будут изменяемыми. Если экземпляр хранится в недоступном для записи месте хранения (поле readonly, временное значение, сгенерированное компилятором и т. Д.), То ни одно из его полей не будет изменяемым. Понятие «тип неизменяемой структуры» является неправильным, поскольку утверждение:
myStruct1 = myStruct2; // Assume variables are of the same structure type
, если myStruct1 доступно для записи, заменит все открытые и закрытые поля из myStruct1 соответствующими полями myStruct2; если myStruct1 не доступно для записи, оператор сгенерирует ошибку во время компиляции. Код для структуры не имеет права голоса в этом вопросе, и даже не будет уведомлен о том, что присвоение выполнено .
Хотя DateTime не предоставляет никаких средств, с помощью которых можно изменить существующий экземпляр DateTime , кроме как посредством целочисленного присваивания , он ничего не может сделать для того, чтобы код не мог перезаписать поля одного экземпляра с помощью содержимое другого, как это происходит с dateTimeVariable = DateTime.Now;.
5 ответов
Немного предыстории: когда в 1995 году появилась Java, тип char был основан на исходной спецификации « Unicode 88 », которая была ограничено 16 битами. Год спустя, когда был реализован Unicode 2.0, была введена концепция суррогатных символов для выхода за пределы 16-битного ограничения.
Java внутренне представляет все String в формате UTF-16. Для кодовых точек, превышающих U + FFFF, кодовая точка представлена суррогатной парой, то есть двумя char s, первая из которых является единицей кода с высоким суррогатом (в диапазоне \ uD800- \ uDBFF), второй - младший суррогатный код (в диапазоне \ uDC00- \ uDFFF).
С первых дней все базовые методы Character были основаны на предположении, что кодовая точка может быть представлена одним char , так что подписи методов выглядят именно так. Я думаю, чтобы сохранить обратную совместимость, которая не изменилась, когда появился Unicode 2.0, и при работе с ними необходимо соблюдать осторожность. Цитата из документации Java :
- Методы, которые принимают только значение char, не могут поддерживать дополнительные символы. Они обрабатывают значения char из суррогатных диапазонов как неопределенные символы. Например, Character.isLetter ('\ uD840') возвращает false, даже если это конкретное значение, если за ним следует любое низко суррогатное значение в строке, будет представлять букву.
- Методы, которые принимают значение int, поддерживают все символы Unicode. , включая дополнительные символы. Например,
Для символов в базовой многоязычной плоскости приведение char к int даст вам код. Это соответствует всем значениям Unicode, которые могут быть закодированы в одном 16-битном значении char. Значения вне этой плоскости (с кодовыми точками, превышающими 0xffff) не могут быть выражены как один символ. Вероятно, поэтому отсутствует Character.toCodePoint (значение символа).
Для символа, который может быть представлен одним символом (16 бит, базовая многоязычная плоскость), вы можете получить код, просто преобразовав символ в целое число (как следует из вопроса), поэтому нет необходимости в специальном методе для выполнения преобразования.
Если вы сравниваете символ с кодом, вам не нужен специальный регистр. Просто сравните char с int напрямую (как следует из вопроса). Если int представляет кодовую точку за пределами базовой многоязычной плоскости, результат всегда будет ложным.
Класс Character содержит множество полезных методов для работы с кодовыми точками Unicode. Обратите внимание на такие методы, как Character.toChars (int) , которые возвращают массив символов. Если ваша кодовая точка находится в дополнительном диапазоне, то массив будет иметь длину два символа.
Как вы хотите сравнивать значения, зависит от того, хотите ли вы поддерживать полный диапазон значений Unicode. Этот пример кода можно использовать для перебора кодовых точек String, проверяя, есть ли совпадение для дополнительного символа MATHEMATICAL_FRAKTUR_CAPITAL_G (
Java использует 16-битную (UTF-16) модель для обработки символов , поэтому любые символы с кодовыми точками> 0xFFFF хранятся в строках как пар 16-битных символов с использованием двух суррогатных символов для представления плоскости и символа внутри плоскости.
Если вы хотите обрабатывать символы и строки правильно, согласно полному стандарту Unicode, вам нужно обрабатывать строки с учетом этого.
XML очень заботится об этом; полезно получить доступ к классу XMLChar в Xerces (который поставляется с версией Java 5.0 и выше) для символьного кода.
Также поучительно взглянуть на процессор Saxon XSLT / XQuery, поскольку он является хорошее приложение XML, оно должно учитывать, как Java хранит кодовые точки в строках. XQuery 1.0 и XPath 2.0 имеют функции для кодовых точек-строк и строк-кодовых точек ;