Forum OpenACS Q&A: Bboard mutltibyte topic failure

Collapse
Posted by Kenny Chiang on

I created a bboard thru admin pages and successfully save a Chinese Big5 topic in bboard_topics.topic column. Then I ran admin-home.tcl to change the options and post the form. The topic got screwed up with gabage charaters.

I already patched the aolserver and openacs to support multibyte functions and were fine with most of other modules. Does anyone have any hints of what could be wrong ?

Collapse
Posted by Kenny Chiang on

Found the problem.

In bboard module (and serveral other modules indeed), it uses [ns_conn form] to pass the ns_set variables to util_prepare_xxx (update, insert) to prepare the sql string instead of [ns_getform] which will do the proper charset encoding conversion.

My solution, for now, is just replace what ever [ns_conn form] to [ns_getform] and preceded it with a ns_setformencoding "big5", e.g. :

ns_setformencoding "big5"
set sql [util_prepare_update $db bboard_topics "topic_id" $topic_id [ns_getform]]

Does anyone have any better solutions ?

Collapse
Posted by Henry Minsky on
That is correct -- ns_getform should always be used instead of ns_conn form. ACS 4 has this done consistently. In my patches for i18n we decided to
make ns_getform be the place that you get to declare what encoding
the posted data was in. The implementation of ns_getform takes
an optional encoding arg, and defaults to the site wide default set
in your config file ("urlcharset"). You even get a chance
to call ns_getform again with a different encoding, in case you
guessed wrong for some reason.

Ideally, for Japanese, we need to link
in a heuristic routine into aolserver to guess the charset, in case it is one of
the several that are in use commonly (SJIS, EUC, ISO-2022). Other asian
languages may need this feature as well, if there are several
common encodings in wide use.