时间戳

首页 > 解决方案 > 将源映射用于非 JS 语言时，源映射行/列定义中的任何细微之处

unicode - 将源映射用于非 JS 语言时，源映射行/列定义中的任何细微之处

问题描述

我正在获取一个代码生成器来生成源映射，该映射基于 Unicode 代码点跟踪行/列，其中行被（LF、CR、CRLF）分隔。我担心嵌入在注释和补充字符中的其他换行符可能会导致源映射消费者不同意源文本的哪一部分是（行、列）对引用。

具体来说，我对source-map v3规范使用的术语感到困惑，例如

原始源中从零开始的起始行

表示的源中行的从零开始的列

我想这些数字被程序员工具用来导航到/突出显示原始源代码中的代码块。

由于不同的换行定义导致的问题

因此，如果 source-map 生成器将 U+0085（例如）视为换行符而 source-map 使用者不这样做，他们可能会不同意 (source-line, source-column) 对指向的位置吗？

由于列定义不同而导致的问题。

旧版本的 JavaScript将源文本定义为 UTF-16 代码单元，这表明列数是自最后一个换行符结束以来的 UTF-16 代码单元数。

ECMAScript 源文本使用 UTF-16 转换格式以 Unicode 字符编码 2.1 或更高版本表示为字符序列。

但是当前的规范没有用 UTF-16 来描述源文本：

SourceCharacter ::
    任何 Unicode 代码点

如果源映射消费者将补充字符不同地视为占用一个代码点列或两个 UTF-16 列，是否可能会丢弃列计数？

例如，由于 '' 是 U+1d12C，一个使用两个 UTF-16 代码单元编码的补充代码点，因此列计数可能与类似的行不一致

let  = "" /*  */ + ""

是第+20 列（由代码点零索引）还是第 23 列（由 UTF-16 代码单元零索引）的符号？

我是否遗漏了规范中的某些内容来澄清这一点，或者是否存在大多数源地图生产者/消费者使用的事实上的规则？

如果这些是问题，在跟踪翻译为 JS 的源语言的行/列计数时是否有已知的解决方法或最佳实践？

我可能不得不对 Mozilla 的 source-map.js 或 Chrome 的开发控制台之类的实现进行逆向工程，但我想我会尝试找到规范参考，这样我就知道要针对谁提交错误以及谁是正确的。

标签： unicodeline-breaksutf-16source-maps

解决方案

推荐阅读