[BitBucket user: Alain Mazy]
[BitBucket date: 2018-04-26.15:07:12]

At some point, we had some files whose encoding was badly specified.  It was declared as UTF-8 but contained \e9 characters (the sequence \e9r\e9 or éré).

With Orthanc 1.3.1 and with Orthanc 1.3.2 running in Docker, the \e9 character is replaced by \efbfbd in UTF-8 (unknown char) which is the expected behaviour.
However, with Orthanc 1.3.2 on Windows, the \e9r\e9 sequence is replaced by \u9ca9.

On the screenshot: left is from Orthanc running on Windows, right is from Orthanc running on Linux 
![Capture.PNG](1136093008-Capture.PNG)

[Bugzilla user: s.jodogne@gmail.com]
[Bugzilla date: 2020-06-29T13:13:47+00:00]

Created attachment 5
1136093008-Capture.PNG

[Bugzilla user: s.jodogne@gmail.com]
[Bugzilla date: 2020-06-29T13:18:09+00:00]

Created attachment 74
eaca2146-0a8d91ac-94a63f18-9ecb7e11-d253474f.dcm

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2018-07-12.11:12:06]

As the input DICOM file is invalid, it is normal that the Orthanc behavior is left undefined (provided no crash occurs, which is indeed the case). Here is a sequence of command lines to check that the file is invalid wrt. UTF-8 encoding:

```
$ dd if=eaca2146-0a8d91ac-94a63f18-9ecb7e11-d253474f.dcm of=StudyDescription bs=1 skip=538 count=14
14+0 records in
14+0 records out
14 bytes copied, 0,000154753 s, 90,5 kB/s

$ hexdump -C StudyDescription
00000000  49 52 4d 20 63 e9 72 e9  62 72 61 6c 65 20        |IRM c.r.brale |
0000000e

$ iconv -f UTF-8 StudyDescription -o /dev/null
iconv: illegal input sequence at position 5
```

[BitBucket user: Sébastien Jodogne]
[BitBucket date: 2018-07-12.11:12:28]

Garbage in, garbage out.