As a follow-on from #75, we currently ensure that all text is utf-8 internally by going through a whole bunch of codepages and accepting whichever one can successfully parse the input bytes first (and then keeping the resulting utf-8 bytes instead of the bytes the source gave us).
However that search isn't guaranteed to succeed only with the correct codepage, so the resulting utf8, while valid utf8, might contain the wrong characters. We can get around this in much the same way as LyricShowPanel3 by providing a way for the user to select a codepage. My current thinking is that we have a dropdown in the editor where the user can pick a codepage to "re-encode" to.
This can (in theory) be implemented easily (if not particularly efficiently) by converting our utf8 text into a wide string, back to a multi-byte string using the selected encoding, then back to a wide string using the same codepage and finally pack to a multi-byte string as utf8.
As a follow-on from #75, we currently ensure that all text is utf-8 internally by going through a whole bunch of codepages and accepting whichever one can successfully parse the input bytes first (and then keeping the resulting utf-8 bytes instead of the bytes the source gave us).
However that search isn't guaranteed to succeed only with the correct codepage, so the resulting utf8, while valid utf8, might contain the wrong characters. We can get around this in much the same way as LyricShowPanel3 by providing a way for the user to select a codepage. My current thinking is that we have a dropdown in the editor where the user can pick a codepage to "re-encode" to.
This can (in theory) be implemented easily (if not particularly efficiently) by converting our utf8 text into a wide string, back to a multi-byte string using the selected encoding, then back to a wide string using the same codepage and finally pack to a multi-byte string as utf8.