Распознавание расширенных символов с использованием JAVACC - PullRequest
Новая
       32

Распознавание расширенных символов с использованием JAVACC

4 голосов
/ 20 апреля 2009

Я создаю грамматику с использованием JavaCC и столкнулся с небольшой проблемой. Я пытаюсь разрешить любой допустимый символ в расширенном наборе ASCII, который будет распознан в результате компилятора. Посмотрев те же примеры JavaCC (прежде всего пример, показывающий сам JavaCC Grammer), я настроил следующий токен для распознавания моих символов: 

< CHARACTER:

  (   (~["'"," ","\\","\n","\r"])
    | ("\\"
        ( ["n","t","b","r","f","\\","'","\""]
        | ["0"-"7"] ( ["0"-"7"] )?
        | ["0"-"3"] ["0"-"7"] ["0"-"7"]
        )
      )
  )

>

Если я правильно понимаю, это должно совпадать в восьмеричном представлении всех символов ASCII, от 0 до 377 (который охватывает все 256 символов в расширенном наборе ASCII). Это работает как ожидается для всех символов клавиатуры (a-z, 0-9,?,. / Etc) и даже для большинства специальных символов (©, ¬ ®). Однако всякий раз, когда я пытаюсь разобрать символ «товарный знак» (™), мой анализатор постоянно выдает исключение «Конец файла», указывая на то, что он не может распознать символ. Есть ли какой-то очевидный способ улучшить определение символа, чтобы разрешить принятие символа торговой марки?

Ответы [ 2 ]

1 голос
/ 20 апреля 2009

Оказывается, что я хотел, чтобы моя грамматика принимала все допустимые символы Unicode, а не символы ASCII, символ ™ является частью спецификации Unicode, а не расширенного набора символов ASCII. Замена моего токена на действительный символ, как описано ниже, решила мою проблему: (Допустимый Unicode в формате U + 00FF) 

< CHARACTER:(   (~["'"," ","\\","\n","\r"])
| ("\\"
    ( ["n","t","b","r","f","\\","'","\""]
    | ["u","U"]["+"]["0"-"9","a"-"f","A"-"F"]["0"-"9","a"-"f","A"-"F"]["0"-"9","a"-"f","A"-"F"]["0"-"9","a"-"f","A"-"F"]
    )
  ) )>
0 голосов
/ 07 декабря 2011

У меня была похожая проблема с распознаванием специальных символов в текстовом файле (либо в кодировке CP1252, либо в кодировке ISO-8859-1), который был прочитан в строку перед анализом Мое решение было добавить UNICODE_INPUT в заголовок грамматики: 

options {
  UNICODE_INPUT=true;
}

работал как ветер.

Дополнительная информация о параметрах JavaCC: http://javacc.java.net/doc/javaccgrm.html

...