Re: Unicode progress [Was: unicode.semantics adinfinitum]
| From: | Johannes Schlüter | Date: | Sat, 24 May 2008 20:11:00 +0000 |
| Subject: | Re: Unicode progress [Was: unicode.semantics adinfinitum] | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-37853@lists.php.net to get a copy of this message | ||
Steph,
On Sat, 2008-05-24 at 20:37 +0100, Steph Fox wrote:
> Heya Johannes,
>
> > For some functions taking binary strings is critical for working nicely
> > with an automatic conversion in this case
> > crc32(u"äöü")
> > and
> > crc32(b"äöü")
> > would give completely different results depending on the runtime
> > encoding,
>
> Yes - but why should the user have to do the casting? Why can't the function
> itself cast to binary when it has an 'S' modifier? Like, during
> zend_parse_parameters() for example? Whatever happened to keeping PHP
> simple?
Since only the users knows the correct encoding. The function might
fallback to unicode.runtime_encoding which can be wrong. And it's hard
to track the reason.
> relying on a implicit conversion there is most likely a bug
> > (at least for apps written with PHP 6 in mind).
> >
> > Oh and I might probably also argue that
> > crc32(u"äöü")
> > should give the crc32 of the internal representation (utf-16...) of the
> > string, which is a total wtf for the user then.
>
> Nobody's asking to be able to cast it to unicode. I'm asking whether it's
> entirely necessary to force users to cast to binary all over the place, and
> a strict binary parameter spec looks like being one place where the cast
> could be done internally.
In this case there's no cast but the most simple implementation of
crc32() on a unicode string.
> > The correct solution is to make safe use of the "S" modifier and not
> > using it too much.
> >
> > As binary casts are allowed in modern PHP versions I don't see this as
> > an issue, while such a cast isn't absolutely the best thing to do: I'd
> > go with unicode_encode() to be sure about the encoding being used,
> > everything else is prone to fail some time (some code changing
> > unicode.runtime_encoding for some random reason...)
>
> You're telling me an explicit cast to binary could fail internally but not
> externally? That doesn't make a lot of sense somehow.
Externally the user is responsible to select the proper encoding
internally PHP has to guess.
johannes