如何从JavaScript中的字符串中获取ASCII代码？

Question

（在StackOverflow上已经提到了类似的问题，但不是这个。最近的可能是“ javascript如何将unicode字符串转换为ascii ”，其中已经有“这必须是一个dup [licate]”这句话。我我已经阅读了一些类似的帖子，但是他们没有回答我的具体问题。我看过非常好的W3Schools网站，并且也用Google搜索过 ，但也没有找到答案。所以这里的任何提示都会非常多赞赏。）

---

我有一个字节数组传递给一段JavaScript。 在JavaScript中，数据以字符串形式到达。 我不知道传输机制，因为它来自第三方应用程序。 我甚至不知道字符串是“宽”还是“窄”。

在我的JavaScript中，我有一些代码，如b = str.charCodeAt(pos); 。

我的问题是像字符0x2020 = 8224这样的字节值如0x86 = 134。这似乎是因为我的原始字节被解释为Latin-1（可能）'匕首'字符，然后被转换为等效的Unicode代码点。 （问题可能是也可能不是JavaScript的'错误'。）其他值也会出现类似的问题，尽管范围0x00..0x7F和0xA0..0xFF看起来很好，但大多数值来自0x80..0x9F受到影响，每种情况下，该值似乎是原始Latin-1的Unicode。

另一个观察结果是，如果以字节为单位测量长度，则字符串的长度是我对窄字符串的期望。 （另一方面，如果length返回抽象字符中的值，这不会告诉我任何事情。）

那么，在JavaScript中，有没有办法获取字符串中的“原始”字节，或者直接获取Latin-1或ASCII字符代码，或者在字符编码之间进行转换，或者定义默认编码？

我可以编写自己的映射，但我不想。 我希望这就是我最终会做的事情，但这种感觉会让人觉得自己已经陷入困境了。

我也在研究是否可以在调用应用程序中调整任何内容（因为它可能将数据作为一个宽字符串传递，尽管我对此表示怀疑）。

无论哪种方式，我都会对是否有简单的JavaScript解决方案感兴趣，或者了解为什么没有。

（如果传入的数据是字符数据，那么自动处理Unicode将是很好的。但事实并非如此，它只是一个二进制数据流。）

谢谢。

Answer 1

字符串中没有原始字节。 EcmaScript规范将字符串定义为UTF-16代码单元序列。 这是任何口译员遇到的最细粒度的表示。

在浏览器上没有编码库。 如果您尝试将字节数组表示为字符串并想要重新编码，则必须自行滚动。

如果您的字符串已经恰好是有效的ASCII，那么您可以使用charCodeAt方法获取代码单元的数值。

"\n".charCodeAt(0) === 10

Answer 2

从Javascript（Ecmascript）规范开始： http ： //www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf 。 说：

8.4字符串类型字符串类型是零个或多个16位无符号整数值（“元素”）的所有有限有序序列的集合。 String类型通常用于表示正在运行的ECMAScript程序中的文本数据，在这种情况下，String中的每个元素都被视为代码单元值（参见条款6）。 每个元素被视为占据序列内的位置。 这些位置用非负整数索引。 第一个元素（如果有）位于位置0，下一个元素（如果有）位于位置1，依此类推。 String的长度是其中的元素数（即16位值）。 空String的长度为零，因此不包含任何元素。

当String包含实际文本数据时，每个元素都被视为单个UTF-16代码单元。 无论这是否是String的实际存储格式，String中的字符都按其初始代码单元元素位置编号，就像它们使用UTF-16表示一样。 对字符串的所有操作（除非另有说明）将它们视为未分化的16位无符号整数的序列; 它们不能确保生成的String是标准化形式，也不能确保语言敏感的结果。

注意此设计背后的基本原理是使Strings的实现尽可能简单和高性能。 目的是在运行程序看到之前，从外部进入执行环境的文本数据（例如，用户输入，从文件读取或通过网络接收的文本等）被转换为Unicode标准化形式C. 通常，这会在传入文本从其原始字符编码转换为Unicode的同时发生（并且不会产生额外的开销）。 由于建议ECMAScript源代码采用规范化格式C，因此保证字符串文字规范化（如果源文本保证规范化），只要它们不包含任何Unicode转义序列即可。

charCodeAt( p )给出的是字符串中索引为p的字符的UTF-16值（16位数）。 由于UTF-16直接表示Unicode的基本多语言平面（即代码点U+0000 - U+D7FF和U+E000 - U+FFFF ，因此您的Latin-1字符应该是您期望的值。

事实上，他们并没有向我建议您对入站第3个八位字节流有编码问题 - 如果转换为UTF-16并且输入入站八位字节流的编码错误，您将得到奇怪的结果。

也许它被视为vanilla ASCII，实际上它是UTF-8（反之亦然）。 UTF-8表示高于0x7F的代码点为2-，3-或4-八位字节“有向图”。