如何正确实现短语级文本替换而非单词级替换_技术教程

本文介绍一种安全可靠的两阶段替换策略，解决在富文本缩写场景中因正则边界匹配导致的嵌套误替换问题，确保“mobile telephone number”被整体替换为 `m/tel`，而不会错误拆解为 `tel number`。

在构建实时文本缩写功能（如将“Mobile telephone number”自动转为带 tooltip 的 M/TEL）时，一个常见陷阱是：若字典中同时存在 "Telephone" 和 "Mobile telephone number"，直接按顺序执行 \b...\b 全局替换会导致短语被长匹配项“覆盖”前，先被短匹配项错误切割——例如 "mobile telephone number" 中的 "telephone" 被提前替换成 TEL，最终生成 M/TEL number 这类语义断裂的结果。

根本原因在于 JavaScript 的 .replace() 是贪婪、顺序执行的，且 \b（单词边界）无法区分“独立单词”与“短语中的子串”。因此，必须打破“边匹配边插入 HTML”的耦合逻辑，采用两阶段隔离替换法：

第一阶段：占位符预替换
遍历所有词条（按长度降序排序，优先匹配更长的短语），用唯一、无歧义的临时标记（如 __replacement:0）替代原始文本中的匹配项；
第二阶段：HTML 安全注入
将所有占位符批量替换为最终带的富文本内容。

这样既规避了 HTML 标签干扰正则匹配（如避免中的 TEL 被二次匹配），又通过预排序确保“Mobile telephone number”总比“Telephone”优先被捕获。

以下是优化后的完整实现（含关键注释）：

let dictionary = {
  "M": { "Mobile telephone number": "M/TEL" },
  "T": { "Telephone": "TEL" }
};

// 扁平化字典为 [key, value] 数组，并按 key 长度降序排序（关键！）
const replacements = Object.values(dictionary)
  .flatMap(obj => Object.entries(obj))
  .sort((a, b) => b[0].length - a[0].length); // 长字符串优先匹配

function abbreviateText() {
  const input = document.getElementById("input").value;
  let output = input;
  const placeholderMap = []; // 存储 [placeholder, finalHTML] 映射

  // 第一阶段：用唯一占位符替换所有匹配项
  for (const [phrase, abbr] of replacements) {
    const escapedPhrase = phrase.replace(/[.*+?^${}()|[\]\\]/g, '\\$&'); // 转义正则特殊字符
    const regex = new RegExp(`\\b${escapedPhrase}\\b`, 'gi');

    output = output.replace(regex, (match) => {
      const placeholder = `__REPL_${placeholderMap.length}__`;
      placeholderMap.push([placeholder, `${abbr}`]);
      return placeholder;
    });
  }

  // 第二阶段：批量替换占位符为最终 HTML
  for (const [placeholder, html] of placeholderMap) {
    output = output.replace(new RegExp(placeholder, 'g'), html);
  }

  document.getElementById("output").innerHTML = output;
}

✅ 关键要点总结：

必须排序：sort((a, b) => b[0].length - a[0].length) 确保“Mobile telephone number”在“Telephone”之前匹配；
必须转义：phrase.replace(/[.*+?^${}()|[\]\\]/g, '\\$&') 防止用户词典中含正则元字符（如 C++、C#）引发语法错误；
占位符需唯一且不可见：使用 __REPL_0__ 等格式，避免与用户输入内容冲突；
不依赖初始 HTML 状态：该方案天然兼容纯文本输入，无需担心已有标签干扰
匹配。