Java词法分析器未识别换行及Token匹配错误修复咨询

1. 解决>=被拆成TK_GT和TK_ASSIGN的问题 #

这是没遵守词法分析的最长匹配原则导致的——你得先检查双字符的运算符，再处理单个字符的。

• 调整Lexer里的符号匹配顺序：先判断当前字符是>且下一个是=，再单独处理>。
• 示例代码片段：

  // 先匹配双字符的>=
  if (currentChar == '>' && peekNext() == '=') {
      skipTwoChars();
      return Token.TK_GEQ;
  } else if (currentChar == '>') {
      skipChar();
      return Token.TK_GT;
  }
  

• 别按单个字符挨个匹配，必须先查多字符组合，不然短符号会先被匹配走。

2. 修复0x10被拆成0（TK_FLOAT）和x10（IDENTIFIER）的问题 #

你得给十六进制数加专门的识别逻辑：

• 当读到0之后，立刻检查下一个字符是不是x或X，如果是，就进入十六进制处理流程：

  if (currentChar == '0') {
      skipChar();
      if (currentChar == 'x' || currentChar == 'X') {
          skipChar();
          StringBuilder hexContent = new StringBuilder("0x");
          // 收集后续的十六进制字符：0-9、a-f、A-F
          while (isHexChar(currentChar)) {
              hexContent.append(currentChar);
              skipChar();
          }
          return Token.TK_HEXADECIMAL;
      } else {
          // 执行原来的十进制数字/浮点数逻辑
          // ...
      }
  }
  

• 自己实现一个isHexChar()工具方法，判断字符是否为合法的十六进制字符。

3. 解决数字跨行合并、未识别换行符的问题 #

这说明你的Lexer根本没处理换行符，把跨行的字符当成连续输入了：

• 在读取字符时，碰到\n要做这几件事：
  1. 行号加1（方便后续错误定位）。
  2. 如果当前正在收集数字或标识符，先把缓冲区里的内容转成对应Token返回，再清空缓冲区，避免跨行字符拼接。
  3. 可以把换行符作为单独的TK_NEWLINE Token返回，或者至少中断当前的字符匹配流程。
• 示例处理逻辑：

  while (hasMoreChars()) {
      currentChar = getNextChar();
      if (currentChar == '\n') {
          lineNum++;
          // 先处理缓冲区中未完成的内容
          if (!buffer.isEmpty()) {
              // 将缓冲区内容转换为对应Token返回
              // ...
              buffer.setLength(0);
          }
          // 可选：返回换行符Token
          // return Token.TK_NEWLINE;
          continue;
      }
      // 其他字符的处理逻辑
      // ...
  }
  

• 另外，读取文件时不要忽略换行符，要么用BufferedReader逐行读取处理，要么确保read()能正确获取到\n字符。

额外提醒 #

• 词法分析的核心规则就是最长匹配和特殊序列优先，所有识别逻辑都要围绕这两点设计。
• 修复后建议单独测试每个问题点：比如单独验证>=、0x10、跨行数字的识别情况，逐个确认修复效果。

内容的提问来源于stack exchange，提问作者Mal Beastin