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

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

Problems with accents

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

Contents

  Problems with accents andre <ahr@blabla.be> - 2018-05-17 10:01 +0200
    Re: Problems with accents Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-05-17 12:32 +0200
      Re: Problems with accents andre <pasmoi@pasici.be> - 2018-05-17 13:36 +0200
        Re: Problems with accents Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-05-17 14:31 +0200
          Re: Problems with accents Jerry Stuckle <jstucklex@attglobal.net> - 2018-05-18 08:50 -0400
        Re: Problems with accents Jerry Stuckle <jstucklex@attglobal.net> - 2018-05-18 08:55 -0400
      Re: Problems with accents Jerry Stuckle <jstucklex@attglobal.net> - 2018-05-18 08:47 -0400
    Re: Problems with accents Richard Yates <richard@yatesguitar.com> - 2018-05-17 05:58 -0700
    Re: solved: Problems with accents andre <pasmoi@pasici.be> - 2018-05-18 17:13 +0200
      Re: solved: Problems with accents Jerry Stuckle <jstucklex@attglobal.net> - 2018-05-18 13:36 -0400
        Re: solved: Problems with accents andre <pasmoi@pasici.be> - 2018-05-19 10:09 +0200
          Re: solved: Problems with accents Jerry Stuckle <jstucklex@attglobal.net> - 2018-05-19 08:48 -0400
          Re: solved: Problems with accents Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-05-19 20:18 +0200
            Re: solved: Problems with accents Jerry Stuckle <jstucklex@attglobal.net> - 2018-05-19 18:33 -0400
              Re: solved: Problems with accents "Peter H. Coffin" <hellsop@ninehells.com> - 2018-05-20 10:44 -0500

#17746 — Problems with accents

This is working well:
print "L'homme\n";
Buts this
print "<P>INPUT NAME='titre' VALUE='l\'homme'>\n";
Print only upto the appostrophe! :  l\
Any idea??
Many thanks
André
-- 
Les politiciens sont imprévoyants, et les électeurs sans mémoire!

[toc] | [next] | [standalone]

#17747

andre wrote:
^^^^^
Your last name is missing there, André no. 74656.

> This is working well:
> print "L'homme\n";
> Buts this
> print "<P>INPUT NAME='titre' VALUE='l\'homme'>\n";
> Print only upto the appostrophe! :  l\
> Any idea??

As you can see if you look at the source code of the dynamically generated 
Web document (e.g. with Ctrl+U), this generates some sort of HTML markup:

  <P>INPUT NAME='titre' VALUE='l\'homme'>

(without indentation).

But HTML is _not_ PHP; if, as you intended, you use the apostrophe as 
(“VALUE”) attribute value delimiter, then for a literal apostrophe you have 
to escape it with a character reference:

  <P>INPUT NAME='titre' VALUE='l&#39;homme'>

This can be automated with PHP:

  echo "<P>INPUT NAME='titre' VALUE='l" . htmlspecialchars("'", ENT_QUOTES) 
. "homme'>";

<https://php.net/htmlspecialchars>

(Do not use “print” unless you are interested in the return value.  
<https://php.net/print>)

In fact, if the attribute value is from a PHP value, the whole attribute 
value should be escaped:

  echo "<P>INPUT NAME='titre' VALUE='" . htmlspecialchars($value, 
ENT_QUOTES) . ">";

But if the value is fixed, in this special case it is easier, and usually 
better, to use another delimiter both for the PHP string and the HTML 
attribute value:

  echo '<P>INPUT NAME="titre" VALUE="l'homme">';

The problem does not arise in the first place if you use the *proper* 
(typographical) apostrophe:

  <P>INPUT NAME='titre' VALUE='l’homme'>


Also, your markup is syntactically wrong; a leading “<” character is missing 
for the “input” element:

  <P><input name="titre" value="l’homme">

This is still *semantically* wrong, because an “input” element does not 
belong in a paragraph (“p”) element; but, for example, in a “fieldset” 
element:

  <fieldset><input name="titre" value="l’homme"> …</fieldset>

Assuming that “l’homme” is an attribute value that is not fixed, but comes 
from a PHP value, then it is not necessary to use either “echo” or “print”;
PHP is the *P*HP *H*ypertext *P*reprocessor:

  $value = 'l’homme';

  ?><fieldset><input name="titre" value="<?= htmlspecialchars($value) ?>"> …
</fieldset>

This approach also works better with syntax highlighting.


You should avoid language-specific identifiers and values that are not 
displayed to the user.  Your code will be easier to write, and easier 
understood by others, if you choose identifiers in English, the
/lingua franca/ of computer technology.

For example, in this case a “select” element is usually the proper element, 
where the “option” elements’ values should be in English, and the element’s 
content can be in the user’s language (which can be automated with classes 
such as Zend\I18n\Translator\Translator):

  <select name="title" size="1">
    <option value="Mr.">M.</option>
    <option value="Ms.">Mme</option>
    <option value="Dr.">Dr</option>
    <option value="Prof.">Pr</option>
  </select>


If this is part of a form, it would be better to use a table anyway, where 
the table headers contain the labels and the table data are the form 
controls:

  <fieldset>
    <legend>User data</legend>
    <table>
      <tr>
        <th>Titre</th>
        <td><select name="title" size="1">
          <option value="Mr.">M.</option>
          <option value="Ms.">Mme</option>
          <option value="Dr.">Dr</option>
          <option value="Prof.">Pr</option>
        </select></td>
      </tr>
      …
    </table>
  </fieldset>

Such *HTML* basics are usually discussed in 
<news:comp.infosystems.www.authoring.html> only.


Finally, an apostrophe is _not_ an accent; both are diacritic marks.

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#17748

Le 17/05/2018 12:32, Thomas 'PointedEars' Lahn a écrit :

Many thanks.

This is made to display the result of a SQL query, but the contains of 
the database is plurilingal and some of the data are in french!!
The file called from a html form, is a php script generating HTML output.
so in fact the line is:
<P>INPUT NAME='titre' VALUE:'$Roww[0]' SIZE=60\n";
This to give users the possibility to modify a erroneous entry!


> andre wrote:
> ^^^^^
> Your last name is missing there, André no. 74656.
>
>> This is working well:
>> print "L'homme\n";
>> Buts this
>> print "<P>INPUT NAME='titre' VALUE='l\'homme'>\n";
>> Print only upto the appostrophe! :  l\
>> Any idea??
>
> As you can see if you look at the source code of the dynamically generated
> Web document (e.g. with Ctrl+U), this generates some sort of HTML markup:
>
>    <P>INPUT NAME='titre' VALUE='l\'homme'>
>
> (without indentation).
>
> But HTML is _not_ PHP; if, as you intended, you use the apostrophe as
> (“VALUE”) attribute value delimiter, then for a literal apostrophe you have
> to escape it with a character reference:
>
>    <P>INPUT NAME='titre' VALUE='l&#39;homme'>
>
> This can be automated with PHP:
>
>    echo "<P>INPUT NAME='titre' VALUE='l" . htmlspecialchars("'", ENT_QUOTES)
> . "homme'>";
>
> <https://php.net/htmlspecialchars>
>
> (Do not use “print” unless you are interested in the return value.
> <https://php.net/print>)
>
> In fact, if the attribute value is from a PHP value, the whole attribute
> value should be escaped:
>
>    echo "<P>INPUT NAME='titre' VALUE='" . htmlspecialchars($value,
> ENT_QUOTES) . ">";
>
> But if the value is fixed, in this special case it is easier, and usually
> better, to use another delimiter both for the PHP string and the HTML
> attribute value:
>
>    echo '<P>INPUT NAME="titre" VALUE="l'homme">';
>
> The problem does not arise in the first place if you use the *proper*
> (typographical) apostrophe:
>
>    <P>INPUT NAME='titre' VALUE='l’homme'>
>
>
> Also, your markup is syntactically wrong; a leading “<” character is missing
> for the “input” element:
>
>    <P><input name="titre" value="l’homme">
>
> This is still *semantically* wrong, because an “input” element does not
> belong in a paragraph (“p”) element; but, for example, in a “fieldset”
> element:
>
>    <fieldset><input name="titre" value="l’homme"> …</fieldset>
>
> Assuming that “l’homme” is an attribute value that is not fixed, but comes
> from a PHP value, then it is not necessary to use either “echo” or “print”;
> PHP is the *P*HP *H*ypertext *P*reprocessor:
>
>    $value = 'l’homme';
>
>    ?><fieldset><input name="titre" value="<?= htmlspecialchars($value) ?>"> …
> </fieldset>
>
> This approach also works better with syntax highlighting.
>
>
> You should avoid language-specific identifiers and values that are not
> displayed to the user.  Your code will be easier to write, and easier
> understood by others, if you choose identifiers in English, the
> /lingua franca/ of computer technology.
>
> For example, in this case a “select” element is usually the proper element,
> where the “option” elements’ values should be in English, and the element’s
> content can be in the user’s language (which can be automated with classes
> such as Zend\I18n\Translator\Translator):
>
>    <select name="title" size="1">
>      <option value="Mr.">M.</option>
>      <option value="Ms.">Mme</option>
>      <option value="Dr.">Dr</option>
>      <option value="Prof.">Pr</option>
>    </select>
>
>
> If this is part of a form, it would be better to use a table anyway, where
> the table headers contain the labels and the table data are the form
> controls:
>
>    <fieldset>
>      <legend>User data</legend>
>      <table>
>        <tr>
>          <th>Titre</th>
>          <td><select name="title" size="1">
>            <option value="Mr.">M.</option>
>            <option value="Ms.">Mme</option>
>            <option value="Dr.">Dr</option>
>            <option value="Prof.">Pr</option>
>          </select></td>
>        </tr>
>        …
>      </table>
>    </fieldset>
>
> Such *HTML* basics are usually discussed in
> <news:comp.infosystems.www.authoring.html> only.
>
>
> Finally, an apostrophe is _not_ an accent; both are diacritic marks.
>

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

#17749

andre wrote:

> Le 17/05/2018 12:32, Thomas 'PointedEars' Lahn a écrit :
>> But if the value is fixed, in this special case it is easier, and usually
>> better, to use another delimiter both for the PHP string and the HTML
>> attribute value:
>>
>>    echo '<P>INPUT NAME="titre" VALUE="l'homme">';
           ^------------------------------^

This is syntactically incorrect PHP code; should be at least

  echo '<P>INPUT NAME="titre" VALUE="l\'homme">';
  //   ^---------------------------------------^

instead.  [In this way, the PHP-based escaping works because the "attribute" 
value is delimited by <"> (straight quotation mark) instead.]

> The file called from a html form, is a php script generating HTML output.
> so in fact the line is:
> <P>INPUT NAME='titre' VALUE:'$Roww[0]' SIZE=60\n";

No, it is not.

> This to give users the possibility to modify a erroneous entry!

What I said before applies, then.  If the value can be entered this way 
(which AISB I do not think it should), you have to escape the previous, 
*user-provided* value for output in order to prevent code injection such
as cross-site scripting (XSS):

<https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet>

Next time, do not top-post:

<https://www.netmeister.org/news/learn2quote.html>

Also, while your real name is somewhat optional (it is considered polite), 
it is a violation of Internet standards and disregard of Network etiquette 
(Netiquette) to falsify address header fields and use foreign namespaces 
without authorization.  For example, your “pasmoi@pasici.be” is *presently* 
_not_ an e-mail address as *presently* pasici.be is not a registered second-
level domain (but may be in the future):

| Verifying <pasmoi@pasici.be>...
| Mail exchanger(s) for pasici.be: none.
| `A' record for pasici.be: 
| None, thus <pasmoi@pasici.be> is definitely not an e-mail address (no MX).

<http://www.interhack.net/pubs/munging-harmful/>

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#17753

On 5/17/2018 8:31 AM, Thomas 'PointedEars' Lahn wrote:
> andre wrote:
> 
>> Le 17/05/2018 12:32, Thomas 'PointedEars' Lahn a écrit :
>>> But if the value is fixed, in this special case it is easier, and usually
>>> better, to use another delimiter both for the PHP string and the HTML
>>> attribute value:
>>>
>>>     echo '<P>INPUT NAME="titre" VALUE="l'homme">';
>             ^------------------------------^
> 
> This is syntactically incorrect PHP code; should be at least
> 
>    echo '<P>INPUT NAME="titre" VALUE="l\'homme">';
>    //   ^---------------------------------------^
> 
> instead.  [In this way, the PHP-based escaping works because the "attribute"
> value is delimited by <"> (straight quotation mark) instead.]
>

Which will cause a problem if there is a double quote in the string.

>> The file called from a html form, is a php script generating HTML output.
>> so in fact the line is:
>> <P>INPUT NAME='titre' VALUE:'$Roww[0]' SIZE=60\n";
> 
> No, it is not.
> 

You know his code better than he does?  I do NOT think so.

>> This to give users the possibility to modify a erroneous entry!
> 
> What I said before applies, then.  If the value can be entered this way
> (which AISB I do not think it should), you have to escape the previous,
> *user-provided* value for output in order to prevent code injection such
> as cross-site scripting (XSS):
> 

You don't know what processing is done on the input.

> <https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet>
> 
> Next time, do not top-post:
> 
> <https://www.netmeister.org/news/learn2quote.html>
> 
> Also, while your real name is somewhat optional (it is considered polite),
> it is a violation of Internet standards and disregard of Network etiquette
> (Netiquette) to falsify address header fields and use foreign namespaces
> without authorization.  For example, your “pasmoi@pasici.be” is *presently*
> _not_ an e-mail address as *presently* pasici.be is not a registered second-
> level domain (but may be in the future):
> 
> | Verifying <pasmoi@pasici.be>...
> | Mail exchanger(s) for pasici.be: none.
> | `A' record for pasici.be:
> | None, thus <pasmoi@pasici.be> is definitely not an e-mail address (no MX).
> 
> <http://www.interhack.net/pubs/munging-harmful/>
> 

YOU are a violation of the Internet standards.

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

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

#17754

On 5/17/2018 7:36 AM, andre wrote:
> Le 17/05/2018 12:32, Thomas 'PointedEars' Lahn a écrit :
> 
> Many thanks.
> 
> This is made to display the result of a SQL query, but the contains of 
> the database is plurilingal and some of the data are in french!!
> The file called from a html form, is a php script generating HTML output.
> so in fact the line is:
> <P>INPUT NAME='titre' VALUE:'$Roww[0]' SIZE=60\n";
> This to give users the possibility to modify a erroneous entry!
> 
> 

You can still use htmlspecialchars() on $Roww[0] (although 
htmlentities() may be a better choice, especially since you could have 
some French characters).

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

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

#17752

On 5/17/2018 6:32 AM, the internet troll Thomas 'Pointed Head' Lahn wrote:
> andre wrote:
> ^^^^^
> Your last name is missing there, André no. 74656.
> 
You're the only one who gives a damn.  He doesn't have to give ANY name 
if he doesn't want to.

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

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

#17750

On Thu, 17 May 2018 10:01:26 +0200, andre <ahr@blabla.be> wrote:

>This is working well:
>print "L'homme\n";
>Buts this
>print "<P>INPUT NAME='titre' VALUE='l\'homme'>\n";
>Print only upto the appostrophe! :  l\
>Any idea??
>Many thanks
>André

You are missing a '<' before INPUT.

Escaping a character with a backslash is not something that works in
HTML. 

This does what you want:

print "<P><INPUT NAME='titre' VALUE='l&#39;homme'>\n";

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

#17755 — Re: solved: Problems with accents

Le 17/05/2018 10:01, andre a écrit :
> This is working well:
> print "L'homme\n";
> Buts this
> print "<P>INPUT NAME='titre' VALUE='l\'homme'>\n";
> Print only upto the appostrophe! :  l\
> Any idea??
> Many thanks
> André
As the data comes from a database, I have made the change in the entry 
procees to the db.
$TT = htmlspecialchars($Titre, ENT_QUOTES);
and oups OK.
I have a few records to update will not be too difficult.
Many thanks again
André

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

#17756 — Re: solved: Problems with accents

On 5/18/2018 11:13 AM, andre wrote:
> Le 17/05/2018 10:01, andre a écrit :
>> This is working well:
>> print "L'homme\n";
>> Buts this
>> print "<P>INPUT NAME='titre' VALUE='l\'homme'>\n";
>> Print only upto the appostrophe! :  l\
>> Any idea??
>> Many thanks
>> André
> As the data comes from a database, I have made the change in the entry 
> procees to the db.
> $TT = htmlspecialchars($Titre, ENT_QUOTES);
> and oups OK.
> I have a few records to update will not be too difficult.
> Many thanks again
> André

HTML is a scripting language for displaying data, not storing it.  You 
really don't want to store the HTML equivalents in your database.  That 
will make searching the database more complicated.  You should store the 
characters in their natural form in the database then use 
htmlspecialchars() or htmlentities() to display the characters.

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

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

#17758 — Re: solved: Problems with accents

Le 18/05/2018 19:36, Jerry Stuckle a écrit :
> On 5/18/2018 11:13 AM, andre wrote:
>> Le 17/05/2018 10:01, andre a écrit :
>>> This is working well:
>>> print "L'homme\n";
>>> Buts this
>>> print "<P>INPUT NAME='titre' VALUE='l\'homme'>\n";
>>> Print only upto the appostrophe! :  l\
>>> Any idea??
>>> Many thanks
>>> André
>> As the data comes from a database, I have made the change in the entry
>> procees to the db.
>> $TT = htmlspecialchars($Titre, ENT_QUOTES);
>> and oups OK.
>> I have a few records to update will not be too difficult.
>> Many thanks again
>> André
>
> HTML is a scripting language for displaying data, not storing it.  You
> really don't want to store the HTML equivalents in your database.  That
> will make searching the database more complicated.  You should store the
> characters in their natural form in the database then use
> htmlspecialchars() or htmlentities() to display the characters.
>
Here the problem is limited to a character you never use for searching 
the database (full text) so in my case it's a limited problem, but you 
are right better no HTML in the database.
Many thanks

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

#17759 — Re: solved: Problems with accents

On 5/19/2018 4:09 AM, andre wrote:
> Le 18/05/2018 19:36, Jerry Stuckle a écrit :
>> On 5/18/2018 11:13 AM, andre wrote:
>>> Le 17/05/2018 10:01, andre a écrit :
>>>> This is working well:
>>>> print "L'homme\n";
>>>> Buts this
>>>> print "<P>INPUT NAME='titre' VALUE='l\'homme'>\n";
>>>> Print only upto the appostrophe! :  l\
>>>> Any idea??
>>>> Many thanks
>>>> André
>>> As the data comes from a database, I have made the change in the entry
>>> procees to the db.
>>> $TT = htmlspecialchars($Titre, ENT_QUOTES);
>>> and oups OK.
>>> I have a few records to update will not be too difficult.
>>> Many thanks again
>>> André
>>
>> HTML is a scripting language for displaying data, not storing it.  You
>> really don't want to store the HTML equivalents in your database.  That
>> will make searching the database more complicated.  You should store the
>> characters in their natural form in the database then use
>> htmlspecialchars() or htmlentities() to display the characters.
>>
> Here the problem is limited to a character you never use for searching 
> the database (full text) so in my case it's a limited problem, but you 
> are right better no HTML in the database.
> Many thanks
> 

Or if you ever want to generate non-html output, such as ad hoc queries 
or reports.  Many reasons you don't want HTML in your database.


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

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

#17760 — Re: solved: Problems with accents

andre <pasmoi@pasici.be> wrote:
       ^^^^^^^^^^^^^^^^

> Le 18/05/2018 19:36, Jerry Stuckle a écrit :
>> HTML is a scripting language for displaying data, not storing it.  You
>> really don't want to store the HTML equivalents in your database.  That
>> will make searching the database more complicated.  You should store the
>> characters in their natural form in the database then use
>> htmlspecialchars() or htmlentities() to display the characters.
>
> Here the problem is limited to a character you never use for searching
> the database (full text) so in my case it's a limited problem, but you
> are right better no HTML in the database.

Yes, and another reason is that it requires more space to be stored.
There are instances where one wants to store at least some markup in a 
database, but this is not one of them.

However, HTML, the HyperText Markup Language, is (as the name says, too)
a _markup_ language, _not_ a scripting language.  (The scripting languages 
that can be used in HTML include ECMAScript implementations such as 
JavaScript, which is one of my other fields of expertise.)

> Many thanks

If only you would play by the rules…

-- 
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

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

#17761 — Re: solved: Problems with accents

On 5/19/2018 2:18 PM, Thomas 'PointedEars' Lahn wrote:
> andre <pasmoi@pasici.be> wrote:
>         ^^^^^^^^^^^^^^^^
>
> However, HTML, the HyperText Markup Language, is (as the name says, too)
> a _markup_ language, _not_ a scripting language.  (The scripting languages
> that can be used in HTML include ECMAScript implementations such as
> JavaScript, which is one of my other fields of expertise.)
> 

So please educate us - what is the difference between a scripting 
language and a markup language?

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

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

#17762 — Re: solved: Problems with accents

On Sat, 19 May 2018 18:33:47 -0400, Jerry Stuckle wrote:
> On 5/19/2018 2:18 PM, Thomas 'PointedEars' Lahn wrote:
>>
>> However, HTML, the HyperText Markup Language, is (as the name says, too)
>> a _markup_ language, _not_ a scripting language.  (The scripting languages
>> that can be used in HTML include ECMAScript implementations such as
>> JavaScript, which is one of my other fields of expertise.)
>> 
>
> So please educate us - what is the difference between a scripting 
> language and a markup language?

Oooh! Oooh! Mr Kottair, sir! Oooh! ;)

-- 
48. I will treat any beast which I control through magic or technology
    with respect and kindness. Thus if the control is ever broken, it 
    will not immediately come after me for revenge.
	--Peter Anspach's list of things to do as an Evil Overlord

[toc] | [prev] | [standalone]

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

csiph-web