Shiki.js项目中Safari浏览器YAML语法高亮崩溃问题解析
问题背景
在Shiki.js语法高亮库的使用过程中,开发者发现了一个特定于Safari浏览器的问题:当尝试高亮YAML代码时,Safari会抛出"Invalid regular expression: invalid range in character class for Unicode pattern"错误。这个问题在Chromium和Firefox等其他浏览器中并不存在,表现出明显的浏览器兼容性问题。
问题根源分析
经过深入调查,发现问题根源在于WebKit(Safari使用的渲染引擎)的正则表达式解析器中存在一个特定bug。这个bug在同时满足以下条件时触发:
- 正则表达式使用了v标志(Unicode集合模式)
- 正则表达式包含特定结构的字符类:
- 包含任意字符集(如\d或\p{L})
- 紧接着是字面连字符(如-、\x2D或\u002D)
- 后面跟随其他标记
在这种情况下,WebKit错误地将字面连字符解释为范围运算符,导致正则表达式解析失败。例如,正确的正则表达式/[\d-a]/v被WebKit错误地当作/[\d-a]/v处理,从而抛出语法错误。
技术细节
Shiki.js在内部使用oniguruma-to-es库将TextMate语法中的Oniguruma正则表达式转换为JavaScript正则表达式。转换过程中,YAML语法中的某些模式会被转换为包含上述问题结构的正则表达式。例如,原始Oniguruma模式:
(?=(?:[^\s[-?:,\[\]{}#&*!|>'"%@]]|[?:-]\S)([^\s:]|:\S|\s+(?![#\s]))\s:(\s|$))`
会被转换为等效的JavaScript正则表达式:
/(?=(?:[^\p{space}\-\?\:\,\[\]\{\}\#\&\*\!\|\>'"\%\@\]|[?:-]\P{space})([^\p{space}:]|:\P{space}|\p{space}+(?![#\p{space}]))\p{space}:(\p{space}|(?=\n?$)))/dgv`
正是这种转换结果在Safari中触发了WebKit的解析bug。
解决方案
临时解决方案
对于当前版本的Shiki.js,开发者可以通过以下方式临时解决这个问题:
在调用Shiki的createJavaScriptRegexEngine时,将target选项设置为'ES2018'。这会使得Shiki使用带有u标志而非v标志的JavaScript正则表达式,从而避免触发WebKit的bug。
长期解决方案
oniguruma-to-es库在3.1.1版本中已经修复了这个问题。修复方法是将字面连字符移动到字符类的开头或结尾,避免它们紧跟在字符集后面。这个修复将被包含在Shiki.js的下一个主要版本中。
需要注意的是,这个修复仅适用于动态生成的语法高亮场景。对于预编译(precompiled)的语言,由于修复是在运行时环境检测到bug时才应用的,因此开发者仍需使用createJavaScriptRegexEngine而非createJavaScriptRawEngine。
开发者建议
- 对于需要立即修复的项目,采用临时解决方案
- 关注Shiki.js的版本更新,及时升级到包含修复的版本
- 在跨浏览器开发中,特别注意Safari/WebKit特有的兼容性问题
- 对于复杂的正则表达式转换场景,建议进行多浏览器测试
总结
这个案例展示了浏览器引擎实现差异可能导致的兼容性问题,特别是在处理复杂正则表达式时。通过深入分析问题根源,开发者社区能够找到有效的解决方案,同时也提醒我们在前端开发中需要重视跨浏览器测试的重要性。
AutoGLM-Phone-9BAutoGLM-Phone-9B是基于AutoGLM构建的移动智能助手框架,依托多模态感知理解手机屏幕并执行自动化操作。Jinja00
Kimi-K2-ThinkingKimi K2 Thinking 是最新、性能最强的开源思维模型。从 Kimi K2 开始,我们将其打造为能够逐步推理并动态调用工具的思维智能体。通过显著提升多步推理深度,并在 200–300 次连续调用中保持稳定的工具使用能力,它在 Humanity's Last Exam (HLE)、BrowseComp 等基准测试中树立了新的技术标杆。同时,K2 Thinking 是原生 INT4 量化模型,具备 256k 上下文窗口,实现了推理延迟和 GPU 内存占用的无损降低。Python00
GLM-4.6V-FP8GLM-4.6V-FP8是GLM-V系列开源模型,支持128K上下文窗口,融合原生多模态函数调用能力,实现从视觉感知到执行的闭环。具备文档理解、图文生成、前端重构等功能,适用于云集群与本地部署,在同类参数规模中视觉理解性能领先。Jinja00
HunyuanOCRHunyuanOCR 是基于混元原生多模态架构打造的领先端到端 OCR 专家级视觉语言模型。它采用仅 10 亿参数的轻量化设计,在业界多项基准测试中取得了当前最佳性能。该模型不仅精通复杂多语言文档解析,还在文本检测与识别、开放域信息抽取、视频字幕提取及图片翻译等实际应用场景中表现卓越。00
GLM-ASR-Nano-2512GLM-ASR-Nano-2512 是一款稳健的开源语音识别模型,参数规模为 15 亿。该模型专为应对真实场景的复杂性而设计,在保持紧凑体量的同时,多项基准测试表现优于 OpenAI Whisper V3。Python00
GLM-TTSGLM-TTS 是一款基于大语言模型的高质量文本转语音(TTS)合成系统,支持零样本语音克隆和流式推理。该系统采用两阶段架构,结合了用于语音 token 生成的大语言模型(LLM)和用于波形合成的流匹配(Flow Matching)模型。 通过引入多奖励强化学习框架,GLM-TTS 显著提升了合成语音的表现力,相比传统 TTS 系统实现了更自然的情感控制。Python00
Spark-Formalizer-X1-7BSpark-Formalizer 是由科大讯飞团队开发的专用大型语言模型,专注于数学自动形式化任务。该模型擅长将自然语言数学问题转化为精确的 Lean4 形式化语句,在形式化语句生成方面达到了业界领先水平。Python00