Most tools UTF-8 encode their filenames (which still isn't always enough to avoid problems).
Windows find file encoding code#
Even between Windows machines, using different codepages doesn't work out well, but non-Windows machines have no concept of those code pages to begin with. That's not necessarily wrong for an internal use where the encoding is fixed and known in advance, although the format specification says that names are supposed to be either UTF-8 or cp437 and yours are neither.
Is there something wrong with the way the file was compressed, or is it just an incompatibility of ZIP implementations? Or even misfeature/bug of the Linux ZIP utilities? The file you've been given was not created portably. The encoding won't be right either way, but we can fix that below. That is probably the effect you got from GNOME's tool already. Unzip -UU should work from the command line to create files with the correct bytes in their names (by disabling all Unicode support). 7z has some understanding of encodings, but I believe it has to be an encoding your system knows about more generally (you pick it by setting the LANG environment variable) and Windows codepages likely aren't among those. Is there another decompression utility that will decompress my files with the correct names? I'm not aware of a zip utility that supports these code pages natively.
It sounds like the filenames are encoded in one of Windows' proprietary codepages ( CP862, 1255, etc).
0 kommentar(er)
