Yes I know the question is 4 years old but I needed this answer for myself.In general, a string represents a sequence of characters in a programming language. Javascript has the option of internally using either UTF-16 or UCS-2 but since it has methods that act like it is UTF-16 I don't see why any browser would use UCS-2. What kind of byte array you want depends on what character encoding you want those bytes to represent. Note that this answer is non-trivial because character encoding is non-trivial. Because charCodeAt returns 2 bytes which is more possible characters than US-ASCII can represent, the function stringToAsciiByteArray will throw in such cases instead of splitting the character in half and taking either or both bytes.
However for UTF-32 is needed which is part of the ECMAScript 6 (Harmony) proposal. returns a maximum number of 2 bytes and matches UTF-16 exactly. US-ASCII on the other hand is fixed width 8-bits which means it can be directly translated to bytes.
#CONVERT STRING TO ARRAY JAVASCRIPT CODE#
But the same code for UTF-16 has only 1 leading 0. If a UTF-32 character has a code point of 65 then that means there are 3 leading 0s. UTF-8, UTF-16, and UTF-32 have a minimum number of bits as their name indicates. UTF-8 is variable length and isn't included because I would have to write the encoding myself. bytes.push(0, 0, 254, 255) //Big Endian Byte Order Marksįor (var i = 0 i 4 bytes is impossible since codePointAt can only return 4 bytesīytes.push((charPoint & 0xFF000000) > 24) īytes.push((charPoint & 0xFF0000) > 16) currently the function returns without BOM. You can split it into distinct bytes using the following: function strToUtf16Bytes(str) bytes of UTF-32 Big Endian without BOM*/ JavaScript's charCodeAt() returns a 16-bit code unit (aka a 2-byte integer between 5). JavaScript encodes strings as UTF-16, just like C#'s UnicodeEncoding, so creating a byte array is relatively straightforward. So if you want reliable solutions, you should have a look at: It might depend on the used JavaScript versions and engines. I'm not sure but when using charCodeAt it seems we get exactly the surrogate codepoints also used in UTF-16, so non-BPM characters are handled correctly. 254 255 0 72 0 101 0 108 0 108 0 32 0 246 0 32 32 172 0 32 3 169 0 32 216 52 221 30Īdded a special character (U+1D11E) MUSICAL SYMBOL G CLEF (outside BPM, so taking not only 2 bytes in UTF-16, but 4.Ĭurrent JavaScript versions use "UCS-2" internally, so this symbol takes the space of 2 normal characters. surrogate codepoints are: d834, dd1e, so one could also write "\ud834\udd1e" S += new String(Character.toChars(0x1D11E)) we take the violin-symbol (U+1D11E) MUSICAL SYMBOL G CLEF now add a character outside the BMP (Basic Multilingual Plane) I don't know if C# places BOM (Byte Order Marks), but if using UTF-16, Java String.getBytes adds following bytes: 254 255. My example contains a few special characters: var str = "Hell ö € Ω 𝄞" If you have non-ASCII characters, it's not enough to add an additional 0. I suppose C# and Java produce equal byte arrays.
0 kommentar(er)
