Thank you Jeff for the suggestion
the PHP implementation looks more elaborate and complete, supporting
more
than a single encoding and several ways to perform the translation.
I think this justifies the adoption of rather general terms for
their commands. We may choose a lower profile adding the basic initial
implementation and keeping the door open for other encodings
(adding ISO-8859-1 should be trivial). The command could be
::rivet::encode <string> ?-encoding <encoding-name>?
::rivet::decode <string> ?-encoding <encoding-name>?
we have to make clear in the docs that current implementation supports
only UTF-8. There is still something that keeps me from adopting this
name wholeheartedly.
-- Massimo
On 21.03.2012 19:38, Jeff Lawson wrote:
Although PHP is not necessarily the best thing to emulate, it does
have the benefit of having a large established userbase and new Rivet
users might have familiarity with its name choices.
htmlentities -- http://php.net/htmlentities
html_entity_decode -- http://php.net/html_entity_decode
These two are basically the equivalents of Rivet's escape_string and
unescape_string:
urlencode -- http://php.net/urlencode
urldecode -- http://php.net/urldecode
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
