On Tue, 07 Jan 2003, Moriyoshi Koizumi wrote:
moriyoshi Mon Jan 6 19:03:26 2003 EDT
Modified files:
/php4/ext/standardfilters.c
Log:
Implemented string.base64 stream filter
@- Implemented string.base64 stream filter. (Moriyoshi)
Couldn't you
Hi,
On Tue, Jan 07, 2003 at 12:12:15PM -0800, Sara Golemon wrote:
Speaking of filter string.base64 I have an issue with its parity.
string.base64 will encode on write and decode on read... What if the user
wants the other way round? Is the expected behavior even obvious from the
name
With the current model, the concept is that you can use either the
filter name or filter parameters to distinguish the ultimate behaviour.
Yes this is a possible headache.
I am thinking that two separate chains of filters (one for reading and
one for writing) might make this situation a little
oooh yes, good point:
stream_filter_append($fp, string.base64, encode);
and
stream_filter_append($fp, string.base64, decode);
probably with encode being the default behavior. That make
implementation very simple and in fact the toupper/tolower calls should be
similarly combined into a single
Couldn't you have used parts of ext/standard/base64.c here instead of
duplicating code?
At first I thought of using php_base64_encode() and php_base64_decode()
rather than reimplementing them. But because those functions are
designed to be used in string semantics while streams require a
