How can I get the right string when capturing http post response in Electron? - node.js

I was using webContents.debugger to capture http post response according to the offical mannual, but it seems that the JSON string in the response was decoded a wrong charset.
The response header did not give the exactly charset, so I guess chrome-devtools decoded it in a wrong charset (maybe iso-8859-1).
I tried this to convert the string:
let content = new Buffer(e.Content, "binary").toString();
Sometimes it really works! But it fails to deal with some Chinese characters such as "啊" cause the buffer was not correct in the utf8 form.
"你好" => E4 BD A0 E5 A5 BD, √
"啊" => e5 22 60, × //correct code is E5 95 8A

Try to use https://www.npmjs.com/package/encoding to convert encoding to utf-8

Related

TELEGRAF TAIL : Creating parser: Invalid data format: Grok

I am using Telegraf to get logs information from specific logs with Hexa data.
I am using tail but i still to get the same error : Invalid data format: Grok.
My log look like this :
18/08/2022 21:04:23 01 41 7B 00 04 14 00 00 00 FD AB
and a configuration for tail in telegraf :
[[inputs.tail]]
files = ["/mnt/cle/*a.*.log"]
from_beginning = true
max_undelivered_lines = 300
character_encoding = "utf-8"
data_format = "Grok"
grok_patterns = ['%{DATE_EU:date} %{TIME:time} %{WORD:my1id} %{WORD:my2id} %{BASE16NUM:01hexa} %{BASE16NUM:02hexa} %{BASE16NUM:03hexa} %{BASE16NUM:04hexa} %{BASE16NUM:05hexa} %{BASE16NUM:06hexa} %{BASE16NUM:07hexa} %{BASE16NUM:08hexa} %{BASE16NUM:09hexa} %{BASE16NUM:10hexa} %{BASE16NUM:11hexa}']
I try also for grok_patterns :
grok_patterns = ['%{TIMESTAMP_ISO8601:timestamp:ts-"2006/01/02 15:04:05"} %{WORD:MRIid} %{WORD:OPUid} %{WORD:01hexa} %{WORD:02hexa} %{WORD:03hexa} %{WORD:04hexa} %{WORD:05hexa} %{WORD:06hexa} %{WORD:07hexa} %{WORD:08hexa} %{WORD:09hexa} %{WORD:10hexa} %{WORD:11hexa}']
Also, i would like to convert my hexa data to decimal and apply a conversion formula.
And to complicate things, i vould like to join two pattern before converting data.
I have used this link for the grok_patterns : Grok input data format
I found a solution and below my correction :
grok_patterns = ['%{TIMESTAMP_ISO8601:timestamp:ts-"2006-01-02 15:04:05"} %{WORD:MATid} %{WORD:OPUid}']
grok_custom_patterns = '''
'''
With this log :
2022-08-19 17:21:18 MAT01 OPU30
2022-08-19 17:21:19 MAT01 OPU30
However, I'm still looking to convert my hexa data to decimal and apply a conversion formula. And to complicate things, i vould like to join two pattern before converting data.

Line endings in child_process.exec() stdout

I'm building my custom wrapper around wmic using node.js and I have problems parsing it's output. Not a problem, but I just don't know why this happens.
I thought line endings are either \r or \r\n and decided to look on it
Here's a demo piece of code:
exec('wmic process', {maxBuffer :1000*1024}, function (err, stdout, stderr){
let location =stdout.indexOf('\n')-6;
let region =stdout.substr(location, 10);
console.log(region);
let buf = new Buffer(stdout);
let buf2 = new Buffer(30);
buf.copy(buf2, 0, location, location+30);
console.log(buf2);
});
I looked at region and saw this:
For some reason there are two \rs instead of one!
Output of console.log(buf2) also shows this:
<Buffer 6f 75 6e 74 20 20 0d 0d 0a 53 79 73 ...
^^ ^^ ^^
I was ready to split lines by \r\r\n when I decided to pipe its output to text file and look through a hex editor:
wmic process > wmic.txt
What? Where are two \rs?
I have two questions:
Where does Node get second \r from? I tried to find some info, but Google is kind of heavy on queries such as \r\r\n, this is the closest I could get, I'm not sure if it's related
Why hex editor shows 16bit encoding and Node doesn't? I suppose I should've specified encoding in exec() options but I don't know which one. chcp shows 437th codepage, but I kind of want it to work in other codepages as well.

can anyone tell me what the encoding of this string is? Its meant to be base64

cpxSR2bnPUihaNxIFFA8Sc+8gUnWuJxJi8ywSW5ju0npWrFJHW2MSZAeMklcZ71IjrBySF2ci0gdecRI0vD/SM4ZF0m1ZSJJBY8bSZJl/0intaxIlQJBSPdY3EdBLM9Hp4wLSOK8Nki8L1pIoglxSAvNbkjHg0VIDlv7R6B2Y0elCqVGFWuVRgagAkdxHTdHELxRR9i2VkdyEUlHU84kRzTS2kalKFxG
This is a string from an XML file from my mass spectrometer. I am trying to write a program to load two such files, subtract one set of values from another, and write the results to a new file. According to the specification file for the .mzML format, the encoding of the numerical data is alleged to be base64. I can't convert this data string to anything legible using any of the many online base64 converter or using NotepaD++ and the MIME toolkit's base64 converter.
The string, in the context of the results file, looks like this:
<binaryDataArray encodedLength="224">
<cvParam cvRef="MS" accession="MS:1000515" name="intensity array" unitAccession="MS:1000131" unitName="number of counts" unitCvRef="MS"/>
<cvParam cvRef="MS" accession="MS:1000521" name="32-bit float" />
<cvParam cvRef="MS" accession="MS:1000576" name="no compression" />
<binary>cpxSR2bnPUihaNxIFFA8Sc+8gUnWuJxJi8ywSW5ju0npWrFJHW2MSZAeMklcZ71IjrBySF2ci0gdecRI0vD/SM4ZF0m1ZSJJBY8bSZJl/0intaxIlQJBSPdY3EdBLM9Hp4wLSOK8Nki8L1pIoglxSAvNbkjHg0VIDlv7R6B2Y0elCqVGFWuVRgagAkdxHTdHELxRR9i2VkdyEUlHU84kRzTS2kalKFxG</binary>
I can't proceed until I can work out what format this encoding is meant to be!
Thanks in advance for any replies.
You can use this trivial program to convert it to plaintext:
#include <stdio.h>
int main(void)
{
float f;
while (fread(&f, 1, 4, stdin) == 4)
printf("%f\n", f);
}
I compiled this to "floatdecode" and used this command:
echo "cpxSR2bnPUihaNxIFFA8Sc+8gUnWuJxJi8ywSW5ju0npWrFJHW2MSZAeMklcZ71IjrBySF2ci0gdecRI0vD/SM4ZF0m1ZSJJBY8bSZJl/0intaxIlQJBSPdY3EdBLM9Hp4wLSOK8Nki8L1pIoglxSAvNbkjHg0VIDlv7R6B2Y0elCqVGFWuVRgagAkdxHTdHELxRR9i2VkdyEUlHU84kRzTS2kalKFxG" | base64 -d | ./floatdecode
Output is:
53916.445312
194461.593750
451397.031250
771329.250000
1062809.875000
1283866.750000
1448337.375000
1535085.750000
1452893.125000
1150371.625000
729577.000000
387898.875000
248514.218750
285922.906250
402376.906250
524166.562500
618908.875000
665179.312500
637168.312500
523052.562500
353709.218750
197642.328125
112817.929688
106072.507812
142898.609375
187123.531250
223422.937500
246822.531250
244532.171875
202255.109375
128694.109375
58230.625000
21125.322266
19125.541016
33440.023438
46877.441406
53692.062500
54966.843750
51473.445312
42190.324219
28009.101562
14090.161133
Yet another Java Base64 decode with options to uncompress should you need it.
Vendor spec indicated "32-bit float" = IEEE-754 and specified little-endian.
Schmidt's converter shows the bit pattern for IEEE-754.
One more Notepad++ step to look at the hex codes:
Notepad++ TextFX plugin (after the Base64 decode you already did)
select the text
TextFX > TextFX Convert > Convert text to Hex-32
lets you look at the hex codes:
"000000000 72 9C 52 47 66 E7 3D 48- ... 6E 63 BB 49 |rœRGfç=H¡hÜHP
Little-endian: 47529C72 converts (via Schmidt) as shown above by David.
You can access such data from mzML files in Python through pymzML, a python interface to mzML files.
http://pymzml.github.com/

What's the CouchDB attachment's md5 digest format?

I'm trying to use the md5 digest of an attachment I put on the CouchDB, but I can't understand what format it uses.
{
"_id":"ef467479af422db0c388fa00b3000d40",
"_rev":"3-6d1015e7d25103180817136eefa9f942",
"_attachments":{
"foo":{
"content_type":"application/octet-stream",
"revpos":2,
"digest":"md5-yDbs1scfYdqqLpxyFb1gFw==",
"length":1952913,"stub":true }
}
}
That md5 is not hexadecimal but still it is ASCII, how do I use it?
The part of the digest after the md5- prefix looks like it's in Base-64 format.
If parsing in Javascript, the atob function can turn it back into binary data.
Assuming the above is correct then the hexadecimal equivalent is:
c8 36 ec d6 c7 1f 61 da aa 2e 9c 72 15 bd 60 17
For anyone looking to work with the digest format used by couchdb using nodejs you can turn the base64 encoded digest into a "normal" hex string by removing the "md5-" prefix and then do:
new Buffer('yDbs1scfYdqqLpxyFb1gFw==', 'base64').toString('hex')
To go the other way and create the digest string from a hex value:
new Buffer('c836ecd6c71f61daaa2e9c7215bd6017', 'hex').toString('base64')

Convert OpenISO8583.Net into different formats

I'm trying to implement an ISO8589 message to a financial institution. They however, have a Web Service that I call and then I load the ISO8589 payload into an appropriate field of the WCF service.
I have created an ISO8589 message this way:
var isoMessage = new OpenIso8583.Net.Iso8583();
isoMessage.MessageType = Iso8583.MsgType._0100_AUTH_REQ;
isoMessage.TransactionAmount = (long) 123.00;
isoMessage[Iso8583.Bit._002_PAN] = "4111111111111111";
// More after this.
I can't seem to figure out how I can convert the isoMessage into an ASCII human readable format so I can pass it through to the web service.
Anyone have any idea how this can be done with this library? Or am I using this library the wrong way?
Thanks.
UPDATED:
I have figured out how to do this doing:
var asciiFormatter = new AsciiFormatter();
var asciiValue = asciiFormatter.GetString(isoMessage.ToMsg());
However, Now I am trying to take the isoMessage and pass the entire thing as hex string easily using OpenIso8583.Net, as follows:
var isoMessage = new OpenIso8583Net.Iso8583();
isoMessage.MessageType = Iso8583.MsgType._0800_NWRK_MNG_REQ;
isoMessage[Iso8583.Bit._003_PROC_CODE] = "000000";
isoMessage[Iso8583.Bit._011_SYS_TRACE_AUDIT_NUM] = "000001";
isoMessage[Iso8583.Bit._041_CARD_ACCEPTOR_TERMINAL_ID] = "29110001";
I know this is tricky, because some fields are BCD, AlpahNumeric, Numeric, etc. however, this should be realively easy (or I would think) using OpenIso8583.Net? The result I'd like to get is:
Msg Bitmap (3, 11, 41) ProcCode Audit Terminal ID
----- ----------------------- -------- -------- -----------------------
08 00 20 20 00 00 00 80 00 00 00 00 00 00 00 01 32 39 31 31 30 30 30 31
Any help would be greatly appreciated!
Essentially, you need to extend Iso8583 which you initialise with your own Template In the Template, you can set the formatters for each field so that BCD and binary packing is not used. Have a look at the source code for Iso8583 as to how it works.

Resources