Only supporting UTF-8 is still strange but I understand why Daniel said so now. After these two line appending, most of my problem on http-get was solved:
(set-port-encoding! (current-output-port) "UTF-8") (fluid-set! %default-port-encoding "UTF-8") This is like a magic!! I think it's better to append this information to Guile manual page. My first problem was not displaying contents body of web page. Second was not calling html->sxml of guile-lib. After reading htmlparg.scm, I realized html->sxml will call htmlprag-internal:parse-html and htmlprag-internal:parse-html use the string-port. I remembered this sentense; "When string ports are created, they do not inherit a character encoding from the current locale." Most people would not realize utility like html->sxml how to implemented and you need to use fluid-set! . 2012/4/29 Eli Zaretskii <e...@gnu.org> > > Date: Sat, 28 Apr 2012 20:29:22 +0200 > > From: Daniel Krueger <keen...@googlemail.com> > > Cc: guile-user@gnu.org, Sunjoong Lee <sunjo...@gmail.com> > > > > i think there shouldn't be any transcoding of guile's strings, as > > strings are internal representation of characters, no matter how they > > are encoded. So the only time when encoding matters is when it passes > > it's `internal boundarys', i mean if you write the string to a port or > > read from a port or pass it as a string to a foreign library. For the > > ports all transcoding is available, and as said, the real > > representation of guile strings internally is as utf8, which can't be > > changed. The only additional thing i forgot about are bytevectors, if > > you convert a string to an explicit representation, but afaik there > > you also can give the encoding to use. > > > > Am I wrong? > > You are mostly right, but only "mostly". Experience teaches that > sometimes you need to change encoding even inside "the boundaries". > One notable example is when the original encoding was determined > incorrectly, and the application wants to "re-decode" the string, when > its external origin is no longer available. Another example is an > application that wants to convert an encoded string into base-64 (or > similar) form -- you'll need to encode the string internally first. > > These kinds of rare, but still important, use cases are the reason why > Emacs Lisp has primitives to do encoding and decoding of in-memory > strings; as much as Emacs maintainers want to get rid of the related > need to support "unibyte strings", they are not going to go away any > time soon. > > IOW, Guile needs a way to represent a string encoded in something > other than UTF-8, and convert between UTF-8 and other encodings. >
