On 24/08/19 2:36 AM, Hongyi Zhao wrote:
Hi,
The following is a gedit plugin which provides a way to copy the current
file path to the clipboard.
https://github.com/willianveiga/gedit-copy-file-path/blob/master/
copyfilepath.py
But, I try and find that it doesn't support the path/file names including
chinese characters.
In this case, it will give messy code like this:
dnsmasq/archive/dnsmasq-全功�
How to fix it?
Does "it will give" mean:
- this is what is returned from the gtk clipboard, or
- this is the fileNM which appears in an errmsg?
Please copy-paste the calling code, source data fileNM, and resulting
errmsgs/output.
NB I only took the quickest look at the code.
A first thought is that this code may have originated in Python2 days.
In which case there may be pertinent differences between how things were
done 'then' (ASCII byte-characters) and how they are done now (Unicode
characters). Also, in the Python3 world, many file/pathNM libraries will
respond (slightly differently) depending upon whether their input is in
(Unicode) characters or bytes.
Is it worth experimenting by throwing some test-data at the object?
- fileNM as Unicode string
- fileNM as bytes
- fileNM in (narrow) ASCII
- fileNM including Kanji (or...)
How does it react differently.
A second issue is that whilst Python negotiated a clear-cut difference
between Unicode and 'the ?bad, old days'; OpSys and file systems do/did
not! (Hence the first question, above) I have run into trouble with
(European language) non-ASCII characters originating on a MSFT platform
not being properly accepted by 'modern' Python file/path libraries
(under Linux - although the OpSys likely doesn't matter). The fileNMs
become mangled during the decode() step - to the point of no-repair.
In debugging this issue, recommend separating what the clip-board is/not
handling, and what the file system might be mangling, ie locate the
ACTUAL point of error and separate that from later consequences!
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
