PHP Mal wieder UTF-8: Suchbegriff mit Umlauten nicht gefunden
0 3 0 Frage stellt sich unerwartet erneut
0 0 0 0 0 0 0 0 0 
molily
0 UTF-8 und etwas Philosophie
0 0 0 dedlfix
0
PHP Mal wieder UTF-8: Suchbegriff mit Umlauten nicht gefunden
Hi,
Ich habe eine Text-DB(UTF-8) darin steht das Wort Düsseldorf.
Also sollte das doch auch mit einem Suchformular gefunden werden. Dem ist nicht so.
Jetzt wollte ich eigentlich meine Frage hier anbringen, aber nun ist mir die Lösung schon klar und ich poste das nur, weil es vielleicht einem anderen hilft, der dieses Problem mal hat.
Das Problem war, dass ich eine Abfrage drin hatte wie:
if(strtolower($line_ar[$ark])== $_GET['cityzip'] ){print_r($line_ar);break;}
$line_ar ist die jeweilige Zeile in der TEXT-DB die ich mittels explode zerlegt hatte. Nun bin ich eigentlich davon ausgegegangen, wenn der Name($_GET['cityzip']) im test klein geschrieben wird, müsste er auch gefunden werden. IRRTUM. Nach Fehlersuche an falscher Stelle und schon bereit hier zu fragen fand ich heraus: kleinschreiben bei UTF-8 reicht nicht aus unter den Umständen, ich musste tatsächlich auch noch:
if(strtolower($line_ar[$ark])== strtolower($_GET['cityzip']) ){print_r($line_ar);break;}
$_GET['cityzip'] mit strtolower behandeln, obwohl bereits klein geschrieben. Ich verstehe es zwar nicht und normalerweise wäre es mir auch gar nicht aufgefallen, weil ausserhalb der Testumbgebung ich die Usereingabe eh noch formatiert hätte, aber es wundert mich doch enorm.
Pete
-
Hello Pete,
wenn Du utf-8 benutzt, musst Du auch http://de.php.net/manual/de/function.mb-strtolower.php benutzen und nicht strtolower().
Liebe Grüße aus Syburg
Tom vom Berg
-
Hallo Tom,
wenn Du utf-8 benutzt, musst Du auch http://de.php.net/manual/de/function.mb-strtolower.php benutzen und nicht strtolower().
Hmm, es funktioniert jetzt aber auch mit strtolower.
Aber sehr interessant(wenn es wirklich sein muss) und wenn ich mal so über fremde Scripte schaue bin ich überzeugt, dass die meissten das nicht wissen dürften.
Bedeutet das dann auch ich kann die meissten anderen Funktionen nicht mehr nutzen darf und muss stattdessen:
mb_stripos
mb_stristr
mb_strlen
mb_strpos
mb_strrchr
mb_strrichr
mb_strripos
mb_strrpos
usw....nutzen?
Pete
-
Hello,
Hallo Tom,
Hmm, es funktioniert jetzt aber auch mit strtolower.
Zufall? "Es funktioniert doch" ist keine Ausrede für fahrlässigen Softwareentwurf :-)
Aber sehr interessant(wenn es wirklich sein muss) und wenn ich mal so über fremde Scripte schaue bin ich überzeugt, dass die meisten das nicht wissen dürften.
Meine Rede!
Dass uns UTF-8 noch viel Spaß[tm] bereiten wird, habe ich schon vor Jahren hier verlauten lassen und dafür viel Schelte erfahren. Es macht das Arbeiten mit Daten keinesfalls nur einfacher!Liebe Grüße aus Syburg
Tom vom Berg
-
Hi Tom,
»» Hmm, es funktioniert jetzt aber auch mit strtolower.
Zufall? "Es funktioniert doch" ist keine Ausrede für fahrlässigen Softwareentwurf :-)
Keine Frage, da gebe ich dir recht.
»» Aber sehr interessant(wenn es wirklich sein muss) und wenn ich mal so über fremde Scripte schaue bin ich überzeugt, dass die meisten das nicht wissen dürften.
Meine Rede!
Dass uns UTF-8 noch viel Spaß[tm] bereiten wird, habe ich schon vor Jahren hier verlauten lassen und dafür viel Schelte erfahren. Es macht das Arbeiten mit Daten keinesfalls nur einfacher!Wundert mich, die Schelte, ich habe seit Anfang UTF-8 Popularität immer wieder Probleme damit.
Eine Frage hast du nicht beantwortet, was ist mit den anderen Funktionen, auch alles "mb_*"?
Gruss
Pete-
echo $begrüßung;
» Dass uns UTF-8 noch viel Spaß[tm] bereiten wird, habe ich schon vor Jahren hier verlauten lassen und dafür viel Schelte erfahren. Es macht das Arbeiten mit Daten keinesfalls nur einfacher!
Daran ist aber nicht UTF-8 schuld sondern eher der Mischmasch beim Übergang dorthin und unzulängliche Werkzeuge, wie PHP kleiner als Version 6.
Eine Frage hast du nicht beantwortet, was ist mit den anderen Funktionen, auch alles "mb_*"?
Schau im Handbuch nach, für welche der Stringfunktionen es ein mb_*-Pendant gibt.
echo "$verabschiedung $name";
-
Hi,
»» Eine Frage hast du nicht beantwortet, was ist mit den anderen Funktionen, auch alles "mb_*"?
Schau im Handbuch nach, für welche der Stringfunktionen es ein mb_*-Pendant gibt.
Also tatsächlich, was fürn Mist. Ich habe hier mal ein wenig die Fragen der letzten Monate durchgestöbert, nicht ein eiziges Mal(bei einer entsprechenden PHP Frage wo eine in Frage kommende Funktion gennant wurde, habe ich bei einer Antwort gesehen, "nutze aber besser mb_* wenn du UTF-8 nutzt". Hätte mir viel Arbeit erspart, na ja Pech.
Gruss
Pete-
Hello,
Also tatsächlich, was fürn Mist. Ich habe hier mal ein wenig die Fragen der letzten Monate durchgestöbert, nicht ein eiziges Mal(bei einer entsprechenden PHP Frage wo eine in Frage kommende Funktion gennant wurde, habe ich bei einer Antwort gesehen, "nutze aber besser mb_* wenn du UTF-8 nutzt". Hätte mir viel Arbeit erspart, na ja Pech.
Am besten lernt man doch immer aus seinen eigenen Fehlern, auch wenn ich früher immer gesagt habe "Intelligenz ist die Fähigkeit aus den Fehlern Anderer zu lernen" *gg*
Liebe Grüße aus Syburg
Tom vom Berg
-
-
Hello,
» Dass uns UTF-8 noch viel Spaß[tm] bereiten wird, habe ich schon vor Jahren hier verlauten lassen und dafür viel Schelte erfahren. Es macht das Arbeiten mit Daten keinesfalls nur einfacher!
Daran ist aber nicht UTF-8 schuld sondern eher der Mischmasch beim Übergang dorthin und unzulängliche Werkzeuge, wie PHP kleiner als Version 6.
Das mag stimmen. Aber das nächste Problem sehe ich danach wieder auf uns zukommen. Wenn dann eines Tages alles "automatisch" funktioniert, also die Editoren und die Interpreter und die Datenbanken sich alle in UTF-8 unterhalten, dann möchte ich mal sehen, wie man dann den IT-Nachwuchskräften noch erklärt, was da eigentlich unter drunter so passiert. Denn dass es dann keine Fehler mehr gibt, glaube ich nicht.
Liebe Grüße aus Syburg
Tom vom Berg
-
Tach,
Wenn dann eines Tages alles "automatisch" funktioniert, also die Editoren und die Interpreter und die Datenbanken sich alle in UTF-8 unterhalten, dann möchte ich mal sehen, wie man dann den IT-Nachwuchskräften noch erklärt, was da eigentlich unter drunter so passiert. Denn dass es dann keine Fehler mehr gibt, glaube ich nicht.
bis das bei den Lehrern ankommt wird es leider noch viel zu lange dauern, bei meiner noch nicht lange zurückliegenden Ausbildung zum Fachinformatiker waren die Lehrer nicht davon zu überzeugen, dass Netzklassen, Subnetting und Supernetting zu lehren heutzutage wohl eher zweitranging sein sollte.
mfg
Woodfighter -
echo $begrüßung;
Wenn dann eines Tages alles "automatisch" funktioniert, also die Editoren und die Interpreter und die Datenbanken sich alle in UTF-8 unterhalten, dann möchte ich mal sehen, wie man dann den IT-Nachwuchskräften noch erklärt, was da eigentlich unter drunter so passiert. Denn dass es dann keine Fehler mehr gibt, glaube ich nicht.
Es ist kaum Sache für den Nachwuchs, sich mit dem Meeresboden zu beschäftigen. Der hat noch genug Probleme schwimmen zu lernen. Und wenn er dann soweit und Willens ist abzutauchen, dann wird er dafür Verständnis aufbringen und erlangen. Der wird das schon schaffen, der Nachwuchs.
echo "$verabschiedung $name";
-
Hallo,
Das mag stimmen. Aber das nächste Problem sehe ich danach wieder auf uns zukommen. Wenn dann eines Tages alles "automatisch" funktioniert, also die Editoren und die Interpreter und die Datenbanken sich alle in UTF-8 unterhalten, dann möchte ich mal sehen, wie man dann den IT-Nachwuchskräften noch erklärt, was da eigentlich unter drunter so passiert. Denn dass es dann keine Fehler mehr gibt, glaube ich nicht.
Das Problem ist ja vielmehr noch ein anderes: Die Leute unterschätzen einfach, wie kompliziert tatsächlich Internationalisierung ist. In der Regel kennt man nämlich nur seinen eigenen Kulturkreis - und den nichtmal unbedingt so gut, wie man denkt.
Zum Beispiel gehen hier in Deutschland fast alle Leute davon aus, dass man von Links nach Rechts schreibt. Viele haben vielleicht schonmal davon gehört, dass man in anderen Kulturkreisen (Israel oder Saudi-Arabien z.B.) auch von Rechts nach Links schreibt. Aber sie haben sich vermutlich noch nie darüber Gedanken gemacht, was das nun für Ein- und Ausgabe am Computer heißt. Ich hab ja mal vor einiger Zeit den Unicode-Bidi-Algorithmus etwas zerpflückt. Der ist höllisch kompliziert. Nicht, weil die Unicode-Leute alle abgehobene Akademiker im Elfenbeinturm sind - im Gegenteil: Der ist so kompliziert, weil die Anforderungen an Unicode eben so kompliziert sind: Wenn man alle Sprachen der Welt abdecken können will, muss man eben enorm viel berücksichtigen.
Weitere Beispiele: In Ländern mit lateinischer Schrift gibt's ja Groß- und Kleinschreibung. Man unterscheidet damit in der Regel zwischen "upper case", "lower case" und "title case" (jeder erste Buchstabe eines Wortes groß, der Rest klein). Dummerweise treten hier gleich *etliche* Probleme auf:
-
Die Regeln für die Umwandlung zwischen Groß- und Kleinschreibung sind nicht immer umkehrbar - z.B. wird "ß" zu "SS", "SS" wird aber zu "ss". Was noch viel schlimmer dabei ist: Ein Zeichen wird plötzlich zu zwei Zeichen. [Ja, Unicode hat übrigens inzwischen ein großes "ß", aber die Regeln für die Groß/Kleinumwandlung haben sie nicht geändert.]
-
Die Regeln für Groß- und Kleinschreibung sind Sprachabhängig. Im Türkischen gibt's z.B. den Buchstaben "i" sowohl in Groß- als auch in Kleinschreibung mit und ohne Punkt (d.h. 4 Varianten) - d.h. im Türkischen ist die Großschreibung von "i" eben "İ" und nicht "I" - und die Kleinschreibung von "I" eben "ı" und nicht "i". Deswegen sind "ISA" und "isa" bei türkischer Spracheinstellung nicht mehr identisch unter einem Vergleich, der "case insensitive" ist. [1].
-
Andere Sprachen kennen keine Groß- und Kleinschreibung - Japanisch fällt z.B. unter die Kategorie (wie auch Koreanisch, etc.).
Weiteres Beispiel: Normalisierung: Um den gesamten Wust an Zeichen, die man so braucht, irgendwie abdecken zu können, gibt's in Unicode die Möglichkeit, Zeichen zusammenzusetzen. D.h. statt "ä" kann man auch schreiben "Umlaut-Modifier", "a". Weil's aber eben auch "ä" gibt (das hat praktische Gründe), muss man beim String-Vergleich höllisch aufpassen.
Noch ein Beispiel: Unihan. Kennt man hierzulande gar nicht. Die Idee ist, dass die Schriftzeichen in China, Japan und Korea zu einem großen Teil sich ähneln. Daher haben sich die Unicode-Leute (damit sie nicht 3x so viele Zeichen hinzufügen müssen wie sie sowieso schon hinzufügen mussten) etwas ausgedacht, was Han Unification (Unihan) genannt wird - d.h. diese drei Schriftsprachen (chinesisch, japanisch und koreanisch) teilen sich die meisten Zeichen. Das Problem: Auch wenn die Zeichen ähnlich aussehen, sehen sie halt doch nicht ganz identisch aus. Deswegen enthält der Unicode-Standard auch etwas, was sich "CJK Disambiguition" nennt - d.h. je nachdem, in welcher Sprache der Text gefasst ist (das verarbeitende Programm muss sich diese Informationen extra besorgen bei HTML z.B. über lang="jp" o.ä.) sollten die Zeichen unterschiedlich dargestellt werden.
Und das waren jetzt mal die prominentesten Beispiele - sie zeigen aber, wie komplex Internationalisierung wirklich ist. Und das liegt nicht am Unicode-Standard, sondern an der Vielfalt an Kulturen, die wir hier auf der Erde haben. Die unter einen Hut zu bringen ist alles andere als einfach.
Und genau *DAS* ist das eigentliche Problem mit UTF-8. *Nicht* das Kodierungsverfahren, das ist eine simple mathematische Vorschrift, welche Bits in welchen Bytes wie gesetzt werden müssen. *Nicht* der Unicode-Standard als solcher - der ist sehr sorgfältig und gewissenhaft designed worden. Nein, das Problem ist einfach, dass die meisten Leute, die Programme schreiben, die Komplexität von Internationalisierung nicht wirklich erfassen. Vielleicht auch gar nicht erfassen können - man kann ja schließlich auch nicht alles wissen. Und deswegen ist es in meinen Augen essentiell, dass die Programmiersprachen das möglichst transparent gegenüber dem Programmierer zu machen - damit der eben nicht mehr zu sehr über so etwas nachdenken muss. Aber bis es in der Hinsicht *wirklich* einfache Lösungen gibt, wird es noch sehr lange dauern. Vor allem, weil es noch viel zu viele Legacy-Systeme gibt - und immer, wenn man die Unicode-Kette irgendwo potentiell unterbrechen muss, wird es dann gleich nochmal deutlich komplizierter.
Viele Grüße,
Christian -
-
-
-
-
-
-
-
Moin!
if(strtolower($line_ar[$ark])== $_GET['cityzip'] ){print_r($line_ar);break;}$line_ar ist die jeweilige Zeile in der TEXT-DB die ich mittels explode zerlegt hatte. Nun bin ich eigentlich davon ausgegegangen, wenn der Name($_GET['cityzip']) im test klein geschrieben wird, müsste er auch gefunden werden. IRRTUM. Nach Fehlersuche an falscher Stelle und schon bereit hier zu fragen fand ich heraus: kleinschreiben bei UTF-8 reicht nicht aus unter den Umständen, ich musste tatsächlich auch noch:
if(strtolower($line_ar[$ark])== strtolower($_GET['cityzip']) ){print_r($line_ar);break;}$_GET['cityzip'] mit strtolower behandeln, obwohl bereits klein geschrieben. Ich verstehe es zwar nicht und normalerweise wäre es mir auch gar nicht aufgefallen, weil ausserhalb der Testumbgebung ich die Usereingabe eh noch formatiert hätte, aber es wundert mich doch enorm.
strtolower() arbeitet byteorientiert, d.h. es zerstört dir unter Umständen deine Mehrbyte-UTF-8-Zeichen, weil es die einzelnen Bytes jeweils separat voneinander in Kleinbuchstaben wandelt (was schiefgehen kann oder zu keiner Veränderung führt, wenn für das Byte kein Kleinbuchstabe bekannt ist).
Deine "Lösung" zerstört jetzt in beiden Strings gleichartig die UTF-8-Zeichen, damit paßt es dann wieder. Ist aber alles andere als eine schöne Lösung, weil ich keine Hand dafür ins Feuer legen würde, dass die Art der Zerstörung in jedem denkbaren Fall immer dieselben Auswirkungen hat.
Wenn du mit UTF-8 arbeitest, dann sorge entweder dafür, dass alle Stringfunktionen ausschließlich in der Datenbank ablaufen (die weiß mit UTF-8-Strings umzugehen), oder setze ausschließlich die mb-Funktionen ein.
- Sven Rautenberg
-
Hi,
mir wurde ja empfohlen mb_strtolower() zu verwenden. Das macht ja auch Sinn und erklärt mein Problem, dachte ich...
Pustekuchen, die gleiche Situation entsteht immer noch(hätte mich von der Logik nicht von einem Test abhalten lassen sollen).
Das bedeutet konkret ich muss sowohl $line_ar[$ark] als auch $_GET['cityzip'] mit (mb_)strtolower behandeln, obwohl bereits der Suchbegriff klein eigegeben wird und meine Seite UTF-8 ist, der Header UTF-8 sogar noch die Metaangabe und das Formular mit accept-charset="UTF-8".
Wie kann das sein?
Ach ja und dann noch eine Frage: Wenn ich ab sofort nur noch die möglichen mb_* Funktionen anstatt der konventionellen verwende, also auch bei Nicht-UTF-8 Seiten, hat das Nachteile oder ist das problemlos abwärtskompatibel?
Pete
-
Hi,
Ach ja und dann noch eine Frage: Wenn ich ab sofort nur noch die möglichen mb_* Funktionen anstatt der konventionellen verwende, also auch bei Nicht-UTF-8 Seiten, hat das Nachteile oder ist das problemlos abwärtskompatibel?
Das kann ich mir mittlerweile selbst beantworten. Riesenkacke!
Ein Aufruf unter Verwendung von strtolower dauert microsekunden, während ein Aufruf mit mb_strtolower() fast eine Sekunde dauert. Das geht ja mal gar nicht. Jetzt reichts, bleibe bei unsauber und zerlege es mit strtolower, frei nach dem Motto(engegengesetzt meiner eigentlichen Meinung) klappt ja! Manchmal muss man eben Priorotäten setzen und der Zeitfaktor ist definitiv zu gravierend und nicht nachzuvollziehen, wei man solch eine Funktion anbieten kann, die dermassen langsam ist.
Pete
-
Hello,
mir ist leider immer noch schleierhaft, was Du da eingetlich betreibst?
Überlicherweise hat man die zur Verfügung stehende Begriffsmenge in seiner Datenbank gespeichert und bekommt vom Client per Formular einen Suchbegriff geschickt.
Nun müssen nur die Codierungen der beiden Begriffe übereinstimmen. Übliche Datenbnaken vergleicehn beim Select die Bedingungen sowieso caseinsensitive, es sei denn, man hat die Spalten extra anders angelegt oder verlangt es beim Query anders.
Wenn Du nun eine Textdatei benutzt, in der Begriffe stehen, nach denen Du suchst, dann kannst Du das ähnlich machen. Du sorgst zuerst für gleiche Codierung auf beiden Seiten. Dann vergleichst Du caseinsensitive mit stripos() http://de.php.net/manual/de/function.stripos.php
Ein "mb_stripos()" gibt es gar nicht. Warum auch? Beim Vergleichen werden hier ja tatsächlich Bytes verglichen, bzw. die entsprechend vorbehandelten Werte. Bei ASCII ist der Unterschied zwischen GROSS- und kleinschreibung fast auf ein Bit (das 32-wertige) zurückzuführen.
Man kann sowieso nur geeignete Zeichensätze caseinseitive miteinander vergleichen. Siehe hierzu Christian Seilers sehr ausführliche Anmerkungen in https://forum.selfhtml.org/?t=184875&m=1226248
Liebe Grüße aus Syburg
Tom vom Berg
-
Hi Tom,
mir ist leider immer noch schleierhaft, was Du da eingetlich betreibst?
in erster Linie erst mal nur Tests.
Wenn Du nun eine Textdatei benutzt, in der Begriffe stehen, nach denen Du suchst, dann kannst Du das ähnlich machen. Du sorgst zuerst für gleiche Codierung auf beiden Seiten. Dann vergleichst Du caseinsensitive mit stripos() http://de.php.net/manual/de/function.stripos.php
»»
Ja mache ich doch, beides UTF-8.
Ein "mb_stripos()" gibt es gar nicht. Warum auch? Beim Vergleichen werden hier ja tatsächlich Bytes verglichen, bzw. die entsprechend vorbehandelten Werte. Bei ASCII ist der Unterschied zwischen GROSS- und kleinschreibung fast auf ein Bit (das 32-wertige) zurückzuführen.
»»
Nein? http://de.php.net/manual/de/function.mb-stripos.php
Da bist du platt, was? ;-)Man kann sowieso nur geeignete Zeichensätze caseinseitive miteinander vergleichen. Siehe hierzu Christian Seilers sehr ausführliche Anmerkungen in https://forum.selfhtml.org/?t=184875&m=1226248
Das war wirklich sehr ausführlich und beschreibt eigentlich ganz gut meine momentane Denkanstrengungen. So wie ich das lese und auch selbst erkenne, kann es keine perfekte Internationalisierung geben. Hat aber trotzdem nicht viel mit meinem geschilderten Problem zu tun, denn hier geht es leidglich (mal wieder) um eine UTF-8 Problematik, die auch einer rein deutschen Seite auftauchen kann.
Pete
-
Hello,
Nein? http://de.php.net/manual/de/function.mb-stripos.php
Da bist du platt, was? ;-)Ja, du hast Recht. Da habe ich mich jetzt selber im Kreise gedreht.
Die Umsetzung der Groß- auf die Kleinschreibung unterliegt bei UTF-8 selbstversändlich anderen Regeln, als bei ISO8859-1 und es wird ja nicht die Byte-Position, sondern die Zeichenposition ermittelt.
Naja, das buche ich unter "blamiere Dich täglich..."
Liebe Grüße aus Syburg
Tom vom Berg
-
-
-
Hallo,
Ach ja und dann noch eine Frage: Wenn ich ab sofort nur noch die möglichen mb_* Funktionen anstatt der konventionellen verwende, also auch bei Nicht-UTF-8 Seiten, hat das Nachteile oder ist das problemlos abwärtskompatibel?
Das kann ich mir mittlerweile selbst beantworten. Riesenkacke!
Ein Aufruf unter Verwendung von strtolower dauert microsekunden,
christian@cobalt ~/tmp/forum $ php -r '$anzahl = 1000000; $start = microtime (true); for ($i = 0; $i < $anzahl; $i++) { $v = strtolower("HALLO"); } $ende = microtime (true); printf ("Ein Aufruf durchschnittlich %.6f Mikrosekunden.\n", ($ende - $start) / $anzahl * 1e6);'
Ein Aufruf durchschnittlich 1.144888 Mikrosekunden.
während ein Aufruf mit mb_strtolower() fast eine Sekunde dauert.
php -r '$anzahl = 1000000; $start = microtime (true); for ($i = 0; $i < $anzahl; $i++) { $v = mb_strtolower("HALLO"); } $ende = microtime (true); printf ("Ein Aufruf durchschnittlich %.6f Mikrosekunden.\n", ($ende - $start) / $anzahl * 1e6);'
Ein Aufruf durchschnittlich 11.516928 Mikrosekunden.
Also etwa Faktor 10. Was für Unicode-Unterstützung durchaus vollkommen in Ordnung ist. Das von Dir beschriebene Verhalten kann ich nicht nachvollziehen.
Viele Grüße,
Christian-
Hallo Christian,
erst mal Kompliment zu: https://forum.selfhtml.org/?t=184875&m=1226248, sehr anschaulich.
Ein Aufruf durchschnittlich 1.144888 Mikrosekunden.
»» während ein Aufruf mit mb_strtolower() fast eine Sekunde dauert.
Ein Aufruf durchschnittlich 11.516928 Mikrosekunden.
Also etwa Faktor 10. Was für Unicode-Unterstützung durchaus vollkommen in Ordnung ist. Das von Dir beschriebene Verhalten kann ich nicht nachvollziehen.
Du sagst doch selber Faktor 10, was kannst du dann nicht nachvollziehen?
Gruss
Pete-
Hi,
»» Also etwa Faktor 10. Was für Unicode-Unterstützung durchaus vollkommen in Ordnung ist. Das von Dir beschriebene Verhalten kann ich nicht nachvollziehen.
»»Kleiner Nachtrag, Faktor 10 ist auch noch Unterkante, probiere das mal mit einer Wortliste, einem grossen Array, und längeren Worten als "HALLO". Das potenziert sich ganz schön auf irgendeine Art und Weise.
Ich nehme zum Beispiel eine PLZ/ORT Liste im Test >3MB.
Gruss
Pete-
Hello,
Ich nehme zum Beispiel eine PLZ/ORT Liste im Test >3MB.
Wie liest Du die denn ein? "Zeilenweise" oder blockorientiert (Random Access)?
Liebe Grüße aus Syburg
Tom vom Berg
-
Hi,
»» Ich nehme zum Beispiel eine PLZ/ORT Liste im Test >3MB.
Wie liest Du die denn ein? "Zeilenweise" oder blockorientiert (Random Access)?
Im Moment so wie es reinkommt, will sagen keine feste Satzlänge also Zeilenweise. Später kommt da sowieso aus einer DB. Aber eben nicht MYSQL, sondern Sqlite, wobei ich dann wahrscheinlich erneut Fragen zu UTF-8 haben werde.
Aber warum fragst du?
Pete
-
Hello,
Aber warum fragst du?
Weil das zeilenweise Lesen, insbesondere mit fgetcsv() und fgets() bei PHP enorm viel Kraft fordert.
Es wird zwar sowieso normalerweise in 8k-Blöcken eingelesen und gepuffert, aber es scheint wohlö recht aufwändig zu sein, darin dann das Zeilenendezeichen zu finden.Ich habe leider noch nicht näher reingeschaut in den Mechanismus. Vielleicht weiß es jemand anderes, warum das soviel Kraft kostet.
Das blockweise lesen geht auf jeden Fall sehr viel schneller.
Mir ist das mal aufgefallen, als ich meine "Megabyte-Versuche" mit Dateien gemacht habe.Liebe Grüße aus Syburg
Tom vom Berg
-
-
-
Hallo,
Kleiner Nachtrag, Faktor 10 ist auch noch Unterkante, probiere das mal mit einer Wortliste, einem grossen Array, und längeren Worten als "HALLO". Das potenziert sich ganz schön auf irgendeine Art und Weise.
Ich nehme zum Beispiel eine PLZ/ORT Liste im Test >3MB.
Ok, bei einem realistischen Text (zwar Englisch, aber immerhin 1.2 MiB) sind's bei mir ~320ms vs. ~5ms - also Faktor 64... Hmm, dann ist mb_strtolower() ineffizienter implementiert, als es theoretisch nötig wäre, ich würde erwarten, dass die Laufzeitklasse bei beiden Funktionen O(n) wäre - halt nur mit einem anderen Faktor und einer anderen additiven Konstante.
Andererseits: Wozu musst Du bei jedem Request megabyteweise Daten mit strtolower() bearbeiten? Das leuchtet mir irgendwie nicht so ganz ein...
Viele Grüße,
Christian-
Hi,
Ok, bei einem realistischen Text (zwar Englisch, aber immerhin 1.2 MiB) sind's bei mir ~320ms vs. ~5ms - also Faktor 64... Hmm, dann ist mb_strtolower() ineffizienter implementiert, als es theoretisch nötig wäre,...»»
meine Aussage.
Andererseits: Wozu musst Du bei jedem Request megabyteweise Daten mit strtolower() bearbeiten? Das leuchtet mir irgendwie nicht so ganz ein...
Nein, muss ich gar nicht. Das Schöne(oft aber auch das Frustreiche) am Programmieren ist, dass viele Wege nach Rom führen. So findet sich nahezu für jede Problem eine lösung, die aber auch wieder neue Probleme mitbringen kann. Mir geht es jetzt auch gar nicht mehr um eine Fallbeispiel, sondern um meine Unkenntniss mb_* Funktionen bei UTF-8 nutzen zu müssen. Da fange ich dann an zu testen und stelle mir u.U. sogar die Frage, warum eigentlich UTF-8, immer gibts Ärger damit.
Ok, da das was ich vorhabe aber nun mal UTF-8 voraussetzt, habe ich keine Wahl, aber schon eine Wahl der Lösungen, und wenn ich nun in diesem Beispiel so vorgehe, dass ich eine Textdatei zeilenweise auslese, durch eine Schleife schicke, die einzelne Zeile in ein Array verwandele und dann
den Wert $array[2] in Kleinbuchstaben umwandele um ihn mit dem Request, der in Kleinbuchstaben vorliegt, zu vergleichen ist das zwar keine optimale Vorgehensweise, aber eine Vorgehensweise, wie sie oft genug bei anderen Prozeduren benötigt wird. Deshalb interessiert mich das nicht nur jetzt, sondern insgesamt für spätere Scripte.Von daher interessiert mich so ein enormer Geschwindigkeitsnachteil natürlich sehr.
Alles in allem wüsste ich dann immer noch gerne den Grund für meine Anfangsfrage, denn an mb_strtolower liegt es ja nun doch nicht.
Pete
-
und stelle mir u.U. sogar die Frage, warum eigentlich UTF-8, immer gibts Ärger damit.
Wir koennen auch einfach wieder zu 7-Bit zurueck, das geht natuerlich auch. ;)
Aber ernsthaft: Freilich solltest du dir diese Frage stellen, aber die Antwort »Nein« bringt bei Webanwendungen nicht unbedingt den erhofften Vorteil. Genauso wie bei UTF-8 musst du alle beteiligten Prozesse und Daten synchronisieren. Und dadurch, dass du eben nicht ohne weiteres die meisten Unicode-Zeichen direkt abbilden kannst und Daten von »außen« bekommen kannst, deren Textkodierung (und oft zusätzlich uneindeutige Zeichenmaskierung) erst auf deine verwendete Kodierung abgebildet werden muss, bringt die Verwendung einer vermeintlich einfachen Kodierung auch gravierende Nacheile bei der Verarbeitung. Da wirst du mit den »fundamentally flawed« Standard-Stringfunktionen auch schnell in die Bredouille kommen.Mathias
-
Hello,
Wir koennen auch einfach wieder zu 7-Bit zurueck, das geht natuerlich auch. ;)
Also mir hat der erweiterte Zeichnsatz von IBM vollkommen ausgereicht, also ASCII plus Grafikzeichennund ein paar Sonderzeichen. Damit konnte ich alle von mir lesbaren (also irgendwie mit Wörterbuch usw.) darstellen. Und das waren etliche Dutzend!
Und wenn ich dann unbedingt mal chinesisch lesen wollte...
Aber die Chinesen hatten ja schon angefangen, sich unserer Kulturtechnik anzupassen. Das hätte auf mittlere bis lange Sicht mehr gebracht für die Verständigung, als dass wir jetzt auch noch "chinesisch" lernen müssen. Denn mit "chinesisch" hat es ja auch noch das Zusatzproblem, dass es das gar nicht gibt, und die erst einmal in ihrem eigenen Gebiet aufräumen müssen mit der Sprache und der Schrift.
Da mag jetzt der Eine oder die Andere sagen, dass das kolonistisch ist, aber so war es in der Geschichte immer. Wenn sich eine Kultur etwas besonders gutes ausgedacht hatte, hat sie das auch erdweit verbreitet. Früher mit Krieg, heute hätte es mit Lernen geklappt. Das Paradoxon daran ist dann, dass die Kultur mit der tollen Entdeckung eigentlich die geistig verarmende ist, weil alle anderen zwar die neue Kulturtechnik erlernen, die Entdeckerkultur aber zu bequem ist, alle anderen Kulturen kennen zu lernen.
Liebe Grüße aus Syburg
Tom vom Berg
-
Tach,
Also mir hat der erweiterte Zeichnsatz von IBM vollkommen ausgereicht, also ASCII plus Grafikzeichennund ein paar Sonderzeichen. Damit konnte ich alle von mir lesbaren (also irgendwie mit Wörterbuch usw.) darstellen. Und das waren etliche Dutzend!
du meinst den Zeichensatz, der das griechische kleine β und das deutsche ß an die selbe Stelle legt und logischerweise kein € enthält?
Das hätte auf mittlere bis lange Sicht mehr gebracht für die Verständigung, als dass wir jetzt auch noch "chinesisch" lernen müssen. Denn mit "chinesisch" hat es ja auch noch das Zusatzproblem, dass es das gar nicht gibt, und die erst einmal in ihrem eigenen Gebiet aufräumen müssen mit der Sprache und der Schrift.
Mandarin (also "hochchinesisch") hat etwa gleich viele Sprecher wie Englisch, warum sollten die sich alle umgewöhnen müssen?
mfg
Woodfighter-
Hello,
Mandarin (also "hochchinesisch") hat etwa gleich viele Sprecher wie Englisch, warum sollten die sich alle umgewöhnen müssen?
Na prima, dann hätte man doch nur versuchen müssen, eine Transformation/Reduktion von Mandarin auf extended ASCII durchzuführen.
Das wäre sicherlich möglich gewesen und auch innerhalb von einer Genaration (25 Jahren) erlernbar gewesen. So intelligent, wie die Chinesen sind, hätten sie sicherlich recht frühzeitig erkannt, dass RISC der passende Weg für die Welt ist...
Liebe Grüße aus Syburg
Tom vom Berg
-
echo $begrüßung;
Na prima, dann hätte man doch nur versuchen müssen, eine Transformation/Reduktion von Mandarin auf extended ASCII durchzuführen.
Das geht nicht wirklich gut. Es gibt viel zu wenig Silben im Chinesischen. Schriebe man nur Pinyin, könnte man die Bedeutung eines Wortes nicht mehr klar erkennen, weil die Silben zu allem Überfluss auch noch mehrfach verwendet werden. Es gibt aber unterschiedliche Zeichen (nicht immer, aber meistens) für die unterschiedlichen Bedeutungen der gleichen Silben. Und das wird dann eindeutiger.
echo "$verabschiedung $name";
-
-
-
-
-
-
-
-
Hallo,
Also etwa Faktor 10. Was für Unicode-Unterstützung durchaus vollkommen in Ordnung ist. Das von Dir beschriebene Verhalten kann ich nicht nachvollziehen.
Du sagst doch selber Faktor 10, was kannst du dann nicht nachvollziehen?
Die Aussage ein paar Mikrosekunde vs. eine Sekunde? Das ist faktor 10000 oder so. ;-)
Viele Grüße,
Christian
-
-
-
-