Re: texteditors that can process and save in different encodings

Metadata that is separate from the data has a way of being disassociated
from it. Annoying, but a fact of life. This can be as simple as file
creation dates not being preserved on copy.

Metadata that is contained in the same file as the data, has a way of
being incorrect. Look no further than HTML language tags or charset
declarations.

Then there is metadata that can be easily reconstituted from the data,
like file sizes, hash signatures or preview images (in many cases). They
are "meta" data only as a mater of convenience, since they don't add
information.

Unless there's a way to rebuild the metadata unambiguously or to enforce
that it is complete and correct, it's very hard to rely on it for any
particular purpose.

That issue isn't limited to a any particular vendor (whether major or
not), it's really in the nature of the beast.

A./

On 10/20/2012 2:39 PM, Doug Ewell wrote:
> When a Major Software Company, which sells the Well-Known Operating
> System that I and a few other people use and develop for, decides to
> add character-encoding metadata to the file system of that OS, and
> when versions of that file system that support encoding metadata are
> widespread enough that I no longer need to target my apps to previous
> versions, then I too will consider encoding detection to be a thing of
> the past.
>
> --
> Doug Ewell | Thornton, Colorado, USA
> http://www.ewellic.org | @DougEwell ­
>
>
> -----Original Message----- From: Philippe Verdy
> Sent: Friday, October 19, 2012 16:45
> To: Doug Ewell
> Cc: Stephan Stiller ; unicode_at_unicode.org
> Subject: Re: texteditors that can process and save in different encodings
>
> . I'm a strong supporter of
> separately stored metadata. It is always possible in all filesystems,
> even if this requires a convention for organizing the content of that
> filesystem.
>
Received on Sat Oct 20 2012 - 21:14:06 CDT