Re: ord(), chr(), and &url.asciitbale.com;

From: Date: Fri, 22 Jun 2018 10:48:15 +0000
Subject: Re: ord(), chr(), and &url.asciitbale.com;
References: 1  Groups: php.doc 
Request: Send a blank email to phpdoc+get-969386978@lists.php.net to get a copy of this message
On 10.06.2018 at 19:59, Rowan Collins wrote: > I'd like to raise a discussion of the patch I've just proposed at > https://edit.php.net/?patchID=2939&project=PHP because > it's a relatively > major change. > > Currently, the ord() and chr() manual pages describe their input and > output in terms of "ASCII" and "characters", which is misleading for a > number of reasons: > > 1) ASCII is a 7-bit encoding, but these functions work with 8-bit > numbers (0 to 255) > 2) The term "character" is often used in the context of multibyte > encodings, but these functions *always* work with a single byte > 3) Neither function is encoding aware in any way, and both can in fact > be used on arbitrary binary strings > > In the patch linked above, I've had a go at completely rewording these > manual pages to make this clearer. Unfortunately, the "preview" function > in the online editor doesn't work for me, so I may have made some > formatting errors, but I'd also like feedback on the proposed wording. Thanks. In my opinion, this is an overall improvement! However, I'm not happy with the <refpurpose>s which appear to be far too general. Regarding the changed parameter name: we should actually use the names which are returned by Reflection, which is $codepoint for chr() (cf. <https://3v4l.org/CrcS2>). > Finally, both pages currently link to http://www.asciitable.com > which > has a reasonable table for ASCII values, and then one labelled "extended > ASCII", which appears to be the top half of DOS Code Page 437, of all > things. I think this should be replaced with a more suitable link, but > I'm not sure where to; Wikipedia has good charts of encodings, for > instance, but what page would we link to? ASCII, ISO-8859-1, Windows > 1252, something else? Good question! Maybe we should remove the link altogether? -- Christoph M. Becker

« previous php.doc (#969386978) next »