Jump to content
php.lv forumi
Sign in to follow this  
jurchiks

mysql true unicode support

Recommended Posts

Server version: 5.5.37-0ubuntu0.14.04.1-log - (Ubuntu)

Server charset: UTF-8 Unicode (utf8)

 

Ir tabula ar 2 kolonnām:

`letter` VARCHAR(1) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,

`searchQuery` VARCHAR(255) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL

 

Satur datus grupēšanai pēc pirmā burta no searchQuery (lowercase). Piemēra dati:

a - Atpūta

ā - Ādas Vāki

 

Problēma - izpildot šādu kveriju:

SELECT DISTINCT `letter` FROM `table_x` ORDER BY `letter` ASC

 

resultsets uztver burtus 'a' un 'ā' kā vienādus, t.i. rezultāts nesatur burtu 'ā', tikai burtu 'a'. Tāpat arī secība ir fucked up - latviešu burti seko tikai pēc latīņu 'z', un krievu burti - pēc latviešu 'ž'.

 

Nomainot `letter` datu tipu uz utf8_bin, parādījās arī 'ā', taču secība vienalga ir fucked up.

 

Kā panākt, ka burti izvadās kaut cik loģiskā secībā (vismaz latviešu un angļu burti, krievu var arī būt beigās, jo viņiem alfabēts citādāk izkārtots)?

Vai man varbūt PHP pusē datus sortēt ar natsort()?

 

Edit: ok, izskatās, ka man te ir vēl citas problēmas, PHP masīvu keys nav unicode, man teksts "Matu fēni" atrodas gan zem latīņu 'm', gan zem krievu 'м'. Ehh...

Edited by jurchiks

Share this post


Link to post
Share on other sites

utf8_general_ci un ar kārtošanu nevajadzētu būt problēmām.

Protams, krievu burti būs pēc ž, tas it kā loģiski, jo nav nekāda kopēja pasaules alfabēta

 

a un ā ir vienādi tikai tā nolūka dēļ, lai kārtošana strādātu pareizi. Tobiš, lai ā nebūtu pēc z

 

Padalies ar info, ja atrisini DISTINCT a ā problēmu

Share this post


Link to post
Share on other sites

Kāda velna pēc 'utf8_general_ci' sortē pareizi, bet 'utf8_unicode_ci' sortē kaut kā randomā?

Un diemžēl DISTINCT/GROUP BY tas neatrisina... Būs jāprasa stackoverflow.

Share this post


Link to post
Share on other sites

Aptuvenais risinājums iegūts:

http://stackoverflow.com/questions/24466208/mysql-select-distinct-letters-including-extended-latin-characters

 

"SELECT DISTINCT BINARY `letter` FROM `texts`"

strādā pareizi, bet

"SELECT DISTINCT BINARY `letter` FROM `texts` ORDER BY `letter` ASC"

sačakarē secību, latviešu burti vienalga ir pēc z.

 

P.S. phpMyAdmin tekstus izvada kaut kādā fucked up formātā (piemēram, 'ā' rādās kā 'c481'). Adminer gan visu rāda normāli.

Share this post


Link to post
Share on other sites

Notestē pie sevis tukšā tabulā. Saliec testa datus un paskaties kā tad kārto. Pamēģināju pie sevis un viss kārtībā - atlasa gan a gan ā un kārto pareizi

Rezultās pēc SELECT DISTINCT BINARY title FROM `kartosana` ORDER BY title

 

a
ā
z
ž
яблоко

 

Izskatās, ka tev dati visādos random character setos tajā tabulā. Gadījumā agrāk tabulas laukam nebija latin1 uzlikts? Un tagad pārliki uz utf8_general_ci?

Edited by Kasspars

Share this post


Link to post
Share on other sites

Mja, izdzēsu tabulu, uztaisīju pa jaunam, uzģenerēju datus, tagad sortē normāli. Pašā sākumā tabula bija utf8_unicode_ci, pēc tam mainīju gan uz utf8_bin, gan uz utf8_general_ci, gan utf8mb4_bin/general_ci/unicode_ci.

Nesmuki kaut kā.

 

Man visur ir tikai UTF-8.

Share this post


Link to post
Share on other sites

Ok, tomēr pat no nulles uzģenerējot, ū burts nāk pirms u...

Šeit ir tabula ar visiem reālajiem datiem: http://pastebin.com/cH2DUzf3

Izpildot to SQL uz testa datubāzes un pēc tam pieprasot

 

SELECT DISTINCT BINARY `letter` FROM `texts` ORDER BY `letter` ASC

 

rezultātā 'ū' ir pirms 'u'. Kā to var izskaidrot?

Edited by jurchiks

Share this post


Link to post
Share on other sites

Tad tev labāk būtu izmantot utf8_latvian_ci, vienīgi tad jātestē kā kārtošana būs ar krievu burtiem

 

Cik dažādas valodas tev tabulā glabājas?

Share this post


Link to post
Share on other sites

Angļu, latviešu, krievu.

Bet pēc būtības basic latin characteriem vienmēr būtu jābūt PIRMS extended latin.

Share this post


Link to post
Share on other sites

Bet pēc būtības basic latin characteriem vienmēr būtu jābūt PIRMS extended latin

Nē. Tieši COLLATION definē kāda būs characteru secība

 

Pats arī visu laiku domāju, ka utf8_general_ci ir zelta vidusceļš, bet tomēr redz, ka ū ir pirms u. Ar utf8_latvian_ci viss kartībā, tā tieši domāta mūsu burtiem.

Share this post


Link to post
Share on other sites

Bet jebkurā gadījumā, u vienmēr vajadzētu būt pirms ū. Tā kā basic hierarhija - u ir pamatklase, ū ir subklase.

Tas taču nav loģiski, ka visi burti ir pareizi sakārtoti, izņemot vienu šitādu spoku.

Turklāt man tajā tabulā nākotnē būs arī lietuviešu un, iespējams, arī igauņu teksti, tā kā izmantot utf8_latvian_ci ir vienkārši nepareizi.

 

+ stackoverflow tauta man darīja zināmu, ka utf8_general_ci īstenībā ir baigais sūds: http://stackoverflow.com/a/1036459/540394

Sucks for me, jo man visa datubāze ir utf8_general_ci...

Edited by jurchiks

Share this post


Link to post
Share on other sites

Uz normāliem nesačakarēties datiem tak neesi testējis utf8_unicode_ci, vai ne? :D

 

utf8_unicode_ci

SELECT DISTINCT BINARY title FROM `kartosana` ORDER BY title ASC

a
ā
u
ū
z
ž
а
б
ё
ж

Share this post


Link to post
Share on other sites

Esmu. Bet es cenšos saprast, kas manos datos tāds "sačakarēts", ka vienu vienīgu burtu kārto nepareizā secībā. Dati ir tajā pastebinā, ja tev ir idejas, please, do share.

Share this post


Link to post
Share on other sites

Ja ā ID būs lielāks par a, tad šajā gadījumā ā būs pirms a. 

 

 

utf8_unicode_ci

ORDER BY title ASC

 

id, title
12,ā
110,a
151,c
152,č
16,ū
150,u
14,ž
130,z
17,а
18,б
19,ё
20,ж
 
Laikam jāiet gulēt :D

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...