Date: Thu, 19 Jan 2012 08:43:14 -0900 (AKST) From: rflynn@acsalaska.net To: Fernando =?iso-8859-1?Q?Apestegu=EDa?= <fernando.apesteguia@gmail.com> Cc: freebsd-ports@freebsd.org Subject: Re: Encoding question Message-ID: <2920.46.129.107.107.1326994994.squirrel@mymail.acsalaska.net> In-Reply-To: <CAGwOe2Zy0rxpEBv0etUFdXmGBU-Bm%2BDpi-OxUpNthEkBZs6W9g@mail.gmail.com> References: <CAGwOe2Zy0rxpEBv0etUFdXmGBU-Bm%2BDpi-OxUpNthEkBZs6W9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > I'm trying to compile a C++ software on FreeBSD. While compiling, this > error shows up: > > error: stray '\357' in program > error: stray '\273' in program > error: stray '\277' in program > > This file is reported (by file[1]) to be "UTF-8 Unicode (with BOM) C > program text, with CRLF line terminators" while the rest of the files > in the package are "ASCII C program text, with CRLF line terminators". > While I can convert the file with iconv -c -f utf-8 -t ascii file > > new_file in the post extract stage, I wonder if there is a more > suitable way for achieving the same thing. Also I would like to avoid > this software from depending on iconv. You have three options: - have it fixed upstream; - post process on extract like above; - post process releases and roll your own tarball which you host yourself. Fixing upstream is by far the best solution and here's some ammunition: The Unicode Standard does permit the BOM in UTF-8, but does not require or recommend its use. Byte order has no meaning in UTF-8 so in UTF-8 the BOM serves only to identify a text stream or file as UTF-8. [1] [1] http://en.wikipedia.org/wiki/Byte_order_mark -- Mel
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2920.46.129.107.107.1326994994.squirrel>