Hi guys,
I am currently implementing DICOM server and sometimes testing it with CONQUEST.
My code is reporting that CONQUEST encodes padding incorrectly for value representation of LO (and perhaps some other string value representations)
According to DICOM standard LO value representation may be padded with leading and/or trailing spaces and CONQUEST uses NULL(0 ascii character)
NULL can be used for padding in UI value representation, not in LO. Moreover control characters like NULL are forbidden in LO.
Excerpt from PS 3.5 for LO encoding:
"character string that may be padded with
leading and/or trailing spaces. The character
code 5CH (the BACKSLASH “\” in ISO-IR 6)
shall not be present, as it is used as the
delimiter between values in multiple valued
data elements. The string shall not have
Control Characters except for ESC."
One good thing here is that this bug is usually non fatal. If other DICOM AE parses the value from LO into some numeric value, the NULL value is treated as the end of the string and value is correctly parsed.
If however, somebody would use the value directly as it was received the problem may arise.
Here is a scenario where the problem can occur:
Other server receives from CONQUEST value with VR of LO and uses it directly to query database. The padding is not ommitted since it is not the expected space character.
On other server side we end up with a query like:
SELECT ... FROM ... WHERE patient.id='some odd number padded with NULL'
Now, this *doesn't* match entity in a database with id from the query!!!
The version of CONQUEST I am using is 1.4.16.
The problem can be reproduced by using QUERY/MOVE and entering odd patient id.
Regards,
Bartosz Meglicki
National Centre for Nuclear Research
Department of Nuclear Equipment
ul. Andrzeja Sołtana 7
05-400 Otwock, Poland