Unicode is not "everywhere"...

[Mark Waddingham]

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