如何從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-八位字節“有向圖”。