(opds): remove redundant UTF-8 fixup#15122
Conversation
…names The getLocalDownloadPath function was calling fixUtf8 with '_' replacement on the full path (directory + filename), after the filename had already been properly sanitized by getSafeFilename which calls fixUtf8 with ''. This double processing with different replacement characters caused: - Non-UTF8 bytes (from URL decoding or header issues) to be replaced with '_' - Encoding artifacts like '=' characters combined with '_' replacements - File extensions corrupted (e.g., .cbz becomes .cbz_=) The fix removes the redundant fixUtf8 call on the full path. The filename is already properly validated by getSafeFilename, and applying fixUtf8 again on the combined path is unnecessary and harmful.
|
While it does indeed look like a now redundant leftover, are these symptoms you mention something you've actually seen or were they made up by AI? Because if invalid UTF-8 was already replaced with an empty string, running it again shouldn't do anything other than waste some small amount of CPU cycles. |
|
This is the behavior I am currently experiencing on my device (Boox Note Air5C). I reviewed the code to see where this could be coming from, and I only found that the file name is modified at that point. Even so, I also reviewed it with Copilot, which confirmed that the name is only modified there and that this logic is redundant. Unfortunately, I have not been able to test the .apk, as I do not have the ability to compile it, but I still went ahead and created the PR, since in principle it should not affect any other logic or functionality, and at worst it would simply result in a more optimized implementation. |
|
To add more info: Expected behaviorThe downloaded file should preserve its original name and extension: Cap 1 - The first book.cbz Actual behaviorThe file name is modified during download, resulting in an encoded and altered name and extension: =UTF8_Q_Cap-1-The_first_book.cbz= I’m not sure why additional characters are being added. |
|
I'll merge it because it is indeed redundant, but this won't solve your problem. |
|
Is that on the old stable (new one likely coming today, depending on how busy I am tonight) or the current nightly? There have been some related changes like #14732. |
The filename is already sanitized by util.getSafeFilename(), which calls util.fixUtf8() internally.
The filename is already sanitized by util.getSafeFilename(), which calls util.fixUtf8() internally.
…names
The getLocalDownloadPath function was calling fixUtf8 with '_' replacement on the full path (directory + filename), after the filename had already been properly sanitized by getSafeFilename which calls fixUtf8 with ''.
This double processing with different replacement characters caused:
The fix removes the redundant fixUtf8 call on the full path. The filename is already properly validated by getSafeFilename, and applying fixUtf8 again on the combined path is unnecessary and harmful.
This change is