Google 表单多选答案含逗号：找回准确的已选项目

修改表格前，先核对一份原始提交

以编辑者身份打开原始表单，进入 Responses → Individual，逐份查看提交内容。选一份已选标签中含有逗号的回复，记下完整选项。如果你的表单存在 Email 与 Email newsletter 这类文字重叠的标签，也找一份相关回复。这样，你就有了可与待生成表格对照的原始依据。测试时使用副本，保留现有导出文件。

确认实际题型。本文讨论普通复选框题，即针对同一问题可以选择多个选项。复选框网格带有行结构，数组形状也不同。同时明确你需要的是各选项的次数、包含某选项的提交列表，还是可视化汇总。如果 Forms 已有的汇总就能回答问题，导出可能只是增加工作。

编写自定义导出前，先试表单原生 CSV

在表单本身依次选择 Responses → More → Download responses (.csv)。这与把关联的 Google 表格下载为 CSV 是两条不同路径。Displayr 于 2026 年 2 月更新的集成文档将原生下载中的多选值描述为以分号分隔；Stack Overflow 上已有回答也报告了这一差别。因此，标签中出现逗号，并不自动意味着原生文件无法使用。

先用能够正确解析 CSV 的读取器处理外层文件，再检查那份已知提交对应的多选字段。CSV 字段外面的引号保护的是整个字段；仅凭这层引号，不能确定字段内部多个选项的编码方式。请确认实际文件的内部分隔符和转义规则。在采用拆分规则前，测试含该分隔符的标签，以及自由填写的 Other 答案。如果拆出的完整选项与原始回复一致，就采用这条更简单的路径。不要仅因关联表格看起来难处理，就用脚本替换已经正确的导出。如果任意填写的 Other 文本可能含有该分隔符，而你又无法确认可靠的转义规则，应使用原始数组。

理解拆分和文字搜索为什么可能给出不同错误

假设允许的四个标签是 ["A", "A, B", "B, C", "C"]。选择 ["A, B", "C"] 与选择 ["A", "B, C"]，在用逗号加空格连接后，都会变成 A, B, C。即使知道完整选项列表，也无法在这两个结果之间作出判断。这是一个人工构造的数据表示示例，并不表示 Google 的每种导出格式都存在同样问题。

文字搜索会造成另一类错误。如果实际选择是 ["Email newsletter", "Food, drinks"]，在连接后的字符串中搜索 Email，就会把未选择的选项也计入。若先按逗号加空格拆分，再按完整值匹配，又会丢掉 Food, drinks。我们在本地实际运行了这两个反例。实际处理时，应先确定选项边界，再计数；在子串匹配与拆分之间切换，本身不能证明边界正确。

从原始表单重新取得已选值数组

Google 的 Apps Script 参考文档规定，普通 CheckboxItem 的回复是包含已选项的 String[]。Stack Overflow 上已有完整示例：读取 getResponses()，遍历每份回复的 getItemResponses()，筛选 CHECKBOX 题，再调用 getResponse()。使用 Apps Script 时，从表单的 More → Apps Script 菜单进入，让脚本绑定到该表单；运行需要编辑权限。文末列出了这份完整示例，Google 也提供了对应 API 方法文档。

在该复选框循环中，保留 itemResponse.getResponse() 返回的数组。把 values 当作数组处理前，先用 Array.isArray(values) 检查；如果需要一种能够保留各字符串边界的文本表示，就用 JSON.stringify(values)。先把数组拼成普通文字、稍后再尝试拆开，会破坏这一目的。将回复 ID 和题目 ID 与值一起保存；题目标题只是标签，题目位置也是另一项属性。Google 还说明复选框数组的顺序可能变化，因此不能把它理解为用户点击选项的先后顺序。

需要结构化分页数据时，使用官方回复 API

Forms REST API 提供另一条有文档依据的路径，无须自定义字段内部的分隔符。在官方 forms.responses.list 参考页面打开 Try it，使用有权读取该表单回复的账户，填写表单编辑网址中的表单 ID。保存返回的 JSON 回复数据，不要把 OAuth 令牌或请求头当成回复内容复制。另一个 forms.get 方法可以取得表单定义，帮助你找到复选框题的 questionId。

对于该题，每个已选值在 textAnswers.answers 中都是一个单独条目。将 responseId、questionId 对应关系和表单 ID 与保存的各页数据放在一起；list 方法不会在每个返回的回复对象中重复提供 formId。这些 REST 题目 ID 属于该 API 的数据模型，不能拿另一份 Apps Script 导出中的题目 ID 来替代。

第一次请求成功，并不能证明已经导出完整。只要存在 nextPageToken，就使用该令牌、同一个表单和相同筛选条件请求下一页，直到返回内容不再包含该令牌。pageSize 指定的是上限，服务可能返回更少的回复。保留每一页，并检查不同的回复 ID，再将这批数据认定为完整。本文没有声称实际导出了登录账户中的数据，也没有声称这些请求构成在同一时刻冻结的事务快照。

按完整值判断是否选中，并单独处理缺失答案

普通复选框答案已经是数组时，values.includes("Food, drinks") 判断的是是否选中了这个完整标签，不会匹配另一标签中的一部分。在 REST 表示中，先对所选题目答案的 textAnswers.answers 使用 .map(x => x.value) 取得字符串，再作同样的完整值判断。针对一个标签，每次提交最多计一次；不要把一份多选回复变成几个不同的人。

没有答案的情况需要单独处理。Apps Script 会从 getItemResponses() 中省略这类未回答题目，因此按数组位置匹配，可能把后面的答案接到错误的问题上。应按元素或题目 ID 匹配。将缺失的复选框答案与明确选择区分开，并有意识地确定百分比的分母：答案缺失本身无法说明该题是被跳过、被分支绕过，还是后来才添加。这些导出也不会恢复已删除的历史题目定义。

核对实际选择，不能只看总行数

将原始提交中的完整标签，与重新取得的数组或解析后的原生 CSV 字段逐一对照。检查含标点的标签、文字被较长标签包含的短标签、表单允许时的自由文本值，以及一道未回答的选填题。随后通过完整值判断，核实一个已选标签和一个未选标签的计数。总行数正确，仍可能伴随行内选择内容错误。

我们实际运行的十项 Node 24.22.1 本地断言覆盖了分隔符碰撞、两种计数错误、UTF-8 JSON 往返、独立题目 ID、缺失题目和安全的文本处理。测试使用符合 Forms 文档对象形状的本地样例，没有实际运行 Google Forms、Apps Script 授权、在线 CSV 导出或登录账户中的 API Explorer。对于仍在接收回复的表单，应记录导出时间或选定的回复范围，并在比较总数前考虑新提交的影响。

只剩有歧义的单元格时，保留这种不确定性

原始表单回复已经不可用时，已知的选项列表有时能确定唯一解释，但不能保证如此：A, B, C 示例就有两种合法选择。Other 自由文本会使“某个分隔符不会出现在值中”这一假设尤其脆弱。将尚未确定的单元格标为待复核，并请所有者提供原始回复，或另一份能够验证边界的导出。

信息被压平成字符串后，再把逗号改为分号，并不能恢复已丢失的信息；给整个单元格加引号也一样。保留源文件，以及经认可的转换所依赖的假设。在用结果分配工作或报告次数之前，应取得可追溯的准确已选值集合，或者明确标出仍未解决的记录。