-
Notifications
You must be signed in to change notification settings - Fork 669
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
[Feature] Filename encoding with gbk standard should be supported #5676
Comments
We are currently preparing 2.3.1 packages with QT5.6 as new Linux packages, those will be worth a try first and then we might be able to look into this. |
I heard from the other engineers that we only support UTF-8 on the client side, sorry. |
Ok, that's fine. Though I'm still hoping it'll support all file name encoding. Because with it, life will be more easy. |
Lets keep it as a feature request, but if not heavily requested from Chinese users this will not be implemented. If you could add some reasoning in regards of the use case and benefits rather then using UTF-8 only this would also be appreicated. |
My wife (who is Chinese) says:
|
Yes, in China, most of Chinese computer users use GBK encoding in Windows, even Linux. |
@ericlin1001 Do you want to try this using a 2.4 nightly build? |
https://central.owncloud.org/t/desktop-client-2-4-0-alpha1-released/9837 @ericlin1001 Alpha1 released. Could you check? |
@ericlin1001 ping |
@guruz @ogoffart I've tested with the example from the first post and it still doesn't work. The client attempts to convert the gbk characters to utf8 and fails, showing a "Filename encoding is not valid" error. That's done in EDIT: Oh, 'codecForLocale' is used in the conversion to unicode in csync? I'll try again with a different locale then. |
Moved to 2.5 |
@ckamm, but what's your file system encoding, and the environment variable that specify the encoding (LC_ALL/LC_CTYPE/LANG)? |
@ogoffart I agree, it's just that none of the env variables I tried had an effect on the system locale. So what I report is a failure of testing and not indicative of a bug on its own. |
I tested:
(en_US is specified in my /etc/locale.gen as en_US ISO-8859-1) However the bug i noticed is that if the server contains filename that cannot be encoded in the user's locale, Qt uses replacement character instead ('?'). And next sync rename the file with the replacement character. |
This is mainly for linux, whose local is not UTF-8. For example, in latin1, it is not possible to encode emoji or chinese character. If there are such character in the filename, Qt would just save the file using the replacement character ('?'). Then, on the next sync, client would rename the files using this replacement character. Avoid this by ignoring the files which cannot be downloaded because the filename cannot be represented with the user's locale Relates to issue #5676 and #5719
This is mainly for linux, whose local is not UTF-8. For example, in latin1, it is not possible to encode emoji or chinese character. If there are such character in the filename, Qt would just save the file using the replacement character ('?'). Then, on the next sync, client would rename the files using this replacement character. Avoid this by ignoring the files which cannot be downloaded because the filename cannot be represented with the user's locale Relates to issue #5676 and #5719
There's an upstream bug where QTextCodec::canEncode returns true even though it should be false. This works around that issue and adds a test. The original work was done in 72809ef See #6287, #5676, #5719 See https://bugreports.qt.io/browse/QTBUG-6925
There's an upstream bug where QTextCodec::canEncode returns true even though it should be false. This works around that issue and adds a test. The original work was done in 72809ef See #6287, #5676, #5719 See https://bugreports.qt.io/browse/QTBUG-6925
There's an upstream bug where QTextCodec::canEncode returns true even though it should be false. This works around that issue and adds a test. The original work was done in 72809ef See #6287, #5676, #5719 See https://bugreports.qt.io/browse/QTBUG-6925
2.5.0 beta1 is out :-) |
Mint Tara (aka Ubuntu 18.04)testpilotcloud version 2.5.0daily20180801 (build 9974) touch 乱码.txt This feature does not seem to be ready for 2.5.0 release. @ckamm I understand the expected outcome should be: file ignored. My personal opinion (aka server enhancement idea): filenames should be opaque byte streams for us. Whatever bytes a user puts into owncloud, should store that and bring it back unchanged. Interpreting encoding of a filename is a problem of the representation layer, not of the transport layer. |
@jnweiger Could you open or link to an issue in core and elaborate on your idea? |
@jnweiger that's because your locale is still UTF-8. So it is expected that when a filename is not in UTF-8, we show one error for this file. (but we still continue to sync the other files)
That's not really possible as you need to display the filename in the web interface from HTML whose encoding is UTF-8. And since you need to sync, you need to compare the filename for equality. So we need to understand what it is. And we can't sync invalid filename. |
Client observing the local locale is actually cool! So correct behaviour there! Mint Tara (aka Ubuntu 18.04)locale LC_ALL=de_DE.UTF-8 LC_CTYPE= LANG=C LC_ALL=C LANGUAGE=C testpilotcloud & touch xxx.txt; sleep 10 # sufficient sleep so that it syncs
Client Error log:
BUT: the file gets renamed on the server.
OK: BUT:
|
@ogoffart Regarding byte-streams. |
The behaviour seen in #5676 (comment) is as expected. Closing. |
Steps to reproduce
touch 乱码.txt
convmv -f utf-8 -t gbk 乱码.txt
Expected behaviour
Tell us what should happen
The file with name encoding in gbk, should be synced. Because I'm converting file name encoding of a large amount of files in linux, and these files are to be used in windows(win7).
Actual behaviour
Tell us what happens instead
Server configuration
Operating system:
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
Web server:
Database:
PHP version:
ownCloud version: (see ownCloud admin page)
Updated from an older ownCloud or fresh install:
Where did you install ownCloud from:
Signing status (ownCloud 9.0 and above):
List of activated apps:
The content of config/config.php:
Are you using external storage, if yes which one: local/smb/sftp/...
Are you using encryption: yes/no
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
LDAP configuration (delete this part if not used)
Client configuration
Browser:
Operating system:
Logs
Web server error log
ownCloud log (data/owncloud.log)
Browser log
The text was updated successfully, but these errors were encountered: