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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#8924 — Re: Unicode support

The Natural Philosopher wrote:

> 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.

Useful for what purpose?

> 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.

I'm not talking about typesetting.  I'm talking about Unicode
characters, which are clearly defined.  Of course there are issues
regarding combining diacritical marks, so the number of characters of
"ñ" is not necessarily 1, but that's another story.

-- 
Christoph M. Becker

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

#8925 — Re: Unicode support

On 30/03/13 20:26, Christoph Becker wrote:
> The Natural Philosopher wrote:
>
>> 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.
>
> Useful for what purpose?

well malloc(strlen(str)) in C for a start, and picking single bytes out 
of strings too.

>
>> 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.
>
> I'm not talking about typesetting.  I'm talking about Unicode
> characters, which are clearly defined.  Of course there are issues
> regarding combining diacritical marks, so the number of characters of
> "ñ" is not necessarily 1, but that's another story.
>


-- 
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]

#8926 — Re: Unicode support

The Natural Philosopher wrote:

> On 30/03/13 20:26, Christoph Becker wrote:
>> The Natural Philosopher wrote:
>>
>>> 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.
>>
>> Useful for what purpose?
> 
> well malloc(strlen(str)) in C for a start, and picking single bytes out
> of strings too.

C's strlen() returning the number of bytes is perfectly fine.  But in
PHP I don't need malloc(), and I have not yet found a reason to pick out
single bytes out of a *character* string (as opposed to a *byte* string,
which are different concepts IMO), except for emulating some UTF-8 aware
functionality.

Consider that programming in PHP happens on a higher level than in C
(e.g. one doesn't need to allocate heap memory, nor does one have to
free it).  This results in the ability to write programs faster, that
run slower.  But the fact, that PHP's string functions work on bytes
(opposed to characters), partially annihilates the advantage[1].  That
is particularly sad, as PHP has its strengths for web development and
UTF-8 is the de facto standard for the web.

[1] Say, I need a wordwrap() for sending UTF-8 encoded emails. Sigh...
BTW: <http://www.php.net/manual/en/function.wordwrap.php> says:

| wordwrap — Wraps a string to a given number of characters

what's obviously wrong; it wraps a string to a given number of bytes.

-- 
Christoph M. Becker

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

#8927 — Re: Unicode support

On 30/03/13 22:14, Christoph Becker wrote:
> The Natural Philosopher wrote:
>
>> On 30/03/13 20:26, Christoph Becker wrote:
>>> The Natural Philosopher wrote:
>>>
>>>> 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.
>>>
>>> Useful for what purpose?
>>
>> well malloc(strlen(str)) in C for a start, and picking single bytes out
>> of strings too.
>
> C's strlen() returning the number of bytes is perfectly fine.  But in
> PHP I don't need malloc(), and I have not yet found a reason to pick out
> single bytes out of a *character* string (as opposed to a *byte* string,
> which are different concepts IMO), except for emulating some UTF-8 aware
> functionality.
>
> Consider that programming in PHP happens on a higher level than in C
> (e.g. one doesn't need to allocate heap memory, nor does one have to
> free it).  This results in the ability to write programs faster, that
> run slower.  But the fact, that PHP's string functions work on bytes
> (opposed to characters), partially annihilates the advantage[1].  That
> is particularly sad, as PHP has its strengths for web development and
> UTF-8 is the de facto standard for the web.
>
> [1] Say, I need a wordwrap() for sending UTF-8 encoded emails. Sigh...
> BTW: <http://www.php.net/manual/en/function.wordwrap.php> says:
>
> | wordwrap — Wraps a string to a given number of characters
>
> what's obviously wrong; it wraps a string to a given number of bytes.
>
well exactly. Which is why I do all serious programming in C - it may be 
a pedantic bitch of a language, but at least when its done, I know that 
some quirk of it is not going to deliver an entirely unexpected result.

Like wot happened to me in Javashite, where some comparisons of what I 
thought were numbers, was cast to strings by one implementation and 
numbers by the other..


How I longed for if(int(a)==(int(b)) or even atoi(b)....

There are to approaches to life: make it easy for idiots and wonder why 
they still manage to fuck it up, or make the rules extremely clear and 
teach  people what they are. And don't let them loose until they have 
learnt them

If all the money spent on road signs traffic lights and white lines had 
been spent on teaching people to drive...


-- 
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]

#8931 — Re: Unicode support

Am 30.03.2013 19:04, schrieb The Natural Philosopher:
> 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.
> 

Of course you need both, the storage requirements, and direct access to characters.
Maybe programming languages should use internally full 32 bit per char, or compress
the unicode string using a good library for access.

C does not even know strings, just byte arrays

/Str.

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

#8932 — Re: Unicode support

On 31/03/13 13:10, M. Strobel wrote:
> Am 30.03.2013 19:04, schrieb The Natural Philosopher:
>> 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.
>>
>
> Of course you need both, the storage requirements, and direct access to characters.
> Maybe programming languages should use internally full 32 bit per char, or compress
> the unicode string using a good library for access.
>
> C does not even know strings, just byte arrays
>
Thereby avoiding the problems completely by  not even pretending to 
solve them.

And you can always wrote a unicode_strlen() to any specification you 
want..the problem is..

...given that many 'characters' may take LESS than a byte (ligature) or 
up to 3-4 bytes (unicode character sets).... what specification?

and the concept of a 'character' is practically valueless anyway..,

> /Str.
>
>


-- 
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]

#8933 — Re: Unicode support

Am 31.03.2013 14:41, schrieb The Natural Philosopher:
> On 31/03/13 13:10, M. Strobel wrote:
>> Am 30.03.2013 19:04, schrieb The Natural Philosopher:
>>> 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.
>>>
>>
>> Of course you need both, the storage requirements, and direct access to characters.
>> Maybe programming languages should use internally full 32 bit per char, or compress
>> the unicode string using a good library for access.
>>
>> C does not even know strings, just byte arrays
>>
> Thereby avoiding the problems completely by  not even pretending to solve them.
> 
> And you can always wrote a unicode_strlen() to any specification you want..the
> problem is..
> 
> ...given that many 'characters' may take LESS than a byte (ligature) or up to 3-4
> bytes (unicode character sets).... what specification?
> 

So what? How much space does a backspace take? And how much a DEL (127)? This has not
been a problem so far.

And a ligature can be decomposed. Of course every case has to be discussed, but this
is done AFAIK.

/Str.

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

#8921 — Re: Unicode support

Christoph Becker wrote:

> 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.

That depends on the character encoding of the source code.  3 is the correct 
answer for an *UTF-8*-encoded U+20AC EURO SIGN character, which is then 
encoded E2 82 AC. [1]
 
> 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.

AISB, unfortunately the “length” property of ECMAScript String instances is 
not a good example in that regard as it does _not_ mean the number of 
characters but the number of 16-bit units (UTF-16 code units, usually).  
That is only less obvious than with UTF-8 because all Unicode characters in 
the BMP can be encoded using only one such unit.  (I am working on a 
workaround; you could call it “an mb_strlen() for ECMAScript 
implementations”.)


PointedEars 
___________
[1] <http://www.rishida.net/tools/conversion/>
-- 
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]

#8922 — Re: Unicode support

Thomas 'PointedEars' Lahn wrote:

> Christoph Becker wrote:
> 
>> 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.
> 
> That depends on the character encoding of the source code.  3 is the correct 
> answer for an *UTF-8*-encoded U+20AC EURO SIGN character, which is then 
> encoded E2 82 AC. [1]

It is the correct answer for an UTF-8 encoded string, as strlen()
returns the length of string in bytes.  But I doubt, that this is
usually expected, and IMO knowing the number of characters is more
useful for common *PHP* as opposed to low-level C programming.

>> 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.
> 
> AISB, unfortunately the “length” property of ECMAScript String instances is 
> not a good example in that regard as it does _not_ mean the number of 
> characters but the number of 16-bit units (UTF-16 code units, usually).  
> That is only less obvious than with UTF-8 because all Unicode characters in 
> the BMP can be encoded using only one such unit.  (I am working on a 
> workaround; you could call it “an mb_strlen() for ECMAScript 
> implementations”.)

ECMA-262, Edition 5.1, Section 15.5.5.1, states:

| *length*
|
| The number of characters in the String value represented by this
| String object.

IMO the spec is quite clear here, and so the implementations might be in
error.  Anyway, I appreciate your working on a workaround; may come in
handy. :)

-- 
Christoph M. Becker

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

#8923 — Re: Unicode support

Christoph Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> 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.
>> 
>> AISB, unfortunately the “length” property of ECMAScript String instances
>> is not a good example in that regard as it does _not_ mean the number of
>> characters but the number of 16-bit units (UTF-16 code units, usually).
>> That is only less obvious than with UTF-8 because all Unicode characters
>> in the BMP can be encoded using only one such unit.  (I am working on a

“BMP” means “Basic Multilingual Plane” (U+0000 to U+FFFF).

>> workaround; you could call it “an mb_strlen() for ECMAScript
>> implementations”.)
> 
> ECMA-262, Edition 5.1, Section 15.5.5.1, states:
> 
> | *length*
> |
> | The number of characters in the String value represented by this
> | String object.
> 
> IMO the spec is quite clear here,

It is.

> and so the implementations might be in error.

For a change, it is not.  You should look up the definition of “character” 
in the Specification.  See also <news:2202673.rtQqbKup0V@PointedEars.de> pp. 
(yes, in comp.lang.python).

> Anyway, I appreciate your working on a workaround; may come in handy. :)

At the latest after first contact ;-)

You will find it in 
<http://PointEdears.de/websvn/listing.php?repname=JSX&path=%2Ftrunk%2Fstring%2F> 
when it is ready for testing.


F'up2 comp.lang.javascript

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]

#8930 — Re: Unicode support

Am 30.03.2013 15:55, schrieb Christoph Becker:
> 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.
> 

TCL has the functions [string length] and [string bytelength], with the obvious
differences.

/Str.

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

#8935 — Re: Unicode support

Am 30.03.2013 15:33, schrieb The Natural Philosopher:
> 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.
> 

strobel@suse123-acer:~> tclshi
% set eur "€"
€
% string length $eur
1
% string bytelength $eur
3
%

Languages have to catch up.

/Str.

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

#8917 — Re: Unicode support

On 30/03/13 12:57, Christoph Becker wrote:

> it's quite ugly to have e.g. strlen('€')===3 when dealing with UTF-8.
>

Its has been noted that the Euro breaks almost everything it touches:-)




-- 
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]

#8799 — Re: UTF-8 charset

On 22/03/13 00:55, Christoph Becker wrote:

> I recently read, that UTF-8 is not available on many Windows PCs in
> Taiwan,...
That would be the ones running on pirated windows yes?
:-)


--
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]

#8798 — Re: UTF-8 charset

Am 22.03.2013 01:17, schrieb Thomas 'PointedEars' Lahn:
> M. Strobel wrote:
> 

>> 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”?
> 

strobel@suse122-intel:~> php -a
Interactive mode enabled

php > echo 071, PHP_EOL;
57
php > echo 070, PHP_EOL;
56
php >

> 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.

+1

/Str.

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

#8787 — 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.
> 

RFC 3977    Network News Transfer Protocol (NNTP)      October 2006
[Page 3]
   o  the default character set is changed from US-ASCII [ANSI1986] to
      UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8);

I am so fed up with limited character sets like ISO-8859 or the Win encoding a
programmer/sysadmin has to care about.

/Str.

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

#8788 — Re: UTF-8 charset [OT]

M. Strobel <sorry_no_mail_here@nowhere.dee> 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.
> > 
> > There are some computers that cannot read UTF-8.  Always use the lowest
> > common denominator if you want to communicate effectively without
> > excluding anyone.
> > 
> 
> RFC 3977    Network News Transfer Protocol (NNTP)      October 2006
> [Page 3]
>    o  the default character set is changed from US-ASCII [ANSI1986] to
>       UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8);
> 
> I am so fed up with limited character sets like ISO-8859 or the Win encoding a
> programmer/sysadmin has to care about.

A lot depends on the readership you are aiming at.  If you are writing
for just one person or a target audience who can all read your preferred
character set, there is no reason not to use it.  If you are writing for
a larger audience and do not want to exclude some potential readers,
then you may have to limit your choice.  If you are writing comercially,
you cannot afford to upset or alienate a single customer.

As a general rule, the larger the readership, the greater the
constraints which fall upon the writer.  A lot of time and extra work
(and possibly frustration) on the part of one writer will save a much
greater amount of time wasted in total by hundreds of frustrated
readers.


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

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

#8789 — Re: UTF-8 charset [OT]

On Thu, 21 Mar 2013 18:22:30 +0000, Adrian Tuddenham wrote:
> M. Strobel <sorry_no_mail_here@nowhere.dee> wrote:
>> [Page 3]
>>    o  the default character set is changed from US-ASCII [ANSI1986] to
>>       UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8);
>> 
>> I am so fed up with limited character sets like ISO-8859 or the Win encoding a
>> programmer/sysadmin has to care about.
>
> A lot depends on the readership you are aiming at.  If you are writing
> for just one person or a target audience who can all read your preferred
> character set, there is no reason not to use it.  If you are writing for
> a larger audience and do not want to exclude some potential readers,
> then you may have to limit your choice.  If you are writing comercially,
> you cannot afford to upset or alienate a single customer.
>
> As a general rule, the larger the readership, the greater the
> constraints which fall upon the writer.  A lot of time and extra work
> (and possibly frustration) on the part of one writer will save a much
> greater amount of time wasted in total by hundreds of frustrated
> readers.

OTOH, curly-quotes (which IIRC were the issue here) add little, if
anything, to clarity for any language, and certainly have no place in
PHP coding.

-- 
83. If I'm eating dinner with the hero, put poison in his goblet, then 
    have to leave the table for any reason, I will order new drinks for
    both of us instead of trying to decide whether or not to switch 
    with him. --Peter Anspach's list of things to do as an Evil Overlord

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

#8791 — Re: UTF-8 charset [OT]

Peter H. Coffin wrote:

> On Thu, 21 Mar 2013 18:22:30 +0000, Adrian Tuddenham wrote:
>> M. Strobel <sorry_no_mail_here@nowhere.dee> wrote:
>>> [Page 3]
>>>    o  the default character set is changed from US-ASCII [ANSI1986] to
>>>       UTF-8 [RFC3629] (note that US-ASCII is a subset of UTF-8);

That is interesting, but hardly relevant here.  The relevant standard here 
is Proposed Standard RFC 5536 (Netnews Article Format, 2009 CE) which refers 
to Draft Standard RFC 5322 (Internet Message Format, 2008) for the general 
format of Internet messages, which in turn refers to the Draft Standards 
RFC 2045 to 2049 (MIME, 1996) for message encoding.

>>> I am so fed up with limited character sets like ISO-8859 or the Win
>>> encoding a programmer/sysadmin has to care about.

Do you even know that the so-called “ISO-8859-1” actually is Windows-1252?

> […]
> OTOH, curly-quotes (which IIRC were the issue here) add little, if
> anything, to clarity for any language, and certainly have no place in
> PHP coding.

Not quite.  While typographic/proper quotation marks (“curly-quotes” is a 
misnomer) have not been used as part of PHP code here (of course), there is 
nothing wrong with using them in syntactically correct ways, like *inside* 
string values, as long as the source code uses the corresponding character 
encoding and the encoding is properly declared (since PHP is encoding-
agnostic, if you declare and use UTF-8 – without BOM, preferably – you can 
type those characters verbatim; do not think that I &ldquo;'d and &rdquo;'d 
everything in PHP source code for <http://PointedEars.de/es-matrix>).

In fact, if the value is to be used in output, like non-code in a Web 
document, it is strongly recommended to use typographical quotes so as to 
improve the readability of the text.  However, few Web developers are aware 
of the benefits of Web typography; I must admit that I had not become very 
much aware of it myself before writing my thesis (in publishable texts like 
scientific works you *must* use correct typography).  Only that some longer 
time before that I had already written PHP code that automatically 
transformed “ASCII” typography into proper one for an e-book; I should 
probably refactor and reuse it now.
 

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]

#8766 — Re: UTF-8 charset

On 20/03/13 22:45, Christoph Becker wrote:
> 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?
>
works for me with a proper newsreader.


-- 
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 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web