Oracle转义符避坑指南：单引号、LIKE与动态SQL-代码聚汇网

Oracle转义符避坑指南：单引号、LIKE与动态SQL

胖厨胡学斌·2026-08-30·阅读 23 GEO检测（免费）

Oracle转义符SQL特殊字符单引号双写

|难度：普通|阅读约 30 分钟

干Oracle这些年，我发现一个很有意思的现象：很多人聊数据量、聊性能优化都能侃侃而谈，结果一碰到SQL里的转义符——尤其是单引号、百分号、下划线、& 这几位“老熟人”——反而容易翻车。程序员群里经常看到有人甩出一段报错SQL，问“为什么我的字符串里有单引号就执行不了”，底下回复也是五花八门。这篇就把 Oracle 转义符这件事从头到尾理一遍，包括单引号怎么双写、LIKE 匹配里的 % 和 _ 怎么处理、正则表达式的转义、客户端 & 符号的坑，以及我在存储过程和动态SQL里踩过的具体案例。适合正在写SQL、开发PL/SQL、或者做数据处理的朋友，看完能直接拿去用。

1. 先理解Oracle的“引号哲学”：单引号才是字符串

1.1 单引号双写是唯一正式的写法

Oracle的SQL语法里，字符串常量必须用单引号包裹，比如 'ABC'。这里有一个和其他很多语言不一样的地方：它在SQL层面没有反斜杠转义机制。也就是说，你不能像Java或者C#那样，在SQL里写 'It\'s' 来表示 It's。Oracle看到反斜杠只会当作一个普通字符，并不会用它来转义后面的单引号。

正确写法是：把一个单引号写成两个连续的单引号，也就是 'It''s'。

sql复制-- 正确
SELECT 'It''s Oracle' FROM dual;

-- 错误，ORA-01756: quoted string not properly terminated
SELECT 'It's Oracle' FROM dual;

这个双写规则是Oracle在普通SQL字符串里转义单引号的唯一正式方式。注意这里跟其他数据库的差异很大：MySQL默认还支持反斜杠转义，SQL Server也是用两个单引号，但Oracle是明确不吃反斜杠这一套的。我见过太多习惯MySQL写法的人，到Oracle里写 '\'' 或者 '\\''，结果花式报错。

理解这个机制其实不难，把Oracle对字符串的解析想象成一个简单的“配对游戏”：它从左往右读，第一个单引号表示字符串开始，下一个单引号表示字符串结束，再下一个又表示开始，就这样交替。所以当你想让字符串中间出现一个单引号字符，就必须连续写两个单引号，让Oracle把这两个当作一个“内容字符”，而不是当作配对边界。

1.2 q'[]' 原生字符串：引号密集场景的救星

从Oracle 10g开始，提供了一种更舒服的写法：q'[...]'。这个语法用一对自定义的定界符包裹字符串，定界符内部的单引号不再需要双写。

sql复制SELECT q'[It's a good day]' FROM dual;
SELECT q'{O''Brien}' FROM dual;

定界符可以是方括号 []、花括号 {}、尖括号 <>、圆括号 ()，甚至可以用任意字符，比如 q'!...!'。唯一的要求是成对出现，而且内容里不能出现结束定界符。

举个例子：如果内容里本身包含 ]，而你用了 q'[...]'，那么字符串会在第一个 ] 处提前结束，照样报错。这时候换个定界符就行，比如 q'!...]...!'。下表是我实践中常用的选择思路：

字符串内容特征	推荐写法	原因
内容里大量单引号，无其他特殊符号	`q'[...]'`	不用双写，最直观
内容里包含 `]`	`q'!...!'` 或 `q'{...}'`	避开结束定界符冲突
内容里有大量反斜杠和单引号（如正则）	`q'[ ... ]'`	减少反斜杠和引号的层数计算

需要提醒的是，q'[...]' 只是字符串字面量的语法糖，它并不能突破Oracle对字符串长度的限制。普通 VARCHAR2 在SQL里的字面量长度上限是4000字节（在PL/SQL中可以是32767字节）。如果内容很长，该用CLOB还是得用CLOB，配合 DBMS_LOB 分块写入，而不是指望 q 语法能一键解决。

1.3 双引号的职责：标识符引用，别跟字符串混用

很多初学者会拿双引号当字符串，这是一个很容易踩的误区。Oracle中双引号的作用是引用标识符（quoted identifier），也就是表名、列名、约束名这些对象名称。

sql复制CREATE TABLE "My Table" ("Id" NUMBER);
SELECT "Id" FROM "My Table";

一旦使用双引号，Oracle会严格保留大小写，而且允许空格、中文等特殊字符出现在对象名里。但是如果不加双引号，Oracle会把表名、列名统一转成大写存储和管理。所以平时写表名、列名，我强烈建议统一不加双引号，避免大小写问题。很多建模工具会生成带双引号的建表语句，这是最麻烦的场景——一旦建出来了，后续所有SQL都得跟着带双引号，否则就报 ORA-00942: table or view does not exist，特别折腾。

我还在实际项目里见过有人把字符串写成双引号，比如 SELECT "abc" FROM dual，意图是返回字符串 abc，结果报 ORA-00904: invalid identifier。这就是把双引号当成字符串引号用了，本质上还是没有理解Oracle的引号职责分工。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 动态SQL和存储过程里的转义：最容易写崩的一段代码

2.1 一层嵌套拼接的引号计算

PL/SQL里写动态SQL，最常见的场景是：

sql复制v_sql := 'SELECT * FROM emp WHERE ename = ''' || v_name || '''';
EXECUTE IMMEDIATE v_sql;

这一段让很多人头皮发麻的地方在于：外面是PL/SQL字符串字面量的引号，里面又是SQL语句需要的字符串字面量引号。这两层引号叠在一起，代码看起来就像乱码。

我建议换一种更直观的写法，利用 q'[ ]' 把外层字符串包起来：

sql复制v_sql := q'[SELECT * FROM emp WHERE ename = ']' || v_name || q'[']';

这样一眼就能看出最终SQL长什么样：SELECT * FROM emp WHERE ename = ' 加上变量，最后再补一个 '。不再需要去数那几个连续引号。

不过这里有个关键问题：如果 v_name 本身包含单引号，比如值是 O'Brien，那么拼出来的SQL会变成：

sql复制SELECT * FROM emp WHERE ename = 'O'Brien'

这依然是错误的，因为 Oracle 解析时会认为字符串到 O 后面的那个单引号就结束了，后面的 Brien 变成非法标识符。所以变量内部的单引号，在拼进SQL之前必须转成双写的形式，也就是把 O'Brien 处理成 O''Brien。

处理手段就是 REPLACE：

sql复制v_ename := REPLACE(v_name, '''', '''''''');

这段代码看起来非常唬人。拆开理解：在PL/SQL里，表示一个单引号字符要写四个单引号 ''''，表示两个单引号字符要写六个单引号 ''''''。所以上面的 REPLACE 就是把变量里的一个单引号替换成两个单引号。

你想表达的字符	PL/SQL源码写法
一个单引号字符 `'`	`''''`
两个单引号字符 `''`	`''''''`

很多从Java转过来的朋友会下意识写 v_name.replace("'", "\\'")，这在Oracle存储过程里完全无效。记住：Oracle编译器不认反斜杠转义，它只认双写。

2.2 绑定变量：根治转义问题的正路

讲了这么多引号计算，其实在存储过程开发里，最推荐的做法是：能用绑定变量就用绑定变量。

sql复制v_sql := 'SELECT * FROM emp WHERE ename = :1';
EXECUTE IMMEDIATE v_sql USING v_name;

绑定变量把字符串原样传进去，完全绕开了引号转义这一层。这不仅让代码可读性更高，还有三个额外好处：

减少硬解析，SQL文本固定，共享池命中率更高；
从根上避免SQL注入风险；
不需要处理各种特殊字符的转义。

我见过不少项目里，开发人员辛辛苦苦拼动态SQL、REPLACE单引号、处理特殊字符，最后发现问题出在转义逻辑上，调试一整天。其实只要改成绑定变量，这些问题基本都消失了。

唯一不能用绑定变量的场景是表名、列名这些对象标识符，比如动态拼接 SELECT * FROM || v_table。这种只能拼接，拼接时要特别注意对象名里有没有特殊字符，尽量走白名单校验，别直接信任外部输入。

2.3 动态SQL执行前，先打印出来看一眼

如果你确实需要拼接，我有个用了很多年的习惯：在执行动态SQL之前，先把拼接结果打出来，用 DBMS_OUTPUT.PUT_LINE(v_sql) 或者写进日志表。特别是调试阶段，这一步能帮你省掉大量盲猜时间。

有一次同事跑存储过程报错，日志里只有一句 ORA-00933: SQL command not properly ended。他盯着代码看了半天，最后把 v_sql 打印出来才发现，字符串变量结尾多了一个单引号，拼接后SQL变成了 ...WHERE ename = 'O''Brien''，末尾多了一个引号。这类问题不打印出来，靠肉眼在动态拼接代码里找，效率太低了。

3. LIKE模糊查询的转义：% 和 _ 不再“通配”

3.1 ESCAPE 子句：指定你的转义字符

LIKE 里的 % 表示零个或多个任意字符，_ 表示任意一个字符。如果业务上要查包含下划线的用户名，直接写 LIKE '%_%' 会把所有记录都返回来，因为 _ 被当成了通配符。

这时候需要 ESCAPE 子句，指定一个字符作为转义符：

sql复制SELECT * FROM users WHERE username LIKE '%\_%' ESCAPE '\';

ESCAPE '\' 告诉Oracle：反斜杠后面的 % 和 _ 按字面量处理，不再是通配符。

这里有一个很典型的坑：在Oracle普通字符串里，反斜杠不是转义符，所以 '\' 直接就是一个反斜杠字符，不需要写成 '\\'。但从Java、Python或者Shell脚本里写这个SQL时，语言层可能会对反斜杠做一层处理，导致实际传给Oracle的SQL变成了 ESCAPE '\\'，也就是两个反斜杠字符，匹配范围立刻就错了。

所以实际操作中，我习惯用 ESCAPE '!' 这种不容易被各层二次转义的字符：

sql复制SELECT * FROM users WHERE username LIKE '%!_%' ESCAPE '!';

选择一个在待匹配文本中不会出现的字符作为转义符，是最稳妥的思路。尤其是跨语言拼接SQL时，避开了反斜杠在各层被转来转去的问题。

3.2 反斜杠在Oracle字符串层和正则层的双重身份

正则表达式是另一套转义体系。Oracle的 REGEXP_LIKE(source, pattern) 中，pattern 遵循POSIX正则，反斜杠用于转义元字符。

关键区别在于：Oracle普通SQL字符串层不处理反斜杠，所以你在SQL里写的 '\d'，Oracle会把反斜杠和字母d原样传给正则库，正则库再解释为“数字”。而很多从其他语言过来的人，习惯在字符串里写 '\\d'，结果正则库收到两个反斜杠加一个d，含义完全变了。

想匹配的内容	正则写法	Oracle SQL字符串写法
点号 `.`	`\.`	`'\.'`
反斜杠 `\`	`\\`	`'\\'`
数字	`\d`	`'\d'`
字母或数字	`\w`	`'\w'`

举个例子，Oracle热搜词里经常有人问“判断字符是字母”，常见写法是：

sql复制SELECT REGEXP_LIKE('A', '^[[:alpha:]]$') FROM dual;

也可以简化为 REGEXP_LIKE(c, '^[A-Za-z]+$')。这里最怕的是有人把反斜杠写成双份，导致匹配结果和预期完全对不上。

在Oracle的 REGEXP_REPLACE、REGEXP_SUBSTR 里也是一样的逻辑。你写的字符串字面量先被SQL解析器处理，然后regexp引擎再处理。两道工序各管各的：SQL层只管单引号双写，不管反斜杠；正则层才管反斜杠转义。把这个分工想清楚，很多混乱就能避免。

3.3 不要把所有模糊匹配都扔给正则

转义问题搞清楚之后，还有一个更实际的选型问题：LIKE 和 REGEXP_LIKE 怎么选。

LIKE 在特定情况下可以走索引，比如 LIKE 'ABC%'，Oracle可能使用索引范围扫描。但一旦写成 LIKE '%ABC%'，前置百分号导致索引失效，只能全表扫。正则更是几乎无法走索引。

我们项目里有一次为了支持复杂的业务筛选规则，把所有 LIKE 都改成了 REGEXP_LIKE，虽然功能的表达能力强了，但查询耗时直接上升了一个数量级。后面不得不对筛选条件做分类，能用LIKE的就用LIKE，能用等值的就用等值，正则只留给真正需要复杂模式匹配的场景。转义只是语法层面的问题，选错工具才是性能上的大坑。

4. 客户端和脚本层面的转义：&、/ 与文件执行

4.1 & 符号：SQL*Plus变量替换的陷阱

在SQL*Plus、SQL Developer、PL/SQL Developer这些客户端工具里，& 默认是替换变量符号。如果SQL文本里有 &，比如：

sql复制SELECT 'A&B' FROM dual;

在SQL*Plus里执行时，会弹出类似 Enter value for b: 的提示，或者把 &b 直接替换成别的字符串。这不是Oracle数据库本身的行为，而是客户端工具做了预处理。

解决办法很简单，在脚本开头执行：

sql复制SET DEFINE OFF;

这条命令会关闭变量替换功能。之后SQL文本里的 & 就能被当作普通字符。也可以改成 SET DEFINE ~;，把替换符号换成别的字符，但这需要在所有脚本里保持一致，容易遗漏。日常维护最省事的还是 SET DEFINE OFF;。

需要注意的是，存储过程内部的 EXECUTE IMMEDIATE 不受客户端 & 替换影响，因为那段SQL字符串直接交给数据库解析了，不经过客户端工具。最容易出问题的是用SQL*Plus执行 .sql 脚本文件，脚本里又有 INSERT、UPDATE 语句包含 & 的情况。比如往业务表里插入一个URL参数：

sql复制INSERT INTO api_config(url) VALUES ('https://host/api?a=1&b=2');

如果不加 SET DEFINE OFF;，执行时就会提示输入b的值，或者把 &b=2 替换掉，插入的数据直接错了。

4.2 斜杠与分号：PL/SQL块执行的边界

在SQL*Plus里执行PL/SQL块时，末尾要加一个单独的斜杠 /：

sql复制BEGIN
  DBMS_OUTPUT.PUT_LINE('OK');
END;
/

这个斜杠不是SQL的一部分，也不是注释符，它的作用是告诉SQL*Plus“把缓冲区里的内容交给数据库执行”。如果漏了斜杠，PL/SQL块不会执行，只是留在缓冲区里，容易造成后续脚本执行顺序混乱。

类似地，SQL*Plus里的 CONNECT、SET、SPOOL 这些命令也不是SQL，不需要分号结尾。字符串里的分号和语句结束的分号是两回事，别混在一起。我在排查脚本问题的时候就见过，有人把SQL文件里的 & 和末尾斜杠搞混，结果脚本执行完一半才报错。

4.3 Shell脚本里的二次转义

如果用Shell脚本去调用sqlplus，转义问题还会再叠一层。比如在 bash 的 here-document 里写SQL：

bash复制sqlplus user/pass@db <<EOF
SET DEFINE OFF;
INSERT INTO t(msg) VALUES ('100% done & ok');
COMMIT;
EOF

Shell层的 & 如果没处理好，可能被解释成后台执行符号。这里因为整个SQL文本在 here-document 里，情况好一些；但如果直接用 sqlplus -S user/pass@db "SELECT 'A&B' FROM dual;"，就很容易被Shell吃掉。

我的经验是：尽量避免在Shell命令行里直接嵌入复杂SQL，把SQL单独写成 .sql 文件，然后通过 sqlplus user/pass@db @script.sql 执行，把Shell层面的干扰降到最低。如果一定要在Shell里拼SQL，先 echo 出来看看实际执行的文本是什么，再决定要不要加转义。

5. 我从实际故障中总结的转义排查套路

5.1 三个高频报错的根因

处理转义问题多了，我发现大部分报错都能归到三类：

报错信息	根因	修复方向
ORA-01756: quoted string not properly terminated	字符串中需要单引号但没双写，或结束引号缺失	检查字符串边界，单引号全部双写
ORA-00911: invalid character	SQL文本中有全角符号、中文引号、多余分隔符	检查字符串之外的特殊字符
ORA-00904: invalid identifier	把字符串写成了双引号，或者别名大小写不一致	区分双引号标识符与字符串单引号

ORA-01756 是最常见的。我见过最离谱的一次，是有人从Word文档里复制了一段SQL，里面引号被Word自动替换成了中文弯引号，结果整整排查了一个多小时。从那以后，我所有SQL都坚持在纯文本编辑器里写，写完整理完再粘贴到客户端。

5.2 动态SQL排查五步法

遇到动态SQL相关错误，我一般不直接改代码，而是按这五步走：

把拼接后的SQL打印出来，用 DBMS_OUTPUT.PUT_LINE(v_sql) 或者插入日志表。
把打印出来的SQL复制到SQL窗口手动执行，看是否报同样的错误。
如果报错，在报错位置前后数引号，重点看字符串变量里的单引号有没有被 REPLACE 成双写。
检查SQL文本里有没有 & 符号被客户端吃掉。
判断拼接受阻的字段能否改成绑定变量，能改就改。

这套流程帮我处理过大量看起来莫名其妙的ORA错误。很多问题在没看到实际拼接SQL之前，根本没法定位。

5.3 一个典型的组合案例

给大家看一个真实案例：业务要求按用户名模糊查询，用户在搜索框里输入了 O'Brien_1%，要求精确匹配这些特殊字符。也就是说，最终SQL要查的是包含 O'Brien_1% 这个字面量的用户名。

这需要同时处理三件事：单引号要转成双写、下划线和百分号要转义、LIKE两侧还要加上通配符。最终的SQL应该长这样：

sql复制SELECT * FROM users
WHERE username LIKE '%O''Brien\_1\%%' ESCAPE '\';

处理流程分成两步。第一步是转义用户输入：

sql复制v_input := REPLACE(v_input, '\', '\\');
v_input := REPLACE(v_input, '%', '\%');
v_input := REPLACE(v_input, '_', '\_');
v_input := REPLACE(v_input, '''', '''''');

第二步是拼LIKE条件。我推荐用 q'[ ]' 或者绑定变量来构造，避免引号层数爆炸：

sql复制v_pattern := '%' || v_input || '%';
EXECUTE IMMEDIATE
  q'[SELECT * FROM users WHERE username LIKE :1 ESCAPE '\']'
  USING v_pattern;

注意这里的优先级：先处理反斜杠本身，再处理 % 和 _，最后处理单引号。反斜杠如果不先转义，后面给 % 加的反斜杠可能会被误解。顺序不能乱。

这是我最推荐的做法：转义逻辑保留在业务变量里，最终SQL文本通过绑定变量传入。这样既处理了通配符转义，又避免了动态拼接时最外层的引号地狱。

5.4 安全视角：转义不只是让程序跑通

最后必须强调一点：处理转义字符不只是为了让SQL不报错，更是为了防SQL注入。

假设你有一段动态SQL：

sql复制v_sql := 'SELECT * FROM users WHERE username = ''' || v_name || '''';
EXECUTE IMMEDIATE v_sql;

如果 v_name 直接取了外部输入，攻击者传入 ' OR '1'='1，最终SQL就变成了：

sql复制SELECT * FROM users WHERE username = '' OR '1'='1'

这个查询会返回所有用户数据。外部输入一旦进入动态SQL，就必须先做单引号双写处理，或者直接用绑定变量。绑定变量是最稳的方案，因为它从机制上让输入不再参与SQL文本解析。

如果让我总结一句，转义不是背规则，而是搞清每一层解析器各自认哪些特殊字符。写SQL时多问自己：这一层是谁在解析？是Oracle的SQL引擎、PL/SQL编译器、正则库、SQL*Plus，还是Shell？每一层都有各自的转义规则，层数一变，写法就要变。这个想通了，绝大多数转义坑都能避开。真碰上搞不定的情况，先把最终要执行的SQL完整打出来看一眼，再动手改代码，远比你盯着那一堆引号猜来猜去高效得多。