node.js Buffer from Uint16Array - node.js

const arr = new Uint16Array(2);
arr[0] = 5000;
arr[1] = 4000;
// Copies the contents of `arr`.
const buf1 = Buffer.from(arr);
// Shares memory with `arr`.
const buf2 = Buffer.from(arr.buffer);
console.log(buf1, buf2 );
// Prints: <Buffer 88 a0>
// Prints: <Buffer 88 13 a0 0f>
i look at the nodejs document where i see that
and my question is why buf1 is not <Buffer 88 13 a0 0f> ?

It is explained here that Buffer.from behaves as new Uint8Array() which can only contain numbers from 0 to 255 (1 byte) and here is stated that each value is converted and the result array length will be the same (so it can't have 4 elements). When converted, 2 byte value will be trimmed to 1 byte value, ignoring the second byte (88 13 -> 88, a0 0f -> a0).

Related

Why is Node.js complaining ERR_OUT_OF_RANGE if the offset is within the file's range?

I'm trying to overwrite some of the contents of a pre-generated 1GB file via a 4 byte buffer at an iterating offset.
Best I can tell, I'm using the correct flag:
const fd = fs.openSync(dataPath, "r+") // also tried "a+"
And the file size looks within range:
let stats = fs.statSync(dataPath)
let fileSizeInBytes = stats["size"]
let fileSizeInMegabytes = fileSizeInBytes / 1000000
console.log("fileSizeInMegabytes", fileSizeInMegabytes) // => fileSizeInMegabytes 1000
But when I try to write the updates:
const bufferSize = 74
let pointer = (timestampSet.size * 4) + 4
for (let j = 0; j < timestampSet.size; j++) {
pointer += mapIterator.next().value * bufferSize
const pointerBuffer = Buffer.alloc(4)
pointerBuffer.writeUInt32BE(pointer, 0) // <Buffer 00 2e 87 e4>
console.log("writing", pointerBuffer, "to file", dataPath, "at offset", j * 4)
// writing <Buffer 00 2e 87 e4> to file E://data.odat at offset 4
fs.writeSync(fd, pointerBuffer, j * 4, 4)
}
fs.close(fd).then(() => {
console.log("write stream closed")
})
iterateProcess()
I get the error:
RangeError [ERR_OUT_OF_RANGE]: The value of "length" is out of range. It must be <= 0. Received 4
Why is this error happening if the file has the correct size and the correct flag is used?
You seem to misinterpret the writeSync arguments. offset refers to the position in the buffer, not in the file. For the address in the file, use position.
The error message comes from the fact that the system cannot find 4 bytes in the buffer starting from the location in the buffer you specified.
Your code should read:
fs.writeSync(fd, pointerBuffer, 0, 4, j*4)
From the docs:
offset determines the part of the buffer to be written, and length is an integer specifying the number of bytes to write.
position refers to the offset from the beginning of the file where this data should be written. If typeof position !== 'number', the data will be written at the current position. [..]

Changing protobuff optional field to oneof

I have the following message:
message Message {
int64 id = 1;
google.protobuf.FloatValue weight = 2;
google.protobuf.FloatValue override_weight = 3;
}
and I wish to change the type of weight and override_weight(optional fields) to google.protobuf.DoubleValue so what I did was the fllowing:
message Message {
int64 id = 1;
oneof weight_oneof {
google.protobuf.FloatValue weight = 2 [deprecated=true];
google.protobuf.DoubleValue double_weight = 4;
}
oneof override_weight_oneof {
google.protobuf.FloatValue override_weight = 3 [deprecated=true];
google.protobuf.DoubleValue double_override_weight = 5;
}
}
My question is, lets assume I have old messages who were compiled by the previous protobuff message compiler for the old message, would I be able to parse them as the new message?
The documentation is very vague about this:
"Move optional fields into or out of a oneof: You may lose some of your information (some fields will be cleared) after the message is serialized and parsed. However, you can safely move a single field into a new oneof and may be able to move multiple fields if it is known that only one is ever set."
Has anyone tried this before? what is the best practice for this situation?
As far as I know fields in an oneof are just serialize using their tag number. The serialized data does not indicate if a field is part of an oneof. This is all handled by the serializer and deserializer. So as long as the tag numbers do not conflict it can be assumed that it will work in both directions, old messages to a new serializer and new messages to an old serializer.
You could test this using an online protobuf deserializer.
Verification:
The code does indeed produce the same byte strings. Below you will find the message definitions and python code I used. The python code will output a byte string you can copy and use in the decoder of Marc Gravell.
syntax = "proto3";
message MessageA {
int64 id = 1;
float weight = 2;
float override_weight = 3;
}
message MessageB {
int64 id = 1;
oneof weight_oneof {
float weight = 2 [deprecated=true];
double double_weight = 4;
}
oneof override_weight_oneof {
float override_weight = 3 [deprecated=true];
double double_override_weight = 5;
}
}
import Example_pb2
# Set some data in the original message
msgA = Example_pb2.MessageA()
msgA.id = 1234
msgA.weight = 3.21
msgA.override_weight = 5.43
# Output the serialized bytes in a pretty format
str = 'msgA = '
for x in msgA.SerializeToString():
str += "{:02x} ".format(x)
print(str)
# Next set the original fields in the new message
msgB = Example_pb2.MessageB()
msgB.id = 1234
msgB.weight = 3.21
msgB.override_weight = 5.43
# Output the serialized bytes in a pretty format
str = 'msgB 1 = '
for x in msgB.SerializeToString():
str += "{:02x} ".format(x)
print(str)
# And finally set the new fields in msgB
msgB.double_weight = 3.21
msgB.double_override_weight = 5.43
# Output the serialized bytes in a pretty format
str = 'msgB 2 = '
for x in msgB.SerializeToString():
str += "{:02x} ".format(x)
print(str)
The output of the python script was:
msgA = 08 d2 09 15 a4 70 4d 40 1d 8f c2 ad 40
msgB 1 = 08 d2 09 15 a4 70 4d 40 1d 8f c2 ad 40
msgB 2 = 08 d2 09 21 ae 47 e1 7a 14 ae 09 40 29 b8 1e 85 eb 51 b8 15 40
As you can see message A and message B yield the same byte string when setting the original fields. Only when you set the new fields you get a different string.

How to convert to ascii using node.js

I am trying to convert length message to ascii.
My length message is like
var ll = "0170";
In node js , is there some kind of function which converts into ascii?
Please help?
Here's a simple function(ES6) which converts a string into ASCII characters using charCodeAt()
const toAscii = (string) => string.split('').map(char=>char.charCodeAt(0)).join(" ")
console.log(toAscii("Hello, World"))
Output:
-> 72 101 108 108 111 44 32 87 111 114 108 100
You could create a prototype function aswell. There are many solutions :)
you can't have an ascii code for a whole string.
An ascii code is an integer value for a character, not a string. Then for your string "0170" you will get 4 ascii codes
you can display these ascii codes like this
var str = "0170";
for (var i = 0, len = str.length; i < len; i++) {
console.log(str[i].charCodeAt());
}
Ouput : 48 49 55 48
use charCodeAt() function to covert asscii format.
var ll = "0170";
function ascii (a) { return a.charCodeAt(); }
console.log(ascii(ll[0]),ascii(ll[1]), ascii(ll[2]), ascii(ll[3]) )
result:
48 49 55 48

how to convert node Buffer to string like console.log show

I want log the buffer to string, but I am not want to use buffer.toString() method
console.log(new Buffer(12))
show
< Buffer 00 22 33 11 55 ...>
but console.log('buffer:' + new Buffer(12))
show
buffer: something can't read
I want
buffer: < Buffer 00 22 33 11 55 ...>
Doing
var b = new Buffer([0x41, 0x42, 0x43, 0x44]);
console.log(b);
// <Buffer 41 42 43 44>
is the same as doing
console.log(b.inspect());
whereas
var b = new Buffer([0x41, 0x42, 0x43, 0x44]);
console.log('str' + b);
// strABCD
is the same as doing
console.log('str' + b.toString());
because using string concatenation using + automatically converts both sides of the operator to strings using .toString(). console.log(...) on the other hand converts its arguments to strings by calling .inspect() when possible.
The easiest way to do what you want to do is to just let console.log do its thing by passing it multiple arguments
console.log('buffer:', new Buffer(12))
Note, the , instead of a +, so instead of concatenating using .toString, you let console.log stringify each of its arguments on its own.

C++ converting hex number to human readable string representation

I have a char[32] that consist of ASCII characters, some of which may be non printable characters, however, they are all in valid range of 0 to 255.
Let's say, it contains these numbers:
{ 9A 2E 5C 66 26 3D 5A 88 76 26 F1 09 B5 32 DE 10 91 3E 68 2F EA 7B C9 52 66 23 9D 77 16 BB C9 42 }
I'd like to print out or store in std::string as "9A2E5C66263D5A887626F109B532DE10913E682FEA7BC95266239D7716BBC942", however, if I print it out using printf or sprintf, it will yield the ASCII representative of each number, and instead it will print out "ö.\f&=Zàv&Ò µ2fië>h/Í{…Rf#ùwª…B", which is the correct ASCII character representation, since: ö = 9a, . = 2e, ...
How do I reliably get the string representation of the hex numbers? ie: I'd expect a char[64] which contains "9A2E5C66263D5A887626F109B532DE10913E682FEA7BC95266239D7716BBC942" instead.
Thanks!
void bytesToHex(char* dest, char* src, int size) {
for (unsigned int i = 0; i < size; i++) {
sprintf(&dest[i * 2], "%02x", src[i]);
}
}
You'd have to allocate your own memory here.
It would be used like this:
char myBuffer[32]
char result[65];
bytesToHex(result, myBuffer, 32);
result[64] = 0;
// print it
printf(result);
// or store it in an std::string
std::string str = string(result);
I tried:
char szStringRep[64];
for ( int i = 0; i < 32; i++ ) {
sprintf( &szStringRep[i*2], "%x", szHash[i] );
}
it works as intended, but if it encountered a < 0x10 number, it will null terminated as it is printing 0
You can encode your string to another system like Base64, which is widely used when using encryption algorithms.

Resources