-
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
[Linux] Support non-utf8 locale for filename #5719
Comments
(I changed the title because there is no need to involve the server, it's purely a client issue) How to handle invalid encoding?: The way we currently do it in SyncEngine::treewalkFile, for example. client/src/libsync/syncengine.cpp Line 364 in e86499d
(however this has to happen at the time of conversion from the system locale, which has to happen in csync, before the reconcile phase.) |
Moving to 2.5 as #5676 was moved too |
Duplicate of #5676 |
ogoffart
added a commit
that referenced
this issue
Nov 21, 2017
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
ogoffart
added a commit
that referenced
this issue
Nov 23, 2017
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
ckamm
added a commit
that referenced
this issue
Jan 10, 2018
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
ckamm
added a commit
that referenced
this issue
Jan 10, 2018
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
ckamm
added a commit
that referenced
this issue
Jan 10, 2018
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
FYI @ogoffart @DeepDiver1975
Related #5676
[Feature] Filename encoding with gbk standard should be supported
Challenges: How to handle invalid encodings?
#4811 (comment)
The text was updated successfully, but these errors were encountered: