dashes being changed to ?

First, if possible, I’d dump this in hex so you know whether or not you are getting the same values.

It could be the display of the viewer messing with you.

When doing a hcihd of the original message with the dash, check to see if it is a legitimate dash or a bogus formatted long dash like in MS word.  I would think a legitimate dash would pass through okay but a long dash might be a problem.

The hex 96 after BC space is not a regular dash/hyphen it is an en dash

An en dash or en rule (

I ran into something similar when upgrading a while back from 5.x to 6.x.  Check the properties tab for both threads involved in this interface and validate the Encoding property.  For those itnerfaces sending extended ASCII characters, if Encoding is set to ASCII, some translation occurs natively in the engine.  I found that if I set encoding to bypass that the problem was fixed.  I’m pretty sure hex 96 was one of the characters Cerner sent that was problematic going to Epic, but it was a while ago when we encountered this.

Hope this helps,

If you decided to take the approach to replace all occurrences of troublesome MS word formatted characters like the long dash to a regular dash, check out my older post of tps_regsub_all.tcl that I used to get around this issue.

<a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=1663&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=1663

Pay close attention to the Notes section in the Header of the proc because when dealing with the upper 128 characters the testing tool and the real interface produce different outcomes and require the args be passed differently depending on which one you use.

Personally when dealing with upper 128 characters I only trust the outcome of the actual interface because of all the extra quirks that can occur when dealing with those characters.

Also when migrating from Cloverleaf 5.6 to 6.0, we got hit with encoding so you may have to play around with that in the inbound thread to preserve the character as received, especially for the upper 128 characters.

Internally the engine is dealing with Unicode so it would probably be something like:   set msg [string map “u00FB u002D” [msget $mh]]  or

set msg [string map “u00FB  x2D” [msget $mh]]

Although I have not tried it.

Hello,

I have a weird character mapping issue similar to this, running on Cloverleaf 6.1.

The incoming transactions are sent to my system in ISO-8859-1 and this is also what I want to send them out to the end points as.

On both the inbound and outbound pipes I have set the encoding to ISO-8859-1. On the inbound smat I can see the data is ISO-8859-1 but on the outbound smat the data is stored as UTF-8 for some odd reason.

I tried the same transaction again but used the bypass encoding on both the inbound and outbound and this produced some unreadable results, neither UTF-8 nor ISO-8859-1.

Does anyone have any advice on what I can do differently?

Thank you for any help or advice.

Aaron

I seem to recall the encoding on outbound threads is not applied until AFTER SMAT is written.

Have you tried to connect the outbound to hcitcptest so you can see the message as delivered (will be in Hex also)?

That way you can verify if my memory is correct and not waste time if SMAT won’t show you what you want.

I can confirm this.

Inbound SMATs are written before encoding, so you see the message in the encoding as it is sent from the inbound system. After the message is written to SMAT, it is encoded into UTF-8 and processed.

Outbound SMATs are always in UTF-8; the messages are first written to SMAT in UTF-8, then encoding occurs towards the chosen encoding for that outbound system and finally the message is send.