Have a input that, when edited, shows matching fields/message types/etc.

Expected Output

119 | ClientID | BLAH

Actual Output

109 |   | BLAH

• Invalid BeginString
• Field value doesn't match expected type
• Checksum invalid
• Incorrect body length

https://drewnoakes.com/fix-decoder/ is not working. Can you please check?

It can be convenient to send a message to someone else for review. The page's hash fragment should be updated (provided it's not too long) with an encoded version of the message text. Possibly use Base64 encoding.

Seeing general conversation on "doesn't support field NNN" always returns to this, fix-decoder should support the current standard.

• Dump FIX 5 fields onto the end of data.js as a fig-leaf
• Add capability for multiple (vanilla) dictionaries with version-detection

Hi,

This is a nice tool, we modified the regexpr to allow ^A and tabular separators

I know it only breaks on ^, it works, so I guess you only keep digits for the fixtags part later on in the code

Tabs are little bit pointless as putty gives away spaces when copy pasting from it, but I guess some people use them for readability as we do, but I am not 100% sure they won't be used in the fix values

see diff below

svn diff
Index: scripts/app/FixParser.js
===================================================================
--- scripts/app/FixParser.js    (revision 23)
+++ scripts/app/FixParser.js    (working copy)
@@ -18,7 +18,8 @@
         FixParser.prototype.parse = function(str)
         {
             // Create a sequence of fields
-            var regex = /([0-9]+)=([^|\001]*)/g,
+            var regex = /([0-9]+)=([^|\001^\t]*)/g,
                 fields = [], result;

             var fixVersion = 'unknown';
@@ -113,4 +114,4 @@

         return FixParser;
     }
-);
\ No newline at end of file
+);

Hello,

I am not a js expert. i am trying to build fix-decoder but when I run gulp I have the next error:

gulp[14802]: ../src/node_contextify.cc:635:static void node::contextify::ContextifyScript::New(const v8::FunctionCallbackInfo<v8::Value>&): Assertion `args[1]->IsString()' failed.
 1: 0x8fa0c0 node::Abort() [gulp]
 2: 0x8fa195  [gulp]
 3: 0x92e5be node::contextify::ContextifyScript::New(v8::FunctionCallbackInfo<v8::Value> const&) [gulp]
 4: 0xb8d2db  [gulp]
 5: 0xb8f272 v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) [gulp]
 6: 0x379a75b5be1d 
Aborted

My tools versions:

eamanu@debian:~/dev/fix-decoder$ node --version
v10.16.3
eamanu@debian:~/dev/fix-decoder$ npm --version
6.9.0
eamanu@debian:~/dev/fix-decoder$ yarn --version
1.17.3
eamanu@debian:~/dev/fix-decoder$ gulp --version
CLI version: 2.2.0
Local version: 3.9.1
eamanu@debian:~/dev/fix-decoder$ 

Include the descriptions of fields as tool tips or similar.

http://www.fixprotocol.org/specifications/fix4.3fiximate/standard_message_header.html

Currently only a few of the header fields are being selected

Currently the app uses a single set for all field IDs. Investigate whether we need a different mapping for each FIX version.

Expected Output

1057 | AggressorIndicator | BLAH

Actual Output

1057 | | BLAH

Valid dictionary values of BLAH are

'Y' | Order initiator is aggressor
'N' | Order initiator is passive

The structure of FIX messages is such that nested structures are represented flattened in the parent. Their boundaries are not self-describing, and additional metadata about the format is required.

Header fields appear at the beginning of the message.

From Wikipedia:

Up to FIX.4.4, the header contained three fields: 8 (BeginString), 9 (BodyLength), and 35 (MsgType) tags.

From FIXT.1.1 / FIX.5.0, the header contains five mandatory fields and one optional field: 8 (BeginString), 9 (BodyLength), 35 (MsgType), 49 (SenderCompID), 56 (TargetCompID) and 1128 (ApplVerID - if present must be in 6th position).

Further, messages which do not contain a valid header should be identified as erroneous.

Tag 22 shows the description (ISIN Number in below example) alongside the actual value (4 in the below example)

22 | SecurityIDSource | ISIN Number (4)

However, Tag 456, which uses the same dictionary as 22 https://www.onixs.biz/fix-dictionary/4.4/tagNum_456.html does not show the description, just the value (1 in the below example, when CUSIP (1) was the expected outcome)

456 | SecurityAltIDSource | 1

http://www.fixprotocol.org/discuss/read/4652b522

This project uses Google Analytics to track page views. Since the processed input is part of the page URL, the processing is not kept locally.

Please remove page tracking or remove the claim that no data is being sent via the internet.