Unicode is not "everywhere"...
Mark Waddingham
mark at livecode.com
Tue Aug 27 08:11:43 EDT 2019
On 2019-08-22 21:07, Paul Dupuis via use-livecode wrote:
> I reported what I thought was 3 bugs in 1 report in
> https://quality.livecode.com/show_bug.cgi?id=22213. I have edited that
> report to focus on a single bug - that the detailed files (and
> probably the detailed folders) is broken for Unicode as every Unicode
> character in a file name is encoded as %3F or ?. Originally I had
> though that meant that there was a problem with urlEncode and
> urlDecode as per bug
> https://quality.livecode.com/show_bug.cgi?id=14015 that your
> references Monte. However, I now consider that urlEncode and urlDecode
> are NOT broken and bug 14015 is really a Documentation bug that the
> urlEncode and urlDecode Dictionary entries should be updated.
> Also, the detailed files and detailed folders doesn't need an array
> returned (although that would be nice). This issue is the
> percent-encoding is not following the standard convention of UTF8
> encoding non-ASCII characters before percent encoding. LC should
> follow industry conventions in this regard.
Strictly speaking urlEncode and urlDecode are indeed not broken - they
are just very old. They were implemented when there were no universally
accepted industry conventions for encoding of URLs (particularly those
containing international characters).
They cannot be changed for obvious reasons - but we could do with
urlEncodeRFC and urlDecodeRFC which would be string->string functions
which do what is expected today. (And also not encode some characters in
a way which is now not the 'standard du jour').
For the same reason that urlEncode and urlDecode cannot be changed, the
detailed files/folders cannot be changed.
My general feeling here is that 'the detailed files' and 'the detailed
folders' should be put out to pasture as they are grossly inefficient
and difficult to work with.
Instead new functions 'fileInfo' and 'folderInfo' could replace them.
They would take one or two parameters, the first a filename and the
second an optional attribute.
If no attribute is specified then an array of all known attributes for
the platform is returned; otherwise that specific attribute is returned.
e.g. fileInfo("foo.txt", "modification time") -> returns the
modification time of foo.txt
fileInfo("foo.txt") -> returns an array with keys such as
"modification time" mapping to the obvious thing
I'd probably vote for the functions returning empty if the target didn't
exist (rather than throwing an error), for the simple reason as you
can't check for existence of a file and get its details in an atomic
fashion (another process could decide to delete the file you just
asserted existed between the 'there exists' and the 'fileInfo' call).
Warmest Regards,
Mark.
--
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the use-livecode
mailing list