| Rejecting Certain Non-ASCII Characters [message #181149] |
Fri, 19 April 2013 16:16  |
Jim Higgins
Messages: 20
Registered: November 2010
Karma: 0
|
Junior Member |
|
|
I have a problem with people entering a slashed zero vs a standard
ASCII zero into HTML forms intended to store data in a MySQL database.
Is there a simple way in PHP to restrict input to the ASCII Character
set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
characters outside this range before committing them to the database?
My mind says it should be easy to detect and that I should be able to
do it myself, but for some reason I'm drawing a huge blank.
Thank you.
|
|
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181151 is a reply to message #181149] |
Fri, 19 April 2013 16:30  |
Daniel Pitts
Messages: 68
Registered: May 2012
Karma: 0
|
Member |
|
|
On 4/19/13 9:16 AM, Jim Higgins wrote:
>
> I have a problem with people entering a slashed zero vs a standard
> ASCII zero into HTML forms intended to store data in a MySQL database.
>
> Is there a simple way in PHP to restrict input to the ASCII Character
> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
> characters outside this range before committing them to the database?
>
> My mind says it should be easy to detect and that I should be able to
> do it myself, but for some reason I'm drawing a huge blank.
>
> Thank you.
>
Are they literally putting "\0", or do you mean it is sending the byte 0
(where "0" is the byte 48)?
If they are putting "\0", then this indicates you are not escaping the
string appropriately. Don't filter it, escape it.
If it is the byte 0, then that is a very unusual thing for them to submit.
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181154 is a reply to message #181149] |
Fri, 19 April 2013 16:48 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/19/2013 12:16 PM, Jim Higgins wrote:
>
> I have a problem with people entering a slashed zero vs a standard
> ASCII zero into HTML forms intended to store data in a MySQL database.
>
> Is there a simple way in PHP to restrict input to the ASCII Character
> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
> characters outside this range before committing them to the database?
>
> My mind says it should be easy to detect and that I should be able to
> do it myself, but for some reason I'm drawing a huge blank.
>
> Thank you.
>
Short of parsing the string some way, no.
If it's a short string, you could loop through it character by
character. Longer strings might benefit from a regex.
But be aware just because YOU are working with an ASCII charset, not
everyone is.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181155 is a reply to message #181149] |
Fri, 19 April 2013 17:38 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jim Higgins wrote:
> I have a problem with people entering a slashed zero vs a standard
> ASCII zero into HTML forms intended to store data in a MySQL database.
Is it really a slashed zero (U+0030 U+0338) they're entering, or do they
enter some similar looking character such as the Danish Ø? In the
former case you can simply replace the slashed zero with a standard
zero. Assuming UTF-8 encoding:
$input = str_replace('\xCC\xB8', '', $input);
> Is there a simple way in PHP to restrict input to the ASCII Character
> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
> characters outside this range before committing them to the database?
If you're dealing with a numeric column, you may consider checking for
is_numeric().
--
Christoph M. Becker
|
|
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181165 is a reply to message #181155] |
Fri, 19 April 2013 20:33 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Becker wrote:
> Jim Higgins wrote:
>> I have a problem with people entering a slashed zero vs a standard
>> ASCII zero into HTML forms intended to store data in a MySQL database.
>
> Is it really a slashed zero (U+0030 U+0338) they're entering,
Could also be U+0030 U+337 or any other (allowed composition) of the at
least 65536 Unicode characters that look(s) similar. For example, it could
be U+2205 EMPTY SET.
> or do they enter some similar looking character such as the Danish Ø?
That character, U+00D8 LATIN CAPITAL LETTER O WITH STROKE *and* its
lowercase counterpart, U+00F8 LATIN SMALL LETTER O WITH STROKE, are present
at least in Danish, Norwegian, and Faroese; They are also used in the
International Phonetic Alphabet (IPA).
> In the former case you can simply replace the slashed zero with a standard
> zero. Assuming UTF-8 encoding:
>
> $input = str_replace('\xCC\xB8', '', $input);
You do not consider that, ambiguity aside, even in UTF-8 there are *several*
ways to produce Unicode characters. See: Unicode Normalization Forms.
>> Is there a simple way in PHP to restrict input to the ASCII Character
>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>> characters outside this range before committing them to the database?
>
> If you're dealing with a numeric column, you may consider checking for
> is_numeric().
There are also regular expressions. Testing against '/[^\0x00-\x7F]/', and
rejecting anything that matches, appears to be the best approach here. If
characters actually should be converted, iconv() should be used instead of a
hardcoded conversion.
However, it is better in the long term to convert the MySQL database (or the
relevant table and column) to utf8_general_ci, and upgrade MySQL if
necessary (character sets and collations were not supported before MySQL 5;
the current stable version is 5.6).
<http://php.net/pcre>
<http://dev.mysql.com/>
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(at)news(dot)demon(dot)co(dot)uk>
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181166 is a reply to message #181165] |
Fri, 19 April 2013 21:08 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
>
>> Jim Higgins wrote:
>>> I have a problem with people entering a slashed zero vs a standard
>>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>
>> Is it really a slashed zero (U+0030 U+0338) they're entering,
>
> Could also be U+0030 U+337 or any other (allowed composition) of the at
> least 65536 Unicode characters that look(s) similar. For example, it could
> be U+2205 EMPTY SET.
Which I was referring to in a abbreviated form in the rest of the
sentence. :)
>> or do they enter some similar looking character such as the Danish Ø?
>
> That character, U+00D8 LATIN CAPITAL LETTER O WITH STROKE *and* its
> lowercase counterpart, U+00F8 LATIN SMALL LETTER O WITH STROKE, are present
> at least in Danish, Norwegian, and Faroese; They are also used in the
> International Phonetic Alphabet (IPA).
>
>> In the former case you can simply replace the slashed zero with a standard
>> zero. Assuming UTF-8 encoding:
>>
>> $input = str_replace('\xCC\xB8', '', $input);
>
> You do not consider that, ambiguity aside, even in UTF-8 there are *several*
> ways to produce Unicode characters. See: Unicode Normalization Forms.
If I'm not mistaken here, this str_replace() will work for NFD and NFC,
but indeed I had not considered NFKD and NFKC. Thanks for pointing this
out.
>>> Is there a simple way in PHP to restrict input to the ASCII Character
>>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>>> characters outside this range before committing them to the database?
>>
>> If you're dealing with a numeric column, you may consider checking for
>> is_numeric().
>
> There are also regular expressions. Testing against '/[^\0x00-\x7F]/', and
> rejecting anything that matches, appears to be the best approach here.
For a numeric column? Why not at least trim down the possibilites of
setting illegal values for the SQL statement?
> If
> characters actually should be converted, iconv() should be used instead of a
> hardcoded conversion.
>
> However, it is better in the long term to convert the MySQL database (or the
> relevant table and column) to utf8_general_ci, and upgrade MySQL if
> necessary (character sets and collations were not supported before MySQL 5;
> the current stable version is 5.6).
>
> <http://php.net/pcre>
> <http://dev.mysql.com/>
--
Christoph M. Becker
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181167 is a reply to message #181151] |
Fri, 19 April 2013 21:38 |
Jim Higgins
Messages: 20
Registered: November 2010
Karma: 0
|
Junior Member |
|
|
On Fri, 19 Apr 2013 09:30:54 -0700, in
<2ject.401871$Nq4(dot)359760(at)newsfe21(dot)iad>, Daniel Pitts
<newsgroup(dot)nospam(at)virtualinfinity(dot)net> wrote:
> On 4/19/13 9:16 AM, Jim Higgins wrote:
>>
>> I have a problem with people entering a slashed zero vs a standard
>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>
>> Is there a simple way in PHP to restrict input to the ASCII Character
>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>> characters outside this range before committing them to the database?
>>
>> My mind says it should be easy to detect and that I should be able to
>> do it myself, but for some reason I'm drawing a huge blank.
>>
>> Thank you.
>>
>
> Are they literally putting "\0", or do you mean it is sending the byte 0
> (where "0" is the byte 48)?
>
> If they are putting "\0", then this indicates you are not escaping the
> string appropriately. Don't filter it, escape it.
>
> If it is the byte 0, then that is a very unusual thing for them to submit.
Where I want to see byte 48 (decimal) they are sending the code for a
zero with a slash thru it. When displaying the data on an HTML page
it appears as "A~" consisting of 0x41 0x7E hex (65 254 decimal.)
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181168 is a reply to message #181154] |
Fri, 19 April 2013 21:46 |
Jim Higgins
Messages: 20
Registered: November 2010
Karma: 0
|
Junior Member |
|
|
On Fri, 19 Apr 2013 12:48:14 -0400, in <kkrsb6$lec$1(at)dont-email(dot)me>,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
> On 4/19/2013 12:16 PM, Jim Higgins wrote:
>>
>> I have a problem with people entering a slashed zero vs a standard
>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>
>> Is there a simple way in PHP to restrict input to the ASCII Character
>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>> characters outside this range before committing them to the database?
>>
>> My mind says it should be easy to detect and that I should be able to
>> do it myself, but for some reason I'm drawing a huge blank.
>>
>> Thank you.
>>
>
> Short of parsing the string some way, no.
>
> If it's a short string, you could loop through it character by
> character. Longer strings might benefit from a regex.
The strings are very short, 1 - 7 characters.
> But be aware just because YOU are working with an ASCII charset, not
> everyone is.
I'm not looking for worldwide compatibility. My primary concern is
with the annoying affectation a few users have of using a slashed zero
in place of a just plain zero. None are using a non-ASCII character
set otherwise.
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181171 is a reply to message #181168] |
Fri, 19 April 2013 22:00 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/19/2013 5:46 PM, Jim Higgins wrote:
> On Fri, 19 Apr 2013 12:48:14 -0400, in <kkrsb6$lec$1(at)dont-email(dot)me>,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>
>> On 4/19/2013 12:16 PM, Jim Higgins wrote:
>>>
>>> I have a problem with people entering a slashed zero vs a standard
>>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>>
>>> Is there a simple way in PHP to restrict input to the ASCII Character
>>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>>> characters outside this range before committing them to the database?
>>>
>>> My mind says it should be easy to detect and that I should be able to
>>> do it myself, but for some reason I'm drawing a huge blank.
>>>
>>> Thank you.
>>>
>>
>> Short of parsing the string some way, no.
>>
>> If it's a short string, you could loop through it character by
>> character. Longer strings might benefit from a regex.
>
>
> The strings are very short, 1 - 7 characters.
>
>> But be aware just because YOU are working with an ASCII charset, not
>> everyone is.
>
> I'm not looking for worldwide compatibility. My primary concern is
> with the annoying affectation a few users have of using a slashed zero
> in place of a just plain zero. None are using a non-ASCII character
> set otherwise.
>
I understand - but YOU have to be aware that people ARE using different
charsets, and handle it according to what YOUR needs are.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181172 is a reply to message #181155] |
Fri, 19 April 2013 22:06 |
Jim Higgins
Messages: 20
Registered: November 2010
Karma: 0
|
Junior Member |
|
|
On Fri, 19 Apr 2013 19:38:02 +0200, in
<kkrvda$od5$1(at)speranza(dot)aioe(dot)org>, Christoph Becker <cmbecker69(at)gmx(dot)de>
wrote:
> Jim Higgins wrote:
>> I have a problem with people entering a slashed zero vs a standard
>> ASCII zero into HTML forms intended to store data in a MySQL database.
>
> Is it really a slashed zero (U+0030 U+0338) they're entering, or do they
> enter some similar looking character such as the Danish Ø? In the
> former case you can simply replace the slashed zero with a standard
> zero. Assuming UTF-8 encoding:
>
> $input = str_replace('\xCC\xB8', '', $input);
It's usually 0x41 0x7E, but sometimes 0xD8. Rather than do
replacement I'd just like to detect and give them an error message
telling them to use their keyboard zero vs Alt Key plus numeric pad to
create special characters.
>> Is there a simple way in PHP to restrict input to the ASCII Character
>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>> characters outside this range before committing them to the database?
>
> If you're dealing with a numeric column, you may consider checking for
> is_numeric().
Thank you. That will solve half the problem - the case where data is
numeric only. The other half of the issue is string fields containing
mixed alpha/numeric.
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181173 is a reply to message #181167] |
Fri, 19 April 2013 22:11 |
Jim Higgins
Messages: 20
Registered: November 2010
Karma: 0
|
Junior Member |
|
|
On Fri, 19 Apr 2013 21:38:31 +0000, in
<etd3n8paphvs1mp97ts8povdkaecg9u5in(at)4ax(dot)com>, Jim Higgins
<ILikeMy(at)Privacy(dot)bogus> wrote:
> On Fri, 19 Apr 2013 09:30:54 -0700, in
> <2ject.401871$Nq4(dot)359760(at)newsfe21(dot)iad>, Daniel Pitts
> <newsgroup(dot)nospam(at)virtualinfinity(dot)net> wrote:
>
>> On 4/19/13 9:16 AM, Jim Higgins wrote:
>>>
>>> I have a problem with people entering a slashed zero vs a standard
>>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>>
>>> Is there a simple way in PHP to restrict input to the ASCII Character
>>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>>> characters outside this range before committing them to the database?
>>>
>>> My mind says it should be easy to detect and that I should be able to
>>> do it myself, but for some reason I'm drawing a huge blank.
>>>
>>> Thank you.
>>>
>>
>> Are they literally putting "\0", or do you mean it is sending the byte 0
>> (where "0" is the byte 48)?
>>
>> If they are putting "\0", then this indicates you are not escaping the
>> string appropriately. Don't filter it, escape it.
>>
>> If it is the byte 0, then that is a very unusual thing for them to submit.
>
>
> Where I want to see byte 48 (decimal) they are sending the code for a
> zero with a slash thru it. When displaying the data on an HTML page
> it appears as "A~" consisting of 0x41 0x7E hex (65 254 decimal.)
Make that 65 126 decimal.
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181175 is a reply to message #181172] |
Fri, 19 April 2013 22:26 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jim Higgins wrote:
> On Fri, 19 Apr 2013 19:38:02 +0200, in
> <kkrvda$od5$1(at)speranza(dot)aioe(dot)org>, Christoph Becker <cmbecker69(at)gmx(dot)de>
> wrote:
>
>> Jim Higgins wrote:
>>> I have a problem with people entering a slashed zero vs a standard
>>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>
>> Is it really a slashed zero (U+0030 U+0338) they're entering, or do they
>> enter some similar looking character such as the Danish Ø? In the
>> former case you can simply replace the slashed zero with a standard
>> zero. Assuming UTF-8 encoding:
>>
>> $input = str_replace('\xCC\xB8', '', $input);
>
>
> It's usually 0x41 0x7E, but sometimes 0xD8.
0xD8 is Ø in ISO-8859-1 for example; I do not know which character
encoding represents the same or a similar character as 0x41 0x7E.
Anyway, ISTM you're missing to enforce a particular character encoding
for your document (see <http://www.w3.org/TR/html4/charset.html> for
HTML 4.01 documents).
> Rather than do
> replacement I'd just like to detect and give them an error message
> telling them to use their keyboard zero vs Alt Key plus numeric pad to
> create special characters.
>
>
>>> Is there a simple way in PHP to restrict input to the ASCII Character
>>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>>> characters outside this range before committing them to the database?
>>
>> If you're dealing with a numeric column, you may consider checking for
>> is_numeric().
>
>
> Thank you. That will solve half the problem - the case where data is
> numeric only. The other half of the issue is string fields containing
> mixed alpha/numeric.
Then you should have a look at the answers of Arno
(<news:5171A6C4(dot)7010706(at)arnowelzel(dot)de>) and Thomas
(<news:62120436(dot)b0HzOcHmYY(at)PointedEars(dot)de>), who recommend using
ctype_print() resp. the regular expression '/[^\0x00-\x7F]/'.
--
Christoph M. Becker
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181177 is a reply to message #181166] |
Fri, 19 April 2013 23:12 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> Jim Higgins wrote:
>>>> Is there a simple way in PHP to restrict input to the ASCII Character
>>>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>>>> characters outside this range before committing them to the database?
>>>
>>> If you're dealing with a numeric column, you may consider checking for
>>> is_numeric().
>>
>> There are also regular expressions. Testing against '/[^\0x00-\x7F]/',
>> and rejecting anything that matches, appears to be the best approach
>> here.
>
> For a numeric column? Why not at least trim down the possibilites of
^^^^^^^^^^^^^^^^
> setting illegal values for the SQL statement?
A numeric column is *your* idea. The questions I have answered were the
ones that were *actually* asked:
| Is there a simple way in PHP to restrict input to the ASCII Character
| set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
| characters outside this range before committing them to the database?
The character at US-ASCII code point 0x7E is _not_ a digit in any number
base.
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(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181178 is a reply to message #181168] |
Fri, 19 April 2013 23:23 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Jim Higgins wrote:
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>> But be aware just because YOU are working with an ASCII charset, not
>> everyone is.
ACK.
> I'm not looking for worldwide compatibility.
On the World Wide Web, most certainly you should. US-ASCII is simply
obsolete there, because it hinders more than it helps. The default
character encoding for HTTP/1.0 and later is ISO-8859-1 (which AFAIK is
PHP's default, too), and using UTF-8 or UTF-16 becomes increasingly common
both on the Web and in current operating systems (see e. g. the percent
encoding in RFC 3986 how to handle that). Most recently, IDNs have been
introduced.
PHP is fully equipped to deal with that (through functions), even though it
has no native Unicode string support.
> My primary concern is with the annoying affectation a few users have of
> using a slashed zero in place of a just plain zero. None are using a non
> ASCII character set otherwise.
One problem with helping you with your problem is that the term “slashed
zero” actually is _not_ well-defined.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181181 is a reply to message #181175] |
Fri, 19 April 2013 23:53 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/19/2013 6:26 PM, Christoph Becker wrote:
> Jim Higgins wrote:
>> On Fri, 19 Apr 2013 19:38:02 +0200, in
>> <kkrvda$od5$1(at)speranza(dot)aioe(dot)org>, Christoph Becker <cmbecker69(at)gmx(dot)de>
>> wrote:
>>
>>> Jim Higgins wrote:
>>>> I have a problem with people entering a slashed zero vs a standard
>>>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>>
>>> Is it really a slashed zero (U+0030 U+0338) they're entering, or do they
>>> enter some similar looking character such as the Danish Ø? In the
>>> former case you can simply replace the slashed zero with a standard
>>> zero. Assuming UTF-8 encoding:
>>>
>>> $input = str_replace('\xCC\xB8', '', $input);
>>
>>
>> It's usually 0x41 0x7E, but sometimes 0xD8.
>
> 0xD8 is Ø in ISO-8859-1 for example; I do not know which character
> encoding represents the same or a similar character as 0x41 0x7E.
> Anyway, ISTM you're missing to enforce a particular character encoding
> for your document (see <http://www.w3.org/TR/html4/charset.html> for
> HTML 4.01 documents).
>
This is a recommendation only. The browser is free to ignore it. There
is no way to force a browser to do anything in HTML.
>> Rather than do
>> replacement I'd just like to detect and give them an error message
>> telling them to use their keyboard zero vs Alt Key plus numeric pad to
>> create special characters.
>>
>>
>>>> Is there a simple way in PHP to restrict input to the ASCII Character
>>>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>>>> characters outside this range before committing them to the database?
>>>
>>> If you're dealing with a numeric column, you may consider checking for
>>> is_numeric().
>>
>>
>> Thank you. That will solve half the problem - the case where data is
>> numeric only. The other half of the issue is string fields containing
>> mixed alpha/numeric.
>
> Then you should have a look at the answers of Arno
> (<news:5171A6C4(dot)7010706(at)arnowelzel(dot)de>) and Thomas
> (<news:62120436(dot)b0HzOcHmYY(at)PointedEars(dot)de>), who recommend using
> ctype_print() resp. the regular expression '/[^\0x00-\x7F]/'.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181184 is a reply to message #181181] |
Sat, 20 April 2013 00:36 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> On 4/19/2013 6:26 PM, Christoph Becker wrote:
>> Jim Higgins wrote:
>>> On Fri, 19 Apr 2013 19:38:02 +0200, in
>>> <kkrvda$od5$1(at)speranza(dot)aioe(dot)org>, Christoph Becker <cmbecker69(at)gmx(dot)de>
>>> wrote:
>>>
>>>> Jim Higgins wrote:
>>>> > I have a problem with people entering a slashed zero vs a standard
>>>> > ASCII zero into HTML forms intended to store data in a MySQL database.
>>>>
>>>> Is it really a slashed zero (U+0030 U+0338) they're entering, or do
>>>> they
>>>> enter some similar looking character such as the Danish Ø? In the
>>>> former case you can simply replace the slashed zero with a standard
>>>> zero. Assuming UTF-8 encoding:
>>>>
>>>> $input = str_replace('\xCC\xB8', '', $input);
>>>
>>>
>>> It's usually 0x41 0x7E, but sometimes 0xD8.
>>
>> 0xD8 is Ø in ISO-8859-1 for example; I do not know which character
>> encoding represents the same or a similar character as 0x41 0x7E.
>> Anyway, ISTM you're missing to enforce a particular character encoding
>> for your document (see <http://www.w3.org/TR/html4/charset.html> for
>> HTML 4.01 documents).
>>
>
> This is a recommendation only. The browser is free to ignore it. There
> is no way to force a browser to do anything in HTML.
The mentioned W3C recommendation also elaborates on the "charset"
parameter of the "Content-Type" header, which should be respected by all
user agents conforming to RFC 2616, if they have requested the URI with
a suitable "Accept-Charset" header. Otherwise the PHP script may
respond with "406 Not acceptable" (and a body explaining the requirements).
--
Christoph M. Becker
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181187 is a reply to message #181184] |
Sat, 20 April 2013 00:58 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/19/2013 8:36 PM, Christoph Becker wrote:
> Jerry Stuckle wrote:
>> On 4/19/2013 6:26 PM, Christoph Becker wrote:
>>> Jim Higgins wrote:
>>>> On Fri, 19 Apr 2013 19:38:02 +0200, in
>>>> <kkrvda$od5$1(at)speranza(dot)aioe(dot)org>, Christoph Becker <cmbecker69(at)gmx(dot)de>
>>>> wrote:
>>>>
>>>> > Jim Higgins wrote:
>>>> >> I have a problem with people entering a slashed zero vs a standard
>>>> >> ASCII zero into HTML forms intended to store data in a MySQL database.
>>>> >
>>>> > Is it really a slashed zero (U+0030 U+0338) they're entering, or do
>>>> > they
>>>> > enter some similar looking character such as the Danish Ø? In the
>>>> > former case you can simply replace the slashed zero with a standard
>>>> > zero. Assuming UTF-8 encoding:
>>>> >
>>>> > $input = str_replace('\xCC\xB8', '', $input);
>>>>
>>>>
>>>> It's usually 0x41 0x7E, but sometimes 0xD8.
>>>
>>> 0xD8 is Ø in ISO-8859-1 for example; I do not know which character
>>> encoding represents the same or a similar character as 0x41 0x7E.
>>> Anyway, ISTM you're missing to enforce a particular character encoding
>>> for your document (see <http://www.w3.org/TR/html4/charset.html> for
>>> HTML 4.01 documents).
>>>
>>
>> This is a recommendation only. The browser is free to ignore it. There
>> is no way to force a browser to do anything in HTML.
>
> The mentioned W3C recommendation also elaborates on the "charset"
> parameter of the "Content-Type" header, which should be respected by all
> user agents conforming to RFC 2616, if they have requested the URI with
> a suitable "Accept-Charset" header. Otherwise the PHP script may
> respond with "406 Not acceptable" (and a body explaining the requirements).
>
SHOULD BE RESPECTED is the key phrase here.
All HTML is recommendations - including the charset. Not all browsers
follow all recommendations - or follow them the same way.
It does not guarantee you will not get non-ASCII characters, especially
if the user is using a non-ASCII charset.
And PHP will not respond with a 406 unless the user sends a 406. PHP
has no idea what charset is set in the outgoing header.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181191 is a reply to message #181187] |
Sat, 20 April 2013 01:34 |
Christoph Becker
Messages: 91
Registered: June 2012
Karma: 0
|
Member |
|
|
Jerry Stuckle wrote:
> On 4/19/2013 8:36 PM, Christoph Becker wrote:
>> Jerry Stuckle wrote:
>>> On 4/19/2013 6:26 PM, Christoph Becker wrote:
>>>> Jim Higgins wrote:
>>>> > On Fri, 19 Apr 2013 19:38:02 +0200, in
>>>> > <kkrvda$od5$1(at)speranza(dot)aioe(dot)org>, Christoph Becker <cmbecker69(at)gmx(dot)de>
>>>> > wrote:
>>>> >
>>>> >> Jim Higgins wrote:
>>>> >>> I have a problem with people entering a slashed zero vs a standard
>>>> >>> ASCII zero into HTML forms intended to store data in a MySQL
>>>> >>> database.
>>>> >>
>>>> >> Is it really a slashed zero (U+0030 U+0338) they're entering, or do
>>>> >> they
>>>> >> enter some similar looking character such as the Danish Ø? In the
>>>> >> former case you can simply replace the slashed zero with a standard
>>>> >> zero. Assuming UTF-8 encoding:
>>>> >>
>>>> >> $input = str_replace('\xCC\xB8', '', $input);
>>>> >
>>>> >
>>>> > It's usually 0x41 0x7E, but sometimes 0xD8.
>>>>
>>>> 0xD8 is Ø in ISO-8859-1 for example; I do not know which character
>>>> encoding represents the same or a similar character as 0x41 0x7E.
>>>> Anyway, ISTM you're missing to enforce a particular character encoding
>>>> for your document (see <http://www.w3.org/TR/html4/charset.html> for
>>>> HTML 4.01 documents).
>>>>
>>>
>>> This is a recommendation only. The browser is free to ignore it. There
>>> is no way to force a browser to do anything in HTML.
>>
>> The mentioned W3C recommendation also elaborates on the "charset"
>> parameter of the "Content-Type" header, which should be respected by all
>> user agents conforming to RFC 2616, if they have requested the URI with
>> a suitable "Accept-Charset" header. Otherwise the PHP script may
>> respond with "406 Not acceptable" (and a body explaining the
>> requirements).
>>
>
> SHOULD BE RESPECTED is the key phrase here.
>
> All HTML is recommendations - including the charset.
A HTTP response header has nothing to do with HTML as you know.
> Not all browsers
> follow all recommendations - or follow them the same way.
>
> It does not guarantee you will not get non-ASCII characters, especially
> if the user is using a non-ASCII charset.
I didn't want to suggest to send
Content-Type: text/html; charset=ASCII
I merely noticed, that a developer should be aware of charset issues and
do the best he can to /minimize/ unexpected or even arbitrary behavior.
Letting the user agent /guess/ how the response is encoded
(respectively rely on the webserver's default), and how it should encode
the follow-up request is surely not the best solution.
> And PHP will not respond with a 406 unless the user sends a 406. PHP
> has no idea what charset is set in the outgoing header.
Of course. Therefore I've written "the PHP script ...". The word
"script" was intended to imply, that the script author is responsible
for doing this.
--
Christoph M. Becker
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181194 is a reply to message #181149] |
Sat, 20 April 2013 08:04 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 19.04.2013 18:16, schrieb Jim Higgins:
>
> I have a problem with people entering a slashed zero vs a standard
> ASCII zero into HTML forms intended to store data in a MySQL database.
>
> Is there a simple way in PHP to restrict input to the ASCII Character
> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
> characters outside this range before committing them to the database?
>
> My mind says it should be easy to detect and that I should be able to
> do it myself, but for some reason I'm drawing a huge blank.
>
I skipped the long discussion, it looks like having little to do with your question.
Input data has to be filtered, IN ANY CASE, plus properly escaped upon insertion into
the database.
For number input, do something like
$val = sscanf($_POST[$key], '%d')
for signed numbers, or
preg_match('#^[0-9]+$#', $_POST[$key])
for ASCII numbers. Other helpful functions are cast to integer, ctype_digit(), ...
/Str.
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181196 is a reply to message #181166] |
Sat, 20 April 2013 12:08 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> In the former case you can simply replace the slashed zero with a
>>> standard zero. Assuming UTF-8 encoding:
>>>
>>> $input = str_replace('\xCC\xB8', '', $input);
>>
>> You do not consider that, ambiguity aside, even in UTF-8 there are
>> *several*
>> ways to produce Unicode characters. See: Unicode Normalization Forms.
>
> If I'm not mistaken here, this str_replace() will work for NFD and NFC,
> but indeed I had not considered NFKD and NFKC. Thanks for pointing this
> out.
[I admit that Unicode Normalization Forms are tricky. Even I did not know
the full range of their complexities before your posting, so thank you for
making me look into it more thoroughly.]
AIUI, your approach will work reliably *only* for Normalization Form D
(NFD), which is the result of “Canonical *D*ecomposition” [1].
Normalization Form C (NFC) is the result of “Canonical Decomposition,
followed by Canonical *C*omposition“ (ibid.) That is, if there is a
character in Unicode that is a composition of the used glyphs, then there
will be no code sequence for a combination character for you to remove.
[NFKD and NFKC are entirely different animals: The NFKD of U+1E9B (“ẛ”)
U+0323 is *U+0073* (“s”) U+0323 U+0307; its NFKC is *U+1E69* (“ṩ”).]
For example, if the original character was U+212B ANGSTROM SIGN (“Å”), then
with NFC there will be only a code sequence for U+00C5 LATIN CAPITAL LETTER
A WITH RING ABOVE (“Å”), and you will not find a code sequence for U+030A
COMBINING RING ABOVE that you could remove in order to get the US-ASCII-
compliant U+0041 LATIN CAPITAL LETTER A (“A”).
However, apparently iconv(), which I suggested, cannot help here either:
$ php -r 'echo iconv("UTF-8", "US-ASCII", "-\xE2\x84\xAB-") . "\n";'
PHP Notice: iconv(): Detected an illegal character in input string in
Command line code on line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
PHP 2. iconv() Command line code:1
-
$ php -r 'echo iconv("UTF-8", "US-ASCII//TRANSLIT", "-\xE2\x84\xAB-") .
"\n";'
-?-
$ php -r 'echo iconv("UTF-8", "US-ASCII//IGNORE", "-\xE2\x84\xAB-") . "\n";'
PHP Notice: iconv(): Detected an illegal character in input string in
Command line code on line 1
PHP Stack trace:
PHP 1. {main}() Command line code:0
PHP 2. iconv() Command line code:1
--
(Expected: -A-)
It might be possible using recode_string(), but I have not found out yet
how. My PHP was not compiled “--with-recode” and I can only get recode(1)
to print “"A” for “Ä”, which is not helpful here.
PointedEars
___________
[1] <http://www.unicode.org/reports/tr15/tr15-37.html>
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181197 is a reply to message #181194] |
Sat, 20 April 2013 12:15 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
M. Strobel wrote:
> Am 19.04.2013 18:16, schrieb Jim Higgins:
>> I have a problem with people entering a slashed zero vs a standard
>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>
>> Is there a simple way in PHP to restrict input to the ASCII Character
>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>> characters outside this range before committing them to the database?
>>
>> My mind says it should be easy to detect and that I should be able to
>> do it myself, but for some reason I'm drawing a huge blank.
>
> I skipped the long discussion, it looks like having little to do with your
> question.
>
> Input data has to be filtered, IN ANY CASE, plus properly escaped upon
> insertion into the database.
>
> For number input, do something like
>
> $val = sscanf($_POST[$key], '%d')
>
> for signed numbers, or
>
> preg_match('#^[0-9]+$#', $_POST[$key])
>
> for ASCII numbers. Other helpful functions are cast to integer,
> ctype_digit(), ...
Nobody said anything about numbers before, though, and with your From header
field value you are *still* violating the Acceptable Use Policy of your
Usenet service provider, uni-berlin.de.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181199 is a reply to message #181197] |
Sat, 20 April 2013 12:26 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 20.04.2013 14:15, schrieb Thomas 'PointedEars' Lahn:
> M. Strobel wrote:
>
>> Am 19.04.2013 18:16, schrieb Jim Higgins:
>>> I have a problem with people entering a slashed zero vs a standard
>>> ASCII zero into HTML forms intended to store data in a MySQL database.
>>>
>>> Is there a simple way in PHP to restrict input to the ASCII Character
>>> set, specifically hex 0x20 - 0x7E ? Or a simple way to detect
>>> characters outside this range before committing them to the database?
>>>
>>> My mind says it should be easy to detect and that I should be able to
>>> do it myself, but for some reason I'm drawing a huge blank.
>>
>> I skipped the long discussion, it looks like having little to do with your
>> question.
>>
>> Input data has to be filtered, IN ANY CASE, plus properly escaped upon
>> insertion into the database.
>>
>> For number input, do something like
>>
>> $val = sscanf($_POST[$key], '%d')
>>
>> for signed numbers, or
>>
>> preg_match('#^[0-9]+$#', $_POST[$key])
>>
>> for ASCII numbers. Other helpful functions are cast to integer,
>> ctype_digit(), ...
>
> Nobody said anything about numbers before, though, and with your From header
> field value you are *still* violating the Acceptable Use Policy of your
> Usenet service provider, uni-berlin.de.
>
>
> PointedEars
>
My code can be easily adapted. And then:
Wall Street Journal online
http://online.wsj.com/article/SB10001424052748704805204575594423931135084.h tml#
or Reuters
http://www.reuters.com/article/2011/03/17/us-eu-internet-privacy-idUSTRE72G 48Z20110317
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181200 is a reply to message #181199] |
Sat, 20 April 2013 12:34 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
M. Strobel wrote:
> Am 20.04.2013 14:15, schrieb Thomas 'PointedEars' Lahn:
>> M. Strobel wrote:
>>> For number input, do something like
>>>
>>> $val = sscanf($_POST[$key], '%d')
>>>
>>> for signed numbers, or
>>>
>>> preg_match('#^[0-9]+$#', $_POST[$key])
>>>
>>> for ASCII numbers. Other helpful functions are cast to integer,
>>> ctype_digit(), ...
>>
>> Nobody said anything about numbers before, though, and with your From
>> header field value you are *still* violating the Acceptable Use Policy of
>> your Usenet service provider, uni-berlin.de.
>
> My code can be easily adapted.
Your code is a repetition of what was posted before (by me), and does not
relate to the question at all, which was how to *reject* strings with
certain characters.
> And then:
> [tl;dr]
You should tell that to your service provider after they canceled your
account, so that they will at least have a good laugh.
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(at)news(dot)demon(dot)co(dot)uk>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181210 is a reply to message #181202] |
Sat, 20 April 2013 15:43 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 20.04.2013 14:41, schrieb Arno Welzel:
> M. Strobel, 2013-04-20 14:26:
>
> [...]
>> My code can be easily adapted. And then:
>>
>> Wall Street Journal online
>>
>> http://online.wsj.com/article/SB10001424052748704805204575594423931135084.h tml#
>>
>> or Reuters
>>
>> http://www.reuters.com/article/2011/03/17/us-eu-internet-privacy-idUSTRE72G 48Z20110317
>
> If you don't want to use a valid address, then use
>
> <invalid(at)invalid(dot)invalid>
>
> Also see <http://www.individual.de/faq.php#5.3>
>
> Did you get it now?
>
>
Get what? This domain exists:
str@suse122-intel:~/Desktop> dig nowhere.dee @208.67.222.222
; <<>> DiG 9.9.2-P2 <<>> nowhere.dee @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17975
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 16384
;; QUESTION SECTION:
;nowhere.dee. IN A
;; ANSWER SECTION:
nowhere.dee. 0 IN A 67.215.65.132
;; Query time: 68 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sat Apr 20 17:42:03 2013
;; MSG SIZE rcvd: 56
/Str.
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181211 is a reply to message #181196] |
Sat, 20 April 2013 15:52 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> However, apparently iconv(), which I suggested, cannot help here either:
>
> $ php -r 'echo iconv("UTF-8", "US-ASCII", "-\xE2\x84\xAB-") . "\n";'
> PHP Notice: iconv(): Detected an illegal character in input string in
> Command line code on line 1
> PHP Stack trace:
> PHP 1. {main}() Command line code:0
> PHP 2. iconv() Command line code:1
> -
>
> $ php -r 'echo iconv("UTF-8", "US-ASCII//TRANSLIT", "-\xE2\x84\xAB-") .
> "\n";'
> -?-
>
> $ php -r 'echo iconv("UTF-8", "US-ASCII//IGNORE", "-\xE2\x84\xAB-") .
> "\n";'
> PHP Notice: iconv(): Detected an illegal character in input string in
> Command line code on line 1
> PHP Stack trace:
> PHP 1. {main}() Command line code:0
> PHP 2. iconv() Command line code:1
> --
>
> (Expected: -A-)
>
> It might be possible using recode_string(), but I have not found out yet
> how. My PHP was not compiled “--with-recode” and I can only get recode(1)
> to print “"A” for “Ä”, which is not helpful here.
On the other hand:
$ php -r 'echo iconv("UTF-8", "US-ASCII//TRANSLIT", \
"-Ȧ-Århus-\x30\xCC\xB8-") . "\n";'
-A-AArhus-0-
So while iconv() does not do Unicode normalization, it can be helpful here
(you can replace “AArhus” unambiguously with the correct alternative
spelling for the city, “Aarhus”, for example).
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
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181212 is a reply to message #181210] |
Sat, 20 April 2013 16:01 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
M. Strobel wrote:
> Am 20.04.2013 14:41, schrieb Arno Welzel:
>> If you don't want to use a valid address, then use
>>
>> <invalid(at)invalid(dot)invalid>
>>
>> Also see <http://www.individual.de/faq.php#5.3>
>>
>> Did you get it now?
>
> Get what? This domain exists:
>
> str@suse122-intel:~/Desktop> dig nowhere.dee @208.67.222.222
>
> ; <<>> DiG 9.9.2-P2 <<>> nowhere.dee @208.67.222.222
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17975
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 16384
> ;; QUESTION SECTION:
> ;nowhere.dee. IN A
>
> ;; ANSWER SECTION:
> nowhere.dee. 0 IN A 67.215.65.132
>
> ;; Query time: 68 msec
> ;; SERVER: 208.67.222.222#53(208.67.222.222)
> ;; WHEN: Sat Apr 20 17:42:03 2013
> ;; MSG SIZE rcvd: 56
It figures that you would post the non-authoritative answer from your
misconfigured nameserver to support your anti-social behavior. That does
not make your From header field value technically valid or socially
acceptable, though, because an *address* there has to have at least a FQDN,
which nowhere.dee is no where near to. (There is no registry for the dee
TLD to begin with. Not *yet*, that is.)
Perhaps someone should inform your service provider to *make* you heed the
rules.
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(at)news(dot)demon(dot)co(dot)uk>
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181213 is a reply to message #181212] |
Sat, 20 April 2013 16:17 |
M. Strobel
Messages: 386
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
Am 20.04.2013 18:01, schrieb Thomas 'PointedEars' Lahn:
> M. Strobel wrote:
>
>> Am 20.04.2013 14:41, schrieb Arno Welzel:
>>> If you don't want to use a valid address, then use
>>>
>>> <invalid(at)invalid(dot)invalid>
>>>
>>> Also see <http://www.individual.de/faq.php#5.3>
>>>
>>> Did you get it now?
>>
>> Get what? This domain exists:
>>
>> str@suse122-intel:~/Desktop> dig nowhere.dee @208.67.222.222
>>
>> ; <<>> DiG 9.9.2-P2 <<>> nowhere.dee @208.67.222.222
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17975
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 16384
>> ;; QUESTION SECTION:
>> ;nowhere.dee. IN A
>>
>> ;; ANSWER SECTION:
>> nowhere.dee. 0 IN A 67.215.65.132
>>
>> ;; Query time: 68 msec
>> ;; SERVER: 208.67.222.222#53(208.67.222.222)
>> ;; WHEN: Sat Apr 20 17:42:03 2013
>> ;; MSG SIZE rcvd: 56
>
> It figures that you would post the non-authoritative answer from your
> misconfigured nameserver to support your anti-social behavior. That does
> not make your From header field value technically valid or socially
> acceptable, though, because an *address* there has to have at least a FQDN,
> which nowhere.dee is no where near to. (There is no registry for the dee
> TLD to begin with. Not *yet*, that is.)
>
> Perhaps someone should inform your service provider to *make* you heed the
> rules.
Haha, gotcha, you did not understand what happens.
This was one of the spamming name servers, they give an address for anything... Never
heard of it? Time to learn.
/Str.
|
|
|
|
| Address munging (was: Rejecting Certain Non-ASCII Characters) [message #181214 is a reply to message #181213] |
Sat, 20 April 2013 16:23 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
È á Path: textnews.cambrium.nl!feeder1.cambriumusenet.nl!feed.tweaknews.nl!193.141.40 .65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news feed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Content-Type: text/plain; charset="ISO-8859-1"
Message-ID: <7018846(dot)Vpm0sXdiuA(at)PointedEars(dot)de>
From: Thomas 'PointedEars' Lahn <PointedEars(at)web(dot)de>
Reply-To: Thomas 'PointedEars' Lahn <php(at)PointedEars(dot)de>
Organization: PointedEars Software (PES)
Date: Sat, 20 Apr 2013 18:23:56 +0200
User-Agent: KNode/4.8.5
Content-Transfer-Encoding: 7Bit
X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <b';Md8`dH6iqhT)6C^.Px|[=M@7=Ik[_w<%n1Up"LPQNu2m8|L!/3iby{-]A+#YE}Kl{Cw$\U!kD%K}\2jz "QQP6Uqr],./"?;=4v
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEf y7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4 jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkk PbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5D OjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrm F2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4 LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTc IKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2Ed Lo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbC nPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYN rgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v /DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2 AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg==
Subject: Address munging (was: Rejecting Certain Non-ASCII Characters)
Newsgroups: comp.lang.php,news.admin.net-abuse.usenet
References: <qfq2n85a3pb4eegtf7buji0o8ern0r838m(at)4ax(dot)com> <atf0h1Fkts9U1(at)mid(dot)uni-berlin(dot)de> <4433483(dot)hWCz3MVrGr(at)PointedEars(dot)de> <atffreFo8fpU1(at)mid(dot)uni-berlin(dot)de> <51728CE8(dot)7010404(at)arnowelzel(dot)de> <atfrchFqpq0U1(at)mid(dot)uni-berlin(dot)de> <5681296(dot)HGuM2lx8Zy(at)PointedEars(dot)de> <atftcrFr6r7U1(at)mid(dot)uni-berlin(dot)de>
Followup-To: news.admin.net-abuse.usenet
MIME-Version: 1.0
Lines: 69
NNTP-Posting-Date: 20 Apr 2013 18:25:14 CEST
NNTP-Posting-Host: b3d4722c.newsspool4.arcor-online.net
X-Trace: DXC=XLlTafVM`KU@@RW1FjIB5S4IUK<Cl32<Q4Fo<]lROoRQ8kF<OcfhCO[9aNUc68?K]XDZm8W4\YJN\b@mF9jNikdUBoKGPB=12AW\2IPTbT6;nT
X-Complaints-To: usenet-abuse(at)arcor(dot)de
Xref: textnews.cambrium.nl comp.lang.php:140712 news.admin.net-abuse.usenet:134183
M. Strobel wrote:
> Am 20.04.2013 18:01, schrieb Thomas 'PointedEars' Lahn:
>> M. Strobel wrote:
>>> Am 20.04.2013 14:41, schrieb Arno Welzel:
>>>> If you don't want to use a valid address, then use
>>>>
>>>> <invalid(at)invalid(dot)invalid>
>>>>
>>>> Also see <http://www.individual.de/faq.php#5.3>
>>>>
>>>> Did you get it now?
>>>
>>> Get what? This domain exists:
>>>
>>> str@suse122-intel:~/Desktop> dig nowhere.dee @208.67.222.222
>>>
>>> ; <<>> DiG 9.9.2-P2 <<>> nowhere.dee @208.67.222.222
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17975
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>>>
>>> ;; OPT PSEUDOSECTION:
>>> ; EDNS: version: 0, flags:; udp: 16384
>>> ;; QUESTION SECTION:
>>> ;nowhere.dee. IN A
>>>
>>> ;; ANSWER SECTION:
>>> nowhere.dee. 0 IN A 67.215.65.132
>>>
>>> ;; Query time: 68 msec
>>> ;; SERVER: 208.67.222.222#53(208.67.222.222)
>>> ;; WHEN: Sat Apr 20 17:42:03 2013
>>> ;; MSG SIZE rcvd: 56
>>
>> It figures that you would post the non-authoritative answer from your
>> misconfigured nameserver to support your anti-social behavior. That does
>> not make your From header field value technically valid or socially
>> acceptable, though, because an *address* there has to have at least a
>> FQDN, which nowhere.dee is no where near to. (There is no registry for
>> the dee TLD to begin with. Not *yet*, that is.)
>>
>> Perhaps someone should inform your service provider to *make* you heed
>> the rules.
>
> Haha, gotcha, you did not understand what happens.
>
> This was one of the spamming name servers, they give an address for
> anything... Never heard of it?
No, I am not in need of their services.
> Time to learn.
Why should I learn about how to commit network abuse best? I for one obey
the forms.
Instead, it is about time for *you* to learn what an address header is
before someone makes you to.
X-Post & F'up2 news.admin.net-abuse.usenet
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(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181217 is a reply to message #181210] |
Sat, 20 April 2013 22:06 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sat, 20 Apr 2013 17:43:13 +0200, M. Strobel wrote:
> Get what? This domain (nowhere.dee) exists ...
<?php
$hosts[] = "localhost";
$hosts[] = "nowhere.dee";
$hosts[] = "invalid.invalid";
$hosts[] = "example.com";
foreach ( $hosts as $host ) {
$ip = gethostbyname( $host );
if ( $ip == $host )
echo "Error - {$host} - host not found\n";
else
echo "{$host} has ip address {$ip}\n";
}
gives output:
localhost has ip address 127.0.0.1
Error - nowhere.dee - host not found
Error - invalid.invalid - host not found
example.com has ip address 192.0.43.10
What you have defined locally is irrelevant. Internet domains do not
exist unless their tld is registered with the internet GTLD root servers,
and there is a dns query path to the relevant domain nameserver from the
internet GTLD root servers.
If you must obscure your email address, I suggest you use
email(at)example(dot)com instead. Using <something>@invalid.invalid is just as
bad as using any other made up domain name. (see <http://www.iana.org/
domains/special> )
postmaster@localhost is of course another possibility, and should be
valid everywhere.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181220 is a reply to message #181216] |
Sun, 21 April 2013 00:03 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2013 3:29 PM, Arno Welzel wrote:
> Jerry Stuckle, 2013-04-20 15:04:
>
>> On 4/20/2013 8:55 AM, Arno Welzel wrote:
>>> Jerry Stuckle, 2013-04-20 14:43:
>>>
>>>> On 4/20/2013 8:41 AM, Arno Welzel wrote:
>>>> > M. Strobel, 2013-04-20 14:26:
>>>> >
>>>> > [...]
>>>> >> My code can be easily adapted. And then:
>>>> >>
>>>> >> Wall Street Journal online
>>>> >>
>>>> >> http://online.wsj.com/article/SB10001424052748704805204575594423931135084.h tml#
>>>> >>
>>>> >> or Reuters
>>>> >>
>>>> >> http://www.reuters.com/article/2011/03/17/us-eu-internet-privacy-idUSTRE72G 48Z20110317
>>>> >
>>>> > If you don't want to use a valid address, then use
>>>> >
>>>> > <invalid(at)invalid(dot)invalid>
>>>> >
>>>> > Also see <http://www.individual.de/faq.php#5.3>
>>>> >
>>>> > Did you get it now?
>>>> >
>>>> >
>>>>
>>>> What does this have to do with PHP, troll?
>>>
>>> You forgot to ask this M. Strobel and Thomas Lahn as well...
>>>
>>>
>>
>> Answer the question, troll. What does this have to do with PHP?
>
>
> <http://www.individual.de/faq.php#5.3> is an example for the use of PHP
> (PHP 5.3.3 to be precise) ;-)
>
>
ROFLMAO, troll. Did you even read it? (Unlike you, I do understand
German, although I'm a bit rusty since it has been over 40 years...)
You can't even answer the question. How like a troll!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: Rejecting Certain Non-ASCII Characters [message #181221 is a reply to message #181208] |
Sun, 21 April 2013 00:06 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 4/20/2013 10:07 AM, The Natural Philosopher wrote:
> On 20/04/13 13:55, Arno Welzel wrote:
>> Jerry Stuckle, 2013-04-20 14:43:
>>
>>> On 4/20/2013 8:41 AM, Arno Welzel wrote:
>>>> M. Strobel, 2013-04-20 14:26:
>>>>
>>>> [...]
>>>> > My code can be easily adapted. And then:
>>>> >
>>>> > Wall Street Journal online
>>>> >
>>>> > http://online.wsj.com/article/SB10001424052748704805204575594423931135084.h tml#
>>>> >
>>>> >
>>>> > or Reuters
>>>> >
>>>> > http://www.reuters.com/article/2011/03/17/us-eu-internet-privacy-idUSTRE72G 48Z20110317
>>>> >
>>>> If you don't want to use a valid address, then use
>>>>
>>>> <invalid(at)invalid(dot)invalid>
>>>>
>>>> Also see <http://www.individual.de/faq.php#5.3>
>>>>
>>>> Did you get it now?
>>>>
>>>>
>>> What does this have to do with PHP, troll?
>> You forgot to ask this M. Strobel and Thomas Lahn as well...
>>
> give him some raw fish and he will go back under his bridge.
>
>
>
Ah, yes, the troll who uses a 'nym because he's scared to death that
someone will find out he's really an out-of-work ditch digger and not
the programmer or EE he claims to be strikes again!
Keep it up, TNP. The more you do, the more people who are laughing at
you. After all, nobody takes you seriously.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]