Re: [Discussion] Introducing str_mask() for partial string masking

From: Date: Thu, 18 Jun 2026 21:44:06 +0000
Subject: Re: [Discussion] Introducing str_mask() for partial string masking
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-131392@lists.php.net to get a copy of this message
2026年6月19日(金) 2:07 Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>: > > On 18 June 2026 17:13:59 BST, "سپهر محمودی" <sepehrphpr@gmail.com> > wrote: > >Hi everyone, > > > >I would like to propose a new native utility function: str_mask(). > > I can definitely see the use case for this function - in fact, I was just reviewing a change > which could have used it. > > >Multibyte Support: Unlike custom userland implementations that might > >break on non-Latin strings (like Persian/Arabic/CJK), a native > >implementation can seamlessly handle multibyte characters. > > As a rule, PHP's str_* functions operate on byte strings with no knowledge of encoding. > Multibyte support would belong in the mbstring or intl extensions, which have conventions for > specifying the encoding in use. > > In fact, a correct Unicode implementation would need to operate on "graphemes", using > the bindings to ICU in the intl extension. Otherwise, it would incorrectly handle things like > combining diacritics and emoji variation selectors. > > > > Rowan Tommins > [IMSoP] Hi, Sepehr, Rowan and Internals I'm interesting your idea. I agree that Rowan say mbstring or grapheme function. For example, number is not only ASCII. One of Full Width number: 0123456789(U+FF19 - U+FF19). There is Japanese number in Kanji (一,二,三,四,五,六,七,八,九) Therefore, your proposal are useful but I suggest to move to grapheme* function. (mbstring is not accept from nearly) Regards Yuya -- --------------------------- Yuya Hamada (tekimen) - https://tekitoh-memdhoi.info - https://github.com/youkidearitai -----------------------------

« previous php.internals (#131392) next »