mkdicomweb create double-encodes non-ASCII PatientName (Cyrillic -> mojibake, QIDO returns 0 hits) #142

Environment

• braveheartsoftware/static-dicomweb:latest = @radicalimaging/static-wado-webserver 1.7.7 (latest published Docker image; the latest tag points to 1.7.7).
• mkdicomweb create from that image.

Summary

mkdicomweb create corrupts non-ASCII PatientName at ingest. A DICOM Part 10
file with SpecificCharacterSet = ISO_IR 192 (UTF-8) and
PatientName = ТЕСТ^ПАЦИЕНТ (a synthetic placeholder) produces a studies
index where 00100010.Value[0].Alphabetic is mojibake - the UTF-8 bytes have
been re-decoded as Latin-1 (Т becomes Т, and so on). QIDO-RS can
therefore never match the patient by the correct name.

Steps to reproduce

1. Create one DICOM Part 10 file with SpecificCharacterSet = ISO_IR 192,
   PatientName = ТЕСТ^ПАЦИЕНТ, and valid Study/Series/SOP Instance UIDs.
2. Convert:
   docker run --rm -v <dicom-dir>:/dicom -v <out-dir>:/dicomweb braveheartsoftware/static-dicomweb:latest mkdicomweb create /dicom --no-thumb
3. Serve:
   docker run -d -p 25080:5000 -v <out-dir>:/dicomweb braveheartsoftware/static-dicomweb:latest
4. Query:
   curl -s -H 'Accept: application/dicom+json' 'http://127.0.0.1:25080/dicomweb/studies?PatientName=%D0%A2%D0%95%D0%A1%D0%A2%5E%D0%9F%D0%90%D0%A6%D0%98%D0%95%D0%9D%D0%A2'

Expected

The study is returned and the stored name is preserved byte-for-byte.

Actual

[] (0 hits). Decompressing <out-dir>/studies/index.json.gz shows
00100010.Value[0].Alphabetic is mojibake (ТÐСТ^ЦÐÐ... instead of
ТЕСТ^ПАЦИЕНТ). Querying with that mojibake string instead returns the
study (1 hit), which confirms the corruption is in the stored index, not in
the QIDO filter.

Impact

PatientName (0010,0010) is a Required study-level matching key for QIDO-RS
(PS3.18 Table 10.6.1-5). Every patient whose name contains non-ASCII
characters (Cyrillic, CJK, Greek, accented Latin, ...) is unsearchable by
name and displays as garbage in viewers.

Scope

Verified for Cyrillic under ISO_IR 192. The mojibake pattern (UTF-8 bytes
re-decoded as Latin-1) suggests every multi-byte UTF-8 sequence - i.e. all
non-ASCII scripts - is affected. Pure ASCII is unaffected.

The name in this report is a synthetic placeholder, not patient data.

Best regards,
Clarus PACS