forked from Mudlet/Mudlet
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
BugFix: fix encoding problems with QTextStreams (Mudlet#5264)
As Leris/Kebap found in issue Mudlet#5262 Windows in particular does not default to using UTF-8 when reading and writing text files - instead it can use an 8-bit local which (probably) depends on the end-users OS country settings. However this is not UTF-8 and that will cause issues if such files are used on another system or OS that does not use the same setting. This commit forces all uses of `QTextStream` (that are not associated with a `QString` as the underlying "device" for which it is not applicable) to use the UTF-8 encoding. However retro-fitting this change *may* (checks will be useful) mess with existing files, specifically: * The config.lua file that contains details of packages/modules in the `.mpackage` ZIP archive file format. This is the bug that this is intended to cure! * Reading of the external Lua files that Mudlet uses itself, the `LuaGlobal.lua` file and the others that it itself loads - however since those are pure ASCII there should not be an issue with them. * (WIndows ONLY) Reading the external `utf8_filenames.lua` file that is used to patch the Lua IO handlers to work with the UTF-16 file names that Windows uses in non-en locales. There shouldn't be an issue with this. * Custom user dictionaries - it is possible that the existing code was making use of UTF-8 anyhow - it needs someone like Leris/Kebap to check that any custom dictionaries still work given that they had a system this encoding problem was happening...! Provided it doesn't break other things this should close Mudlet#5262. Revised to ensure QTextCode::setCodec is used AFTER setDevice I think this may have been the cause of the odd behaviour where the code asked for the UTF-8 codec but ended up using a different one - the setDevice(...) method happens to reset the codec so a setCodec(...) call must be used after it and not before! Signed-off-by: Stephen Lyons <slysven@virginmedia.com> Co-authored-by: Vadim Peretokin <vperetokin@gmail.com>
- Loading branch information
Showing
6 changed files
with
36 additions
and
5 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters