ResourceToolActionPipe.getContentstring() can incorrectly decode content.
GENERAL
TESTING
GENERAL
TESTING
Description
Activity
Show:
Matthew Buckett October 8, 2014 at 8:10 AM
This isn't an issue in Sakai 10 as the only place getContentstring() is call is when dealing with URLs.
Steve Swinsburg February 23, 2013 at 11:15 PM
Matthew I think this was meant to go back to you to decide if still an issue.
Gregory Thomas February 19, 2013 at 11:17 AM
Steve,
I don't believe this issue is relevant for Sakai 2.9 or beyond since I think FCKeditor has been eliminated. Assigning this to you to decide if this is still a 2.8 issue and something that should be addressed.
David Horwitz May 28, 2010 at 2:55 AM
This seems to me to be a similar problem to
Non-Issue
Details
Details
Priority
MajorAffects versions
Components
Assignee
Matthew BuckettReporter
Matthew BuckettEnvironment
Content on filesystem, UTF-8 MySQL database.
Created April 27, 2010 at 7:26 AM
Updated April 25, 2018 at 3:18 PM
Resolved October 8, 2014 at 8:10 AM
Ok, so if you upload a HTML file to Sakai that is encoded as UTF-8. This file is stored and served up correctly. But if you don't have file.encoding=UTF-8 set (directly or indirectly) when you attempt to edit the file with the FCKeditor the content string gets encoded as HTML entities to be placed into the textarea, and when retrieving the content the platforms default character encoding is used to convert from a byte array to a string.
In our case the JVM was defaulting to a file.encoding=US-ASCII, this then means that lots of the characters in a UTF-8 file can't be rendered.
In org.sakaiproject.content.impl.BasicResourceToolActionPipe.getContentstring() there is a section of commented out code that forces all conversions to be done as UTF-8 which would have fixed the problem for us. As it stands we're actually switching the file.encoding to be UTF-8.