TCL Help – Extended ASCII character substitution

Clovertech Forums Read Only Archives Cloverleaf Cloverleaf TCL Help – Extended ASCII character substitution

  • Creator
    Topic
  • #49920
    Robert Milfajt
    Participant

      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

    Viewing 1 reply thread
    • Author
      Replies
      • #64104
        Rob Abbott
        Keymaster

          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

        • #64105
          Robert Milfajt
          Participant

            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

        Viewing 1 reply thread
        • The forum ‘Cloverleaf’ is closed to new topics and replies.