Fulltext search! Vai vajag tabulas tipu Binary?

[Venom]

kad proxy nogriezti, izmantojam

www.google.lv > cached version ;)

 

SELECT BINARY ...

[bubu]

Venom: UTF-8 NAV divbaitīgs simbolu kodējums, tāds ir UTF-16

Gacha: manuālis jau defaultā, html formātā nāk līdzi mysql-am. Es personīgi izmantoju šo: http://phlab.net/myman/ - tas ir tas pats, tikai .chm formātā.

[Gacha]

SQL => Select BINARY * from vardadienas where vardi Like'%$vards%' Nu tagad man neatgriež neko, tas laikam tapēc, ka tam laukam atributs nav BINARY. Tad man nāksies lauku pārtaisīt :(

[Venom]

par UTF-8 es pastrīdētos, jo tas pats vien UTF-16 ir, tikai "angļu" burtiem (kas sakrīt ASCII pamata tabulu) nav tas high order bits vaikāviņutursauc, kas nosaka no kuras code page būs nākošais simbols

 

yup-yup manuālis iekš chm ir labs (tikai kā teu tur ar linux un chm ies, nezinu gan)

/me ikdienā pielieto php un mysql iekš chm, ir arī daži priekš html un css

[bubu]

Šeit: http://en.wikipedia.org/wiki/UTF-8 (un arī daudzkur citur līdzīgi redzams) ir ļoti skaista tabuliņa, kur ir parādīts, kā attēlojās konkrēti ASCII simboli UTF-8 un UTF-16 kodējumos. Kā redzams, to garumi NAV vienādi. Tātad tas nav viens un tas pats.

[Venom]

SQL => Select BINARY * from vardadienas where vardi Like'%$vards%' Nu tagad man neatgriež neko, tas laikam tapēc, ka tam laukam atributs nav BINARY. Tad man nāksies lauku pārtaisīt :(

laukam (kolonnai) _nav_ tāda atribūta

tā ir SELECT mehānisma iekšējā pārslēgopcija (ķipa izmantot case-sensitive vai case-insensitive funkcijas)

 

ar %% jābūt uzmanīgam, jo UTF-8 stringiem priekšā var būt tāds "neredzams" strings (UTF-cookie, signature), un % ne vienmēr pareizi "sašķels" tālāko stringu bez pareizā utf-8 supporta, e.g.

J|x y|n|i|s, kur xy ir ā iekš utf-8

zj|x|y|n|i|s - kur z ir multi-byte cookie

% ne vienmēr ņem pretī gadījumu, kad vērtība sākas ar meklējamo tekstu (tāpēc es augšā sarakstīju tos daudzos OR)

[Venom]

Šeit: http://en.wikipedia.org/wiki/UTF-8 (un arī daudzkur citur līdzīgi redzams) ir ļoti skaista tabuliņa, kur ir parādīts, kā attēlojās konkrēti ASCII simboli UTF-8 un UTF-16 kodējumos. Kā redzams, to garumi NAV vienādi. Tātad tas nav viens un tas pats.

however iekš UTF-8 var būt 2 baiti vienam burtam un decimālajās vērtības tie "baiti" var sakrist, jo vienam iekšējais "iztēlojums" ir binary, otram - hex

 

whatever, tālāk neiedziļināsimies

[Gacha]

Nu tagad viss ir štokos, es pielietoju explode metodi un tagad tas atrod visu ko vajaga. Tnx jums par padomiem!

[bubu]

however iekš UTF-8 var būt 2 baiti vienam burtam un decimālajās vērtības tie "baiti" var sakrist, jo vienam iekšējais "iztēlojums" ir binary, otram - hex

 

whatever, tālāk neiedziļināsimies

Nē, iedziļināsimies gan! Tur jau ir tā UTF-8 priekšrocība, ka viš ir diezgan back-ward savietojams, jo otrais un tālākie baiti nekad nebūs mazāki par 128. Tamdēļ vārds UTF-8 kodējumā nekad netīšām nesakritīs ar citu vārdu, ja izmanto parastus ascii simbolus.

[Venom]

un kā ar FIND_IN_SET ?

[Gacha]

un kā ar FIND_IN_SET ?

Ja šis bija man, tad es to neizmēģināju, jo nav tagad man tas manuālis un nav arī man uzlikts mysql, tapec nav man arī tas uz kompa. Vēlāk iečekošu :)