This is the mail archive of the
libc-locales@sourceware.org
mailing list for the GNU libc locales project.
Re: locale encodings
- From: Keld Simonsen <keld at keldix dot com>
- To: Troy Korjuslommi <tjk at tksoft dot com>
- Cc: Steven Abner <pheonix at zoomtown dot com>, libc-locales at sourceware dot org
- Date: Tue, 12 Nov 2013 03:22:58 +0200
- Subject: Re: locale encodings
- Authentication-results: sourceware.org; auth=none
- References: <31AACAB8-A716-47CC-B755-F33DD77BA51E at zoomtown dot com> <1384174607 dot 4028 dot 8 dot camel at uno11 dot loco>
Well, the encoding of the source coode of all locales should be 7-bit ascii, for
maximum portability. Then the target encoding should be recorded via the
% charset specification, which gives a list of possible charsets, comma separated.
UTF-8 should always be included there, but other encodings should also be available.
best regards
keld
On Mon, Nov 11, 2013 at 02:56:47PM +0200, Troy Korjuslommi wrote:
> If you mean the locale data files, they have a line such as
> "% Charset: ISO-8859-1"
> which tell you the charset.
>
> It would indeed be a good idea to tell the files' maintainers to use
> UTF-8 from now on. For now you can use iconv or uconv to convert them.
> E.g. iconv -f iso-8859-1 -t utf-8 < file > newfile
>
> Troy
>
>
>
> On Sun, 2013-11-10 at 19:03 -0500, Steven Abner wrote:
> > Hi,
> > Can you tell me what file format "cs_CZ", "sk_SK", "sv_SE" and "wo_SN" are encoded in? I was going to try
> > to fix it for my use, but can't open in a normal editor. I was doing a design test when these files tripped a non-POSIX portable character set code in my scanf()'s isspace(). I think they might be ISO8859-2 but not sure. Normal editor claims it can't be
> > open in UTF-8. I'd rather not second guess someone else's work, if I can. If it is ISO8859-2, I'll just decode/encode me a
> > UTF file to examine. Two other files have UTF8 encodings, which is no problem. Others do but weren't within scope of
> > the trap (comment character to first word after). I am only trying to verify the file parser is picking up exact data, and hopefully
> > not being corrupted by unusual codes, as some have been.
> > Thanks,
> > Steve
> > pheonix@zoomtown.com
> >
>