Req #77819 [Opn->Wfx]: Proposal

From: Date: Fri, 29 Mar 2019 08:25:11 +0000
Subject: Req #77819 [Opn->Wfx]: Proposal
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-220249@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=77819&edit=1 ID: 77819 Updated by: nikic@php.net Reported by: hen20-19 at yahoo dot co dot jp Summary: Proposal -Status: Open +Status: Wont fix Type: Feature/Change Request Package: mbstring related Operating System: Windows PHP Version: 7.1.27 Block user comment: N Private report: N New Comment: mb_ereg() is backed by the oniguruma library, which requires that regular expressions and subjects passed to it are valid under the given encoding. Strings with invalid encoding may lead to crashes and security issues. If your string is not valid UTF-8, then you need to treat it as binary data and specify the encoding accordingly. In that case I'd recommend using preg_match() instead though, which is binary by default and uses PCRE, which is a superior regular expression library. Previous Comments: ------------------------------------------------------------------------ [2019-03-29 06:19:20] hen20-19 at yahoo dot co dot jp Description: ------------ I propose revival of handling ability of illegal byte sequences by mb_ereg() functions. After PHP 7.1, mb_ereg() functions reject illegal byte sequences. I think it's admirably fine for beginners with checking function of input strings, but for me, with mb_ereg(), I had been handling illegal byte sequences as easy-made cipher, eg. UTF-8 with inappropriate BOM, which easily prevent careless beginners from unintentional changing of file contents with such as MS-Excel. mb_ereg() functions enable us to create and deal with original file formats only for us. But the functions gone. I strongly long for the functions come back. Perhaps with a new option. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=77819&edit=1

« previous php.bugs (#220249) next »