mySQL: Fehler mit COLLATE

[Linuchs]

Moin,

irgendwie scheint nicht mein Tag zu sein. Es gibt Probleme mit COLLATE und ich weiß nicht warum.

Hier im Programm funktioniert es:

...
FROM    bia_orte ort1
WHERE   ort1.loe_kz       =  0
AND    (LOWER(name)           LIKE '%uecker%' COLLATE 'utf8_bin'
        OR plz                LIKE  'uecker%' COLLATE 'utf8_bin'
        OR LOWER(name_zusatz) LIKE '%uecker%' COLLATE 'utf8_bin'
        OR LOWER(keywords)    LIKE '%uecker%' COLLATE 'utf8_bin')
...

und hier nicht. Bei phpMyAdmin eingegeben sieht das so aus:

Keine Ahnung, was mit CHARACTER SET 'utf8mb4' gemeint ist. Die Felder haben alle die Kollation utf8_unicode_ci

Edit: utf8_bin wird benötigt, um Umlaute gezielt zu finden, z.B. bei Suche nach Münster

ratloser Linuchs

[Der Martin]

Hallo Linuchs,

...
FROM    bia_orte ort1
WHERE   ort1.loe_kz       =  0
AND    (LOWER(name)           LIKE '%uecker%' COLLATE 'utf8_bin'
        OR plz                LIKE  'uecker%' COLLATE 'utf8_bin'
        OR LOWER(name_zusatz) LIKE '%uecker%' COLLATE 'utf8_bin'
        OR LOWER(keywords)    LIKE '%uecker%' COLLATE 'utf8_bin')
...

hier stehen die Angaben zur Zeichencodierung in Anführungszeichen.

und hier nicht. Bei phpMyAdmin eingegeben sieht das so aus:

Hier nicht. Sollten sie aber meines Wissens, denn es sind ja keine Keywords, Spaltennamen oder Alias-Bezeichner.
Das Keyword COLLATE ist offenbar korrekt erkannt worden, wie die Einfärbung zeigt. Es ist vermutlich nur der unbekannte Ausdruck danach, der dem SQL-Server Rätsel aufgibt.

Live long and pros healthy,
 Martin

[Linuchs]

Hallo Martin,

Hier nicht. Sollten sie aber meines Wissens, denn es sind ja keine Keywords, Spaltennamen oder Alias-Bezeichner.

Hatte ich auch ausprobiert, Fehler bleibt:

Es liegt auch nicht an einem bestimmten Feld oder Ziffern:

Linuchs

[Linuchs]

Habe mich bewusst nicht besonders reingekniet in Betriebssysteme und Programmiersprachen.

Empfinde mich eher als Taxifahrer, der Kunden / Seiten-Besucher zum Ziel bringt. Nichts dagegen, mal die Zündkerzen zu wechseln und Öl nachzukippen, aber wenn's ans Getriebe geht, ...

So toll, wie mir hier immer geholfen wird. Aber manchmal ist es eben auch so, wenn die Zündung nicht anspringt, wird geraten, den Reifen zu wechseln.

[Der Martin]

n'Abend,

Habe mich bewusst nicht besonders reingekniet in Betriebssysteme und Programmiersprachen.

Empfinde mich eher als Taxifahrer, der Kunden / Seiten-Besucher zum Ziel bringt. Nichts dagegen, mal die Zündkerzen zu wechseln und Öl nachzukippen, aber wenn's ans Getriebe geht, ...

dagegen ist nichts zu sagen; nicht jeder muss gleich Automechaniker sein. Ich selbst fühle mich eher als ein solcher (im übertragenen Sinn), manchmal sogar als Motorenentwickler. Aber ich erwarte das nicht von anderen.

So toll, wie mir hier immer geholfen wird. Aber manchmal ist es eben auch so, wenn die Zündung nicht anspringt, wird geraten, den Reifen zu wechseln.

Du hast einen Hang zur Polemik. Ja, es stimmt schon, dass viele der Stammposter hier oft nicht direkt auf die eigentliche Frage antworten, sondern sich an vermeintlichen Nebensächlichkeiten festbeißen. Das tu ich manchmal auch.
Denn die IT ist eine sehr komplexe Welt mit unglaublich vielen Querverbindungen und Fallstricken. Wenn ich bei einer Laienfrage den Eindruck habe, dass das eigentliche Problem viel weiter oben in der Hierarchie liegt und die konkret gestellte Frage nur ein Folge-Folge-Problem ist, dann versuche ich auch, das Übel an der Wurzel zu packen. Das sieht dann manchmal so aus, als würde ich das Thema ignorieren und etwas völlig anderes kritisieren, aber das täuscht normalerweise.

Und ja, wenn ich meine Hinweise zum Problem (oder zu dem, was ich dafür halte) gegeben habe, gehe ich auch gern noch auf andere Aspekte ein.

F: Beim Bremsen zieht das Auto immer leicht nach rechts. Müsste man da nicht die Spur nachstellen?
A: Nein, ich würde eher mal die vorderen Bremsscheiben und -beläge kontrollieren. Ach, und übrigens: Deine Kennezichenbeleuchtung hinten geht auch nicht.

Live long and pros healthy,
 Martin

[Linuchs]

Du hast einen Hang zur Polemik.

Klingt irgendwie negativ. Satire finde ich besser. Wird aber gut verstanden, von dir ja auch. Genauso habe ich es gemeint, wie du es verstanden hast.

Linuchs

[Der Martin]

Hi,

Du hast einen Hang zur Polemik.

Klingt irgendwie negativ. Satire finde ich besser.

ich auch. Denn Satire wird schnell zur Polemik, wenn sie sich anhört, als wäre sie abwertend und negativ gemeint. Den Eindruck hatte ich bei dir.

Das ist ähnlich wie mit Sarkasmus und Zynismus: Sarkasmus ist scherzhaft gemeint, Zynismus eher boshaft.

Wird aber gut verstanden, von dir ja auch. Genauso habe ich es gemeint, wie du es verstanden hast.

Ja, ich habe ein dickes Fell. 😀

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Das ist ähnlich wie mit Sarkasmus und Zynismus: Sarkasmus ist scherzhaft gemeint, Zynismus eher boshaft.

„Wird aus ’m Zyniker noch mal ’n Schelm?“ —Gundermann, Wo bleiben wir

(Und ja, die Musik dazu hat er sich woanders besorgt. Ihr erkennt’s?)

😷 LLAP

[Der Martin]

Hallo Gunnar,

Das ist ähnlich wie mit Sarkasmus und Zynismus: Sarkasmus ist scherzhaft gemeint, Zynismus eher boshaft.

„Wird aus ’m Zyniker noch mal ’n Schelm?“ —Gundermann, Wo bleiben wir

(Und ja, die Musik dazu hat er sich woanders besorgt. Ihr erkennt’s?)

es erinnert mich entfernt an Rod Stewarts Downtown Train, ist aber meiner Ansicht nach sehr stark verfremdet.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

„Wird aus ’m Zyniker noch mal ’n Schelm?“ —Gundermann, Wo bleiben wir

(Und ja, die Musik dazu hat er sich woanders besorgt. Ihr erkennt’s?)

es erinnert mich entfernt an Rod Stewarts Downtown Train, ist aber meiner Ansicht nach sehr stark verfremdet.

Downtown Train – ja.

Rod Stewart?? TIL: Der hat das auch mal gecovert.

Original ist’s von Tom Waits.

😷 LLAP

[Der Martin]

Hallo,

es erinnert mich entfernt an Rod Stewarts Downtown Train, ist aber meiner Ansicht nach sehr stark verfremdet.

Downtown Train – ja.

Rod Stewart?? TIL: Der hat das auch mal gecovert.

ah, gut. Ich kenne nur die Rod-Stewart-Version.

Original ist’s von Tom Waits.

Man lernt nie aus. Den kenne ich aber auch nur dem Namen nach.

Live long and pros healthy,
 Martin

[kai345]

Original ist’s von Tom Waits.

Man lernt nie aus. Den kenne ich aber auch nur dem Namen nach.

Ich kenn' ihn auch nur von einem Lied, das jahreszeitlich gesehen bald wieder aktuell wird ;)

[Gunnar Bittersmann]

@@kai345

Original ist’s von Tom Waits.

Man lernt nie aus. Den kenne ich aber auch nur dem Namen nach.

Ich kenn' ihn auch nur von einem Lied, das jahreszeitlich gesehen bald wieder aktuell wird ;)

Ich glaube, ich kannte ihn ursprünglich auch durch eine Coverversion (der auf Live/1975–’85).

Und für @at noch ein Cover (wenn der Thread so weit im Keller ist, dass er ihn liest).

😷 LLAP

[at]

Hallo Gunnar,

vielen Dank, dass du an mich gedacht hast :-)

MfG, at

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Original ist’s von Tom Waits.

Auch bei „In der Nachbarschaft“ hat sich Gundermann eines Stücks von Tom Waits bedient – da nicht nur der Musik, sondern auch des Titels „In the Neighborhood“.

😷 LLAP

[Gunnar Bittersmann]

@@Gunnar Bittersmann

„Wird aus ’m Zyniker noch mal ’n Schelm?“ —Gundermann, Wo bleiben wir

Das Lied hatte auch seinen festen Platz in meinem Programm „Versuche, Heimat zu definieren“.

Ich hatte das aber auch „verfremdet“. Die Klampfe als Rhythmusinstrument – bei Bruce Springsteens „Promised Land“ in der Version von der Solo-Acoustic-Tour abgekuckt.

Hm, Düsseldorf 1996 – ich glaube, da war ich live dabei.

😷 LLAP

[dedlfix]

Tach!

hier stehen die Angaben zur Zeichencodierung in Anführungszeichen.

[...]

Hier nicht. Sollten sie aber meines Wissens, denn es sind ja keine Keywords, Spaltennamen oder Alias-Bezeichner.

Sie müssen nicht. Ich finde zwar die Stelle im MySQL-Handbuch nicht, aber es geht auch ohne Anführungszeichen. In vielen Beispielen im Handbuch sind sie auch unquotiert.

Das Keyword COLLATE ist offenbar korrekt erkannt worden, wie die Einfärbung zeigt. Es ist vermutlich nur der unbekannte Ausdruck danach, der dem SQL-Server Rätsel aufgibt.

Der obere Teil der Fehlermeldung stammt von phpMyAdmin. Was auch immer der für ein Problem damit hat, MySQL hat es nicht. Das stört sich - wie in der lezten Zeile der Meldung zu sehen - nur daran, dass die Angabe nicht zur Wirklichkeit passt.

dedlfix.

[dedlfix]

Tach!

Keine Ahnung, was mit CHARACTER SET 'utf8mb4' gemeint ist. Die Felder haben alle die Kollation utf8_unicode_ci

Einer von euch beiden stimmt nicht mit der Realität überein. Ich zweifle, dass es MySQL ist.

dedlfix.

[Linuchs]

Einer von euch beiden stimmt nicht mit der Realität überein. Ich zweifle, dass es MySQL ist.

myPhpAdmin zeigt nicht die Art der Datenbank. Meine Programme melden MySQL-Vers.=[10.1.37-MariaDB-0+deb9u1]

Aber auch Maria macht's mal wie gewünscht und beim zweiten Mal eben nicht.

[dedlfix]

Tach!

Einer von euch beiden stimmt nicht mit der Realität überein. Ich zweifle, dass es MySQL ist.

myPhpAdmin zeigt nicht die Art der Datenbank. Meine Programme melden MySQL-Vers.=[10.1.37-MariaDB-0+deb9u1]

Egal ob MariaDB oder MySQL, schau lieber nach, wie die Tabellen wirklich definiert sind.

dedlfix.

[Linuchs]

schau lieber nach, wie die Tabellen wirklich definiert sind.

Wo schaut man da?

Beim Export sieht es so aus:

CREATE TABLE `bia_interessenten` (
  `id` int(11) NOT NULL,
...
  `last_modified` timestamp NOT NULL DEFAULT '1999-12-31 23:00:00' ON UPDATE CURRENT_TIMESTAMP
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

[dedlfix]

Tach!

schau lieber nach, wie die Tabellen wirklich definiert sind.

Wo schaut man da?

Beim Export sieht es so aus:

CREATE TABLE `bia_interessenten` (
  `id` int(11) NOT NULL,
...
  `last_modified` timestamp NOT NULL DEFAULT '1999-12-31 23:00:00' ON UPDATE CURRENT_TIMESTAMP
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Die Felder nicht weglassen, die könnten anders definiert sein. Der Wert für die Tabelle ist nur ein Defaultwert beim Anlegen von Feldern, wenn da keine Angabe gemacht wird.

dedlfix.

[Rolf B]

Hallo Linuchs,

so, Recherche beendet.

https://mariadb.com/kb/en/supported-character-sets-and-collations/

Nicht jede Collation passt zu jedem Charset. Die Collation utf8_bin gehört zum Charset utf8, wie die verlinkte Quelle zeigt, und für das Charset utf8mb4 brauchst Du die Collation utf8mb4_bin.

Offenbar stellt phpMyAdmin die DB-Verbindung mit einem anderen Charset her als dein Programm, das kann man bei Verbindungsaufname festlegen. In PDO mit einer charset-Angabe im Connection String, in mysqli mit der set_charset Methode auf dem mysqli Objekt.

Wenn Du nichts angibst, dann ist utf8 oder eine Einstellung an der Datenbank wohl der Default.

Der Unterschied zwischen utf8 und utf8mb4 ist die maximale Länge einer Codesequenz für ein Zeichen. Bei utf8 ist es 3, bei utf8mb4 ist es 4. Die Folge ist, dass man mit utf8 nur die Basis-Ebene des Unicode darstellen kann (65536 Zeichen) und mit utf8mb4 bis zu 2,1 Millionen Zeichen.

Ich nehme an, dass diese Restriktion bei utf8 aus der Zeit vor Unicode 3.1 stammt (bis Unicode 3.0 reichte das. Unicode 3.1 ist von 2001 und MySQL von 1995) und man damit Speicher sparen wollte. utf8mb4 wurde später eingeführt, um der lieben Kompatibilität wegen mit einem neuen Namen.

Rolf

[Linuchs]

Hallo Rolf,

erstmal danke, dass du dich wieder mal so besonders reinkniest. Verstanden habe ich allerdings nur Bahnhof.

Die beiden Beispiele stammen aus zwei Mini-php-Programmen, die eine schnelle Antwort auf ihre Ajax-Anfragen geben. Das eine Programm schlägt Orte vor (funktioniert), das andere Adressen (funktioniert nicht). Zwar zwei Tabellen, aber dieselbe Datenbank.

Beide Programme beginnen so:

error_reporting( E_ERROR | E_WARNING | E_PARSE );  // Einfache Laufzeitfehler melden
mb_internal_encoding('UTF-8');
header('content-type: text/plain; charset=UTF-8');
...
// ==========================
// DATENBANK OEFFNEN
// ==========================
function zeigMeldung( $text ) {echo $text;} // Fatal error: Call to undefined function zeigMeldung() in _db_connect.php
include( "../db/_db_connect.php" );
db_connect(0);
$conn_id = $db[0]['conn_id'];
@mysql_query( "SET NAMES 'utf8'", $conn_id );
...

Damit hatte ich noch nie Probleme, erst heute. Und ich weiß nicht, warum. Wo könnte ich einen Charset bestimmen?

[dedlfix]

Tach!

erstmal danke, dass du dich wieder mal so besonders reinkniest. Verstanden habe ich allerdings nur Bahnhof.

Der phpMyAdmin ist das Problem in dem Fall, und nicht die Tabellendefinition, wie ich zuerst annahnm. Auf der Startseite steht, welche Zeichenkodierung/Collation er für die Verbindung verwendet, und das ist wohl utf8mb4_…. Stell das auf utf8_… um, wenn du Statements mit utf8_… als Collation-Angabe verwendest.

dedlfix.

[Linuchs]

Hallo dedlfix,

Auf der Startseite steht, welche Zeichenkodierung/Collation er für die Verbindung verwendet

Startseite? Die sehe ich seit 20 Jahren heute (vermutlich) zum ersten Mal, nach dem Login ist man ja nicht drauf:

Also gut, umgestellt auf

Aber das war's nicht, Fehler bleibt. Hätte mich auch gewundert, da mein PHP-Programm und myPhpAdmin unabhängig voneinander auf die Tabellen zugreifen.

[Rolf B]

Hallo Linuchs,

könntest Du nochmal klarstellen, wo der Fehler auftritt und wo nicht? Ich war der Meinung, es hätte im myPhpAdmin nicht funktioniert.

Wenn Du für myPhpAdmin die Collation/das Charset änderst, gilt das natürlich auch nur für SQL Statements im myPhpAdmin.

Wenn Du den Fehler auch in einem PHP Script von Dir hast, und dieser Fehler unerklärlicherweise von jetzt auf gleich entstanden ist, dann musst Du Dich natürlich fragen, was Du unabsichtlich geändert hast. Irgendwas muss es ja sein. Du kannst, wie geschrieben, im PHP Programm auch noch mysql[i]_set_charset verwenden, um utf8 zu erzwingen.

Ich hatte selbst auch kurz probiert, mit meinem MySQL 5.6 Relikt und PHP 7.4. Ich habe allerdings PDO zur Verbindungsherstellung verwendet. Wenn ich da den charset-Parameter verwende, um utf8 oder utf8mb4 einzustellen, kann ich deinen Fehler nachvollziehen. Man muss halt die Collation verwenden die zum Charset passt.

Rolf

[Linuchs]

Hallo Rolf,

und dieser Fehler unerklärlicherweise von jetzt auf gleich entstanden ist, dann musst Du Dich natürlich fragen, was Du unabsichtlich geändert hast

Logisch. Bevor ich hier frage, tüftle ich natürlich erstmal, will ja nicht als Trottel dasitzen, der Punkt und Komma verwexelt. Ein beliebter Fehler und beim Überfliegen des Code leicht zu übersehen.

Und dann vergleiche ich zwei Programme, die gleichartig sind. Manchmal tippe ich eine Zeile neu - sie sieht exakt so aus wie die alte - aber funktioniert plötzlich.

Ich nehme es hin wie Schnee und Regen. Vielleicht haben zwei Zeichen, die exakt gleich aussehen verschiedenen Code. Vielleicht hat sich ein unsichtbares Zeichen eingeschlichen. Vor Jahren war die E-Mail auf einer Webseite mit solchen Zeichen „versaut“.

Oder ich berühre irgendwas. So verschwindet ein Tab aus dem Browser und findet sich in einer neuen Instanz wieder. Ich weiß weder, was ich da berührt habe, noch, wie ich den Tab wieder zurückbekomme in seine Familie.

Du empfiehlst mysqli - warum? Diese Mini-Ajax-Antwortprogramme eignen sich gut zum Ausprobieren. Bin aber kritisch bei persönlichen Vorlieben ohne Begründung.

Im Prinzip möchte ich einen Fehler verstehen und nicht umgehen.

Gruß, Linuchs

[Rolf B]

Hallo Linuchs,

mysqli ist Martins Kennzeichenbeleuchtung. Hat nichts mit dem Problem zu tun, ist aber trotzdem irgendwann wichtig. Weil es eine technische Schuld ist, die Du irgendwann zahlen musst. Die mysql-Schnittstelle gibt's nur in PHP 5. PHP 5 ist tot. Es wird nicht mehr gewartet. Falls es Security-Bugs gibt, behebt sie niemand menr. Es ist gefährlich geworden, es einzusetzen. Aber deswegen hast Du keine Collation/Charset Probleme. Und es steht dir natürlich frei, auf deinen Geburtstag zu gucken und zu sagen: "Mein Nachfolger will auch noch Arbeit haben" (den Du nicht findest, oder wie war das?).

Richtig geantwortet hast Du jetzt nicht, aber ich lese es trotzdem raus, dass da zwei Commandline-Programme sind, die an entscheidender Stelle (DB-Verbindungsaufbau) gleich aussehen und trotzdem unterschiedlich reagieren. In dem einen funktioniert COLLATE 'utf8_bin', im anderen fliegt es raus weil Collation utf8_bin nicht mit Charset utf8mb4 kompatibel ist.

Richtig wiedergegeben?

Wenn's nicht am Programm liegt, woran dann? Das ist jetzt von hier aus die reine Hellseherei. Vermutlich hast Du Dich das alles auch schon gefragt, aber ich liste mal trotzdem auf.

• Du connectest zur gleichen DB?
• Du verwendest den gleichen User?
• Hast Du ein init-statement in dem Maria-Äquivalent zur my.cnf?
• Du machst das mit der gleichen PHP Instanz/Version?
• Du machst das vom gleichen Computer aus?
• Sind die Scripte im gleichen Ordner? Werden sie mit der gleichen php.ini gestartet? Includen sie die gleiche ../db/_db_connect.php Datei?

Bau mal ein, dass nach dem mysql_connect die Funktion mysql_client_encoding aufgerufen wird. Die liefert das eingestellt Charset. Unterscheidet sich was?

Probier mal, statt der SET NAMES Query die mysql_set_charset Funktion aufzurufen - das ist der vom Handbuch empfohlene Weg weil der MYSQL-Treiber das dann auch mitbekommt.

Irgendwo muss ja was anders sein. Der Küstennebel ist nur leider zu dicht, um durchzustochern. Oder ich bin vom Küstennebel zu dicht... hehehe.

Rolf

[dedlfix]

Tach!

Probier mal, statt der SET NAMES Query die mysql_set_charset Funktion aufzurufen - das ist der vom Handbuch empfohlene Weg weil der MYSQL-Treiber das dann auch mitbekommt.

Das hat keinen Einfluss auf das Problem. Der Unterschied ist nur, dass die clientseitige Funktionen mysql_real_escape_string() damit das Charset auch kennt und berücksichtigen kann^[1]. Bei den üblichen Kodierungen ISO-8859-x und UTF-8 ist das unerheblich, weil alle zu behandelnden Zeichen in jedem Fall korrekt beachtet werden.

dedlfix.

---

1. https://dev.mysql.com/doc/c-api/8.0/en/mysql-set-character-set.html ↩︎

[Linuchs]

Moin Rolf,

so, nun mit zeitlichem Abstand, ausgeruht, gefrühstückt neu ans Werk.

PHP 5 ist tot.

Aber noch nicht bestattet, ich habe tatsächlich MySQL-Vers.=[10.1.37-MariaDB-0+deb9u1], PHP-Vers.=[5.6.40-0+deb8u1]

Mein Server steht in Frankfurt und ich kann per ssh zugreifen. Gibt es eine wasserdichte Anleitung, die neue Version aufzuspielen?

Bau mal ein, dass nach dem mysql_connect die Funktion mysql_client_encoding aufgerufen wird.

Ist bei beiden Programmen latin1

Bei getOrte.php mache ich dieses:

SELECT
 SQL_CALC_FOUND_ROWS
 ort1.id
,ort1.land_kz
,ort1.plz
,ort1.name
,ort1.name_zusatz
,ort1.bundesland

FROM    bia_orte ort1
WHERE     ort1.loe_kz       =  0
AND       (   LOWER(name)        LIKE '%6452%' COLLATE 'utf8_bin'           OR plz                LIKE  '6452%' COLLATE 'utf8_bin'           OR LOWER(name_zusatz) LIKE '%6452%' COLLATE 'utf8_bin'           OR LOWER(keywords)    LIKE '%6452%' COLLATE 'utf8_bin')

ORDER BY  name
LIMIT 0,10

und bekomme Ergebnisse. Bei getMitgliederInteressenten.php dieses

(
SELECT
 adr1.id      VIP
,'0'          ITR
,adr1.firma1  firma1
,adr1.ort_id
,adr1.land_kz
,adr1.plz
,adr1.ort     ort_name

FROM          bia_adressen adr1
WHERE         adr1.owner_id = 1
AND           LOWER( adr1.firma1 ) LIKE '%brem%' COLLATE 'utf8_bin'
AND           adr1.loe_kz = '0'
)
UNION
(
SELECT
 '0'          VIP
,itr1.id      ITR
,itr1.firma1  firma1
,itr1.ort_id
,itr1.land_kz land_kz
,itr1.plz     plz
,itr1.ort     ort_name
FROM          bia_interessenten itr1
# ist dieser Interessent auch Mitgled?
LEFT JOIN     bia_adressen adr1
ON            adr1.id  = itr1.adress_id

WHERE         itr1.owner_id = 1
AND           LOWER( itr1.firma1 ) LIKE '%brem%' COLLATE 'utf8_bin'
AND           itr1.loe_kz = '0'
AND          (itr1.adress_id IS NULL OR  adr1.loe_kz = '1' ) -- nicht, wenn Interessent kein oder **aktives** Mitglied ist
)
ORDER BY  firma1
LIMIT 0,10

und laufe auf den Fehler 1253: COLLATION 'utf8_bin' is not valid for CHARACTER SET 'latin1' Wie jetzt? Gestern wars utf8mb4, heute latin1

Probier mal, statt der SET NAMES Query die mysql_set_charset Funktion aufzurufen

Habe ich gemacht mysql_set_charset('utf8', $conn_id); - Fehler ist weg. Anschließend //mysql_set_charset('utf8', $conn_id); auskommentiert, Fehler bleibt weg.

Habe Firefox beendet (löscht Cookies) und neu aufgerufen. Fehler bleibt weg trotz latin1.

Pfuscht mir da jemand ins Handwerk? Vor einiger Zeit bekam ich diese seltsame Mail:

Hallo HErr OSxxxxx,

ich bin bei Recherchen für Leaks auf die Daten der IP 195.34.184.98 gestossen.
Könnten sie da prüfen ob alles abgesichert ist und evtl. Sicherungsmaßnahmen durchführen ?

https://leakix.net/host/195.34.184.98
 https://leakix.net/about


Mit freundlichen Grüßen / kind regards

INET Team
Jan Cxxxxxxxx


Mit freundlichen Grüßen / kind regards

INET Team
Jan Cxxxxxxxxx

Habe ich nicht weiter beachtet, da ich immer mal wieder „seltsame“ Mails mit bekanntem Absender bekomme. Jan C. ist der Operator bei dem Hoster, bei dem mein Server steht. Er hat mir u.a. https eingerichtet. Die seltsame Groß- und Kleinschreibung in der Anrede bei sonst ordentlichem Text sagte mir, da stimmt was nicht.

Gruß, Linuchs

[Der Martin]

Hallo,

PHP 5 ist tot.

Aber noch nicht bestattet, ich habe tatsächlich MySQL-Vers.=[10.1.37-MariaDB-0+deb9u1], PHP-Vers.=[5.6.40-0+deb8u1]

Mein Server steht in Frankfurt und ich kann per ssh zugreifen. Gibt es eine wasserdichte Anleitung, die neue Version aufzuspielen?

normalerweise über apt-get. Aber das Installieren einer aktuellen PHP-Version zieht sehr wahrscheinlich nach sich, dass einige Scripts nicht mehr funktionieren, weil sie noch Funktionen verwenden, die mittlerweile nicht mehr zur Verfügung stehen.

Bau mal ein, dass nach dem mysql_connect die Funktion mysql_client_encoding aufgerufen wird.

Ist bei beiden Programmen latin1

Nicht utf8??

Bei getOrte.php mache ich dieses:
und bekomme Ergebnisse. Bei getMitgliederInteressenten.php dieses

Du hast bei deinen Bezeichnern eine eigenartige Sprachmischung. 😉

und laufe auf den Fehler 1253: COLLATION 'utf8_bin' is not valid for CHARACTER SET 'latin1' Wie jetzt? Gestern wars utf8mb4, heute latin1

Bist du sicher, dass du nichts verwechselst? In mySQL wird die Codierung einmal als Default für die ganze Tabelle festgelegt, einmal individuell für jedes Feld, und dann nochmal für die Textschnittstelle zwischen Server und Client (Anwendung).

Habe ich gemacht mysql_set_charset('utf8', $conn_id); - Fehler ist weg. Anschließend //mysql_set_charset('utf8', $conn_id); auskommentiert, Fehler bleibt weg.

Die letzte Einstellung bleibt anscheinend gespeichert. Hätte ich nicht erwartet.

Habe Firefox beendet (löscht Cookies) und neu aufgerufen. Fehler bleibt weg trotz latin1.

Klar. Dadurch ändert sich ja PHP-seitig nichts.

Pfuscht mir da jemand ins Handwerk? Vor einiger Zeit bekam ich diese seltsame Mail:

Hallo HErr OSxxxxx,

...

INET Team
Jan Cxxxxxxxxx

Habe ich nicht weiter beachtet, da ich immer mal wieder „seltsame“ Mails mit bekanntem Absender bekomme. Jan C. ist der Operator bei dem Hoster, bei dem mein Server steht.

Und hast du den nicht gefragt, ob diese Nachricht wirklich von ihm kommt, oder ob das ein Fake ist?

Live long and pros healthy,
 Martin

[Tabellenkalk]

Hallo,

Die seltsame Groß- und Kleinschreibung in der Anrede bei sonst ordentlichem Text sagte mir, da stimmt was nicht.

Wenn das der einzige Hinweis sein soll, bist du zu paranoid. Dass am Wortanfang zwei Buchstaben statt einem groß sind, kommt bei Schnelltippern schon mal vor. Textprogramme haben dafür extra eine Korrekturfunktion.

Gruß
Kalk

[Rolf B]

Hallo Linuchs,

@mysql_query( "SET NAMES 'utf8'", $conn_id );

Damit hatte ich noch nie Probleme,

Uh oh - aber Du wirst, wenn Du mal PHP 7 einsetzt. mysql ist tot wie ein Tarpan^[1] und die Aufrufe sollten unbedingt auf mysqli umgestellt werden.

SET NAMES 'utf8' ist, so wie ich das verstehe, die nicht empfohlene Art, den Zeichensatz der Verbindung einzustellen. Korrekt wäre

mysql_set_charset('utf8', $conn_id);

äh, also eigentlich natürlich

mysqli_set_charset('utf8', $conn_id);
// bzw.
$conn_id->set_charset('utf8');

Rolf

---

1. um man das engl. dead as a dodo irgendwie zu übersetzen ↩︎

[Der Martin]

Hallo Rolf,

mysql ist tot wie ein Tarpan [um man das engl. dead as a dodo irgendwie zu übersetzen]

zumindest die Alliteration hast du damit recht gut ins Deutsche hinübergerettet. Aber was zum Geier ist ein Tarpan? Nie gehört.
Da musste ich doch erstmal die allwissende Müllhalde befragen (nein, diesmal gleich die andere).

Wieder was gelernt. 😀

Live long and pros healthy,
 Martin

[klawischnigg]

Hi there,

Keine Ahnung, was mit CHARACTER SET 'utf8mb4' gemeint ist. Die Felder haben alle die Kollation utf8_unicode_ci

Wahrscheinlich sind die einzelnen Felder mit uft8mb4 definiert. Unter phpmyadmin unter Struktur als Kollation in der Feldbearbeitung zu finden (wenn Du ein deutschsprachiges phpmyadmin hast). Und kann dort auch geändert werden, für jedes Feld einzeln.

Ich weiß nicht, wie Du Deine Tabellen erstellst, aber wenn man zB die Table durch ein Skript erstellen läßt, in dem die Kollation bei den einzelnen Feldern nicht definiert ist, dann passiert das manchmal, daß defaultmäßig ein Charcter-Set utf8mb4 angenommen wird (ich nehm einmal an das ist dem Umstand geschuldet, daß utf8mb4 so ziemliche alle Eventualitäten abdeckt, die als Zeichensatz daherkommen könnten.)...

[Linuchs]

Die Fehler konnten nicht zuverlässig herbeigeführt werden, ich habe den Grund also nicht verstanden.

Habe die beiden Mini-Programme neu aufgesetzt mit mysqli und Angabe von char_set:

include( "../db/_db_connect.php" );
$mysqli = new mysqli($db[0]['host'], $db[0]['id'], $db[0]['pw'], $db[0]['database']);
if ( $mysqli->connect_errno ) {
  die ('Connect Error (' . $mysqli->connect_errno . ') ' . $mysqli->connect_error );
} else {
//echo 'Success... ' . $mysqli->host_info . "<br>\n";
  $mysqli->set_charset( 'utf8' );
}

Jetzt funktioniert es wie gewünscht. Mal schaun, wie lange. Danke für eure Hilfe.

Linuchs