Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #8752 > unrolled thread

mysql dynamic binding and pass-by-ref deprecated

Back to article view | Back to comp.lang.php

Contents

  mysql dynamic binding and pass-by-ref deprecated oldyork90 <oldyork90@yahoo.com> - 2013-03-19 20:49 -0700
    Re: mysql dynamic binding and pass-by-ref deprecated Jerry Stuckle <jstucklex@attglobal.net> - 2013-03-20 06:42 -0400
      Re: mysql dynamic binding and pass-by-ref deprecated oldyork90 <oldyork90@yahoo.com> - 2013-03-20 07:09 -0700
        Re: mysql dynamic binding and pass-by-ref deprecated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-20 15:29 +0100
          Re: mysql dynamic binding and pass-by-ref deprecated The Cat in the Hat <doctor@suess.com> - 2013-03-20 21:58 +0000
            UTF-8 charset (was: mysql dynamic binding and pass-by-ref deprecated) Christoph Becker <cmbecker69@gmx.de> - 2013-03-20 23:45 +0100
              Re: UTF-8 charset (was: mysql dynamic binding and pass-by-ref deprecated) The Cat in the Hat <doctor@suess.com> - 2013-03-20 23:13 +0000
                Re: UTF-8 charset The Natural Philosopher <tnp@invalid.invalid> - 2013-03-20 23:31 +0000
                Re: UTF-8 charset "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-03-21 10:11 +0100
                  Re: UTF-8 charset adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2013-03-21 14:31 +0000
                    Re: UTF-8 charset The Natural Philosopher <tnp@invalid.invalid> - 2013-03-21 16:22 +0000
                    Re: UTF-8 charset "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-03-21 18:05 +0100
                      Re: UTF-8 charset Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-22 01:17 +0100
                        Re: UTF-8 charset Christoph Becker <cmbecker69@gmx.de> - 2013-03-22 01:55 +0100
                          Unicode support (was: UTF-8 charset) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-22 02:16 +0100
                            Re: Unicode support Christoph Becker <cmbecker69@gmx.de> - 2013-03-30 13:57 +0100
                              Re: Unicode support Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-30 14:25 +0100
                                Re: Unicode support The Natural Philosopher <tnp@invalid.invalid> - 2013-03-30 14:33 +0000
                                  Re: Unicode support Christoph Becker <cmbecker69@gmx.de> - 2013-03-30 15:55 +0100
                                    Re: Unicode support The Natural Philosopher <tnp@invalid.invalid> - 2013-03-30 18:04 +0000
                                      Re: Unicode support Christoph Becker <cmbecker69@gmx.de> - 2013-03-30 21:26 +0100
                                        Re: Unicode support The Natural Philosopher <tnp@invalid.invalid> - 2013-03-30 21:26 +0000
                                          Re: Unicode support Christoph Becker <cmbecker69@gmx.de> - 2013-03-30 23:14 +0100
                                            Re: Unicode support The Natural Philosopher <tnp@invalid.invalid> - 2013-03-30 22:29 +0000
                                      Re: Unicode support "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-03-31 14:10 +0200
                                        Re: Unicode support The Natural Philosopher <tnp@invalid.invalid> - 2013-03-31 13:41 +0100
                                          Re: Unicode support "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-03-31 19:12 +0200
                                    Re: Unicode support Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-30 20:18 +0100
                                      Re: Unicode support Christoph Becker <cmbecker69@gmx.de> - 2013-03-30 21:05 +0100
                                        Re: Unicode support Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-30 21:19 +0100
                                    Re: Unicode support "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-03-31 14:06 +0200
                                  Re: Unicode support "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-04-02 19:59 +0200
                              Re: Unicode support The Natural Philosopher <tnp@invalid.invalid> - 2013-03-30 14:29 +0000
                          Re: UTF-8 charset The Natural Philosopher <tnp@invalid.invalid> - 2013-03-22 10:50 +0000
                        Re: UTF-8 charset "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-03-22 09:46 +0100
                    Re: UTF-8 charset "M. Strobel" <sorry_no_mail_here@nowhere.dee> - 2013-03-21 18:36 +0100
                      Re: UTF-8 charset [OT] adrian@poppyrecords.invalid.invalid (Adrian Tuddenham) - 2013-03-21 18:22 +0000
                        Re: UTF-8 charset [OT] "Peter H. Coffin" <hellsop@ninehells.com> - 2013-03-21 15:00 -0500
                          Re: UTF-8 charset [OT] Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-03-22 01:47 +0100
              Re: UTF-8 charset The Natural Philosopher <tnp@invalid.invalid> - 2013-03-20 23:20 +0000
                Re: UTF-8 charset Scott Johnson <noonehome@chalupasworld.com> - 2013-03-20 16:39 -0700
            Re: mysql dynamic binding and pass-by-ref deprecated Jerry Stuckle <jstucklex@attglobal.net> - 2013-03-20 23:29 -0400
            OT: Xnews mime-proxy (was: mysql dynamic binding and pass-by-ref deprecated) BootNic <bootnic.bounce@gmail.com> - 2013-03-21 10:53 -0400
          Re: mysql dynamic binding and pass-by-ref deprecated oldyork90 <oldyork90@yahoo.com> - 2013-03-21 06:43 -0700

Page 1 of 3  [1] 2 3  Next page →

#8752 — mysql dynamic binding and pass-by-ref deprecated

I developed php code on a local uSWin box - php 5.3.8, mysql 5.5.
Every thing worked fine.

I moved it to godaddy - boom.

-->Call-time pass-by-reference has been deprecated

call_user_func_array(array($sth,'bind_param'),$vr) wants an array of
references.

But I get these deprecated messages when I push the references on an
array and when I try and run call_user_func_array()

I tried removing the references and directly pushing on the vars, but
no go.

Short of a giant switch statement to count parameters, any ideas?
godaddy is sitting at php 5.3, mysql 5.0.96

[toc] | [next] | [standalone]

#8756

On 3/19/2013 11:49 PM, oldyork90 wrote:
> I developed php code on a local uSWin box - php 5.3.8, mysql 5.5.
> Every thing worked fine.
>
> I moved it to godaddy - boom.
>
> -->Call-time pass-by-reference has been deprecated
>
> call_user_func_array(array($sth,'bind_param'),$vr) wants an array of
> references.
>
> But I get these deprecated messages when I push the references on an
> array and when I try and run call_user_func_array()
>
> I tried removing the references and directly pushing on the vars, but
> no go.
>
> Short of a giant switch statement to count parameters, any ideas?
> godaddy is sitting at php 5.3, mysql 5.0.96
>

Sorry, my crystal ball is in the shop so I can't see your code.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#8758

> Sorry, my crystal ball is in the shop so I can't see your code.

Mine isn't..
OOooooo. AAaaaaa.  I see a white picket fence and a woman crying...

$vr = array();
.
.
$bind_name = 'bp' . $fld_name;
@ $$bind_name = $validated_field_input;
@ array_push($vr, &$$bind_name);
.
@ array_push($vr, &$validated_uid);
.
.
array_unshift($vr, $bind_types);  // $bind_types is a string like
"ssisii"
call_user_func_array(array($sth,'bind_param'),$vr)

Thanks for any help.

[toc] | [prev] | [next] | [standalone]

#8759

oldyork90 wrote:

> $vr = array();
> .
> .
> $bind_name = 'bp' . $fld_name;
> @ $$bind_name = $validated_field_input;
> @ array_push($vr, &$$bind_name);
> .
> @ array_push($vr, &$validated_uid);

Simply omit the “&”s in the calls.  Not pass-by-reference as such is 
deprecated since PHP 5.3, but “*call-time* pass-by-reference”, as the 
warning says.  The rationale is that it should be up to the function to 
decide whether a parameter should be treated as a reference, and so
require a name for a variable to be be modified; not to the caller.

RTFM: <http://php.net/manual/en/language.references.pass.php>


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#8761

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote in 
news:2206171.g8a4ScMWm9@PointedEars.de:

> oldyork90 wrote:
> 
>> $vr = array();
>> .
>> .
>> $bind_name = 'bp' . $fld_name;
>> @ $$bind_name = $validated_field_input;
>> @ array_push($vr, &$$bind_name);
>> .
>> @ array_push($vr, &$validated_uid);
> 
> Simply omit the “&”s in the calls. 

How about omitting the smart quotes in your posts?

Come back after you've figured out how to configure your newsreader properly.

[toc] | [prev] | [next] | [standalone]

#8763 — UTF-8 charset (was: mysql dynamic binding and pass-by-ref deprecated)

The Cat in the Hat wrote:

> How about omitting the smart quotes in your posts?
> 
> Come back after you've figured out how to configure your newsreader properly.

Thomas' message was properly encoded as UTF-8.  Isn't that acceptable in
this NG?

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#8765 — Re: UTF-8 charset (was: mysql dynamic binding and pass-by-ref deprecated)

Christoph Becker <cmbecker69@gmx.de> wrote in news:kide60$df1$1@speranza.aioe.org:

> The Cat in the Hat wrote:
> 
>> How about omitting the smart quotes in your posts?
>> 
>> Come back after you've figured out how to configure your newsreader properly.
> 
> Thomas' message was properly encoded as UTF-8.  Isn't that acceptable in
> this NG?

Usenet was designed to use ASCII, not UTF-8. At best, it's poor netiquette in *any* NG.

[toc] | [prev] | [next] | [standalone]

#8767 — Re: UTF-8 charset

On 20/03/13 23:13, The Cat in the Hat wrote:
> Christoph Becker <cmbecker69@gmx.de> wrote in news:kide60$df1$1@speranza.aioe.org:
>
>> The Cat in the Hat wrote:
>>
>>> How about omitting the smart quotes in your posts?
>>>
>>> Come back after you've figured out how to configure your newsreader properly.
>>
>> Thomas' message was properly encoded as UTF-8.  Isn't that acceptable in
>> this NG?
>
> Usenet was designed to use ASCII, not UTF-8. At best, it's poor netiquette in *any* NG.
>
Roads were designed to take horses and carts.

Hows your Nag and Surrey?

-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#8774 — Re: UTF-8 charset

Am 21.03.2013 00:13, schrieb The Cat in the Hat:
> Christoph Becker <cmbecker69@gmx.de> wrote in news:kide60$df1$1@speranza.aioe.org:
> 
>> The Cat in the Hat wrote:
>>
>>> How about omitting the smart quotes in your posts?
>>>
>>> Come back after you've figured out how to configure your newsreader properly.
>>
>> Thomas' message was properly encoded as UTF-8.  Isn't that acceptable in
>> this NG?
> 
> Usenet was designed to use ASCII, not UTF-8. At best, it's poor netiquette in *any* NG.
> 

Utter nonsense.

/Str.

[toc] | [prev] | [next] | [standalone]

#8783 — Re: UTF-8 charset

M. Strobel <sorry_no_mail_here@nowhere.dee> wrote:

> Am 21.03.2013 00:13, schrieb The Cat in the Hat:
> > Christoph Becker <cmbecker69@gmx.de> wrote in
> > news:kide60$df1$1@speranza.aioe.org:
> > 
> >> The Cat in the Hat wrote:
> >>
> >>> How about omitting the smart quotes in your posts?
> >>>
> >>> Come back after you've figured out how to configure your newsreader
> >>>properly.
> >>
> >> Thomas' message was properly encoded as UTF-8.  Isn't that acceptable
> >> in this NG?
> > 
> > Usenet was designed to use ASCII, not UTF-8. At best, it's poor
> > netiquette in *any* NG.
> > 
> 
> Utter nonsense.

There are some computers that cannot read UTF-8.  Always use the lowest
common denominator if you want to communicate effectively without
excluding anyone.

-- 
~ Adrian Tuddenham ~
(Remove the ".invalid"s and add ".co.uk" to reply)
www.poppyrecords.co.uk

[toc] | [prev] | [next] | [standalone]

#8785 — Re: UTF-8 charset

On 21/03/13 14:31, Adrian Tuddenham wrote:
> M. Strobel <sorry_no_mail_here@nowhere.dee> wrote:
>
>> Am 21.03.2013 00:13, schrieb The Cat in the Hat:
>>> Christoph Becker <cmbecker69@gmx.de> wrote in
>>> news:kide60$df1$1@speranza.aioe.org:
>>>
>>>> The Cat in the Hat wrote:
>>>>
>>>>> How about omitting the smart quotes in your posts?
>>>>>
>>>>> Come back after you've figured out how to configure your newsreader
>>>>> properly.
>>>>
>>>> Thomas' message was properly encoded as UTF-8.  Isn't that acceptable
>>>> in this NG?
>>>
>>> Usenet was designed to use ASCII, not UTF-8. At best, it's poor
>>> netiquette in *any* NG.
>>>
>>
>> Utter nonsense.
>
> There are some computers that cannot read UTF-8.  Always use the lowest
> common denominator if you want to communicate effectively without
> excluding anyone.
>
That's why I always send a semaphore sign video attachment to all my posts.

Cos deaf people cant hear me otherwise. sheesh.

Remember Amoebea dont speak inglish. And they deserve to know what your 
saying as well.

that's about as insane as having wheelchair access to a specialist rock 
climbing shop..

Or braille markings on video DVDS.


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#8786 — Re: UTF-8 charset

Am 21.03.2013 15:31, schrieb Adrian Tuddenham:
> M. Strobel <sorry_no_mail_here@nowhere.dee> wrote:
> 
>> Am 21.03.2013 00:13, schrieb The Cat in the Hat:
>>> Christoph Becker <cmbecker69@gmx.de> wrote in
>>> news:kide60$df1$1@speranza.aioe.org:
>>>
>>>> The Cat in the Hat wrote:
>>>>
>>>>> How about omitting the smart quotes in your posts?
>>>>>
>>>>> Come back after you've figured out how to configure your newsreader
>>>>> properly.
>>>>
>>>> Thomas' message was properly encoded as UTF-8.  Isn't that acceptable
>>>> in this NG?
>>>
>>> Usenet was designed to use ASCII, not UTF-8. At best, it's poor
>>> netiquette in *any* NG.
>>>
>>
>> Utter nonsense.
> 
> There are some computers that cannot read UTF-8.  Always use the lowest
> common denominator if you want to communicate effectively without
> excluding anyone.
> 

More than 90% of the text is still readable if your usenet client only displays ASCII.

In the anglophone world people get easily to think ASCII is sufficient, but in a
global world even 16-bit Unicode (Basic Multilingual Plane) is not.

Some languages use UCS-16 internally, and it is not enough for all uses and users.

So UTF-8 is THE solution. There must be some progress sometime. ASCII, 7-bit
encodings and octal are left behind.

/Str.

[toc] | [prev] | [next] | [standalone]

#8790 — Re: UTF-8 charset

M. Strobel wrote:

> Am 21.03.2013 15:31, schrieb Adrian Tuddenham:
>> M. Strobel <sorry_no_mail_here@nowhere.dee> wrote:
>>> Am 21.03.2013 00:13, schrieb The Cat in the Hat:
>>>> Christoph Becker <cmbecker69@gmx.de> wrote in
>>>> news:kide60$df1$1@speranza.aioe.org:
>>>>> The Cat in the Hat wrote:
>>>>>> How about omitting the smart quotes in your posts?
>>>>>>
>>>>>> Come back after you've figured out how to configure your newsreader
>>>>>> properly.
>>>>>
>>>>> Thomas' message was properly encoded as UTF-8.  Isn't that acceptable
>>>>> in this NG?
>>>>
>>>> Usenet was designed to use ASCII, not UTF-8. At best, it's poor
>>>> netiquette in *any* NG.
>>>
>>> Utter nonsense.

ACK.
 
>> There are some computers that cannot read UTF-8.

That would be computers and software older than 30 years now.  The Unicode 
Standard, version 2.0, and UTF-8, one the encodings for the character set 
thus specified, was published in 1992 CE.  All reasonably modern operating 
systems, in effect all commonly used ones, support Unicode and provide 
Unicode-capable fonts.  Many have made a Unicode encoding their default 
encoding; for example, NTFS encodes filenames using UTF-16, and UTF-8 has 
been the default locale encoding on GNU/Linux systems for several years now.

Thus, a major criticism of PHP is that as of version 5.4 it still has no 
native Unicode support, while other popular programming languages on the 
Web, like ECMAScript implementations and Python, have.

>> Always use the lowest common denominator if you want to communicate
>> effectively without excluding anyone.

Insisting on using *ancient* and therefore inherently *insecure* hardware 
and software is no excuse for claiming something mindbogglingly absurd like 
that using UTF-8 encoding would be “poor netiquette in *any* NG”.  First of 
all, netiquette (network etiquette) is less concerned with the technical 
aspects of messages but with the behavior of people towards each other thus 
exhibited.  Which makes this clearly a case of “the pot calling the kettle 
black”.

Speaking of netiquette, though, it *is* considered polite (on Usenet) to 
introduce oneself with one's full name.  People posting under unnecessarily 
abbreviated names, pseudonyms, and plain nick names, like “The Cat in the 
Hat”, are usually either frowned upon, laughed at, or ignored instead by 
longtime regulars (like me).  The same applies to people who violate 
technical standards or quasi-standards such as RFC 5536, along with the AUPs 
of their providers, by using non-addresses in address header field values:

<http://www.zedat.fu-berlin.de/NetNews-Regeln>
<http://www.kirchwitz.de/~amk/dni/netiquette> (based on a Big 8 original)

> More than 90% of the text is still readable if your usenet client only
> displays ASCII.
> 
> In the anglophone world people get easily to think ASCII is sufficient,
> but in a global world even 16-bit Unicode (Basic Multilingual Plane) is
> not.

Those are good points, however:

> Some languages use UCS-16 internally, and it is not enough for all uses
> and users.

This is a common misconception.  There is no “UCS-16” and there never was.
At most, there is or was (depending how you look at it), UCS-2 (Universal 
Character Set 2), to whose character set the Unicode character set from 
Unicode 2.0 on is byte-by-byte equivalent.

The underlying misconception here is confusing character set with character 
encoding, probably also common because of the “charset” parameter of 
Internet messages that despite its name declares *character encoding* of a 
message.

UCS-2 is/was a standard for a *character set along with a specific, 16-bit 
encoding* to encode all characters in the Basic Multilingual Plane (BMP), 
and *only* those.  This and the overhead for simple (purely US-ASCII-based) 
texts lead to the later success of the competing standard, Unicode.

See also: <http://en.wikipedia.org/wiki/UCS-16> (properly redirected to the 
UCS article, with an explanation why “UCS-16” is just wrong.)

*UTF*-16 (Unicode Transformation Format, 16-bit) is *another* encoding where 
each *code unit* of a sequence for a character has 16 bit; a character may 
be encoded using more than one code unit (the same is true for the other 
UTFs).  The character set thus encoded is the Unicode character set, and 
both are defined in the Unicode Standard.  That character set comprises, and 
its transformation formats can encode, a lot more than just the BMP, 
although of the subsets of Unicode the BMP remains the best supported one, 
also due to pre-installed font support.  At the moment, there are 1'114'112 
code points in Unicode (U+0000 to U+10FFFF), so in theory a text encoded 
with one of the UTFs could contain 1'114'112 different characters.  (In 
practice, some code point ranges in the BMP are reserved for surrogate 
characters to allow more than the 65536 potential characters of the BMP 
while keeping the encoding relatively simple and backwards-compatible.)
 
> So UTF-8 is THE solution. There must be some progress sometime.

ACK.

> ASCII, 7-bit encodings and octal are left behind.

US-ASCII *is* a 7-bit encoding.  “Octal”?

The most important thing about UTF-8 is that it is equivalent to US-ASCII 
for code points below U+0080 (one 8-bit code unit per character, the MSB is 
always 0, encodes the same characters as in US-ASCII).  Therefore, UTF-8, 
through Unicode, allows texts with the greatest possible range of characters 
(all written languages, even some extinct ones, common symbols, punctuation 
etc.) while using the least amount of memory when this range is _not_ fully 
used.

Actually, it should not be necessary to explain all this to people 
subscribed to a programming newsgroup, and to Web developers in particular, 
but there you are.

<http://www.joelonsoftware.com/articles/Unicode.html>
<http://unicode.org/faq/>


HTH

PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

[toc] | [prev] | [next] | [standalone]

#8792 — Re: UTF-8 charset

Thomas 'PointedEars' Lahn wrote:

>> Am 21.03.2013 15:31, schrieb Adrian Tuddenham:

>>> There are some computers that cannot read UTF-8.

> That would be computers and software older than 30 years now.  The Unicode 
> Standard, version 2.0, and UTF-8, one the encodings for the character set 
> thus specified, was published in 1992 CE.  All reasonably modern operating 
> systems, in effect all commonly used ones, support Unicode and provide 
> Unicode-capable fonts.  Many have made a Unicode encoding their default 
> encoding; for example, NTFS encodes filenames using UTF-16, and UTF-8 has 
> been the default locale encoding on GNU/Linux systems for several years now.

I recently read, that UTF-8 is not available on many Windows PCs in
Taiwan, where `BIG5' is still prevalent, what would be very unfortunate.
 OTOH restricting oneself to ASCII on Usenet reminds me of offering full
support for IE 6 on the Web (e.g. by using GIFs instead PNGs when
transparency is required), which IMO holds back reasonable innovation.

> Thus, a major criticism of PHP is that as of version 5.4 it still has no 
> native Unicode support, while other popular programming languages on the 
> Web, like ECMAScript implementations and Python, have.

Indeed, that's a shame and rather painful for developers.  And if I'm
not mistaken, the situation won't change with PHP 5.5. :(

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#8793 — Unicode support (was: UTF-8 charset)

Christoph Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>>> Am 21.03.2013 15:31, schrieb Adrian Tuddenham:
>>>> There are some computers that cannot read UTF-8.
>> 
>> That would be computers and software older than 30 years now.  The
>> Unicode Standard, version 2.0, and UTF-8, one the encodings for the
>> character set thus specified, was published in 1992 CE.  All reasonably
>> modern operating systems, in effect all commonly used ones, support
>> Unicode and provide Unicode-capable fonts.  Many have made a Unicode
>> encoding their default encoding; for example, NTFS encodes filenames
>> using UTF-16, and UTF-8 has been the default locale encoding on GNU/Linux
>> systems for several years now.
> 
> I recently read, that UTF-8 is not available on many Windows PCs in
> Taiwan, where `BIG5' is still prevalent, what would be very unfortunate.

I would like to see proof of that.  While possible, I consider it unlikely. 
Taiwan is especially intertwined with the Western world (being the location 
of major local hardware manufacturers, and major foreign investments on the 
doorstep to mainland China), and Traditional Chinese as written in Taiwan 
was one of the first scripts to be covered by Unicode, with CJK Unified 
Ideographs, in 1992.

Windows has been supporting Unicode, and came pre-installed with Unicode-
capable fonts since Windows NT (and so, Windows 2000).  Did not Windows XP 
support end last year?

>  OTOH restricting oneself to ASCII on Usenet reminds me of offering full
> support for IE 6 on the Web (e.g. by using GIFs instead PNGs when
> transparency is required), which IMO holds back reasonable innovation.

ACK.

>> Thus, a major criticism of PHP is that as of version 5.4 it still has no
>> native Unicode support, while other popular programming languages on the
>> Web, like ECMAScript implementations and Python, have.
> 
> Indeed, that's a shame and rather painful for developers.  And if I'm
> not mistaken, the situation won't change with PHP 5.5. :(

That would be a pity.  Native Unicode support was announced for PHP 6 before 
those plans were abandoned.  I wonder, what can be that hard in implementing 
it?  Apparently even Perl managed the transition years ago although it 
requires a few extra lines per script.


PointedEars
-- 
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
  -- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#8915 — Re: Unicode support

Thomas 'PointedEars' Lahn wrote:
>
> Christoph Becker wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>>> Am 21.03.2013 15:31, schrieb Adrian Tuddenham:
>>>>> There are some computers that cannot read UTF-8.
>>>
>>> That would be computers and software older than 30 years now.  The
>>> Unicode Standard, version 2.0, and UTF-8, one the encodings for the
>>> character set thus specified, was published in 1992 CE.  All reasonably
>>> modern operating systems, in effect all commonly used ones, support
>>> Unicode and provide Unicode-capable fonts.  Many have made a Unicode
>>> encoding their default encoding; for example, NTFS encodes filenames
>>> using UTF-16, and UTF-8 has been the default locale encoding on GNU/Linux
>>> systems for several years now.
>>
>> I recently read, that UTF-8 is not available on many Windows PCs in
>> Taiwan, where `BIG5' is still prevalent, what would be very unfortunate.
> 
> I would like to see proof of that.  While possible, I consider it unlikely. 
> Taiwan is especially intertwined with the Western world (being the location 
> of major local hardware manufacturers, and major foreign investments on the 
> doorstep to mainland China), and Traditional Chinese as written in Taiwan 
> was one of the first scripts to be covered by Unicode, with CJK Unified 
> Ideographs, in 1992.

I'm quite sure now, that I was mistaken.  It is not UTF-8 support that
is missing on the PCs, but rather that the file systems are using BIG5
by default, what is of course something quite different.  Sorry for the
incorrect information.

> Windows has been supporting Unicode, and came pre-installed with Unicode-
> capable fonts since Windows NT (and so, Windows 2000).  Did not Windows XP 
> support end last year?

According to <http://www.microsoft.com/en-us/windows/endofsupport.aspx>
support of Windows XP SP3 ends on April 8, 2014.

>>  OTOH restricting oneself to ASCII on Usenet reminds me of offering full
>> support for IE 6 on the Web (e.g. by using GIFs instead PNGs when
>> transparency is required), which IMO holds back reasonable innovation.
> 
> ACK.
> 
>>> Thus, a major criticism of PHP is that as of version 5.4 it still has no
>>> native Unicode support, while other popular programming languages on the
>>> Web, like ECMAScript implementations and Python, have.
>>
>> Indeed, that's a shame and rather painful for developers.  And if I'm
>> not mistaken, the situation won't change with PHP 5.5. :(
> 
> That would be a pity.  Native Unicode support was announced for PHP 6 before 
> those plans were abandoned.  I wonder, what can be that hard in implementing 
> it?  Apparently even Perl managed the transition years ago although it 
> requires a few extra lines per script.

Native Unicode support was planned to be resp. already partially
implemented by using UTF-16 internally throughout.  It seems, that
several PHP developers had concerns about the performance and memory
overhead of doing so.  Obviously no agreement could be found, and on
March 11, 2010 Rasmus Lerdorf `decided' to delay PHP 6 and the Unicode
support.[1]

Of course there are several extensions handling UTF-8 quite well, but
these may not be available on shared web hosting services, and anyway
it's quite ugly to have e.g. strlen('€')===3 when dealing with UTF-8.

[1] <http://news.php.net/php.internals/47120>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#8916 — Re: Unicode support

Christoph Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> I recently read, that UTF-8 is not available on many Windows PCs in
>>> Taiwan, where `BIG5' is still prevalent, what would be very unfortunate.
>> 
>> I would like to see proof of that.  While possible, I consider it
>> unlikely. Taiwan is especially intertwined with the Western world (being
>> the location of major local hardware manufacturers, and major foreign
>> investments on the doorstep to mainland China), and Traditional Chinese
>> as written in Taiwan was one of the first scripts to be covered by
>> Unicode, with CJK Unified Ideographs, in 1992.
> 
> I'm quite sure now, that I was mistaken.  It is not UTF-8 support that
> is missing on the PCs, but rather that the file systems are using BIG5
> by default,

But not NTFS, I presume?

> what is of course something quite different.  Sorry for the incorrect
> information.

Never mind.
 
>> Windows has been supporting Unicode, and came pre-installed with Unicode-
>> capable fonts since Windows NT (and so, Windows 2000).  Did not Windows
>> XP support end last year?
> 
> According to <http://www.microsoft.com/en-us/windows/endofsupport.aspx>
> support of Windows XP SP3 ends on April 8, 2014.

That is good to know.  However, it should be noted that (at Microsoft) there 
are different levels of support, and there are different versions of Windows 
XP.  Mainstream Support and Extended Support for some versions of Windows XP 
has ended already:

<http://support.microsoft.com/lifecycle/search/default.aspx?sort=PN&alpha=Windows+XP&Filter=FilterMS&msdate=0>

We are now looking forward to the date that *all* support will be 
discontinued for *all* versions of Windows XP (as there will be no more 
Service Packs).

>>> […] if I'm not mistaken, the situation won't change with PHP 5.5. :(
>> 
>> That would be a pity.  Native Unicode support was announced for PHP 6
>> before those plans were abandoned.  I wonder, what can be that hard in
>> implementing it?  Apparently even Perl managed the transition years ago
>> although it requires a few extra lines per script.
> 
> Native Unicode support was planned to be resp. already partially
> implemented by using UTF-16 internally throughout.  It seems, that
> several PHP developers had concerns about the performance and memory
> overhead of doing so.  Obviously no agreement could be found, and on
> March 11, 2010 Rasmus Lerdorf `decided' to delay PHP 6 and the Unicode
> support.[1]

Thanks.  ISTM that PHP developers are struggling with the same issues as 
Python developers did once.  UTF-16 is considerably large, but string 
operations (like determining string length) are fast within the BMP.  UTF-8 
is small for low code points, but harder to deal with.  UTF-32 covers more 
than the BMP, and would allow fast operations, but is wasteful of precious 
memory.  (As of Python 3.3, Python uses an encoding that attempts to get the 
best of both worlds.)

Still, a UTF-8 pragma like in Perl would not be such a bad idea for PHP.  
Only those who need it would use it.

> Of course there are several extensions handling UTF-8 quite well, but
> these may not be available on shared web hosting services, and anyway
> it's quite ugly to have e.g. strlen('€')===3 when dealing with UTF-8.

The same issue exists with characters outside the BMP in ECMAScript 
implementations which uses 16-bit characters (usually one UTF-16 code unit 
per character).  But you can work around that rather efficiently.
 
> [1] <http://news.php.net/php.internals/47120>

I will read that later.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#8918 — Re: Unicode support

On 30/03/13 13:25, Thomas 'PointedEars' Lahn wrote:

> The same issue exists with characters outside the BMP in ECMAScript
> implementations which uses 16-bit characters (usually one UTF-16 code unit
> per character).  But you can work around that rather efficiently.
>

The problem become 'what do you mean by strlen()' - the space the 
characters will occupy in an constant width font, or the storage 
allocated to the string?

Mostly we are concerned with the latter.

Because lack of precision in font reproduction, or even in guaranteeing 
which font may be selected, renders the former an 'open' question.

strlen('€')===3 is in fact the correct answer.

>> [1] <http://news.php.net/php.internals/47120>
>
> I will read that later.
>
>
> PointedEars
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

#8919 — Re: Unicode support

The Natural Philosopher wrote:

> On 30/03/13 13:25, Thomas 'PointedEars' Lahn wrote:
> 
>> The same issue exists with characters outside the BMP in ECMAScript
>> implementations which uses 16-bit characters (usually one UTF-16 code
>> unit
>> per character).  But you can work around that rather efficiently.
>>
> 
> The problem become 'what do you mean by strlen()' - the space the
> characters will occupy in an constant width font, or the storage
> allocated to the string?
> 
> Mostly we are concerned with the latter.

I am more concerned about the number of characters the string holds.
Say, I want to get the last character:

  $str = '€';
  echo $str[2];

> Because lack of precision in font reproduction, or even in guaranteeing
> which font may be selected, renders the former an 'open' question.
> 
> strlen('€')===3 is in fact the correct answer.

I suppose most *higher level languages* define the length of a string as
the number of characters the string holds.  Cf. ECMAScript's length
property and TCL's [string length].  Even PHP's mb_strlen() returns the
number of characters.

C is quite a different thing.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#8920 — Re: Unicode support

On 30/03/13 14:55, Christoph Becker wrote:
> The Natural Philosopher wrote:
>
>> On 30/03/13 13:25, Thomas 'PointedEars' Lahn wrote:
>>
>>> The same issue exists with characters outside the BMP in ECMAScript
>>> implementations which uses 16-bit characters (usually one UTF-16 code
>>> unit
>>> per character).  But you can work around that rather efficiently.
>>>
>>
>> The problem become 'what do you mean by strlen()' - the space the
>> characters will occupy in an constant width font, or the storage
>> allocated to the string?
>>
>> Mostly we are concerned with the latter.
>
> I am more concerned about the number of characters the string holds.
> Say, I want to get the last character:
>
>    $str = '€';
>    echo $str[2];
>
>> Because lack of precision in font reproduction, or even in guaranteeing
>> which font may be selected, renders the former an 'open' question.
>>
>> strlen('€')===3 is in fact the correct answer.
>
> I suppose most *higher level languages* define the length of a string as
> the number of characters the string holds.  Cf. ECMAScript's length
> property and TCL's [string length].  Even PHP's mb_strlen() returns the
> number of characters.
>

so what happens in a typographic ligature like 'ᴁ'?

I think you are making a rod for your back here.

The storage requirements are exact specific and useful.

The concept of a 'character in a text string' is really not..and if you 
go deep into typography with kerning, leading,ligature and the like and 
the like you will understand why.

Not that I am any expert. I just know enough to now there's a minefield 
out there.



> C is quite a different thing.
>


-- 
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to 
lead are elected by the least capable of producing, and where the 
members of society least likely to sustain themselves or succeed, are 
rewarded with goods and services paid for by the confiscated wealth of a 
diminishing number of producers.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.php

csiph-web