Opened 17 years ago
Last modified 6 years ago
#4432 closed defect
Filenames in Zip-Downloads corrupted — at Version 5
| Reported by: | Owned by: | Christian Boos | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | version control/browser | Version: | 0.10.2 |
| Severity: | minor | Keywords: | preferences, zip |
| Cc: | Thijs Triemstra | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description (last modified by )
Filenames in Zip-Downloads of whole directories are corrupted when they contain any special chars (like german umlaute). For example ü is replaced by ++.
Change History (5)
comment:1 by , 17 years ago
comment:3 by , 17 years ago
Rather as an user preference then, as this corresponds to the client tool used, not to something that can be known from the server side.
comment:4 by , 17 years ago
Well, I think this could be a server config. Because in your project so sould define your filename conventions. and these conventions than match your server config. Or even as an default for the client-option, beacause many users would not know which filenameencoding to use.
comment:5 by , 17 years ago
| Description: | modified (diff) |
|---|---|
| Keywords: | preferences added |
| Milestone: | → 0.11 |
| Severity: | normal → minor |
| Summary: | Filenames in Zip-Downloads coruppted → Filenames in Zip-Downloads corrupted |
It's not a matter of conventions, it's a matter of what filesystem you're using on your computer, and what Zip tools you're using. See r3096.
E.g. I think that on Macintosh, a popular Zip tool expects UTF-8 encoded filenames.
But yes, we could try to pick up some "sane" default if the user preference is not set, e.g. the same as the configured default charset for the repository.
Well, the filename is currently saved as an UTF-8 string, which is not supported by all Zip tools. Last time I've checked, other choices were even worse/less portable.
What would you suggest?