started by James Leonard Halliday with the subject
"text encoding problem with bitstreams in DSpace 3.1 - resolved":
> Hi everyone,
> I posted about this a while back, and finally found a workaround
> so I wanted to share. My problem was regarding HTML bitstreams
> in DSpace 3.1 (XMLUI).
> In previous versions of DSpace, the encoding for my UTF-8 bitstreams
> worked just fine, but in DSpace 3.1, the encoding for ONLY the bitstreams
> was coming out as ISO-8859 instead. After much searching, I finally found
> a workaround.
First of all thanks for sharing, Leonard!
Now Dspace 4.0 rc3 has the same problem and the same fix helps:
> I'm thinking that our filter as written could never have done what you
> expect, and the effect was produced elsewhere. Our filter only sets
> the request's encoding. Spring's filter is documented to also set the
> response's encoding when forceEncoding=true. Perhaps BitstreamReader
> should just set the encoding on the response?
It seems that Spring's filter not only forces encoding for text/html,
but also converts the file. Please check out the results with default
Dspace web.xml (web.xml.old.data and web.xml.old.head) and
modified as described above (web.xml.new.data and web.xml.new.head):
root@dspace4-test:~# ls -l
-rw-r--r-- 1 root root 15140 Jan 13 15:06 web.xml.new.data
-rw-r--r-- 1 root root 384 Jan 13 15:06 web.xml.new.head
-rw-r--r-- 1 root root 24656 Jan 13 15:05 web.xml.old.data
-rw-r--r-- 1 root root 389 Jan 13 15:06 web.xml.old.head
web.xml.*.data files were obtained by running "lynx --dump"
and web.xml.*.head files were obtained by "lynx --head --dump"
As you can see headers differ as one would expect: