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.
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
-
Andrey Moskvitin -
Sebastian Tennant