Fulltext index og danske tegn

For det foerste kan du aendre varedien (det er ft_min_word_len som default er 4).

Hvilket charset bruger du?

http://dev.mysql.com/doc/refman/5.5/en/fulltext-restrictions.html naevner hvad der kan bruges og hvad der ikke kan bruges.

Jeg tvivler på at jeg kan (få lov) at ændre ft_min_word_len - det er jo en "global variabel", og jeg ligger på en "virtuel" server (på Servage.net)
- Skal dog forsøges!

Jeg bruger UTF-8 overalt - og søgningen virker sådan set fint : )
- det er bare svært at forklare reglen for brugerne, når jeg ikke selv har gennemskuet den : )

Hvis det er en VPS kan du da netop aendre det.

Vil en "mindst 4 ASCII tegn" regel passe med det du observerer?

Jeg fik vist brugt et forkert "kodeord" virtuel..
- jeg har bare en www-mappe - MySQL-serveren ligger på en anden iP-adresse.

#5 Desværre ikke

"tælle" nej - "tæller" ja
"skøde" nej - "skøder" ja
"skærm" / "skærme" nej - "skærmen" ja

Og endnu mere sært:

Jeg finder "tønder" ved søgning efter "bønder" / "hænder" / "ånder"

"æbler" findes med: "åbler", "øbler", "ÿbler", "knÿbler", "$bler", "sløkråbler"

Ikke-ascii-tegn indgår slet ikke indgår i indexet (som andet end luft)
= der bare skal være 4 matchende ascii-tegn i træk

Men så enkelt er det ikke - i nogle tilfælde er 3 ascii-tegn nok:
Både "blæbørgråd" og "rgrÿ" (men ikke "ÿrgr") finder "blåbærgrød"

Kan ÆØÅ blive opfattet som ord adskillelse?

Sådan ser det desværre ud herfra : (

Men jeg kan næsten ikke tro det.
- det gør jo fulltext-søgninger nærmest ubrugelige på ikke-engelsk..


Mistænker at det er min forbindelse (connection) til MySQL(i) den er gal med.
(Søgning efter "æbler" finder (også) "bler" - som om æ'et slet ikke eksisterer)

På trods af at alt andet (æøå-relateret) fungerer perfekt..

Jeg kan med "Mysql Query Browser" se diverse "characterset / collation" halløj med:
"SHOW VARIABLES LIKE 'c%'"

Dér optræder en del "Latin1" og "latin1_swedish_ci" - hvor jeg hellere havde set "utf8"

Men når jeg prøver at lave dén query (med PHP og HTML - i relevante miljø) returneres "-1" ?!?


Det anbefalse "derude" at man, som det første efter connection er etableret, udfører:
$mysqli->query("SET NAMES 'utf8'");
eller
mysqli_set_charset($mysqli, "utf8");

Men begge "ødelægger" mine æøå'er (og andre "specialtegn") i alle andre sammenhænge..

hvis

mysqli_set_charset($mysqli, "utf8");

ødelægger dine speciel-tegn tyder det jo ret meget på at der er et eller andet sted hvor du IKKE kører utf8...

hvad hvis du laver en query i phpmyadmin?

DAMN - jeg har opdaget problemet - og det er IKKE MySQL's fulltext-index der er galt : )

Al min data-udveksling med databasen (både læsning og skrivning) sker med jQuery-ajax.

Uden contentType (dvs. default: 'application/x-www-form-urlencoded')
og data i et json-object => $_POST

Såvidt jeg kan se, betyder det at "specialtegn" ankommer som multi-byte-tegn:
æøå => æøå  (sådan ser de ud i MySQL's "Query Browser")
- det undrede mig godt nok lidt, men pyt...

For når jeg henter data ud igen (med samme type ajax-kald) sker "det omvendte" = det ser fint ud..
- Selvom det er helt galt!


Det er i hvetfald teorien lige nu : )
- jeg forsøger at give den en "rigtig" contentType

Eksempel (før)
Men hvis jeg tilføjer  contentType : "application/json; charset=utf-8"
så modtager ajax.php et tomt array i $_POST[] ?!?
- mens jeg med ovenstående eksempel kan trække data ud af
$_POST["kommando"] og $_POST['aktiv']['freq'] f.eks..

Nogen idé om hvad der går galt (med contentType-tilføjelsen) ?

Problemet er LØST  : D
- uden at fifle med alle Ajax-kaldene (30+)

Det er connectionen: Latin1 => UTF-8
troede fejlagtigt at UTF-8 var default - men nej. Lad os håbe at det er DET SIDSTE æøå-bøvl.

Som det først efter connection er etableret: mysqli_set_charset($mysqli, "utf8");

Og så var der lige alle de Latin1-data i datasen - som nu ser "ødelagte" ud.
- de kan konverteres af MySQL selv, som plaster på såret : )

UPDATE tabel SET kolonne=CONVERT(CONVERT(CONVERT(kolonne USING latin1) USING binary) using utf8)

Så nu ser det hele ud som forleden OG søgningen virker perfekt.
- SÅ blev det fredag (faktisk næsten lørdag..)

Ja OK, så perfekt som "collationen" nu tillader ( å = a - mens æ og ø er OK)
- det kan jeg leve med, indtil MySQL ('s fortolkning af UTF-generel revurderes)


Arne og splazz, i var begge korrekt inde på at mit tegnsæt var "suspekt" - Svar og del pointene!

svar...

Arne, lægger du ikke et svar, også ?

nedlagt?

hmm, tak for points :)