I am trying to filter Turkish names from MySql database through AJAX POST, the English letter words are listing all okay however if I send Ö (which is letter O with dots) the results come for both O and Ö not only Ö
Also what I noticed is the AJAX post is send Ö as %C3%96, anybody can help?
Please bare my somewhat lengthy response.
Let's start with your second question.
%C3%96
means that the bytes 0xC3 and 0x96 are transmitted. Those two bytes encode the characterÖ
in utf-8.From this (and that your query yields the described results) I assume that you're using utf-8 all the way through.
The lexicographical order of characters of a given charset is determined by the collation used.
That's more or less an ordered list of characters. E.g. A,B,C,D,.... meaning
A<B<C
....But these lists my contain multiple characters in the same "location", e.g.
[A,Ä],B,C,D.... meaning that
A==Ä->true
___ excursion, not immediately relevant to your question ____
Let's take a look at the "name" of the character
Ö
, it'sLATIN CAPITAL LETTER O WITH DIAERESIS
.So, the base character is O, it just has some decoration(s).
Some systems/libraries allow you to specify the "granularity"/level/strength of the comparison, see e.g. Collator::setStrength of the php-intl extension.
prints
On the primary level all the involved characters (o,O,ö,Ö) are just some irrelevant variations of the character O, so all are regarded as equal.
On the secondary level the additional "feature"
WITH DIAERESIS
is taken into consideration and on the third level also whether it is a small or a capital letter.But ...MySQL doesn't exactly work that way ...so, sorry again ;-)
___ end of excursion ____
In MySQL there are collation tables that specify the order. When you select a charset you also implictly select the default collation for that charset, unless you explictly specify one. In your case the implictly selected collation is probably utf8_general_ci and it treats ö==o.
This applies to both the table defintion and charset/collation of the connection (the latter being almost irrelevant in your case).
utf8_turkish_ci on the other hand treats ö!=o. That's probably the collation you want.
When you have a table defintion like
the default collation for utf8 is chosen -> general_ci -> o=ö
You can specifiy the default collation for the table when defining it
Since you already have a table plus data, you can change the collation of the table ...but if you do it on the table level you have to use
ALTER TABLE ... CONVERT
(in case you use MODIFY, the column keeps its "original" collation).That should pretty much take care of your problem.
As a side note there is (as mentioned) a collation assigned to your connection as well. Selecting a charset means selecting a collation. I use mainly PDO when (directly) connecting to MySQL and my default connection code looks like this
note the
charset=utf8
; no collation, so again general_ci is assigned to the connection. And that's whyprints
1
meaning o==ö. The string literals used in the statement are treated as utf8/utf8_general_ci.I could either specify the collation for the string literal explicitly in the statement
(only setting it for one of the two literals/operands; for why and how this works see Collation of Expressions)
or I can set the connection collation via
both result in
printing
0
.edit: and to complicate things even a bit further:
The charset
utf8
can't represent all possible characters. There's an even broader character setutf8mb4
.