TCL Help – Extended ASCII character substitution

[Robert Milfajt]

The problem:

On Cloverleaf 5.5 rev1, AIX 5.3, I have an HL7->XML interface, all works well for normal messages.  In the actual Xlate, Cloverleaf tranlates & to &, which is fine.  However, I get some messages with characters in the extended ASCII character set (decimal 128-155; hex 80-ff), which crash the interface.  In particular the xb2 (subscribted 2) for meters squared, although I figure I should code for the entire block, x80-xff.

The plan:

Convert all the extended ASCII characters to a four character representation, where the character xb2 becomes the four characters: , x, b, and 2.  In a post-xlate routine I will convert xnn to the XML standard &#nn; via a single regsub command.

The issue:

I could not do this in one straight regsub command, i.e.,

Code:

regsub -all ([\x80-\xff]) $x [conv_char 1]

because I could not access the character that was being converted (1) inside another TCL command.

My next attempt was to run through the message, one character at a time and if the character was x80-xff, convert it, but that really seemed wrong to process a loop a couple of thousand times to pick up 0-3 characters.

My last attempt looks like this:

Code:

           keylget args MSGID mh
           set msg [msgget $mh]
           for {set i 128} {$i<256} {incr i} {
               set hex [format %x $i]
               if {[regexp -- \x$hex $msg]} {
                       regsub -all \x$hex $msg \x$hex new_msg
                       set msg $new_msg
               }
           }
           msget $mh $msg

and I like it better because it is only processing 128 loop iterations vs. thousands.

Does anyone know a better way?   ❓

Thanks in advance,

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

Topic

[Rob Abbott]

Bob, one thing you can try that may simplify this-

make sure the encoding is set properly in the XML header, e.g. in your case it should be

If it’s utf-8 in there instead of 8859-1, you will have problems, because the codes you mention are not legal utf-8.  This may be why it’s complaining.

If the header doesn’t exist, then the encoding defaults to utf-8, so you will need to add it if it’s not there.

Hope this helps

Rob Abbott
Cloverleaf Emeritus

[Robert Milfajt]

I meant to reply, but we have an Ophthalmology PACS integration this week and a Radiology PACS next week and I have been against it.

I did change the encoding from utf-8 to iso-8859-1 and it fixed everything.

Thanks for your reply,

Bob

Robert Milfajt
Northwestern Medicine
Chicago, IL

[Author]

Replies