Ideally, it would all be driven by the encoding specified by the xml
template.
As a second choice, I think it should be driven by a configurable symbol.
No, neither of both makes sense here. The only thing that is required to
fix the bug is that reading uses the same encoding as
It is because that is only a intermediate presentation of the page's
content:
- it is read from filesystem by whatever encoding is configured
- it is pre-processed and written internally as UTF-8 (hard-coded) into
a byte array or such
- it is read again internally as System encoding (not
Hi,
could please anyone with commit access fix this little issue
https://issues.apache.org/jira/browse/TAP5-2219 or at least add the
testcase to the testsuite? This becomes a show-stopper for us for
migration to tapestry 5.4 since all pages with utf-8 chars fails on windows.
Kind regards,
You could set -Dfile.encoding=UTF-8 when starting up the servlet container.
On 8 Apr 2014 14:24, Michael Wyraz michael.wy...@evermind.de wrote:
Hi,
could please anyone with commit access fix this little issue
https://issues.apache.org/jira/browse/TAP5-2219 or at least add the
testcase to
It still would be great if this could be fixed :-)
Agreed, but I'm not convinced that hard coding UTF8 is the answer :)
Thank you, that helped a lot!
It still would be great if this could be fixed :-)
Regards,
Michael.
You could set -Dfile.encoding=UTF-8 when starting up the servlet container.
On 8 Apr 2014 14:24, Michael Wyraz michael.wy...@evermind.de wrote:
Hi,
could please anyone with commit access