异常教程

mybatis 大于小于转义（超详细）

更新时间:

💡一则或许对你有用的小广告

欢迎加入小哈的星球 ，你将获得：专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸：仿小红书（微服务架构）》 正在持续爆肝中，基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...，点击查看项目介绍 ;
  • 《从零手撸：前后端分离博客项目（全栈开发）》 2 期已完结，演示链接： http://116.62.199.48/ ;

截止目前， 星球 内专栏累计输出 82w+ 字，讲解图 3441+ 张，还在持续爆肝中.. 后续还会上新更多项目，目标是将 Java 领域典型的项目都整一波，如秒杀系统, 在线商城, IM 即时通讯，权限管理，Spring Cloud Alibaba 微服务等等，已有 2900+ 小伙伴加入学习 ，欢迎点击围观

问题背景与核心挑战

在使用 MyBatis 进行数据库操作时，开发者常会遇到一个看似简单却容易忽视的问题：在 SQL 语句中直接使用大于（>）或小于（<）符号时，XML 解析器会报错。这类错误通常表现为“XML 解析失败”或“SQL 语法错误”，尤其当开发者在 MyBatis 的 XML 映射文件中编写动态 SQL 时，问题会更加突出。

例如，假设我们需要查询表中价格大于 100 的商品，直接编写如下 SQL：

<select id="selectItemsByPrice" resultType="Item">  
  SELECT * FROM items WHERE price > 100  
</select>

此时，XML 解析器会报错，提示“> 符号未被正确转义”。

这一现象的本质在于 XML 标记语言的语法规范与 SQL 语句的语法冲突。XML 规定，任何 < 或 > 符号若出现在文本节点中，必须通过特殊字符转义来避免被误认为是标签的起始或结束标记。

根本原因：XML 语法与 SQL 的冲突

XML 的特殊字符规则

XML 对特殊字符有严格的限制：

  1. < 必须转义为 &lt;
  2. > 必须转义为 &gt;
  3. & 必须转义为 &amp;
  4. " 必须转义为 &quot;
  5. ' 必须转义为 &apos;

当 SQL 语句中的 > 或 < 符号未被转义时，XML 解析器会认为它们是标签的开始或结束标记，从而导致解析失败。

类比解释：快递分拣系统的比喻

想象一个快递分拣系统：

  • XML 解析器就像一个“分拣机器人”，它的规则是“遇到 < 就认为是包裹的开始，遇到 > 就认为是包裹的结束”。
  • 当 SQL 中的 > 符号未转义时，机器人会误判这是一个新包裹的结束标记，从而打乱分拣逻辑，导致系统崩溃。

这个比喻帮助理解：特殊字符在 XML 中如同“控制指令”，必须通过转义来“伪装”成普通文本。

解决方案：转义字符的正确使用

方法一：使用 XML 转义符号

直接对 > 和 < 进行转义：

<select id="selectItemsByPrice" resultType="Item">  
  SELECT * FROM items WHERE price &gt; 100  
</select>

此时，XML 解析器会将 &gt; 解析为 >，SQL 语句得以正确执行。

方法二：使用 CDATA 区段

另一种方式是将 SQL 内容包裹在 <![CDATA[ ... ]]> 区段中，告诉解析器忽略其中的特殊字符：

<select id="selectItemsByPrice" resultType="Item">  
  <![CDATA[  
    SELECT * FROM items WHERE price > 100  
  ]]>  
</select>

CDATA 的原理类似于“告诉分拣机器人：这段内容是普通包裹，无需解析”。

方法三：通过 MyBatis 的 #{} 占位符

在参数绑定场景中，若条件值动态传递，可利用 MyBatis 的 #{} 占位符间接避免转义问题：

<select id="selectItemsByPrice" resultType="Item">  
  SELECT * FROM items WHERE price > #{price}  
</select>

此时，> 符号无需转义，因为 MyBatis 会自动处理参数的绑定和转义。

关键对比：转义方法的选择策略

场景推荐方法原因说明
固定 SQL 中的 > 符号使用 &gt; 转义直接符合 XML 规范，代码可读性高
长文本 SQL 块使用 CDATA 区段避免频繁转义，减少代码冗余
动态参数传递使用 #{} 占位符自动处理转义，且防范 SQL 注入风险

进阶技巧与常见误区

误区 1：误用 ${} 而忽略转义

若使用 MyBatis 的 ${} 占位符直接拼接 SQL：

<select id="selectItemsByPrice" resultType="Item">  
  SELECT * FROM items WHERE price > ${price}  
</select>

此时，若参数 price 的值包含特殊字符（如 100 > 50），则会导致 SQL 语法错误。因此，除非必要，避免直接使用 ${}，因其会绕过 MyBatis 的参数转义机制。

误区 2：忽略其他特殊字符

除了 > 和 <，其他符号（如 &、"）也可能引发问题。例如，若 SQL 中需包含 WHERE name LIKE '%a & b%'，则需转义为 &amp;：

SELECT * FROM items WHERE name LIKE '%a &amp; b%'

动态 SQL 中的转义技巧

在编写动态 SQL（如 <if> 标签）时，转义规则同样适用。例如：

<select id="selectItems" resultType="Item">  
  SELECT * FROM items  
  <where>  
    <if test="price != null">  
      AND price &gt; #{price}  
    </if>  
  </where>  
</select>

此时，> 符号必须转义为 &gt;，否则 <if> 标签内的 SQL 片段会被 XML 解析器错误解析。

实际案例与代码示例

案例 1：商品价格筛选

需求：查询价格在 200 到 500 之间的商品。

错误写法：

<select id="selectItemsByPriceRange" resultType="Item">  
  SELECT * FROM items WHERE price > 200 AND price < 500  
</select>

此写法因未转义 > 和 <，XML 解析器会报错。

正确写法（转义法）：

<select id="selectItemsByPriceRange" resultType="Item">  
  SELECT * FROM items WHERE price &gt; 200 AND price &lt; 500  
</select>

正确写法（CDATA 法）：

<select id="selectItemsByPriceRange" resultType="Item">  
  <![CDATA[  
    SELECT * FROM items WHERE price > 200 AND price < 500  
  ]]>  
</select>

案例 2：动态参数绑定

需求：根据用户输入的最小价格查询商品。

代码实现：

public interface ItemMapper {  
  @Select("SELECT * FROM items WHERE price > #{minPrice}")  
  List<Item> selectItemsByMinPrice(@Param("minPrice") Integer price);  
}

此时，> 符号无需转义，因为 MyBatis 会自动处理参数绑定，且 SQL 写在注解中时，XML 转义规则不适用。

性能与可维护性优化

优化建议 1：优先使用 #{} 占位符

通过参数绑定而非直接拼接 SQL，既能避免转义问题，又能防范 SQL 注入攻击。例如：

<!-- 推荐写法 -->  
<select id="selectItemsByPrice" resultType="Item">  
  SELECT * FROM items WHERE price > #{minPrice}  
</select>  

Map<String, Object> params = new HashMap<>();  
params.put("minPrice", 100);  
itemMapper.selectItemsByPrice(params);

优化建议 2：结合 CDATA 与参数

在复杂 SQL 中，可混合使用 CDATA 和参数绑定：

<select id="complexQuery" resultType="Item">  
  <![CDATA[  
    SELECT * FROM items  
    WHERE (price > #{minPrice} AND price < #{maxPrice})  
    OR (category = #{category} AND name LIKE '%${keyword}%')  
  ]]>  
</select>

此处：

  • #{} 参数被安全转义
  • ${keyword} 直接拼接，需确保输入合法性

可维护性技巧：模块化 SQL 片段

将高频使用的条件语句提取为 <sql> 片段：

<sql id="priceCondition">  
  <![CDATA[ price &gt; #{minPrice} AND price &lt; #{maxPrice} ]]>  
</sql>  

<select id="selectItems" resultType="Item">  
  SELECT * FROM items  
  <where>  
    <include refid="priceCondition"/>  
    <if test="category != null">  
      AND category = #{category}  
    </if>  
  </where>  
</select>

常见问题与解答

Q1：为什么使用 <![CDATA[]]> 时可以不用转义？

A：CDATA 区段的作用是告诉 XML 解析器“忽略此区域内的所有特殊字符”，因此 > 和 < 可直接使用，但需注意 CDATA 内部不可嵌套其他标签。

Q2：在注解方式（@Select）中是否需要转义？

A：不需要。因为注解中的 SQL 字符串以 Java 字符串形式存储，XML 解析器不直接处理它，因此 > 和 < 可以直接使用。

Q3：如何快速检查 XML 文件的语法错误？

A：

  1. 使用 IDE 的 XML 验证功能（如 IntelliJ IDEA 的实时语法检查）。
  2. 通过命令行工具（如 xmllint）验证 XML 文件： 
    xmllint --noout your-mapper.xml

结论与总结

通过本文的讲解，我们系统性地解决了 MyBatis XML 配置中 大于小于符号转义的核心问题。关键要点总结如下：

  1. 根本原因：XML 语法要求特殊字符必须转义。
  2. 解决方案：使用 &gt;/&lt; 转义、CDATA 区段或参数绑定。
  3. 最佳实践：优先使用 #{} 占位符，避免直接拼接 SQL；复杂场景可结合 CDATA 和参数化查询。

掌握这一技巧后，开发者不仅能解决 XML 解析错误，还能提升代码的安全性和可维护性。在 MyBatis 的开发旅程中，这类细节问题的解决将帮助开发者更从容地应对复杂的数据库交互场景。

提示：若需进一步了解 MyBatis 的动态 SQL 机制或参数绑定原理，可参考官方文档或相关技术博客。

最新发布

查看更多文章