Re: texteditors that can process and save in different encodings

From: Asmus Freytag <asmusf_at_ix.netcom.com>
Date: Tue, 09 Oct 2012 23:33:08 -0700

On 10/9/2012 10:47 PM, Stephan Stiller wrote:
>
>> You very nearly never know which version of a character set a sender
>> or receiver uses or requires, and even for documents, the best you
>> can tell is which version(s) (plural) of a given character set a text
>> can be encoded in. You can't tell whether any edits to a document
>> that would require one of the newer versions would still be
>> acceptable or not to the originator.
>
> Yep. (I wasn't meaning to encourage use of older versions for outgoing
> communication.) – The use case I have in mind is a passive one: having
> an easy way, in a few clicks, to fix a text that looks slightly odd
> without me having to do the work of researching older versions of
> codepages myself.
>

This is an issue only where older versions of a character set have
different character arrangement, rather than new characters fitting
existing holes. It's an issue also for certain closely related character
sets, for example ISO/IEC 8859-1 and ISO/IEC 8859-15. In these cases,
about the only method that works is to have tool that gives you a
preview (and perhaps also a spell-checker for the correct language).
With such tools you can zero in on code conversion problems and try
related character sets. (If the choices were presented not in a
drop-down list, but as "neighborhoods" of related character sets, your
task would be even easier.

But realistically, who's going to go to that kind of trouble? From what
someone posted earlier, it seems Word went a good part of the way -
haven't tried that myself, but seems useful.

In the standard case, where you are reading a character set that was
extended by filling holes, using the latest tables for conversion should
do the trick.

A./
Received on Wed Oct 10 2012 - 01:35:26 CDT

This archive was generated by hypermail 2.2.0 : Wed Oct 10 2012 - 01:35:26 CDT