Error illegal character u00a0 - Исправление ошибок и поиск оптимальных решений проблем

make on linux ,I got some error
../java/org/zeromq/ZMQ.java:667: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:667: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:667: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:667: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:667: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:667: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:667: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:1082: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:1082: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:1082: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:1082: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:1082: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:1082: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:1082: error: illegal character: ‘u00a0’
        /**
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
../java/org/zeromq/ZMQ.java:1091: error: illegal character: ‘u00a0’
            setLongSockopt(56, handover);
^
25 errors

Источник

I have a program that allows a user to type java code into a rich text box and then compile it using the java compiler. Whenever I try to compile the code that I have written I get an error that says that I have an illegal character at the beginning of my code that is not there. This is the error the compiler is giving me:

C:UsersTravis Michael>"Program FilesJavajdk1.6.0_17binjavac" Test.java
Test.java:1: illegal character: 187
∩╗┐public class Test
 ^
Test.java:1: illegal character: 191
∩╗┐public class Test
  ^
2 errors

Chad Carisch

2,3923 gold badges21 silver badges30 bronze badges

asked Jan 2, 2010 at 21:33

The BOM is generated by, say, File.WriteAllText() or StreamWriter when you don’t specify an Encoding. The default is to use the UTF8 encoding and generate a BOM. You can tell the java compiler about this with its -encoding command line option.

The path of least resistance is to avoid generating the BOM. Do so by specifying System.Text.Encoding.Default, that will write the file with the characters in the default code page of your operating system and doesn’t write a BOM. Use the File.WriteAllText(String, String, Encoding) overload or the StreamWriter(String, Boolean, Encoding) constructor.

Just make sure that the file you create doesn’t get compiled by a machine in another corner of the world. It will produce mojibake.

answered Jan 2, 2010 at 22:11

Hans PassantHans Passant

913k145 gold badges1671 silver badges2507 bronze badges

That’s a byte order mark, as everyone says.

javac does not understand the BOM, not even when you try something like

javac -encoding UTF8 Test.java

You need to strip the BOM or convert your source file to another encoding. Notepad++ can convert a single files encoding, I’m not aware of a batch utility on the Windows platform for this.

The java compiler will assume the file is in your platform default encoding, so if you use this, you don’t have to specify the encoding.

answered Jan 2, 2010 at 22:30

zneozneo

5883 silver badges10 bronze badges

If using an IDE, specify the java file encoding (via the properties panel)
If NOT using an IDE, use an advanced text-editor (I can recommend Notepad++) and set the encoding to «UTF without BOM», or «ANSI», if that suits you.

answered Jan 2, 2010 at 21:43

BozhoBozho

582k142 gold badges1053 silver badges1136 bronze badges

In this case do the following Steps 1-7

In Android Studio

1. Menu -> Edit -> Select All
2. Menu -> Edit -> Cut

Open new Notepad.exe

In Notepad

4. Menu -> Edit -> Paste
5. Menu -> Edit -> Select All
6. Menu -> Edit -> Copy

Back In Android Studio

7. Menu -> Edit -> Paste

answered Jan 21, 2018 at 17:16

IngoIngo

5,1401 gold badge28 silver badges23 bronze badges

http://en.wikipedia.org/wiki/Byte_order_mark

The byte order mark (BOM) is a Unicode
character used to signal the
endianness (byte order) of a text file
or stream. Its code point is U+FEFF.
BOM use is optional, and, if used,
should appear at the start of the text
stream. Beyond its specific use as a
byte-order indicator, the BOM
character may also indicate which of
the several Unicode representations
the text is encoded in.

The BOM is a funky-looking character that you sometimes find at the start of unicode streams, giving a clue what the encoding is. It’s usually handles invisibly by the string-handling stuff in Java, so you must have confused it somehow, but without seeing your code, it’s hard to see where.

You might be able to fix it trivially by manually stripping the BOM from the string before feeding it to javac. It probably qualifies as whitespace, so try calling trim() on the input String, and feeding the output of that to javac.

answered Jan 2, 2010 at 21:42

skaffmanskaffman

396k96 gold badges814 silver badges768 bronze badges

That’s a problem related to BOM (Byte Order Mark) character. Byte Order Mark BOM is an Unicode character used for defining a text file byte order and comes in the start of the file. Eclipse doesn’t allow this character at the start of your file, so you must delete it. for this purpose, use a rich text editor like Notepad++ and save the file with encoding «UTF-8 without BOM». That should remove the problem.

I have copy pasted the some content from a website to a Notepad++ editor,
it shows the "LS" with black background. Have deleted the "LS" content and 
have copy the same content from notepad++ to java file, it works fine.

answered Mar 15, 2016 at 14:10

anand krishanand krish

4,1014 gold badges40 silver badges47 bronze badges

I solved this by right clicking in my textEdit program file and selecting [substitutions] and un-checking smart quotes.

answered Nov 11, 2016 at 18:53

instead of getting Notepad++,
You can simply
Open the file with Wordpad
and then
Save As — Plain Text document

answered Sep 6, 2016 at 15:29

Even I was facing this issue as am using notepad++ to code. It is very convenient to type the code in notepad++. However after compiling I get an error » error: illegal character: ‘u00bb'».
Solution :
Start writing the code in older version of notepad(which will be there by default in your PC) and save it. Later the modifications can be done using notepad++.
It works!!!

answered Jul 3, 2016 at 5:15

I had the same problem with a file i generated using the command echo echo "" > Main.java in Windows Powershell. I searched the problem and it seemed to have something to do with encoding. I checked the encoding of the file using file -i Main.java and the result was text/plain; charset=utf-16le.

Later i deleted the file and recreated it using git bash using touch Main.java and with this the file compiled successfully. I checked the file encoding using file -i command and this time the result was Main.java: text/x-c; charset=us-ascii.

Next i searched the internet and found that to create an empty file using Powershell we can use the Cmdlet New-Item. I create the file using New-Item Main.java and checked it’s encoding and this time the result was Main.java: text/x-c; charset=us-ascii and this time it compiled successully.

answered Apr 10, 2021 at 6:01

velocityvelocity

1,50019 silver badges23 bronze badges

Источник

1. Overview

The illegal character compilation error is a file type encoding error. It’s produced if we use an incorrect encoding in our files when they are created. As result, in languages like Java, we can get this type of error when we try to compile our project. In this tutorial, we’ll describe the problem in detail along with some scenarios where we may encounter it, and then, we’ll present some examples of how to resolve it.

2.1. Byte Order Mark (BOM)

Before we go into the byte order mark, we need to take a quick look at the UCS (Unicode) Transformation Format (UTF). UTF is a character encoding format that can encode all of the possible character code points in Unicode. There are several kinds of UTF encodings. Among all these, UTF-8 has been the most used.

UTF-8 uses an 8-bit variable-width encoding to maximize compatibility with ASCII. When we use this encoding in our files, we may find some bytes that represent the Unicode code point. As a result, our files start with a U+FEFF byte order mark (BOM). This mark, correctly used, is invisible. However, in some cases, it could lead to data errors.

In the UTF-8 encoding, the presence of the BOM is not fundamental. Although it’s not essential, the BOM may still appear in UTF-8 encoded text. The BOM addition could happen either by an encoding conversion or by a text editor that flags the content as UTF-8.

Text editors like Notepad on Windows could produce this kind of addition. As a consequence, when we use a Notepad-like text editor to create a code example and try to run it, we could get a compilation error. In contrast, modern IDEs encode created files as UTF-8 without the BOM. The next sections will show some examples of this problem.

2.2. Class with Illegal Character Compilation Error

Typically, we work with advanced IDEs, but sometimes, we use a text editor instead. Unfortunately, as we’ve learned, some text editors could create more problems than solutions because saving a file with a BOM could lead to a compilation error in Java. The “illegal character” error occurs in the compilation phase, so it’s quite easy to detect. The next example shows us how it works.

First, let’s write a simple class in our text editor, such as Notepad. This class is just a representation – we could write any code to test. Next, we save our file with the BOM to test:

public class TestBOM {
    public static void main(String ...args){
        System.out.println("BOM Test");
    }
}

Now, when we try to compile this file using the javac command:

$ javac ./TestBOM.java

Consequently, we get the error message:

∩╗┐public class TestBOM {
 ^
.TestBOM.java:1: error: illegal character: 'u00bf'
∩╗┐public class TestBOM {
  ^
2 errors

Ideally, to fix this problem, the only thing to do is save the file as UTF-8 without BOM encoding. After that, the problem is solved. We should always check that our files are saved without a BOM.

Another way to fix this issue is with a tool like dos2unix. This tool will remove the BOM and also take care of other idiosyncrasies of Windows text files.

3. Reading Files

Additionally, let’s analyze some examples of reading files encoded with BOM.

Initially, we need to create a file with BOM to use for our test. This file contains our sample text, “Hello world with BOM.” – which will be our expected string. Next, let’s start testing.

3.1. Reading Files Using BufferedReader

First, we’ll test the file using the BufferedReader class:

@Test
public void whenInputFileHasBOM_thenUseInputStream() throws IOException {
    String line;
    String actual = "";
    try (BufferedReader br = new BufferedReader(new InputStreamReader(file))) {
        while ((line = br.readLine()) != null) {
            actual += line;
        }
    }
    assertEquals(expected, actual);
}

In this case, when we try to assert that the strings are equal, we get an error:

org.opentest4j.AssertionFailedError: expected: <Hello world with BOM.> but was: <Hello world with BOM.>
Expected :Hello world with BOM.
Actual   :Hello world with BOM.

Actually, if we skim the test response, both strings look apparently equal. Even so, the actual value of the string contains the BOM. As result, the strings aren’t equal.

Moreover, a quick fix would be to replace BOM characters:

@Test
public void whenInputFileHasBOM_thenUseInputStreamWithReplace() throws IOException {
    String line;
    String actual = "";
    try (BufferedReader br = new BufferedReader(new InputStreamReader(file))) {
        while ((line = br.readLine()) != null) {
            actual += line.replace("uFEFF", "");
        }
    }
    assertEquals(expected, actual);
}

The replace method clears the BOM from our string, so our test passes. We need to work carefully with the replace method. A huge number of files to process can lead to performance issues.

3.2. Reading Files Using Apache Commons IO

In addition, the Apache Commons IO library provides the BOMInputStream class. This class is a wrapper that includes an encoded ByteOrderMark as its first bytes. Let’s see how it works:

@Test
public void whenInputFileHasBOM_thenUseBOMInputStream() throws IOException {
    String line;
    String actual = "";
    ByteOrderMark[] byteOrderMarks = new ByteOrderMark[] { 
      ByteOrderMark.UTF_8, ByteOrderMark.UTF_16BE, ByteOrderMark.UTF_16LE, ByteOrderMark.UTF_32BE, ByteOrderMark.UTF_32LE
    };
    InputStream inputStream = new BOMInputStream(ioStream, false, byteOrderMarks);
    Reader reader = new InputStreamReader(inputStream);
    BufferedReader br = new BufferedReader(reader);
    while ((line = br.readLine()) != null) {
        actual += line;
    }
    assertEquals(expected, actual);
}

The code is similar to previous examples, but we pass the BOMInputStream as a parameter into the InputStreamReader.

3.3. Reading Files Using Google Data (GData)

On the other hand, another helpful library to handle the BOM is Google Data (GData). This is an older library, but it helps manage the BOM inside the files. It uses XML as its underlying format. Let’s see it in action:

@Test
public void whenInputFileHasBOM_thenUseGoogleGdata() throws IOException {
    char[] actual = new char[21];
    try (Reader r = new UnicodeReader(ioStream, null)) {
        r.read(actual);
    }
    assertEquals(expected, String.valueOf(actual));
}

Finally, as we observed in the previous examples, removing the BOM from the files is important. If we don’t handle it properly in our files, unexpected results will happen when the data is read. That’s why we need to be aware of the existence of this mark in our files.

4. Conclusion

In this article, we covered several topics regarding the illegal character compilation error in Java. First, we learned what UTF is and how the BOM is integrated into it. Second, we showed a sample class created using a text editor – Windows Notepad, in this case. The generated class threw the compilation error for the illegal character. Finally, we presented some code examples on how to read files with a BOM.

As usual, all the code used for this example can be found over on GitHub.

Источник

Содержание

Недопустимый символ при попытке скомпилировать код Java
10 ответов
error illegal character u00bb
9 Answers 9
Недопустимый символ при попытке скомпилировать Java-код
Очень странные вещи c Java Characters
Тайна ошибки комментария и другие истории.
Вступление
Примитивный тип данных char
Печатаемые символы клавиатуры
Формат Unicode (шестнадцатеричное представление)
Специальные escape-символы
Написание Java кода в формате Unicode
Формат Unicode для escape-символов
Тайна ошибки комментария
Выводы

Недопустимый символ при попытке скомпилировать код Java

У меня есть программа, которая позволяет пользователю вводить java-код в текстовое поле, а затем компилировать его с помощью java-компилятора. Всякий раз, когда я пытаюсь скомпилировать код, который я написал, я получаю сообщение об ошибке, в котором говорится, что у меня есть незаконный символ в начале моего кода, которого нет. Это ошибка, которую компилятор мне дает:

10 ответов

Спецификация создается, например, File.WriteAllText() или StreamWriter, если вы не указали кодировку. По умолчанию используется кодировка UTF8 и создается спецификация. Вы можете сообщить компилятору java об этом с помощью параметра командной строки -encoding.

Путь наименьшего сопротивления состоит в том, чтобы избежать создания спецификации. Сделайте это, указав System.Text.Encoding.Default, который напишет файл с символами на кодовой странице по умолчанию вашей операционной системы и не будет писать спецификацию. Используйте перегрузку File.WriteAllText(String, String, Encoding) или конструктор StreamWriter (String, Boolean, Encoding).

Просто убедитесь, что созданный вами файл не скомпилируется машиной в другом уголке мира. Он произведет mojibake.

Это знак байтового порядка, как все говорят.

javac не понимает спецификацию, даже когда вы пытаетесь что-то вроде

Вам нужно снять спецификацию или преобразовать исходный файл в другую кодировку. Notepad ++ может преобразовывать единую кодировку файлов, для этого я не знаю о пакетной утилите на платформе Windows.

Компилятор java предполагает, что файл находится в кодировке по умолчанию для платформы, поэтому, если вы используете это, вам не нужно указывать кодировку.

Знак порядка байтов (BOM) — это Unicode символ, используемый для endianness (порядок байтов) текстового файла или поток. Его кодовая точка U + FEFF. Использование спецификации необязательно, и, если используется, должен появиться в начале текста поток. Помимо его конкретного использования в качестве байт-указатель, спецификация символ может также указывать, какой из несколько представлений Unicode текст закодирован.

BOM — это забавный вид, который вы иногда находите в начале потоков Unicode, давая понять, что такое кодировка. Он обычно обрабатывает невидимые элементы обработки строк в Java, поэтому вы должны каким-то образом смутить его, но, не видя своего кода, трудно увидеть, где.

Возможно, вы сможете устранить его тривиально, вручную удалив спецификацию из строки перед ее подачей на javac . Вероятно, он квалифицируется как пробел, поэтому попробуйте называть trim() на входной строке и подавать вывод этого значения на javac .

Источник

error illegal character u00bb

У меня есть исходный код проекта Eclipse (мне сказали, что в Android Studio, может быть, они просто смущены), и я начинаю переносить код в студию Android, ссылаясь на

Но это не сработает. поэтому я напрямую импортирую проект из пути, и он автоматически переносится в проект Android-студии, но все-таки что-то не так, когда я компилирую.

Ошибка: (1, 1) error: disabledcharacter: ‘ ufeff’

позиция ошибки относится к

Пожалуйста, помогите мне, спасибо

Это проблема, связанная с типом BOM (Byte Order Mark). Знак порядка байтов BOM — это символ Юникода, используемый для определения порядка байтов текстового файла и входит в начало файла. Eclipse не разрешает этот символ в начале вашего файла, поэтому вы должны его удалить. Для этого используйте богатый текстовый редактор, например Notepad ++, и сохраните файл с кодировкой «UTF-8 без спецификации». Это должно устранить проблему.

Это знак байтового порядка, как все говорят.

javac не понимает спецификацию, даже когда вы пытаетесь что-то вроде

Знак порядка байтов (BOM) — это Unicode символ, используемый для endianness (порядок байтов) текстового файла или поток. Его кодовая точка U + FEFF. Использование спецификации необязательно, и, если используется, должен появиться в начале текста поток. Помимо его конкретного использования в качестве байт-указатель, спецификация символ может также указывать, какой из несколько представлений Unicode текст закодирован.

Я решил это, щелкнув правой кнопкой мыши в своем программном файле textEdit и выбрав [замены] и отключив смарт-кавычки.

9 Answers 9

Just make sure that the file you create doesn’t get compiled by a machine in another corner of the world. It will produce mojibake.

That’s a byte order mark, as everyone says.

javac does not understand the BOM, not even when you try something like

You need to strip the BOM or convert your source file to another encoding. Notepad++ can convert a single files encoding, I’m not aware of a batch utility on the Windows platform for this.

The java compiler will assume the file is in your platform default encoding, so if you use this, you don’t have to specify the encoding.

If using an IDE, specify the java file encoding (via the properties panel)
If NOT using an IDE, use an advanced text-editor (I can recommend Notepad++) and set the encoding to «UTF without BOM», or «ANSI», if that suits you.

The byte order mark (BOM) is a Unicode character used to signal the endianness (byte order) of a text file or stream. Its code point is U+FEFF. BOM use is optional, and, if used, should appear at the start of the text stream. Beyond its specific use as a byte-order indicator, the BOM character may also indicate which of the several Unicode representations the text is encoded in.

You might be able to fix it trivially by manually stripping the BOM from the string before feeding it to javac . It probably qualifies as whitespace, so try calling trim() on the input String, and feeding the output of that to javac .

Источник

Недопустимый символ при попытке скомпилировать Java-код

У меня есть программа, которая позволяет пользователю вводить код Java в поле с форматированным текстом, а затем компилировать его с помощью компилятора Java. Всякий раз, когда я пытаюсь скомпилировать написанный мной код, я получаю сообщение об ошибке, в котором говорится, что у меня есть недопустимый символ в начале моего кода, которого нет. Это ошибка, которую выдает мне компилятор:

Спецификация создается, скажем, с помощью File.WriteAllText () или StreamWriter, если вы не указываете кодировку. По умолчанию используется кодировка UTF8 и создается спецификация. Вы можете сообщить об этом компилятору java с помощью параметра командной строки -encoding.

Путь наименьшего сопротивления — избежать создания спецификации. Сделайте это, указав System.Text.Encoding.Default, который запишет файл с символами из кодовой страницы по умолчанию вашей операционной системы и не будет записывать спецификацию. Используйте перегрузку File.WriteAllText (String, String, Encoding) или конструктор StreamWriter (String, Boolean, Encoding).

Просто убедитесь, что созданный вами файл не компилируется машиной в другом уголке мира. Из него получится моджибаке .

Как все говорят, это знак порядка байтов.

javac не понимает спецификации, даже когда вы пытаетесь что-то вроде

Вам нужно удалить спецификацию или преобразовать исходный файл в другую кодировку. Notepad ++ может преобразовывать кодировку отдельных файлов, я не знаю о пакетной утилите на платформе Windows для этого.

Компилятор java предполагает, что файл находится в кодировке по умолчанию вашей платформы, поэтому, если вы используете это, вам не нужно указывать кодировку.

При использовании IDE укажите кодировку файла java (через панель свойств)
Если НЕ используете IDE, используйте расширенный текстовый редактор (я могу порекомендовать Notepad ++ ) и установите кодировку «UTF без спецификации» или «ANSI», если вам это подходит.

В этом случае выполните следующие шаги 1-7.

В Android Studio

Откройте новый Notepad.exe

Вернуться в Android Studio

The byte order mark (BOM) is a Unicode character used to signal the endianness (byte order) of a text file or stream. Its code point is U+FEFF. BOM use is optional, and, if used, should appear at the start of the text stream. Beyond its specific use as a byte-order indicator, the BOM character may also indicate which of the several Unicode representations the text is encoded in.

Спецификация — это необычный на вид символ, который иногда можно встретить в начале потоков Unicode, что дает представление о кодировке. Обычно он незаметно обрабатывается средствами обработки строк в Java, поэтому вы, должно быть, как-то его запутали, но, не видя своего кода, трудно понять, где.

Вы можете легко исправить это, вручную удалив спецификацию из строки перед ее отправкой в javac . Вероятно, он квалифицируется как пробел, поэтому попробуйте вызвать trim() входную строку и передать ее вывод javac .

Источник

Очень странные вещи c Java Characters

Тайна ошибки комментария и другие истории.

Вступление

Знаете ли вы, что следующее является допустимым выражением Java?

Вы можете попробовать скопировать и вставить его в основной метод любого класса и скомпилировать. Если вы затем добавите следующий оператор

и после компиляции запустите этот класс, код напечатает число 8!

А знаете ли вы, что этот комментарий вместо этого вызывает синтаксическую ошибку во время компиляции?

Тем не менее, комментарии не должны приводить к синтаксическим ошибкам. Фактически, программисты часто комментируют фрагменты кода, чтобы компилятор их игнорировал. так что же происходит?

Для того, чтобы узнать почему это происходит, потратьте несколько минут на небольшой обзор основ Java о примитивном типе char .

Примитивный тип данных char

Как всем известно, char это один из восьми примитивных типов Java. Это позволяет нам хранить по одному символу. Ниже приведен простой пример, в котором значение символа присваивается типу char :

На самом деле этот тип данных используется нечасто, потому что в большинстве случаев программистам нужны последовательности символов и поэтому они предпочитают строки. Каждое буквальное значение символа должно быть заключено между двумя одинарными кавычками, чтобы не путать с двойными кавычками, используемыми для строковых литералов. Объявление строки:

Есть три способа присвоить литералу значение типа char , и все три требуют включения значения в одинарные кавычки:

используя один печатный символ на клавиатуре (например ‘&’ ).

используя формат Unicode с шестнадцатеричной нотацией (например, ‘u0061’ , который эквивалентен десятичному числу 97 и идентифицирует символ ‘a’ ).

используя специальный escape-символ (например, ‘n’ который указывает символ перевода строки).

Давайте добавим некоторые детали в следующих трех разделах.

Печатаемые символы клавиатуры

Мы можем назначить любой символ, найденный на нашей клавиатуре, char переменной, при условии, что наши системные настройки поддерживают требуемый символ и что этот символ доступен для печати (например, клавиши «Canc» и «Enter» не печатаются).

В любом случае литерал, присваиваемый примитивному типу char , всегда заключен между двумя одинарными кавычками. Вот некоторые примеры:

Тип данных char хранится в 2 байтах (16 бит), а диапазон состоит только из положительных чисел от 0 до 65 535. Фактически, существует «отображение», которое связывает определенный символ с каждым числом. Это отображение (или кодирование) определяется стандартом Unicode (более подробно описанным в следующем разделе).

Формат Unicode (шестнадцатеричное представление)

Мы сказали, что примитивный тип char хранится в 16 битах и может определять до 65 536 различных символов. Кодирование Unicode занимается стандартизацией всех символов (а также символов, смайликов, идеограмм и т. д.), существующих на этой планете. Unicode — это расширение кодировки, известной как UTF-8, которая, в свою очередь, основана на старом 8-битном расширенном стандарте ASCII, который, в свою очередь, содержит самый старый стандарт, ASCII code (аббревиатура от American Standard Code for Information Interchange).

Мы можем напрямую присвоить Unicode char значение в шестнадцатеричном формате, используя 4 цифры, которые однозначно идентифицируют данный символ, добавляя к нему префикс u (всегда в нижнем регистре). Например:

В данном случае мы говорим о литерале в формате Unicode (или литерале в шестнадцатеричном формате). Фактически, при использовании 4 цифр в шестнадцатеричном формате охватывается ровно 65 536 символов.

Java 15 поддерживает Unicode версии 13.0, которая содержит намного больше символов, чем 65 536 символов. Сегодня стандарт Unicode сильно изменился и теперь позволяет нам представлять потенциально более миллиона символов, хотя уже присвоено только 143 859 чисел конкретным символам. Но стандарт постоянно развивается. В любом случае, для присвоения значений Unicode, выходящих за пределы 16-битного диапазона типа char , мы обычно используем классы вроде String и Character , но поскольку это очень редкий случай и не интересен для целей этой статьи, мы не будем об этом говорить.

Специальные escape-символы

В char типе также можно хранить специальные escape-символы, то есть последовательности символов, которые вызывают определенное поведение при печати:

b эквивалентно backspace, отмене слева (эквивалентно клавише Delete).

n эквивалентно переводу строки (эквивалентно клавише Ente).

\ равняется только одному (только потому, что символ используется для escape-символов).

t эквивалентно горизонтальной табуляции (эквивалентно клавише TAB).

’ эквивалентно одинарной кавычке (одинарная кавычка ограничивает литерал символа).

» эквивалентно двойной кавычке (двойная кавычка ограничивает литерал строки).

r представляет собой возврат каретки (специальный символ, который перемещает курсор в начало строки).

f представляет собой подачу страницы (неиспользуемый специальный символ, представляющий курсор, перемещающийся на следующую страницу документа).

Обратите внимание, что присвоение литерала ‘»‘ символу совершенно законно, поэтому следующий оператор:

что эквивалентно следующему коду:

правильно и напечатает символ двойной кавычки:

Если бы мы попытались не использовать escape-символ для одиночных кавычек, например, со следующим утверждением:

мы получим следующие ошибки времени компиляции, поскольку компилятор не сможет различить разделители символов:

Поскольку разделители строковых литералов представлены в двойных кавычках, ситуация обратная. Фактически, внутри строки можно заключить одинарные кавычки:

С другой стороны, мы должны использовать » escape-символ, чтобы использовать двойные кавычки в строке. Итак, следующее утверждение:

вызовет следующие ошибки компиляции:

Вместо этого верна следующая инструкция:

Написание Java кода в формате Unicode

Литеральный формат Unicode также можно использовать для замены любой строки нашего кода. Фактически, компилятор сначала преобразует формат Unicode в символ, а затем оценивает синтаксис. Например, мы могли бы переписать следующий оператор:

Фактически, если мы добавим к предыдущей строке следующий оператор:

Несомненно, это бесполезный способ написания нашего кода. Но может быть полезно знать эту функцию, поскольку она позволяет нам понять некоторые ошибки, которые (редко) случаются.

Формат Unicode для escape-символов

Тот факт, что компилятор преобразует шестнадцатеричный формат Unicode перед оценкой кода, имеет некоторые последствия и оправдывает существование escape-символов. Например, давайте рассмотрим символ перевода строки, который можно представить с помощью escape-символа n . Теоретически перевод строки связан в кодировке Unicode с десятичным числом 10 (что соответствует шестнадцатеричному числу A). Но, если мы попытаемся определить его в формате Unicode:

мы получим следующую ошибку времени компиляции:

В реальности, компилятор преобразует предыдущий код в следующий перед его оценкой:

Формат Unicode был преобразован в символ новой строки, и предыдущий синтаксис не является допустимым синтаксисом для компилятора Java.

Аналогично, символ одинарной кавычки ‘ , который соответствует десятичному числу 39 (эквивалентно шестнадцатеричному числу 27) и который мы можем представить с помощью escape-символа ’, не может быть представлен в формате Unicode:

Также в этом случае компилятор преобразует предыдущий код следующим образом:

что приведет к следующим ошибкам времени компиляции:

Первая ошибка связана с тем, что первая пара кавычек не содержит символа, а вторая ошибка указывает на то, что указание третьей одинарной кавычки является незакрытым символьным литералом.

Также есть проблемы с символом возврата каретки, представленным шестнадцатеричным числом D (соответствующим десятичному числу 13) и уже представленным с помощью escape-символа r . Фактически, если мы напишем:

мы получим следующую ошибку времени компиляции:

Фактически, компилятор преобразовал число в формате Unicode в возврат каретки, вернув курсор в начало строки, и то, что должно было быть второй одинарной кавычкой, стало первой.

Что касается символа , , представленного десятичным числом 92 (соответствующего шестнадцатеричному числу 5C) и представленного escape-символом , если мы напишем:

мы получим следующую ошибку времени компиляции:

Это потому, что предыдущий код будет преобразован в следующий:

и поэтому пара символов ‘ рассматривается как escape-символ, соответствующий одинарной кавычке, и поэтому в буквальном закрытии отсутствует другая одинарная кавычка.

С другой стороны, если мы рассмотрим символ » , представленный шестнадцатеричным числом 22 (соответствующий десятичному числу 34) и представленный escape-символом » , если мы напишем:

проблем не будет. Но если мы используем этот символ внутри строки:

мы получим следующую ошибку времени компиляции:

поскольку предыдущий код будет преобразован в следующий:

Тайна ошибки комментария

Еще более странная ситуация возникает при использовании однострочных комментариев для форматов Unicode, таких как возврат каретки или перевод строки. Например, несмотря на то, что оба следующих оператора закомментированы, могут возникнуть ошибки во время компиляции!

Это связано с тем, что компилятор всегда преобразует шестнадцатеричные форматы с помощью символов перевода строки и возврата каретки, которые несовместимы с однострочными комментариями; они печатают символы вне комментария!

Чтобы разрешить ситуацию, используйте обозначение многострочного комментария, например:

Другая ошибка, из-за которой программист может потерять много времени, — это использование последовательности u в комментарии. Например, со следующим комментарием мы получим ошибку времени компиляции:

Если компилятор не находит допустимую последовательность из 4 шестнадцатеричных символов после u , он выведет следующую ошибку:

Выводы

В этой статье мы увидели, что использование типа char в Java скрывает некоторые действительно удивительные особые случаи. В частности, мы увидели, что можно писать код Java, используя формат Unicode. Это связано с тем, что компилятор сначала преобразует формат Unicode в символ, а затем оценивает синтаксис. Это означает, что программисты могут находить синтаксические ошибки там, где они никогда не ожидали, особенно в комментариях.

Примечание автора: эта статья представляет собой короткий отрывок из раздела 3.3.5 «Примитивные символьные типы данных» тома 1 моей книги «Java для пришельцев». Для получения дополнительной информации посетите сайт книги (вы можете загрузить раздел 3.3.5 из области «Примеры»).

Источник