I've got a CL filter I'm using to process news postings (this very
post ran through it); I am running into the following problem:
> (processnews)
Process file:C:\HOME\NEWS\drafts\drafts\5
Output location: C:\HOME\movehome\news\x3182784084.5
*** - invalid byte #x81 in CHARSET:ISO-8859-1 conversion
1. Break NEWS[2]> where
EVAL frame for form (READ-LINE INS NIL 'EOF)
By looking at a backtrace, I can see that what it's "freaking at" is
that it's reading a line with a name that contains a "funny
international accent," which presumably isn't fitting well into
ISO-8859-1.
Relevant code fragment:
(with-open-file (inp-stream input-file)
(format outs "From: ········@hex.net~%")
(format outs "Reply-to: ········@hex.net~%")
(do ((line (read-line inp-stream)
(read-line inp-stream nil 'eof)))
((eq line 'eof) "Reached end of file.")
(rewrite-line line outs)))
Now, I had been _thinking_ that all this readtable stuff that has been
causing such bluster was pretty irrelevant to me, and that I could,
for the time being, just ignore it from a practical perspective.
It now seems otherwise; it seems as if I need to attach some sort of
readtable information _somewhere_; I'm not quite clear on where.
--
(concatenate 'string "cbbrowne" ·@hex.net")
<http://www.ntlug.org/~cbbrowne/>
Economists are still trying to figure out why the girls with the least
principle draw the most interest.
* Christopher Browne
| By looking at a backtrace, I can see that what it's "freaking at" is
| that it's reading a line with a name that contains a "funny
| international accent," which presumably isn't fitting well into
| ISO-8859-1.
Windows' apostrophes are usually taken from the typographic are of
Unicode and mapped into high control area (0x80-0x9F) just to screw
with people who like the ISO 8859-1 standard.
| Now, I had been _thinking_ that all this readtable stuff that has been
| causing such bluster was pretty irrelevant to me, and that I could,
| for the time being, just ignore it from a practical perspective.
It has nothing to do with readtables, ut everything to do with
external-format processing.
| It now seems otherwise; it seems as if I need to attach some sort of
| readtable information _somewhere_; I'm not quite clear on where.
See your system documentation on the available and default external-
format settings to open (and friends).
#:Erik
--
Al-Gore-ism: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.
See also algorithm.
········@hex.net wrote:
> *** - invalid byte #x81 in CHARSET:ISO-8859-1 conversion
> 1. Break NEWS[2]> where
>
> EVAL frame for form (READ-LINE INS NIL 'EOF)
>
> By looking at a backtrace, I can see that what it's "freaking at" is
> that it's reading a line with a name that contains a "funny
> international accent," which presumably isn't fitting well into
> ISO-8859-1.
Set either :EXTERNAL-FORMAT argument or LISP:*DEFAULT-FILE-ENCODING*
to (make-encoding :charset CHARSET:CP1252 :line-terminator :DOS), or
whatever is relevant in your case (no pun intended ;-).
SY, Uwe
--
···@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
········@hex.net writes:
> Relevant code fragment:
> (with-open-file (inp-stream input-file)
> (format outs "From: ········@hex.net~%")
> (format outs "Reply-to: ········@hex.net~%")
> (do ((line (read-line inp-stream)
> (read-line inp-stream nil 'eof)))
> ((eq line 'eof) "Reached end of file.")
> (rewrite-line line outs)))
>
> ... seems as if I need to attach some sort of
> readtable information _somewhere_; I'm not quite clear on where.
Readtables do not affect read-line. Your problem is not with that.