local language

[Haris]

Hi.

I put the following line between head tags:

<meta http-equiv='Content-Type' content='text/html' charset='UTF-8' />

and now I can submit a form with Croatian characters but
when that data is entered in Postgresql table, it's entered like:
đ instead of "ð", for example.
The database language is also Croatian (character type, collation) and
encoding is utf-8.
What do I have to change to get "ð" instead od đ ?

Thanks

 

[Jukka K. Korpela]

I put the following line between head tags:

<meta http-equiv='Content-Type' content='text/html' charset='UTF-8' />

It will be ignored (by the specifications as well as in practice), if the
server sends an actula Content-Type HTTP header that conflicts with it.

That’s one reason why people should post a URL when they ask for help with a
web page.

and now I can submit a form with Croatian characters but
when that data is entered in Postgresql table, it's entered like:
đ instead of "Ä‘", for example.

That’s a common symptom of using an encoding other than UTF-8. When the
encoding of the form data (which is by default the same as the encoding of
the enclosing page, but can be set separately, too) does not contain a
character that appears in the user input, the effects are undefined. What
browsers tend to do is that they represent the offending character as a
character reference like đ. This madness in principle. This is not
something in HTML source, where such references have a defined meaning, and
this behavior implies that we cannot distinguish actual user input of
“đ†from something that made the browser generate such a notation. In
practice, it’s not that mad or bad, it’s just inconvenient (a simple
server-side parser would be needed to convert the references to UTF-8
encoded characters).

Try testing first how the form data is actually sent. Simple echo-back
scripts that you could use in a test form’s action attribute:
http://www.cs.tut.fi/cgi-bin/run/~jkorpela/echo8.cgi
It interprets its data as UTF-8. So if you get đ when you input Ä‘, then
apparently your form does _not_ handle data in UTF-8. If you get Ä‘ but the
database gets something else, then the problem is purely server-side, in the
processing transfer of incoming data.

The database language is also Croatian (character type, collation) and
encoding is utf-8.
What do I have to change to get "Ä‘" instead od đ ?

Basically to make the form data encoding UTF-8. It is best if you can do
this by setting the document's own encoding, but if you cannot, then use
enctype="utf-8" attribute in the <form> tag.

 

[Mayeul]

It will be ignored (by the specifications as well as in practice), if
the server sends an actula Content-Type HTTP header that conflicts with it.

It will be ignored, because it is something else than

<meta http-equiv='Content-Type' content='text/html; charset=UTF-8' />

 

[Jukka K. Korpela]

It will be ignored, because it is something else than

<meta http-equiv='Content-Type' content='text/html; charset=UTF-8' />

No, it will be ignored if and only if server-sent headers override it.

The use of charset="..." as an attribute of an HTML element (and not as part
of content type denotation), though non-conforming by HTML 4 specs, is so
common that browsers actually recognize it and honor it. HTML5 turns this
into a rule: you can write just <meta charset='UTF-8'>.

Demo: http://www.cs.tut.fi/~jkorpela/chars/demo.htm
Intentionally server without charset parameter in HTTP headers.
This makes a meta tag with charset attribute take effect.

 

[Mayeul]

No, it will be ignored if and only if server-sent headers override it.

The use of charset="..." as an attribute of an HTML element (and not as
part of content type denotation), though non-conforming by HTML 4 specs,
is so common that browsers actually recognize it and honor it. HTML5
turns this into a rule: you can write just <meta charset='UTF-8'>.

Demo: http://www.cs.tut.fi/~jkorpela/chars/demo.htm
Intentionally server without charset parameter in HTTP headers.
This makes a meta tag with charset attribute take effect.

I stand corrected, thank you very much.

(Now, to understand what I actually did when I thought I proved that
does not work. Probably some http header I failed to check, I guess.
Cannot reproduce. Oh well.)