There are two problems with the way that RTO is encoding TS1 data in UTF-8
- One character is mapped to a different character in the same range
- Several characters are expanded out into two characters and given the way it's done, I'm not sure it's possible to reverse the expansion 100% correctly in all cases
I've also captured the websocket traffic in Fiddler and it looks like this is coming from upstream and we're not distorting it any way in our "app". I've attached this rto-202105181200-ts1.zip showing this binary data in FIDs ROW64_1-14 before it reaches our app. Rename the filename from .zip -> .saz to open in Fiddler.
Also attached is "ts1-rto character mappings.txt" which shows the IDN characters and how they are being mapped to RTO. We arrived at this by making the same request through the LPC (Legacy Protocol Converter) 1.2 which connects to Elektron (RTO) and then comparing the binary data in the FIDs.
Can anyone shed an light on this decoding process? Or whom to have look at this?
Maybe our request in the Fiddler SAZ is just wrong? Its pretty basic.
{
"ID":2,"Streaming":false
"Key":{
"Name":["dBOc1d"],
"Service":"ELEKTRON_DD"
}
}
Either the LPC is dealing with these different encodings or it is making a slightly different request that causes the data to come back encoded differently.