Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72511 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17856 invoked from network); 12 Feb 2014 12:12:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Feb 2014 12:12:34 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:57896] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BE/70-14696-0356BF25 for ; Wed, 12 Feb 2014 07:12:33 -0500 Received: (qmail 8306 invoked by uid 89); 12 Feb 2014 12:12:29 -0000 Received: by simscan 1.3.1 ppid: 8299, pid: 8303, t: 0.0873s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 12 Feb 2014 12:12:29 -0000 Message-ID: <52FB65FD.8080906@lsces.co.uk> Date: Wed, 12 Feb 2014 12:15:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [VOTE] Multbye char handling - Remove vulnerability related to multibyte short and long term From: lester@lsces.co.uk (Lester Caine) Yasuo Ohgaki wrote: >> The proper way to handle this is language Unicode support. Having *yet >> >another* "UTF-8" extension is not a long term solution. > > Although, it aims to replace existing mbstring, I can agree with your opinion. > If PHP is going to support Unicode fully, i.e. have encoding parameter/property, > then it would be good solution. Just one quick question, what do you think about > encoding parameter/property? Functions like fgetcsv() needs to specify encoding, > but it seems many people against it. The first thing that has to be decided is if the whole core is simply UTF8. To my mind this is the most practical approach, so that fgetcsv() will work only with UTF8. This then moves the problem of coding to where it should be, on the 'connection', so either everything is stored as unicode and transcoded when being saved, or your streaming adds the transcoding. Conversion to lower/upper case would be the same sort of filter on the data stream. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk