In NHapi, I'm attempting to create a pipe-encoded ORM. When I parser.Encode() my populated message, only some of the segments are printed. Notably among the missing segments is MSH!
I don't know for sure, but I believe that the encoder is skipping segments that it considers to be incomplete.
I have given values for the required fields MSH-1, 2, 9, 10, 11, and 12, but I cannot get the MSH segment to encode.
If I am right that the MSH segment's incompleteness is causing this omission: Is there any way to have the PipeEncoder or some other validator throw exceptions if messages are not complete?
And: In any case, why is the MSH segment not encoding?
Perhaps this could help someone, so I won't just close it. I was printing these encoded messages to the Console and seeing only two segments, and jumbled at that, though I wasn't familiar enough with HL7 to realize.
What was happening was that NHapi's '\r' single newline character (rather than "\r\n") was merely overwriting each line with the next segment. My PID segment was long enough to wrap, getting me to the second line and the two segments.
That was dumb.
Related
I have JSON files with hundreds of lines, but when there is an error that causes a parsing exception, the library returns a character position, not a line number.
Line number would be hugely helpful since most text editors will show you, or take you to the line number, but I don't know of any that give the absolute character number.
I found the spot in parse_error where deserialization member byte_ holds the character index, but it doesn't seem to have line number info.
Does the json container "know" which line it is, and I could ask for it in the exception handler? I know this isn't a trivial issue, since different OS's give us the "joys" of different EOLs, but perhaps it has been handled anyway?
I have a generated report in Informix 4GL that prints to the screen.
I need to have one column displayed in reverse format.
I tried the following:
print line_image attribute(reverse)
But that doesn't work. Is this possible at all?
Adding on to the previous answer, you can try the following
print "\033[7mHello \033[0mWorld"
\033[7m means to print in reverse. And, \033[0m means to go back to standard.
If you mean "is there any way at all to do it", the answer's "yes". If you mean "is there a nice easy built-in way to do it", the answer's "no".
What you'll need to do is:
Determine the character sequence that switches to 'reverse' video — store the characters in a string variable brv (begin reverse video; choose your own name if you don't like mine).
Determine the character sequence that switches to 'normal' video — store the characters in a string variable erv (end reverse video).
Arrange for your printing to use:
PRINT COLUMN 1, first_lot_of_data,
COLUMN 37, brv, reverse_data,
COLUMN 52, erv,
COLUMN 56, next_lot_of_data
There'll probably be 3 or 4 characters needed to switch. Those characters will be counted by the column-counting code in the report.
Different terminal types will have different sequences. These days, the chances are your not dealing with the huge variety of actual green-screen terminals that were prevalent in the mid-80s, so you may be able to hardwire your findings for the brv and erv strings. OTOH, you may have to do some fancy footwork to find the correct sequences for different terminals at runtime. Shout if you need more information on this.
A simple way which might allow you to discover the relevant sequences is to run a program such as (this hasn't been anywhere near an I4GL compiler — there are probably syntax errors in it):
MAIN
DISPLAY "HI" AT 1,1
DISPLAY "REVERSE" AT 1,4 ATTRIBUTE(REVERSE)
DISPLAY "LO" AT 1, 12
SLEEP 2
END MAIN
Compile that into terminfo.4ge and run:
./terminfo.4ge # So you know what the screen looks like
./terminfo.4ge > out.file
There's a chance that won't use the display attributes. You'd see that if you run cat out.file and don't see the reverse flash up, then we have to work harder.
You could also look at the terminal entry in the termcap file or from the terminfo entry. Use infocmp $TERM (with the correct terminal type set in the environment variable) and look for the smso (enter standout mode) and rmso (exit standout mode) capabilities. Decipher those (I have rmso=\E[27m and smso=\E[7m for an xterm-256color terminal; the \E is ASCII ESC or \033) and use them in the brv and erv strings. Note that rmso is 5 characters long.
I have a string that, by using string.format("%02X", char), I've received the following:
74657874000000EDD37001000300
In the end, I'd like that string to look like the following:
t e x t NUL NUL NUL í Ó p SOH NUL ETX NUL (spaces are there just for clarification of characters desired in example).
I've tried to use \x..(hex#), string.char(0x..(hex#)) (where (hex#) is alphanumeric representation of my desired character) and I am still having issues with getting the result I'm looking for. After reading another thread about this topic: what is the way to represent a unichar in lua and the links provided in the answers, I am not fully understanding what I need to do in my final code that is acceptable for this to work.
I'm looking for some help in better understanding an approach that would help me to achieve my desired result provided below.
ETA:
Well I thought that I had fixed it with the following code:
function hexToAscii(input)
local convString = ""
for char in input:gmatch("(..)") do
convString = convString..(string.char("0x"..char))
end
return convString
end
It appeared to work, but didnt think about characters above 127. Rookie mistake. Now I'm unsure how I can get the additional characters up to 256 display their ASCII values.
I did the following to check since I couldn't truly "see" them in the file.
function asciiSub(input)
input = input:gsub(string.char(0x00), "<NUL>") -- suggested by a coworker
print(input)
end
I did a few gsub strings to substitute in other characters and my file comes back with the replacement strings. But when I ran into characters in the extended ASCII table, it got all forgotten.
Can anyone assist me in understanding a fix or new approach to this problem? As I've stated before, I read other topics on this and am still confused as to the best approach towards this issue.
The simple way to transform a base16-encoded string is just to
function unhex( input )
return (input:gsub( "..", function(c)
return string.char( tonumber( c, 16 ) )
end))
end
This is basically what you have, just a bit cleaner. (There's no need to say "(..)", ".." is enough – if you specify no captures, you'll automatically get the whole match. And while it might work if you write string.char( "0x"..c ), it's just evil – you concatenate lots of strings and then trigger the automatic conversion to numbers. Much better to just specify the base when explicitly converting.)
The resulting string should be exactly what went into the hex-dumper, no matter the encoding.
If you cannot correctly display the result, your viewer will also be unable to display the original input. If you used different viewers for the original input and the resulting output (e.g. a text editor and a terminal), try writing the output to a file instead and looking at it with the same viewer you used for the original input, then the two should be exactly the same.
Getting viewers that assume different encodings (e.g. one of the "old" 8-bit code pages or one of the many versions of Unicode) to display the same thing will require conversion between different formats, which tends to be quite complicated or even impossible. As you did not mention what encodings are involved (nor any other information like OS or programs used that might hint at the likely encodings), this could be just about anything, so it's impossible to say anything more specific on that.
You actually have a couple of problems:
First, make sure you know the meaning of the term character encoding, and that you know the difference between characters and bytes. A popular post on the topic is The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
Then, what encoding was used for the bytes you just received? You need to know this, otherwise you don't know what byte 234 means. For example it could be ISO-8859-1, in which case it is U+00EA, the character ê.
The characters 0 to 31 are control characters (eg. 0 is NUL). Use a lookup table for these.
Then, displaying the characters on the terminal is the hard part. There is no platform-independent way to display ê on the terminal. It may well be impossible with the standard print function. If you can't figure this step out you can search for a question dealing specifically with how to print Unicode text from Lua.
My application is parsing incoming emails. I try to parse them as best as possible but every now and then I get one with puzzling content. This time is an email that looks to be in ASCII but the specified charset is: ansi_x3.110-1983.
My application handles it correctly by defaulting to ASCII, but it throws a warning which I'd like to stop receiving, so my question is: what is ansi_x3.110-1983 and what should I do with it?
According to this page on the IANA's site, ANSI_X3.110-1983 is also known as:
iso-ir-99
CSA_T500-1983
NAPLPS
csISO99NAPLPS
Of those, only the name NAPLPS seems interesting or informative. If you can, consider getting in touch with the people sending those mails. If they're really using Prodigy in this day and age, I'd be amazed.
The IANA site also has a pointer to RFC 1345, which contains a description of the bytes and the characters that they map to. Compared to ISO-8859-1, the control characters are the same, as are most of the punctuation, all of the numbers and letters, and most of the remaining characters in the first 7 bits.
You could possibly use the guide in the RFC to write a tool to map the characters over, if someone hasn't written a tool for it already. To be honest, it may be easier to simply ignore the whines about the weird character set given that the character mapping is close enough to what is expected anyway...
My BizTalk receive XML message as a input message. I am converting that message to HL7 message using Transform in orchestration.
Now if input message consists of any empty field in any of the node, the HL7 message breaks up at that postion and also include space in that message.
Can anyone help me to resolve this issue? following is my HL7 message:
Note --- Copy this message in Textpad to get to know exact space in it
MSH|^~\&|EEHR^bbbbbbbbbb|aaaaaaaaaaaaaaaaa^12699^DNS|KYIR|CDP|201103060733||VXU^V04|14962|P|2.3.1||||
PID|1||765874316^^^^SS||ssssss^anan^T|wwwww^^^^^^M|20100217|M||2135-2^YYYYYYYY or jjjjjj^HL70005|5896 hyhyhyhy Ave^Apt# 112^Wanta Fe^NM^85678^XXX^H^^049||5033331120X
^PRN^PH^^^505^5551120^~^NET^X.400^xxxxxx#yutyutopo.com|5056083515X4365^WPN^PH^^^505^6086715^4365|es^English^HL70296||||215486702|||H^erererer or qwqwqw^HL70189|bnbnbn|Y|1||||
Thanks.
I'm not entirely sure what the issue is - is it that there are spaces in the output HL7 message string? I'm not on my windows partition right now, so I'm not able to actually see any glaring issues with spacing in your posted message.
Anyway, if it is just spaces, can you just parse through the string and replace spaces in fields with an empty string?
Something like: message.replaceAll("\\| \\|", "||"); <-- This is Java code
That previous code would replace all instances of '| |' with '||' (i.e. replace fields with a space with an empty string).
Hope that helps.
Cheers
It seems your problem is that there are wrong segment separators.
As it would be possible to find just all segment headers as a combination of a blank followed by a known segment header and a field delimiter and to replace the blank by the correct segment separator, there is no guarantee, that you will not get the same combination by chance at a position different from the start of a segment.
So best advice would be to avoid the wrong segment separators und to provide it right.