Whenever I insert a geographical coordinate in database or even in
textfile after submit, for example 15=B016'18''
it ends op like 15=C2=B016'18''. =E9, =E0, =E7, =E8, ... ends up funny too.=
It
shows ok when displayed on webpage. But it is hardly readable in
database or in textfile.
I've created 3 different tables with 3 different collations
(utf8_unicode_ci, latin1_bin, latin_swedish_ci) each with 3 fields
(varchar with the 3 different collations) 9 posibilities. All with the
same result. When I input via phpMyAdmin it works fine: I see
15=B016'18'' in all the tables and all the columns. So it must be
somthing I do or don't do when submitting the information. When I
ouput the contents of the $_POST to a textfield it also shows 15=C2
=B016'18'' on linux (cli) en wordpad on windows. Shows ok in notepad.
I've tried changing the http-equiv=3D"Content-Type", using
stripslashes(strip_tags(trim(urldecode(on the post-variables))))
Problem is I have to do test on the contents of the fields (once they
are in database) so for example for geographical coordinates I want to
find '=B0' and not '=C2=B0'.

Help,

Pugi!

On 19 Feb, 14:37, "Pugi!" <pugin... [at] gmail.com> wrote:
> Whenever I insert a geographical coordinate in database or even in
> textfile after submit, for example 15=B016'18''
> it ends op like 15=C2=B016'18''. =E9, =E0, =E7, =E8, ... ends up funny to=
o=2E It
> shows ok when displayed on webpage. But it is hardly readable in
> database or in textfile.
> I've created 3 different tables with 3 different collations
> (utf8_unicode_ci, latin1_bin, latin_swedish_ci) each with 3 fields
> (varchar with the 3 different collations) 9 posibilities. All with the
> same result. When I input via phpMyAdmin it works fine: I see
> 15=B016'18'' in all the tables and all the columns. So it must be
> somthing I do or don't do when submitting the information. When I
> ouput the contents of the $_POST to a textfield it also shows 15=C2
> =B016'18'' on linux (cli) en wordpad on windows. Shows ok in notepad.
> I've tried changing the http-equiv=3D"Content-Type", using
> stripslashes(strip_tags(trim(urldecode(on the post-variables))))
> Problem is I have to do test on the contents of the fields (once they
> are in database) so for example for geographical coordinates I want to
> find '=B0' and not '=C2=B0'.
>
> Help,
>
> Pugi!

Whilst not exactly an answer to your original question, might I
suggest that you shouldn't be storing the symbols in the first place.
A coordinate is a value. You should store them as values and then
apply formatting for display.

Pugi! wrote:
> Whenever I insert a geographical coordinate in database or even in
> textfile after submit, for example 15°16'18''
> it ends op like 15°16'18''. é, à, ç, è, ... ends up funny too. It
> shows ok when displayed on webpage. But it is hardly readable in
> database or in textfile.

You store UTF-8 characters into your database/files, you still need
UTF-8 support in the terminal where you display the result, most people
still uses some sort of ISO8859, in which character with values over 127
will be represented with a "dual 8-bit character". As the browser is set
to display UTF-8 it will be shown correctly.

You can in worst case use utf_decode()/utf_encode()

--

//Aho

On 19 Feb, 14:37, "Pugi!" <pugin... [at] gmail.com> wrote:
> Whenever I insert a geographical coordinate in database or even in
> textfile after submit, for example 15=B016'18''
> it ends op like 15=C2=B016'18''. =E9, =E0, =E7, =E8, ... ends up funny to=
o=2E It
> shows ok when displayed on webpage. But it is hardly readable in
> database or in textfile.
> I've created 3 different tables with 3 different collations
> (utf8_unicode_ci, latin1_bin, latin_swedish_ci) each with 3 fields
> (varchar with the 3 different collations) 9 posibilities. All with the
> same result. When I input via phpMyAdmin it works fine: I see
> 15=B016'18'' in all the tables and all the columns. So it must be
> somthing I do or don't do when submitting the information. When I
> ouput the contents of the $_POST to a textfield it also shows 15=C2
> =B016'18'' on linux (cli) en wordpad on windows. Shows ok in notepad.
> I've tried changing the http-equiv=3D"Content-Type", using
> stripslashes(strip_tags(trim(urldecode(on the post-variables))))
> Problem is I have to do test on the contents of the fields (once they
> are in database) so for example for geographical coordinates I want to
> find '=B0' and not '=C2=B0'.
>
> Help,
>
> Pugi!

Whilst not exactly an answer to your original question, might I
suggest that you shouldn't be storing the symbols in the first place.
A coordinate is a value. You should store them as values and then
apply formatting for display.

Pugi! wrote:
> Whenever I insert a geographical coordinate in database or even in
> textfile after submit, for example 15°16'18''
> it ends op like 15°16'18''. é, à, ç, è, ... ends up funny too. It
> shows ok when displayed on webpage. But it is hardly readable in
> database or in textfile.

You store UTF-8 characters into your database/files, you still need
UTF-8 support in the terminal where you display the result, most people
still uses some sort of ISO8859, in which character with values over 127
will be represented with a "dual 8-bit character". As the browser is set
to display UTF-8 it will be shown correctly.

You can in worst case use utf_decode()/utf_encode()

--

//Aho

On 19 Feb, 16:47, "J.O. Aho" <u... [at] example.net> wrote:
> Pugi! wrote:
> > Whenever I insert a geographical coordinate in database or even in
> > textfile after submit, for example 15=B016'18''
> > it ends op like 15=C2=B016'18''. =E9, =E0, =E7, =E8, ... ends up funny =
too. It
> > shows ok when displayed on webpage. But it is hardly readable in
> > database or in textfile.
>
> You store UTF-8 characters into your database/files, you still need
> UTF-8 support in the terminal where you display the result, most people
> still uses some sort of ISO8859, in which character with values over 127
> will be represented with a "dual 8-bit character". As the browser is set
> to display UTF-8 it will be shown correctly.
>
> You can in worst case use utf_decode()/utf_encode()
>
> --
>
> //Aho

Yes it is all down to character encoding and php's bad support for
utf8, you have to work quite hard to make sure that utf8 is used in
all the places where
php is run
rendering takes place
data transfer (php<->database, php<->browser
data storage

you can set the browser display using
header( 'Content-Type: text/html; charset=3Dutf8' );

you must be aware that most php function are not utf8 aware, you have
to be careful which ones you use, and where there are no mb_
(multibyte) equivalents you must seek to set them to be utf8 aware, if
you can't you cannot use them, unless you are prepared then to convert
back at the earliest point.

The data transport between mysql and php never uses utf8, you have to
force that (fake it) to (mysql connection collation utf-8 unicode
utf8)
make sure your mysql databases, tables, and individual fields are
using the right character sets.

On top of this, make sure that you edit those utf8 docs in a utf8
editor.

Fun isn't it. Do all that, and make it a habit, and you'll be fine.

On 19 Feb, 16:47, "J.O. Aho" <u... [at] example.net> wrote:
> Pugi! wrote:
> > Whenever I insert a geographical coordinate in database or even in
> > textfile after submit, for example 15=B016'18''
> > it ends op like 15=C2=B016'18''. =E9, =E0, =E7, =E8, ... ends up funny =
too. It
> > shows ok when displayed on webpage. But it is hardly readable in
> > database or in textfile.
>
> You store UTF-8 characters into your database/files, you still need
> UTF-8 support in the terminal where you display the result, most people
> still uses some sort of ISO8859, in which character with values over 127
> will be represented with a "dual 8-bit character". As the browser is set
> to display UTF-8 it will be shown correctly.
>
> You can in worst case use utf_decode()/utf_encode()
>
> --
>
> //Aho

Yes it is all down to character encoding and php's bad support for
utf8, you have to work quite hard to make sure that utf8 is used in
all the places where
php is run
rendering takes place
data transfer (php<->database, php<->browser
data storage

you can set the browser display using
header( 'Content-Type: text/html; charset=3Dutf8' );

you must be aware that most php function are not utf8 aware, you have
to be careful which ones you use, and where there are no mb_
(multibyte) equivalents you must seek to set them to be utf8 aware, if
you can't you cannot use them, unless you are prepared then to convert
back at the earliest point.

The data transport between mysql and php never uses utf8, you have to
force that (fake it) to (mysql connection collation utf-8 unicode
utf8)
make sure your mysql databases, tables, and individual fields are
using the right character sets.

On top of this, make sure that you edit those utf8 docs in a utf8
editor.

Fun isn't it. Do all that, and make it a habit, and you'll be fine.