[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gnu-libiconv] EBCDIC support
From: |
Bruno Haible |
Subject: |
Re: [bug-gnu-libiconv] EBCDIC support |
Date: |
Mon, 24 Jan 2022 02:19:22 +0100 |
Calvin Buckley wrote:
> > EBCDIC is supported in this fork of gnu libiconv by Calvin Buckley.
> > In some form it would be good to merge as a contribution to the main
> > tree.
> > https://github.com/NattyNarwhal/libiconv-ebcdic/
>
> The fork is based on Ulrich Schwab's (which seems to have been
> removed?), but I just updated it for newer libiconv.
Well, since apparently several people really want these encodings supported
(something that I couldn't imagine when I wrote GNU libiconv), I added
these encodings now. More precisely only those
- which are 8-bit encodings (CJK encodings are a lot of manual work,
let's hope no one needs this),
- for which the conversion tables from different parties (z/OS, Windows,
glibc) reasonably agree.
https://git.savannah.gnu.org/gitweb/?p=libiconv.git;a=commit;h=68ac8a9f73e4c7238402a3557e6c08bfeaaf701a
> One of the big annoyances about it is it's not comprehensive with
> supported EBCDIC codepages, but most are basically equivalent (i.e.
> 1140 is basically the same as 37 for the purposes of most users).
Not "most users", but "most users in the U.S.".
Users outside the US *do* need the non-ASCII characters and heavily
depend on them. That's why iconv() is so essential in applications
that are not yet fully Unicode-based.
Bruno