Replace A0 ascii character with A20 ascii character

Kirby,

Just a guess here but I think you mean this

     msgset $mh $newmsg

     return  “{CONTINUE $mh}”   ;# run

Instead of

     msgget $mh $newmsg return

      “{CONTINUE $mh}”   ;# run

What Jim says is true.  Also the statement:

   regsub -all — “xA0” $msgdata “x20” newmsg

Since the fields are ib quotes instead of braces they will be interpreted by Tcl as well as the regsub command and can give weird results.  If using the regsub I would do it like:

    regsub -all — {xA0} $msgdata “x20” newmsg

However in this case I would not use a regsub at al I would use a string map command

      set newmsg [string map

$msgdata]

I have invented my own code, tried supplied code, and cannot get what you are suggesting to work.

In my message, there is an embedded xd7 in OBX-5.

I’ve tried:

x7f to xff to see if there was something I wasn’t seeing.

But that doesn’t come close to covering the range of non-ascii characters. In TCL they go up to at least 0xffff.

Why don’t you try printing out the values of each character in your string? TCL may be doing some kind of strange conversion of the message before it gets to your script.

You could add something like this to your TCL proc.

I’m a little confused by your statement.  The largest value in one signed byte is FF.  And a hex editor shows D7.

But I did what you suggested and the mystery character came up with 65533 which is FFFD .  

I guess that proves the theory that what it’s reading in is not what I thought and I agree with your statement that the tcl must be somehow interfering with the read.  But it still leaves me unable to change the value within the tcl preproc.  (I’ve tried xffxfd and xfffd).

I think I’m relegated to capturing the bad messages in a file and use a unix command to replace the original d7 problem (which does work), although cumbersome.

Thank you for your comments.  If you figure out (based on the message I uploaded) how to change the character, I would still be very interested in the result.

By gum, using a Unicode translation fixed it!

I regsub’d ufffd instead of x.

And then, after successfully testing, I try to implement it and it will not work.    Such frustration.

I thought maybe it was the “state” it was in when I resent it, so I made sure the inbound thread received it as it normally would by creating extra threads and sending the message down a pipeline.

Another post said that the tester needed \ or {} to indicate it was a control character and the implemenation did not.  I’ve tried both ways and neither work.  I gave up passing as a variable, afraid that was impacting the esacape sequences and it still does not work.

So I thought maybe now that it’s going through the engine, it interprets the characters differently.

…

Yes, it’s back to the original d7.

I’m a little confused by your statement.

If you’re trying to convert only nulls why not use msgget?

set msgdata [msgget -cvtnull x20 $mh]

From help contents:

msgget

Retrieves message data from the region specified by offset and length.

msgget ?-cvtnull char? msgId ?offset? ?length?

Nulls in the retrieved data are converted to char if you use -cvtnull. If the message contains nulls and you do not use the -cvtnull option, you cannot access any message data past the first null in the message from Tcl.

In addition, if you store the string returned in this non-conversion case, only the Tcl-visible string portion is stored.

This command returns the retrieved, converted data

Lastly…  I found that when you “resend” messages it had the unicode character ufffd and when they came from a thread in the traditional way it used xd7.

In case anyone wasnted to know there is a difference between resending and thread throughput.

I tried setting up a tcp-ip inbound thread, a file outbound thread to a /dev/null file and a raw static route between them. I put a proc on the route to print the message contents (and the hex code for non-printable characters). Here’s the code I used:

I sent your message to the file using the TCP tester like this:

I used a resend command to send the message like this:

I used the testing tool to run my proc like this:

In all of these cases the multiplication character was in my string as D7.

The only way that I was able to replicate your problem was to use the testing tool and change the encoding to ASCII like this:

This is the output:

The Unicode FFFD (�) character is actually a special character called the “replacement character”. According to Wikipedia “It is used to indicate problems when a system is not able to render a stream of data to a correct symbol.” It makes sense that I would see this if I picked an encoding that doesn’t match the data.

I was not able to replicate the FFFD problem using the resend command.

I too have pulled my hair out when dealing with what I will refer to as funky characters.

I have discovered the tester and a real interface will not produce the same outcome when dealing with funky characters.

In some cases even the real interface is stubborn when dealing with funky characters.

Sometimes this is complicated by advanced encoding schemes and UTF-8 that adds to the struggle, so I don’t envy you.

So what I’ve said so far, sort of summarizes what I see already talked about in this post, so congrats on still clinging to the mountain side.

Keep up the faith because seeing it work in hcitcl tells you it works but just have to get the agrs passed without all the extra unwanted intelligence corrupting it.

Now that you are aware of all these pitfalls but still stuck, I can share one more approach I resorted to in an extreme case to get a hard-coded funky character passed as an argument, when all else failed to work.

I created a cloverleaf lookup table and placed the funky character in the lookup table (not the x0… but the actual character using copy/paste then double check lookup table funky character on back end with hcihd), then accessing the lookup table read the funky character into an argument variable.

I know this is a high level overview of the trick I’m describing but is the best I can do at this time with my work load.