[hunchentoot-devel] UTF-8 encoding problems
Hi all, CL-USER> (hunchentoot-asd:*hunchentoot-version*) "1.1.0" With: (setq tbnl:*default-content-type* "text/html; charset=utf-8") called once when TBNL is initialised, Turkish characters provided in Lisp source files are sent to the client without a problem, but Turkish characters that come from a UTF-8 database via Postmodern cause the following error: Error while processing connection: #\LATIN_SMALL_LETTER_DOTLESS_I (code 305) is not a LATIN-1 character. before they can be sent to the client. Why does TBNL expect LATIN-1 characters in one context but not in another? Incidentally, I experience the same 'not a LATIN-1 character' error when I evaluate Lisp files via SLIME, but not when the files are load'ed. Putting: (setf (content-type*) "text/html; charset=utf-8") in the handler makes no difference. What else can I try? Seb P.S. Turkish characters in the results of Postmodern queries performed directly in the REPL are displayed (in SLIME) correctly. -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
What else can I try?
(setf hunchentoot:*hunchentoot-default-external-format* hunchentoot::+utf-8+) Andrey 2010/4/13 Sebastian Tennant <sebyte@smolny.plus.com>
Hi all,
CL-USER> (hunchentoot-asd:*hunchentoot-version*) "1.1.0"
With:
(setq tbnl:*default-content-type* "text/html; charset=utf-8")
called once when TBNL is initialised, Turkish characters provided in Lisp source files are sent to the client without a problem, but Turkish characters that come from a UTF-8 database via Postmodern cause the following error:
Error while processing connection: #\LATIN_SMALL_LETTER_DOTLESS_I (code 305) is not a LATIN-1 character.
before they can be sent to the client.
Why does TBNL expect LATIN-1 characters in one context but not in another?
Incidentally, I experience the same 'not a LATIN-1 character' error when I evaluate Lisp files via SLIME, but not when the files are load'ed.
Putting:
(setf (content-type*) "text/html; charset=utf-8")
in the handler makes no difference.
What else can I try?
Seb
P.S. Turkish characters in the results of Postmodern queries performed directly in the REPL are displayed (in SLIME) correctly.
-- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
_______________________________________________ tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Quoth Andrey Moskvitin <archimag@gmail.com>:
(setf hunchentoot:*hunchentoot-default-external-format* hunchentoot::+utf-8+)
Damn! This time it is making a difference :) Thanks. I tried setting this variable (without success) when I wrote to this list about the evaluation-versus-load'ing oddity a while back: http://thread.gmane.org/gmane.lisp.lib.tbnl.general/2523 I was also told: "As explained in the documentation, the special variable *HUNCHENTOOT-DEFAULT-EXTERNAL-FORMAT* is used when computing the /request/ object. As you said, it doesn't have an effect on the reply." Hence I didn't try it again this time round. If it's only used to compute the request object, why is it now helping with (some of) my UTF-8 replies? Seb -- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
participants (2)
-
Andrey Moskvitin -
Sebastian Tennant