Oh, I see. I suppose this can break old scripts that expect 8 bit characters
without UTF-8 flag come through unaltered.
On Thu, Jun 4, 2009 at 9:23 AM, Gisle Aas gi...@aas.no wrote:
On Wed, Jun 3, 2009 at 23:46, Alex Kapranoff k...@nadoby.ru wrote:
It's an optimization to avoid unnecessary
On Thu, Jun 4, 2009 at 3:39 PM, Gisle Aas gi...@aas.no wrote:
On Thu, Jun 4, 2009 at 11:46, Alex Kapranoff k...@nadoby.ru wrote:
Oh, I see. I suppose this can break old scripts that expect 8 bit
characters
without UTF-8 flag come through unaltered.
They would then have to set
It's an optimization to avoid unnecessary calls to Encode.pm. It should not
affect the result.
On Thu, Jun 4, 2009 at 1:38 AM, Gisle Aas gi...@aas.no wrote:
On Mon, Jun 1, 2009 at 23:43, Alex Kapranoff k...@nadoby.ru wrote:
The patch is attached.
Thanks! I've now applied your patch. I do
On Thu, Jun 4, 2009 at 11:46, Alex Kapranoff k...@nadoby.ru wrote:
Oh, I see. I suppose this can break old scripts that expect 8 bit characters
without UTF-8 flag come through unaltered.
They would then have to set $form-accept_charset(latin-1) as a
workaround. I think that's acceptable. I
On Mon, Jun 1, 2009 at 23:43, Alex Kapranoff k...@nadoby.ru wrote:
The patch is attached.
Thanks! I've now applied your patch. I do think I would like to get
rid of the 'if utf8::is_utf8($fi)' condition on encoding values. I
don't think the semantics should depend on this. Will that break
On Wed, Jun 3, 2009 at 23:46, Alex Kapranoff k...@nadoby.ru wrote:
It's an optimization to avoid unnecessary calls to Encode.pm. It should not
affect the result.
It does affect the result for strings that only contain chars in the
latin1 range.
See
