phpbar.de logo

Mailinglisten-Archive

HTML-Entities in der Volltextsuche

HTML-Entities in der Volltextsuche

Torsten Berger - WahnBerlin listen at wahnberlin.de
Mit Dez 15 13:19:49 CET 2004


Sebastian Mendel schrieb:

> ... schließlich sind normalerweise & und ; keine Wortzeichen,
> werden also von MySQL als Trenner behandelt

Dafür erst mal vielen Dank. Da lag genau mein Denkfehler, ich hab
zwar z.B. das "&" als "besonderes" Zeichen erkannt, aber nicht
bedacht, dass es gar nicht erst zu den indizierten Zeichen gehört.

> ein 'mögen' wäre dann wie ein 'm ouml gen' und die Wörter
> in der DB werden ja ebenso Indiziert, also jedes ouml als Wort.

> wir mögen MySQL =>> wir mögen MySQL => ouml, MySQL

Allerdings verstehe ich dann nicht wieso z.B. die Suche nach
"mögen" genau dieses findet? Müsste dann nicht nach "m ouml
gen" gesucht werden? Letzteres führt nicht zum Ergebnis, ersteres
schon. Das m als einzelner Buchstabe wird doch gar nicht
gelistet, oder doch? Wieso wird die Kobination gefunden? Ich
würde es gern verstehen, wenn ich auch jetzt (mit Deiner Hilfe)
für *dieses* Projekt eine hinreichende Lösung gebastelt habe:

$helparray = explode (' ', $gesucht);

 foreach($helparray as $ding) {

   $vor = substr($ding,0,1);
   $vor = ($vor == "-" || $vor == "+")?$vor:"";
   $ding = ($vor == "-" || $vor == "+")?substr($ding,1):$ding;

   if (  $ding !== htmlentities( $ding ) ) {
                        
     $ding = str_replace('*','',$ding);
     $search[] = $vor.'"'.htmlentities( $ding ).'"';

   } else {

     $search[] = $vor.$ding;

   }
 }

 $sql_suche = implode( ' ', $search );

Damit habe ich die BOOLEAN-Operatoren gerettet und * in der
Phrase ausgeschaltet (da dort nur störend und nicht nötig.

> da fällt einem natürlich auch gleich auf das ein Volltext-Index
> auf einen Text mit HTML-Entities wohl ungleich größer sein wird
> als einer ohne. Und vor allem auch viel weniger effektiv.

An das Suchen hab ich am Anfang nicht gedacht. An diese Zeichen
schon gar nicht. Ich wollte mit dem sofortigen Wandeln in
HTML-Zeichen sicherstellen, dass die Ausgabe unabhängig vom
verwendeten Zeichensatz des Systems ist. Wird vom MySQL-Server
ein Latin1 Zeichen gegeben, aber der empfangene Rechner hat einen
anderen am laufen, kann es zu Schwierigkeiten kommen. Bei
westlichen Zeichen eher selten ein Problem, aber die ganzen
osteuropäischen machen immer wieder Murx. Und: ja, ich weiß, dass
ich z.B. im Browser den Zeichensatz bestimmen kann etc.

Leider findet sich zu dem Thema Zeichensätze nur sehr weniges
(und immer das gleiche) im Netz, auch MySQL bearbeitet diese
Problematik erst mit der Version 4.1 erstmalig (rudimentär). In
Fachbüchern wird gar nix dazu gesagt. Da hier immer alles nach
Westen orientiert war, war es auch nie größeres Problem, aber mit
der Öffnung nach Osten kommt das. Ein Freund von mir übersetzt
z.B. ins Slowakische und verzweifelt regelmäßig an gängiger
Software und im Netz z.B. an Formularen.

Nochmal Dank für die Aufklärung
Gruß aus Berlin
Torsten

**********************************

www.wahnberlin.de

Torsten Berger
Jasmunder Straße 13
13355 Berlin


-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql 


php::bar PHP Wiki   -   Listenarchive