🧩 背景
在开发低代码平台表单功能时，发现某些字段（如 is_active、isblock）在接口返回 JSON 数据中**显示为 "1 "（即值后带有空格）**，导致前端解析异常或逻辑判断出错。
例如：
json
"is_active": "1 ",
"isblock": "1 "而这些字段在数据库中实际存储的值是 '1'，但前端接收到的是带空格的字符串。这严重影响了业务逻辑的准确性。
🔍 问题现象
✅ 执行前（原始数据）
-
接口返回：
json"is_active": "1 ", "isblock": "1 ", "manage_unit_uuid": "-1" -
字段值末尾多出若干空格，无法正常进行字符串比较或布尔判断。
✅ 执行后（修复后）
-
接口返回：
json"is_active": "1", "isblock": "1" -
空格消失，数据干净，前端逻辑恢复正常。
🔎 根本原因分析
通过查看数据库表结构发现：
sql
CREATE TABLE ECP_FORM_FUNCTION (
IS_ACTIVE CHAR(1) DEFAULT '1',
ISBLOCK CHAR(1),
...
);⚠️ 关键点：字段类型为
CHAR(1)而非VARCHAR2(1)
💡 原理说明
在 Oracle、MySQL 等数据库中：
| 类型 | 特性 |
|---|---|
CHAR(n) |
定长字符串，若内容不足 n 个字符，则用空格右填充（right-padded with spaces） |
VARCHAR(n) |
变长字符串，只存储实际内容，不会自动补空格 |
因此，当你插入 '1' 到 CHAR(1) 字段时，数据库会存储为 '1 '（后面补空格到长度 1），虽然你看不到，但在查询或导出时可能暴露出来。
✅ 验证方法：
sqlSELECT is_active, LENGTH(is_active), DUMP(is_active) FROM ECP_FORM_FUNCTION WHERE function_uuid = 'FFCE2D460EDC4A73ABE7AFF0765820AB';输出：
is_active: '1' LENGTH: 1 DUMP: Typ=96 Len=1: 49 (ASCII 49 是 '1')但注意：Oracle 的
CHAR类型在读取时可能会保留空格，尤其在某些驱动或中间件中未做 trim 处理。
🛠️ 解决方案
✅ 步骤一：将 CHAR 字段改为 VARCHAR2
执行以下 SQL 修改字段类型（保留默认值）：
sql
ALTER TABLE GSDM.ECP_FORM_FUNCTION MODIFY IS_ACTIVE VARCHAR2(1);
ALTER TABLE GSDM.ECP_FORM_FUNCTION MODIFY ISBLOCK VARCHAR2(1);
-- 其他类似字段同理✅ 注意：Oracle 在修改字段类型时会自动保留原有默认值，无需重新设置。
✅ 步骤二：清理历史数据（可选）
如果已有脏数据（如 '1 '），可执行：
sql
UPDATE GSDM.ECP_FORM_FUNCTION
SET IS_ACTIVE = TRIM(IS_ACTIVE),
ISBLOCK = TRIM(ISBLOCK)
WHERE SYSISDELETE = '0';
COMMIT;✅ 步骤三：验证结果
再次查询数据库：
sql
SELECT IS_ACTIVE, ISBLOCK FROM ECP_FORM_FUNCTION WHERE FUNCTION_UUID = 'FFCE2D460EDC4A73ABE7AFF0765820AB';输出：
IS_ACTIVE: 1
ISBLOCK: 1无空格，正常。
📊 对比图示
| 图片 | 说明 |
|---|---|
| 图 1 | 接口返回数据中 is_active 和 isblock 显示为 "1 "，明显带空格 |
| 图 2 | 表结构显示 IS_ACTIVE、ISBLOCK 等字段为 CHAR(1)，这是根本原因 |
| 图 3 | 执行前，is_active 字段值显示为空格填充状态（客户端工具未 trim） |
| 图 4 | 将字段改为 VARCHAR2(1) 后，数据不再带空格，前端接收正常 |
✅ 最佳实践建议
- 避免使用
CHAR(n)存储短文本
如Y/N、1/0、T/F等，应统一使用VARCHAR2(1)或NUMBER(1)。 - 字段命名规范
使用IS_开头表示布尔标志，配合VARCHAR2(1)更清晰。 - 应用层处理
即使数据库正确，也建议在服务端返回前对敏感字段做TRIM()处理，防止意外。 - 迁移策略
- 先备份表
- 修改字段类型
- 清理数据
- 验证接口
🧾 总结
| 项目 | 内容 |
|---|---|
| 问题 | CHAR(1) 字段导致字符串值后带空格 |
| 原因 | CHAR(n) 自动右填充空格，影响 JSON 返回 |
| 解决 | 将 CHAR(1) 改为 VARCHAR2(1) |
| 效果 | 接口返回干净，前端逻辑稳定 |
| 建议 | 未来建表优先使用 VARCHAR2，避免定长陷阱 |
🚀 一句话总结 ：
"别让CHAR的空格毁了你的 JSON！"
📌 附录：其他常见 CHAR 字段修改语句
sql
ALTER TABLE GSDM.ECP_FORM_FUNCTION
MODIFY IS_HISTORY VARCHAR2(1),
MODIFY SYSISDELETE VARCHAR2(1),
MODIFY IS_GLOBAL VARCHAR2(1),
MODIFY ISBLOCK VARCHAR2(1),
MODIFY IS_ACTIVE VARCHAR2(1);如果你有更多类似问题，欢迎继续记录，形成一套"数据库字段设计避坑指南"！
✅ 本文可用于团队分享、知识沉淀、面试复盘等场景。