本教程详细阐述如何利用javascript正则表达式，将遵循whatsapp风格的特殊符号（如`*`、`_`、`~`）标记的文本转换为对应的html标签（``、``、``）。文章深入探讨了如何通过负向先行断言和负向后行断言处理复杂的格式化条件，包括前置字符限制和内容起始空格限制，并提供实用的代码示例及潜在局限性分析。
在现代即时通讯应用中，用户通常通过简单的符号（如星号、下划线、波浪线）来对文本进行加粗、斜体或删除线等格式化操作。这些应用在解析这些符号时，往往会遵循一套特定的规则，例如限制前置字符、禁止内容以空格开头，甚至对符号的重复使用有严格要求。本教程旨在介绍如何使用JavaScript和正则表达式来模拟这种“类WhatsApp”的文本格式化规则，并将其转换为标准的HTML标签。
理解类WhatsApp文本格式化规则
在实现转换之前，我们需要明确这些规则的特点：
-
基本语法：
- 加粗：*文本* 转换为 文本
- 斜体：_文本_ 转换为 文本
- 删除线：~文本~ 转换为
文本 - 组合格式：~_*文本*_~ 转换为
文本
前置字符限制： 某些字符紧跟在格式化符号之前时，可能会阻止格式化生效。例如，在WhatsApp中，,*文本* 可以格式化为 ,文本，但 @*文本* 则不会被格式化。这意味着我们需要识别并排除某些特定的前置字符。
内容起始空格限制： 格式化符号后紧跟空格的文本通常不会被格式化。例如，* 文本* 不会被加粗。
-
符号重复限制： 连续使用多个相同的格式化符号可能会导致不同的行为：
- **文本**：有时会被解析为 *文本*（即只处理最外层的一对符号，内部的符号保留）。
- ***文本**：在某些严格的规则下，如果起始符号数量超过一个（例如三个星号），则整个文本块可能完全不被格式化。
使用正则表达式实现格式转换
核心思路是利用正则表达式捕获符合特定模式的文本，然后使用替换功能将其包裹在相应的HTML标签中。为了处理上述复杂规则，我们将引入“先行断言”（Lookahead Assertion）和“后行断言”（Lookbehind Assertion）。
立即学习“前端免费学习笔记（深入）”；
初始正则表达式尝试及局限性
一个基本的正则表达式可能如下所示：
text
.replace(/(?:\*)(?:(?!\s))((?:(?!\*|\n).)+)(?:\*)/g, '$1')
.replace(/(?:_)(?:(?!\s))((?:(?!\n|_).)+)(?:_)/g, '$1')
.replace(/(?:~)(?:(?!\s))((?:(?!\n|~).)+)(?:~)/g, '$1');这段代码通过 (?!\s) 确保格式化符号后不紧跟空格，并使用 ((?:(?!\*|\n).)+) 捕获内容，直到遇到下一个符号或换行符。然而，它并未解决前置字符限制和复杂的符号重复限制。
引入负向后行断言处理前置字符限制
为了处理前置字符限制，我们可以使用负向后行断言（Negative Lookbehind Assertion），即 (?
以下是针对加粗、斜体和删除线的增强型正则表达式：
// 加粗：匹配 *文本*，但前面不能是 {、[、?、}、] 且 * 后不能是空格
string = string.replace(/(?$1');
// 斜体：匹配 _文本_，但前面不能是 {、[、?、}、] 且 _ 后不能是空格
string = string.replace(/(?$1');
// 删除线：匹配 ~文本~，但前面不能是 {、[、?、}、] 且 ~ 后不能是空格
string = string.replace(/(?$1');正则表达式解析：
- (?
- \* 或 _ 或 ~：匹配字面意义上的格式化符号。
- (?!\s)：这是一个负向先行断言。它确保格式化符号后面不能紧跟一个空格。这解决了内容起始空格的限制。
- (.+?)：这是一个非贪婪匹配模式，捕获两个格式化符号之间的所有字符。$1 在替换时引用这里捕获的内容。
- \* 或 _ 或 ~：匹配结束的格式化符号。
完整代码示例
function formatWhatsAppTextToHtml(text) {
let formattedText = text;
// 1. 处理加粗
// 匹配 *文本*，但前面不能是 {、[、?、}、] 且 * 后不能是空格
// 注意：此规则会处理 `**bold**` 为 `*bold*`
formattedText = formattedText.replace(/(?$1');
// 2. 处理斜体
// 匹配 _文本_，但前面不能是 {、[、?、}、] 且 _ 后不能是空格
formattedText = formattedText.replace(/(?$1');
// 3. 处理删除线
// 匹配 ~文本~，但前面不能是 {、[、?、}、] 且 ~ 后不能是空格
formattedText = formattedText.replace(/(?$1');
return formattedText;
}
// 示例测试
const inputString = `
这些应该成功格式化:
*this text is bold*,
_this text is italic_,
~this text is strikethrough~.
~_*this text is bold, italic and strike-through*_~
,*this text is bold* (逗号前置)
这些应该不被格式化 (或部分格式化):
_ example_ (内容以空格开头)
{*example*} (前置字符 { )
@*example* (前置字符 @ - 注意：当前lookbehind未涵盖此情况)
**this text is bold** (多余的星号)
***this text is not bold** (多余的星号，应完全不格式化 - 注意：当前regex未完全实现此严格规则)
`;
console.log("--- 原始文本 ---");
console.log(inputString);
console.log("\n--- 格式化结果 ---");
console.log(formatWhatsAppTextToHtml(inputString));
/* 预期输出示例 (基于当前正则表达式):
--- 原始文本 ---
... (同inputString)
--- 格式化结果 ---
这些应该成功格式化:
this text is bold,
this text is italic,
this text is strikethrough.
this text is bold, italic and strike-through
,this text is bold (逗号前置)
这些应该不被格式化 (或部分格式化):
_ example_ (内容以空格开头)
{*example*} (前置字符 { )
@*example* (前置字符 @ - 注意：当前lookbehind未涵盖此情况)
*this text is bold* (多余的星号)
**this text is not bold (多余的星号，应完全不格式化 - 注意：当前regex未完全实现此严格规则)
*/注意事项与局限性
尽管上述正则表达式解决了许多复杂场景，但仍存在一些局限性，特别是在严格模拟所有WhatsApp规则时：
不完整的前置字符列表： 当前 (?
-
符号重复限制的复杂性：
- 对于 **this text is bold**，当前正则表达式会将其转换为 *this text is bold*。这符合某些Markdown方言的行为，但如果预期是 this text is bold 或者完全不格式化，则需要更复杂的逻辑。
- 对于 ***this text is not bold**，根据问题描述，这应该完全不被格式化。然而，当前的正则表达式会将其处理为 **this text is not bold。要实现“如果起始符号数量超过一个，则不格式化”的规则，仅靠简单的替换可能不够。这可能需要更精细的正则表达式（例如，检查开头是否有多个相同符号且没有匹配的结束符号）或者一个分词器（lexer）来处理。
嵌套格式化： 对于 *bold _italic_* 这样的嵌套结构，简单的顺序替换可能会产生预期之外的结果。例如，先处理加粗，内部的 _italic_ 可能仍然保留，或者如果先处理斜体，外部的 *bold ...* 可能无法正确匹配。通常，处理嵌套结构需要更复杂的解析器或递归处理。
性能考量： 对于非常大的文本块，连续应用多个正则表达式替换可能会影响性能。
总结
通过巧妙运用正则表达式的先行断言和后行断言，我们可以有效地将带有特定规则的符号化文本转换为HTML格式。这在构建文本编辑器、聊天应用解析器或内容管理系统时非常有用。然而，对于高度复杂的、包含多层嵌套或严格上下文依赖的格式化规则，可能需要超越简单的正则表达式，考虑构建一个更健壮的词法分析器或解析器来确保准确性和灵活性。在实际应用中，应根据具体需求和规则的复杂程度选择最合适的实现方案。
