Hi,
On Aug 23, 2005, at 7:30 PM, Makoto Tozawa wrote:
"HTTP Input Encoding
...
If the HTTP request contains the encoding specification in the headers,
then it will be used instead of this setting."
With my best knowledge there isn't such http request header which
specifies the encoding of the request. In case the intent is to honor
the ACCEPT-CHARSET, it may cause a problem because browsers don't
gurantee the encoding in the ACCEPT-CHARSET is same as the encoding
used to escape characters in the URL query string. After all, the
ACCEPT-CHARSET is to specify the character encodings acceptable for
the response.
I took a closer look at this today and RFC 2616 does not specify
whether user agents are supposed to send a charset parameter in the
Content-Type header of the POST request. I did not see any of my
browsers doing so. I think we can safely disregard this and rely on
http_input_encoding and output_encoding settings. We are not going to
use Accept-Charset for the reasons you mention.
Is there any way to keep the byte semantics (in oppose to unicode
semantics)
only for the existing functions? For example, the Oracle 8 functions
can be
configured to use utf-8 for the character encoding of strings. In
order for
them to work properly, fundamental functions, which Oracle 8 function
call,
have to behave in byte samentics. And if they work properly when the
unicode
semantics switch is turned on, by setting the runtime_encoding to
utf-8,
they can be called by uncode applications.
I couldn't parse this on the first try. Could you restate this?
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
