Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug with UTF-8 encoding on labels and AutoTools #2520

Open
4 tasks done
phene opened this issue Jun 12, 2023 · 5 comments
Open
4 tasks done

Bug with UTF-8 encoding on labels and AutoTools #2520

phene opened this issue Jun 12, 2023 · 5 comments
Labels
bug need feedback Waiting for additional information. v4.1 wontfix

Comments

@phene
Copy link

phene commented Jun 12, 2023

Please complete the following tasks.

  • Web browser cache cleared
  • Link provided to install script if applicable
  • Not using broken rtinst install script
  • Web browser, ruTorrent, PHP and OS version provided

Tell us about your environment

Web Browser: Firefox 113.0.2 (64-bit) (also occurs in Chrome)
ruTorrent - v4.0-stable
PHP: PHP 8.1.7
OS: Ubuntu 22.10

Tell us how you installed ruTorrent

not relevent

Describe the bug

Re-using an existing label with UTF-8 characters causes the string to be re-encoded incorrectly. This combined with AutoTools causes the folder that the data is written into to change.

Steps to reproduce

  1. Configure AutoTools to move files into a folder based on the label name
  2. Add torrent and assign the label 엄마.
  3. Observe that the file is saved into a folder called 엄마
 "엄마".bytes
 => [236, 151, 132, 235, 167, 136]
  1. Add a new torrent and assign the existing 엄마 label to it.
  2. Observe that the new file is saved into a folder called 엄마, with the following bytes.
"엄마".bytes
 => [225, 132, 139, 225, 133, 165, 225, 134, 183, 225, 132, 134, 225, 133, 161]
  1. Observe that the formatting of the Korean characters is not correct.
    bad-korean

Note: the oddly encoded string does not survive copy-paste into the browser, but does in and out of a terminal.

Expected behavior

I would expect the string for the label to stay the same in order to consistently put the content in the same folder.

Additional context

No response

@stickz
Copy link
Collaborator

stickz commented Jun 12, 2023

Is this bug reproduceable on version 4.1.6? There were some changes made to labels in version 4.1.

As a side note, the latest v4.1.6 branch release is significantly more stable than v4.0. It's undesirable to still be using v4.0.

@phene
Copy link
Author

phene commented Jun 13, 2023

I've reproduced this in 4.1.6.

@stickz
Copy link
Collaborator

stickz commented Jun 13, 2023

It looks like the UTF-8 encoding is being lost. I will implement a new utility function to convert back to UTF-8. Target is v4.2.

    function url_encode($string){
        return rawurlencode(mb_convert_encoding($string, "UTF-8", "auto"));
    }
    
    function url_decode($string){
        return mb_convert_encoding(rawurldecode($string), "UTF-8", "auto"));
    }

stickz added a commit that referenced this issue Aug 7, 2023
@stickz
Copy link
Collaborator

stickz commented Aug 11, 2023

I've reproduced this in 4.1.6.

Are you able to reproduce this bug in v4.2.2? The autotools plugin converts to UTF-8 now, when encoding and decoding URLs.

@stickz stickz added bug v4.1 need feedback Waiting for additional information. labels Aug 12, 2023
Copy link

stale bot commented Mar 17, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Mar 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug need feedback Waiting for additional information. v4.1 wontfix
Projects
None yet
Development

No branches or pull requests

2 participants