Monte Goulding wrote:
>> On 13 Feb 2018, at 11:56 am, Richard Gaskin wrote:
>> something more sensible
>
> We already have:
>
> open file for “utf-8” text
>
> There was some discussion of implementing “file+:/path
> /to/file” style urls to avoid having to use binfile and textDecode
> and manual
ICU has character set detection. Looks like it wouldn’t be that hard to add a
function to return either the best match or an array of encoding -> confidence.
Perhaps dd an enhancement request if there isn’t one already.
Cheers
Monte
> On 13 Feb 2018, at 1:04 pm, Paul Dupuis via use-livecode
On 2/12/2018 8:49 PM, Monte Goulding via use-livecode wrote:
>
>> On 13 Feb 2018, at 11:56 am, Richard Gaskin via use-livecode
>> wrote:
>>
>> something more sensible
> We already have:
>
> open file for “utf-8” text
>
> There was some discussion of implementing
> On 13 Feb 2018, at 11:56 am, Richard Gaskin via use-livecode
> wrote:
>
> something more sensible
We already have:
open file for “utf-8” text
There was some discussion of implementing “file+:/path/to/file” style
urls to avoid having to use binfile and
Given the nearly-universal use of UTF-8, it would seem ideal for a
language focusing on ease of use if that could be made a default.
I can understand why we can't use "open tFile for text..." given the
legacy, but maybe something like "open tFile for modernText..." or
something more sensible.
No, nothing has changed. The Dictionary entry for textEncode and
textDecode still contains this note:
It is highly recommended that any time you interface with things
outside LiveCode (files, network sockets, processes, etc) that you
explicitly textEncode any text you send outside LiveCode and
If you know it *is* utf-8 then (in LC 8/9) it "just works" whether put into
a variable or directly into a field.
But you have to be aware when working with the variable that you have to
use codepoint for conversions for "foreign chars" (e.g. using diacritics).
> Malte P-B. wrote:
> Hi, I am a