Re: [Discussion] Should All String Functions Become Multi-Byte Safe?

2024年8月17日(土) 9:17 Mike Schinkel <mike@newclarity.net>: > > > On Aug 16, 2024, at 8:02 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > > On 17 August 2024 00:25:13 BST, Mike Schinkel <mike@newclarity.net> wrote: > >> I am not sure I agree with you that adding Unicode support is the wrong angle, per se. > >> > >> A strong argument could be made that Unicode support is a necessary but not sufficient > >> building block for "internationalization support." IOW, if you want to get to the latter > >> it is probably a lot easier to start with the former as the scope of the latter is by-nature larger. > >> After all, perfect is the enemy of the good and waiting for a full-press effort for > >> internationalization support could well push off Unicode support long down the road.. > > > > Again, that's not really what I intended to say, but I'm probably not expressing > > myself clearly. > > > > I was thinking about the way we frame the conversation, the words we focus on, and how > > that shapes the conversation. > > > > The example that keeps coming to mind is password_hash/password_verify. It seems to me > > that for years, the conversation was framed around "cryptographically safe hashing > > functions", and teaching users why and how to use powerful but confusing functions like hash() > > and crypt(). Then it got reframed from the point of view of a web developer wanting to implement > > logins, and we ended up with fantastically easy to use functions. > > > > In the same way, I think "Unicode support" should be the awkward background work > > that we do *because we're trying to solve specific problems involving text*. > > > > In the case of this thread, I think the actual user story is "I want to allow users > > to enter a wide range of characters, but restrict them in contextually appropriate ways to ensure > > various types of safety and security". The implementation of that involves a lot of > > technicalities about how Unicode works, but ideally we want to find meaningful abstractions of those > > technicalities, not just require every user to understand them. > > We are in no real disagreement there. > > -Mike > > P.S. I do think we could reach the same end-goal by taking either direction since Unicode > support is a building block of solving specific problems involving text, and thus needs to happen > either way. > > But, as I implied earlier, whichever road takes us there works for me so no need for me to > further bikeshed it, as long as the road we take will not result in a dead-end. Hi, internals I added grapheme_str_split in PHP 8.4. I added this because I thought the function of grapheme function was missing. I think grapheme functions is still lacks functionality. I would like to add grapheme function. PHP's Unicode support is still not sufficient. I would like to strengthen PHP's Unicode support. After a while, I have plans I would like add RFC for Unicode functions. Regards Yuya -- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------