短信验证码自动填充：Android、iOS与网页格式指南

Your Example code is 123456.

@example.com #123456

网页上的验证码自动填充如何工作？

先添加属性，再为支持的浏览器添加JavaScript。

<input type="text" inputmode="numeric"
       autocomplete="one-time-code" name="otp" />

Chrome的文档推荐使用该属性以实现跨浏览器兼容，并指出Safari虽然没有WebOTP的JavaScript API，但会用它从格式正确的短信中建议验证码。

对于Android上的Chrome，请用sms传输方式调用WebOTP。该API需要安全来源（HTTPS），并且可以用AbortController在用户手动输入验证码时取消待处理的请求。

if ("OTPCredential" in window) {
  const ac = new AbortController();
  const form = document.querySelector("form");
  const input = document.querySelector("input[autocomplete=one-time-code]");

  form.addEventListener("submit", () => ac.abort());

  navigator.credentials
    .get({ otp: { transport: ["sms"] }, signal: ac.signal })
    .then((otp) => {
      input.value = otp.code;
      form.submit();
    })
    .catch(() => {}); // user dismissed, or no matching SMS
}

短信必须遵循WICG规范和Chrome指南中的来源绑定格式：末行之前有一个由四到十位字母数字组成、至少含一个数字的验证码，末行以@开头，后跟主机、一个空格，以及#加验证码。主机中不得含有空白字符。

一条短信能同时适用于Android、iOS和网页吗？

通常可以，因为这些规则相互兼容。把便于阅读的文字放在最前，把Android哈希放在结尾之上的一行，把域名绑定行放在最后。这种排布是根据文档规则推导的，并非厂商保证，所以请测试。

Your Example code is 483921. Do not share it.
Ab3dE+9xYz1
@example.com #483921

为什么是这个顺序：Apple和网页规范都要求域名和验证码在末行。Google要求短信中某处含有11位哈希，但在我们查阅的页面中并未限定其位置。上面的示例以纯拉丁字符计为78字节，远低于140字节的限制。

上线前的检查清单：

1. 验证码是单独一个词元，与文本中的其他数字清晰分开。
2. 末行的域名与网站及应用的关联域名一致。
3. Retriever版本的总长度在140字节以内。
4. 哈希与被测构建的签名密钥一致。
5. 在每个平台的真机上，并通过您实际使用的运营商完成测试。

阿拉伯语和Unicode文本怎么办？

让验证码和两个机器可读的部分保持朴素。Google的限制按字节计算，而Unicode短信单条能容纳的字符远少于GSM-7：单段分别为70个和160个（参见短信字符限制与Unicode）。因此一句阿拉伯语会很快耗尽额度，只要有一个非GSM字符，整条短信就会切换为Unicode。

稳妥的做法：验证码使用拉丁数字，@域名 #验证码使用ASCII，阿拉伯语文字尽量简短。我们没有找到描述其他数字体系书写的验证码如何自动填充的官方文档，所以不作说明，并建议使用前先测试。

WhatsApp身份验证模板如何处理自动填充？

Meta的身份验证模板有三种按钮样式，每种都带有<code> is your verification code.形式的固定正文。

Meta的文档还指出，在iOS 26及更高版本上，键盘建议无需任何集成即可提供自动填充，而在不支持零点击的平台上，用户会收到复制验证码按钮。您可以用code_expiration_minutes设置有效期，预览API接受1至90分钟的值。两种渠道的对比见WhatsApp验证码与短信验证码。

实例：网约车应用登录

“Qafila Rides”（虚构）有Android应用、iOS应用和位于qafila.example的移动网站。

1. 用户点击“发送验证码”时，Android应用启动SMS Retriever。
2. 后端生成一个有效期为几分钟的六位验证码，并通过短信API发送上面的三行短信。
3. Android把短信交给应用。iOS在键盘上方提供验证码。在移动网站上，Safari给出建议，Chrome通过WebOTP填入。
4. 服务器只校验该验证码一次，拒绝重复使用和已过期的验证码，并限制请求频率。
5. 如果短信在较短的超时时间内未得到确认，后端会提供WhatsApp身份验证模板作为第二条路径。

常见错误有哪些？

• 验证码不单独出现。 验证码旁边多出其他数字（电话、价格、日期）会干扰识别。每条短信只放一个验证码。
• 哈希错误。 哈希随签名证书而变。调试密钥生成的哈希与生产构建不匹配。
• 域名不一致。 @example.com必须与网站或关联域名一致，否则iOS和WebOTP不会提供验证码。
• 末行被破坏。 #验证码之后有任何内容、缺少空格，或域名中含有空白，都会破坏格式。
• 短信过长或Unicode过多， 超出140字节的Retriever限制。
• 监听过晚。 User Consent API会忽略在启动之前收到的短信。
• 把自动填充当作安全措施。 自动填充只是便利。仍须在服务器端校验、让验证码过期并限制尝试次数，同时留意短信泵送欺诈。
• 适用范围。 本指南涵盖撰写时文档所述的行为。平台规则会变化，发布前请查阅所附来源。

关于短信措辞和有效期的选择，请参阅我们的验证码与身份验证消息指南。

OmniChannels.ai如何提供帮助

OmniChannels.ai通过BroadNet的运营商直连发送短信和WhatsApp验证码，让您能够掌控自动填充格式所依赖的确切短信文本。WhatsApp模板涵盖复制验证码、一键和零点击身份验证。渠道回退（例如先WhatsApp后短信）可按使用场景配置，送达状态以统一的Webhook格式送达。请参阅短信API文档、WhatsApp API文档和验证码解决方案。