Как обнаружить символы unicode в строке Java?
предположим, что у меня есть строка, содержащая Ü. Как я найду все эти символы unicode? Должен ли я проверить их код? Как мне это сделать?
например, учитывая строку «AÜXÜ», я хотел бы преобразовать ее в»AYXY». Я хотел бы сделать то же самое для других символов Юникода, и мне бы не хотелось хранить их в какой-то карте перевода.
6 ответов
определение «символов Юникода» является расплывчатым, но будет принято за символы UTF-8, не охваченные стандартом кодировка ISO 8859. Если это верно в вашем случае, выполните цикл через все символы в строке и проверьте ее кодовую точку, чтобы определить, находится ли она в заданном наборе символов.
можно использовать Map и символы на карте, которые содержат совпадают с ключами. Например:
или, вы имеете в виду «все символы с диакритикой»? Если да, то используйте java.text.Normalizer удалить диакритические знаки:
одна ловушка, Ü станет U, а не Y. не уверен, что это то, что вам нужно. Если вы хотите заменить произнесенный символ, вам действительно нужно создать сопоставление. Конечно, это утомительная работа, но она сделана за меньшее время, чем вам нужно, чтобы следовать этой теме.
вы можете перебирать строку и для каждого вызова символа
вы можете пойти другим путем и спросить, является ли символ символом ascii.
вам, конечно,придется проанализировать строку char по char.
(метод commons-lang Charutils, который содержит множество полезных методов персонаж)
мне не совсем ясно, что получается при преобразовании «AÜXÜ»в » AYXY». Это потому, что Ü произносится как Y на определенном языке? На каком языке? И какие еще правила могут применяться?
С точки зрения терминологии.
выше приведена строка Unicode. Он содержит один кодированный символ UTF-16.
Если вы хотите ограничить диапазон символов английского алфавита, посмотрите нормализация выполняется в этом ответе.
класс Character также предлагает некоторые интересные методы. Взгляните на него.
Создание символа Юникода из его номера
Я хочу отобразить символ Unicode в Java. Если я это сделаю, все будет хорошо:
String symbol = «\u2202»;
символ равен “∂”. Это то, что я хочу.
Проблема в том, что я знаю номер Юникода и мне нужно создать символ Юникода. Я пробовал (мне) очевидную вещь:
Однако в этом случае символ равен “\ u2202”. Это не то, что я хочу.
Как я могу построить символ, если я знаю его номер Юникода (но только во время выполнения — я не могу его жестко записать в первом примере)?
Преобразует указанный символ (кодовая точка Юникода) в его представление UTF-16, хранящееся в массиве char. Если указанная кодовая точка является значением BMP (Basic Multilingual Plane или Plane 0), результирующий массив char имеет то же значение, что и codePoint. Если указанная кодовая точка является дополнительной кодовой точкой, результирующий массив char имеет соответствующую суррогатную пару.
Другие ответы здесь либо поддерживают только unicode до U + FFFF (ответы, относящиеся только к одному экземпляру char), либо не сообщают, как добраться до фактического символа (ответы останавливаются на Character.toChars( ) или с использованием некорректного метода после этого), поэтому добавление моего ответа здесь тоже.
Чтобы поддерживать дополнительные кодовые точки, это то, что нужно сделать:
Я также быстро проверил, какие методы преобразования работают, а какие
Помните, что char является интегральным типом и поэтому может быть задано целочисленное значение, а также константа char.
Это работало отлично для меня.
Теперь text2 будет иметь.
Вот как вы это делаете:
Хотя это старый вопрос, в Java 11, который был выпущен сегодня, есть очень простой способ сделать это: вы можете использовать новую перегрузку Character.toString():
Поскольку этот метод поддерживает любую кодовую точку Unicode, длина возвращаемой строки не обязательно равна 1.
Код, необходимый для примера, приведенного в вопросе, просто:
Этот подход предлагает несколько преимуществ:
В приведенном ниже коде будут записаны четыре символа unicode (представленные десятичными знаками) для слова “be” на японском языке. Да, глагол “быть” на японском языке имеет 4 символа!
Значение символов находится в десятичной форме и оно считывается в массив String [] – например, с использованием split. Если у вас есть Octal или Hex, parseInt возьмите радиус.
К сожалению, удалить один ответ, упомянутый в первом комментарии (newbiedoodle), не приведет к хорошему результату. Большинство (если не все) IDE вызывают синтаксическую ошибку. Причина в том, что Java Escapeed Unicode формат ожидает синтаксиса “\ uXXXX”, где XXXX – это четыре шестнадцатеричных цифры, которые являются обязательными. Попытки свернуть эту строку из кусков не удаются. Конечно, “\ u” не совпадает с “\\ u”. Первый синтаксис означает “u”, второй означает экранированный люфт (который представляет собой люфт), за которым следует “u”. Странно, что на страницах Apache представлена утилита, которая выполняет именно это поведение. Но на самом деле это Escape mimic utility. У Apache есть свои собственные утилиты (я их не тестировал), которые делают это для вас. Может быть, это все еще не так, что вы хотите иметь. Утилиты Apache Escape Unicode Но эта утилита 1 имеет хорошие подход к решению. С комбинацией, описанной выше (MeraNaamJoker). Мое решение – создать эту Escaped mimic строку, а затем преобразовать ее обратно в unicode (чтобы избежать реального ограничения Unicode). Я использовал его для копирования текста, поэтому возможно, что в методе uencode лучше использовать ‘\\ u’, кроме ‘\\\\ u’. Попробуйте.
Вот блок для печати символов unicode между \u00c0 и \u00ff :
char c = (char) 0x2202;
Строка s = “” + c;
(ANSWER IS IN DOT NET 4.5 и в java, должен существовать аналогичный подход)
Теперь, если вы знаете это значение в отношении своего языка, то как вы производите правильный символ Unicode на этом языке?
В Dot Net это так просто:
Теперь x – ваш ответ.
Но это HEX путем преобразования HEX и предложения в предложение преобразования – это работа для исследователей: P
Java: Юникод
Данные программы хранятся в памяти компьютера (оперативной или постоянной) в виде последовательности нулей и единиц. На этом уровне нет разницы между строками, числами или булевыми значениями, в памяти все выглядит одинаково. Разница появляется только в результате интерпретации. Программа знает, что внутри некоторой переменной хранится строка, поэтому она берет нули и единички и пропускает их сквозь кодовую таблицу, в которой указано, какому числу соответствует какая буква. В результате программист видит строку.
Поначалу все было хорошо, но с распространением компьютеров возникла потребность в других алфавитах. Каждая страна решала данную проблему созданием собственной кодировки, большинство из которых совместимы с ASCII. То есть первые 128 номеров полностью соответствовали ASCII, а вот остальные 128 заполнялись локальным алфавитом. 128 + 128 = 256, а это 2 в 8 степени. Эти кодировки были однобайтовыми (для хранения одного символа требовался один байт). Внезапно открылись врата ада. Попытка открыть в редакторе файл в другой кодировке, приводила к появлению крякозябр: Øèðîêàÿ ýëåêòðèôèêàöèÿ þæíûõ ãóáåðíèé äàñò ìîùíûé òîë÷îê ïîäú¸ìó ñåëüñêîãî õîçÿéñòâà. Возникают они потому, что один и тот же код в разных кодировках соответствует совершенно разным символам, за исключением первых 128. Поэтому текст, использующий английские буквы всегда читался, а в остальном как повезет. Ситуация усугублялась тем, что даже в рамках одного алфавита создавалось множество разных кодировок, например: Windows-1252, KOI8-R, CP 866, ISO 8859-5.
В языках программирования на тот момент все функции для работы со строками создавались из расчета, что один символ — это один байт. По крайней мере, это свойство было общим для всех кодировок.
Разные кодировки стали причиной постоянных проблем при взаимодействии людей и программ. Особенно остро эта проблема проявилась с развитием интернета. Такая ситуация не могла продолжаться бесконечно, и в конце концов был создан стандарт Юникод (Unicode). На данный момент он содержит более 100 тысяч символов и включает в себя все существующие (и даже мёртвые) языки. Стандарт Юникод не является кодировкой и ничего не говорит о том, как должны храниться символы в памяти, он лишь определяет связь между символом и некоторым числом. Конкретный способ кодирования юникода определяется соответствующими кодировками, среди которых UTF-8, UTF-16 и некоторые другие. В этих кодировках для хранения одного символа уже недостаточно одного байта, они используют больше. UTF-8 ведет себя хитрее: для символов английского алфавита (и некоторых других) используется один байт, для других алфавитов — 2.
После многих лет популяризации Юникода свершилось чудо, и сейчас подавляющее большинство программного обеспечения использует UTF-8. Этот процесс был болезненный и по-разному отразился на языках программирования.
Языки разделились на два лагеря. Некоторые встроили поддержку в уже существующие функции и переход на UTF-8 никак не отразился на процессе программирования. Среди них Java, Ruby, JavaScript.
Задание
Эта задача для тренировки и не относится к теме урока.
Очень странные вещи c Java Characters
Тайна ошибки комментария и другие истории.
Вступление
Знаете ли вы, что следующее является допустимым выражением Java?
Вы можете попробовать скопировать и вставить его в основной метод любого класса и скомпилировать. Если вы затем добавите следующий оператор
и после компиляции запустите этот класс, код напечатает число 8!
А знаете ли вы, что этот комментарий вместо этого вызывает синтаксическую ошибку во время компиляции?
Тем не менее, комментарии не должны приводить к синтаксическим ошибкам. Фактически, программисты часто комментируют фрагменты кода, чтобы компилятор их игнорировал. так что же происходит?
Примитивный тип данных char
Как всем известно, char это один из восьми примитивных типов Java. Это позволяет нам хранить по одному символу. Ниже приведен простой пример, в котором значение символа присваивается типу char :
На самом деле этот тип данных используется нечасто, потому что в большинстве случаев программистам нужны последовательности символов и поэтому они предпочитают строки. Каждое буквальное значение символа должно быть заключено между двумя одинарными кавычками, чтобы не путать с двойными кавычками, используемыми для строковых литералов. Объявление строки:
используя один печатный символ на клавиатуре (например ‘&’ ).
используя специальный escape-символ (например, ‘\n’ который указывает символ перевода строки).
Давайте добавим некоторые детали в следующих трех разделах.
Печатаемые символы клавиатуры
Мы можем назначить любой символ, найденный на нашей клавиатуре, char переменной, при условии, что наши системные настройки поддерживают требуемый символ и что этот символ доступен для печати (например, клавиши «Canc» и «Enter» не печатаются).
Тип данных char хранится в 2 байтах (16 бит), а диапазон состоит только из положительных чисел от 0 до 65 535. Фактически, существует «отображение», которое связывает определенный символ с каждым числом. Это отображение (или кодирование) определяется стандартом Unicode (более подробно описанным в следующем разделе).
Формат Unicode (шестнадцатеричное представление)
Мы можем напрямую присвоить Unicode char значение в шестнадцатеричном формате, используя 4 цифры, которые однозначно идентифицируют данный символ, добавляя к нему префикс \u (всегда в нижнем регистре). Например:
В данном случае мы говорим о литерале в формате Unicode (или литерале в шестнадцатеричном формате). Фактически, при использовании 4 цифр в шестнадцатеричном формате охватывается ровно 65 536 символов.
Специальные escape-символы
В char типе также можно хранить специальные escape-символы, то есть последовательности символов, которые вызывают определенное поведение при печати:
\b эквивалентно backspace, отмене слева (эквивалентно клавише Delete).
\n эквивалентно переводу строки (эквивалентно клавише Ente).
\\ равняется только одному \ (только потому, что символ \ используется для escape-символов).
\t эквивалентно горизонтальной табуляции (эквивалентно клавише TAB).
\’ эквивалентно одинарной кавычке (одинарная кавычка ограничивает литерал символа).
\» эквивалентно двойной кавычке (двойная кавычка ограничивает литерал строки).
\r представляет собой возврат каретки (специальный символ, который перемещает курсор в начало строки).
\f представляет собой подачу страницы (неиспользуемый специальный символ, представляющий курсор, перемещающийся на следующую страницу документа).
Обратите внимание, что присвоение литерала ‘»‘ символу совершенно законно, поэтому следующий оператор:
что эквивалентно следующему коду:
правильно и напечатает символ двойной кавычки:
Если бы мы попытались не использовать escape-символ для одиночных кавычек, например, со следующим утверждением:
мы получим следующие ошибки времени компиляции, поскольку компилятор не сможет различить разделители символов:
Поскольку разделители строковых литералов представлены в двойных кавычках, ситуация обратная. Фактически, внутри строки можно заключить одинарные кавычки:
С другой стороны, мы должны использовать \» escape-символ, чтобы использовать двойные кавычки в строке. Итак, следующее утверждение:
вызовет следующие ошибки компиляции:
Вместо этого верна следующая инструкция:
Написание Java кода в формате Unicode
Литеральный формат Unicode также можно использовать для замены любой строки нашего кода. Фактически, компилятор сначала преобразует формат Unicode в символ, а затем оценивает синтаксис. Например, мы могли бы переписать следующий оператор:
Фактически, если мы добавим к предыдущей строке следующий оператор:
Несомненно, это бесполезный способ написания нашего кода. Но может быть полезно знать эту функцию, поскольку она позволяет нам понять некоторые ошибки, которые (редко) случаются.
Формат Unicode для escape-символов
мы получим следующую ошибку времени компиляции:
В реальности, компилятор преобразует предыдущий код в следующий перед его оценкой:
Формат Unicode был преобразован в символ новой строки, и предыдущий синтаксис не является допустимым синтаксисом для компилятора Java.
Также в этом случае компилятор преобразует предыдущий код следующим образом:
что приведет к следующим ошибкам времени компиляции:
Первая ошибка связана с тем, что первая пара кавычек не содержит символа, а вторая ошибка указывает на то, что указание третьей одинарной кавычки является незакрытым символьным литералом.
мы получим следующую ошибку времени компиляции:
Фактически, компилятор преобразовал число в формате Unicode в возврат каретки, вернув курсор в начало строки, и то, что должно было быть второй одинарной кавычкой, стало первой.
мы получим следующую ошибку времени компиляции:
Это потому, что предыдущий код будет преобразован в следующий:
и поэтому пара символов ‘ рассматривается как escape-символ, соответствующий одинарной кавычке, и поэтому в буквальном закрытии отсутствует другая одинарная кавычка.
проблем не будет. Но если мы используем этот символ внутри строки:
мы получим следующую ошибку времени компиляции:
поскольку предыдущий код будет преобразован в следующий:
Тайна ошибки комментария
Еще более странная ситуация возникает при использовании однострочных комментариев для форматов Unicode, таких как возврат каретки или перевод строки. Например, несмотря на то, что оба следующих оператора закомментированы, могут возникнуть ошибки во время компиляции!
Это связано с тем, что компилятор всегда преобразует шестнадцатеричные форматы с помощью символов перевода строки и возврата каретки, которые несовместимы с однострочными комментариями; они печатают символы вне комментария!
Чтобы разрешить ситуацию, используйте обозначение многострочного комментария, например:
Выводы
В этой статье мы увидели, что использование типа char в Java скрывает некоторые действительно удивительные особые случаи. В частности, мы увидели, что можно писать код Java, используя формат Unicode. Это связано с тем, что компилятор сначала преобразует формат Unicode в символ, а затем оценивает синтаксис. Это означает, что программисты могут находить синтаксические ошибки там, где они никогда не ожидали, особенно в комментариях.
Примечание автора: эта статья представляет собой короткий отрывок из раздела 3.3.5 «Примитивные символьные типы данных» тома 1 моей книги «Java для пришельцев». Для получения дополнительной информации посетите сайт книги (вы можете загрузить раздел 3.3.5 из области «Примеры»).
Java, Unicode и таинственная ошибка компиляции
Начнем с самого начала. Экранирование Unicode используется для представления символов Unicode только с символами ASCII. Это пригодится, когда вам нужно вставить символ, который не может быть представлен в наборе символов исходного файла. В соответствии с разделом 3.3 Спецификации языка Java (JLS) экранирование Юникода состоит из символа обратной косой черты (\), за которым следуют один или несколько символов «u» и четыре шестнадцатеричных цифры.
Так, например, \u000A
Пример использования
Ниже приведен фрагмент кода Java, содержащий escape-код Unicode.
Найдите минутку, чтобы подумать о том, что будет распечатано. Если вы хотите, скопируйте и вставьте код в новый файл, скомпилируйте и запустите его.
На первый взгляд, похоже, что программа печатает 18 Между двойными кавычками 18 символов, поэтому длина строки должна быть 18. Но если вы запустите программу, вы получите 13 Как следует из комментария, экранирование Unicode будет заменено одним символом.
Осознавая, что экранированные символы Юникода заменяются соответствующими символами Юникода, давайте рассмотрим следующий пример.
Можете ли вы угадать, что будет распечатано сейчас? Ответ должен быть таким же, как и раньше, верно? Я уверен, что некоторые из вас могут подозревать, что это вопрос с подвохом, и на самом деле это так. Этот пример не будет компилироваться вообще.
Какая!? Так много ошибок! Моя IDE не показывает волнистые красные линии, и я не могу найти синтаксические ошибки самостоятельно. Ошибка в строке 3? Но это комментарий. Что здесь происходит?
Что вызвало ошибку?
Спецификация языка Java говорит, что лексический перевод выполняется в следующих 3 шагах, где каждый шаг применяется к результату предыдущего шага:
Как видите, самый первый шаг процесса Unicode обрабатывает побеги. Это делается до того, как у компилятора появится возможность разделить исходный код на токены. Вообще говоря, это похоже на применение функции поиска и замены в исходном коде, замену всех правильно сформированных экранированных символов Юникода соответствующими символами Юникода, а затем разрешение компилятору работать с остальной частью кода.
Имейте в виду, что при обработке экранирования Unicode компилятор не отличает комментарии от реального кода. Он может видеть только последовательность символов. И это объясняет ошибочный код, который вы видели во введении этого поста. Давайте посмотрим на это снова.
Экран Unicode, представляющий символ перевода строки, заменяется переводом строки, и теперь часть комментария находится на новой строке. К сожалению, новая строка не начинается с двойной косой черты ( // Отсюда запутанная ошибка компилятора, показанная ранее.
