special character – encoding – outbounding

[Alan James]

I have a vendor who includes a superscript in unit measurements, which are part of the data in OBX.5.  I can substitute a 2 for the special character, superscript 2.  But, I’m having a hard time figuring out how to get the engine to outbound it to downstream apps.

Everything works in my testing tool, both the TPS and the Routes, IF I set the Encoding to ASCII.  Both my IB thread from the vendor and my OB thread to downstreams are configured to be ASCII encoding.

I can resend the messages from SMAT, and, AS LONG AS I set the encoding to ASCII, the outbounded transactions delivered to the downstream apps out of the engine are good, i.e., they do not contain the special character, superscript 2 in them.

But, transactions which run through the engine real-time still have the superscript 2 in them.

I sure would appreciate some insight here – thanks ahead of time for your consideration.

Topic

[Charlie Bursell]

When you say substitute 2 for the super script what do you mean?  Are out in a new value in Xlate?

Setting the encoding does not change the character, just how it is interpreted.  As I just said on another thread what is displayed is UTF-8.   Try looking at the output with Word or something similar.

Also if you have ASCII encoding SMAT will be saved as that

[Alan James]

Here’s what I’m getting from the vendor:

OBX|28|TX|R^REPORT||AVA (VTI): 1.6 cm�||||||F

I’m running this through a route with a pre proc to swap the special character out and replace it with the numeral 2.  Here’s the relevent code for that:

 set x “�”

   regsub -all $x $msg {2} newmsg

This works in the testing tool so long as I keep the encoding setting set to ASCII.  It doesn’t work at all in real-time, though.  Here’s what’s getting delivered to my OB thread:

OBX|28|TX|R^REPORT||AVA (VTI): 1.6 cm�||||||F

Like it’s not being acted upon by the pre proc at all.

When I use SMAT to resend, though (keeping the encoding set to ASCII), here’s what I get:

OBX|28|TX|R^REPORT||AVA (VTI): 1.6 cm2||||||F

Which tells me the pre proc is working.

I’m getting out of my area/limits of expertise here, but I really need to fix this for my downstream app – these special characters are blowing the users out of their application when they try to inquire these reports.

Is there a way for me to determine what the vendor’s encoding is, and to convert that to ASCII?

Or, is something entirely different (not encoding) going on here?

[Alan James]

Actually, even if the pre proc is doing nothing, then my questions are still relevent:  how can I determine what the vendor’s encoding is, and how can I make that character an ascii, or utf-8, numeral 2?

[Charlie Bursell]

It probably has to do with the way you entered the code to substitute.  The engine deals with Unicode.  The superscript 2 is Hex c2b2.

You could do it a couple of ways.  Assume str contains the text

set str [string map “xc2b2  2” $str]

or simply:

regsub — {cm.} $str {cm2} str

[Alan James]

Thank-you much – that did the trick!

[Keith McLeod]

I have been performing upgrades from 5.X to 6.1 routinely, however, the latest upgrade I have found that the degree symbol is as follows:

5.7: OBX:5 contained: Coned down magnification views and a 90

[David Barr]

Keith McLeod wrote:

I noticed that 5.7 is using xc2xa2 whereas 6.1 only uses the xa2 for the cent symbol.

[Author]

Replies