Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:100687 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 7607 invoked from network); 17 Sep 2017 08:54:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Sep 2017 08:54:59 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=pass Received-SPF: pass (pb1.pair.com: domain lsces.co.uk designates 185.153.204.204 as permitted sender) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 185.153.204.204 mail4.serversure.net Linux 2.6 Received: from [185.153.204.204] ([185.153.204.204:47572] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/49-19300-1683EB95 for ; Sun, 17 Sep 2017 04:54:57 -0400 Received: (qmail 16133 invoked by uid 89); 17 Sep 2017 08:54:54 -0000 Received: by simscan 1.3.1 ppid: 16123, pid: 16130, t: 0.0453s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 17 Sep 2017 08:54:54 -0000 To: "internals@lists.php.net" Message-ID: Date: Sun, 17 Sep 2017 09:54:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Progress or just 'a mess'? From: lester@lsces.co.uk (Lester Caine) It's a question I've asked before, but there still does not seem to be a proper answer ... just where is PHP in relation to unicode? The thread on 'case-insensitive constants' cherry picks a particular aspect without picking up on the base problem? Just what character set is PHP7 designed to work with. The SQL standard provides a working solution to the problem and one that is still applied 25 years on ... it lists the subset of characters available for writing SQL code. Essentially the Latin character set with well defined special characters. The irritating part of cause is that this standard is one you have to pay for copies off, but the principle can easily be copied along perhaps with some of the extensions relating to handling unicode data within the constrained framework. Everything in SQL is essentially 'upper case' although I still have fun moving datasets to PHP arrays where the keys end up as lower case' versions of the default UPPER CASE returned by the standard. THIS is an area where case-insensitive operations would be very useful, but that is not going to happen any time soon. For PHP8 is it not time to lay out a similar set of rules as provided by SQL and identify just what 'case-insensitive' means and where it does apply? -- 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