一个很小的现象：从平台下载 ID 数据，再上传到标签或分群，结果表里的主体值带上了双引号。页面看起来是同一个 ID，关联时却匹配不上。
出问题的是序列化边界
CSV 下载侧会给字段加双引号，字段里的双引号用两个双引号转义。这是文件格式的一部分，并不属于业务值。
旧导入实现直接按逗号拆分再 trim，于是把包裹引号也写进了结果表。更隐蔽的是，字段本身包含逗号时，直接 split 还会拆错列；Excel 导出的 UTF-8 BOM 也可能出现在第一个 ID 前面。
问题不在 SQL 查询，而在“文件里的表示”和“数据库里的值”没有正确转换。
修复要还原格式，不能随便清洗
这次将字段处理收敛到共用的 IdCsvFieldSupport，供 ID 标签与分群相关入口复用：
- 找到引号外的第一个逗号，避免把字段内的逗号当分隔符。
- 只剥掉字段首尾成对的双引号。
- 将字段内部连续的两个双引号还原成一个。
- 显式处理首部 BOM。
不能全局删除所有引号，因为引号也可能是用户值的一部分。单边引号也不能凭猜测删除。
用一组输入看清边界
| 文件中的字段 | 期望业务值 | 检查点 |
|---|---|---|
00123 |
00123 |
保留前导零 |
"00123" |
00123 |
外层引号属于 CSV 格式 |
"user,west" |
user,west |
字段里的逗号不是列分隔符 |
"say ""hi""" |
say "hi" |
还原转义引号 |
这些是回看修复时使用的边界示例。当前工具针对单行的一列或两列 ID 数据，不是覆盖多行字段等全部场景的通用 CSV 解析器。
留下的检查点
导入功能应该拿自己导出的文件做一次往返验证，并检查原值是否保持一致。只用手工输入的裸值测试，很容易错过序列化产生的问题。
多入口共享同一种格式时，修复也要共享。标签修好了、分群还在用旧 split，问题只是换个入口再出现。
本次修复见 2026-10-09 的提交 d8f092647。它体现的是输入边界识别和跨入口修复能力。