Guma

[string in uft-8 umwandeln]

Hallo zusammen, ich will einen String $buffer in uft-8 umwandeln. wie kann ich das mit php bewerkstelligen

grüße von Guma

[wahsaga]

hi,

Hallo zusammen, ich will einen String $buffer in uft-8 umwandeln. wie kann ich das mit php bewerkstelligen

iconv Funktionen, Multibyte String Functions

grüße von Guma

Ach, nicht von string in uft-8 umwandeln?

gruß,
wahsaga

[Guma]

Hallo wahsager,

Ach, nicht von string in uft-8 umwandeln?

doch du hast Recht. Weiter will ich einen string in eine MYSQL DB schreiben am besten schon als uft-8 - String. er kommt aus einer multiple-select-box und wurde aus einer asci-datei leistungen.csv eingelesen:

$handle = fopen("leistungen.csv","r");
  while (!feof($handle)) {
    $buffer = fgets($handle, 4096);
    $buffer_utf8 = utf8_encode($buffer);
 $ctmp = mysql_query("SELECT leistung,id FROM logo_leistungen WHERE id='$myid' && leistung LIKE '$buffer_utf8'");
    if(mysql_num_rows($ctmp)>0) $selected = " selected";
    else $selected = "";
    echo "<option value="".$buffer_utf8."" ".$selected.">".$buffer_utf8."</option>";
}
fclose ($handle);

So jetzt dachte ich mir wird der string schon im uft-8-Format ausgegeben und in die datenbank eingetragen. Das scheint aber nicht der fall zu sein. Denn wenn ich den datensatz in der datenbank ändere (mit phpmyadmin) wird dieser in uft-8 konvertiert. sowas seltsames. wo ist mein fehler? Guma

[dedlfix]

echo $begrüßung;

Weiter will ich einen string in eine MYSQL DB schreiben am besten schon als uft-8 - String. er kommt aus einer multiple-select-box und wurde aus einer asci-datei leistungen.csv eingelesen:

Ein sehr komplexes Thema, weil es hier viele verschiedenen Stellen zum Fehlermachen gibt. Ich werde es nur im Groben anreißen, da man damit ganze Tutorials füllen kann. Außerdem gehe ich davon aus, dass du einen MySQL-Server in Version 4.1 oder höher verwendest.

Als erstes gilt es das Kapitel Character Support zu lesen und zu verstehen, an welchen Stellen man überall Zeichenkodierungen einstellen kann, und wo automatisch Umwandlungen vorgenommen werden. Für letzteres ist besonders das Kapitel Connection Character Sets and Collations wichtig und auch das Statement "SET NAMES ...". (Das Teilthema Collation ist dabei nichts so interessant, dabei geht es nur um richtige Sortierung.)

Als nächstes kommen die eingeschränkten oder kaum vorhandenen Fähigkeiten PHPs (kleiner als Version 6) hinzu, Strings in Mehrbyte-Zeichenkodierungen zu verarbeiten. Zumindest das Umwandeln von ISO-8859-1 (MySQL sagt latin1 dazu) nach UTF-8 und zurück funktioniert[*].

Und außerdem kommt noch die Kodierung der Webseite hinzu, und das was die Browser dabei anstellen.
Die Kodierungsangabe im HTTP-Header ist dabei die ausschlaggebende, wenn sowohl sie als auch eine Ersatz-Angabe in einem HTML-Meta-Element vorhanden ist.
Verwendet man eine Kodierung, die ein bestimmtes vom Anwender eingegebenes Zeichen nicht enthält, senden manche Browser eine Ersatzdarstellung in Form eines HTML-Entities &#x...; Das lässt sich leider nicht von einer gewollten Eingabe des Anwenders unterscheiden. Gut, das kommt nicht so häufig vor, ist aber trotzdem unschön.

echo "$verabschiedung $name";

[*] Natürlich mit den technisch bedingten Einschränkungen. Zeichen, die mit ISO-8859-1 nicht darstellbar sind, gehen bei einer Wandlung von UTF-8 nach ISO-8859-1 verloren.

[Guma]

Danke für die Erklärung dedlfix,

ich verstehe gut, dass hier und da Fehler auftreten können, wenn SQL und Textdateien zusammen arbeiten. Um dem aus dem weg zu gehen bin ich am überlegen, ob ich die Wertetabelle nicht besser als SQL-Tabelle anlege und damit arbeite. Dann müssen keine Umkodierungen stattfinden. Nur: Was mache ich mit den alten Datensätzen in der relationalen Datenbank? Die werde ich wohl mit Select und Update umschreiben und trimmen. Dann ist das ganze sauber und besser umgesetzt. Die Zusammenarbeit von Textfiles mit SQL ist etwas komplizerter und umfangreicher. Einfacher ist besser.

Grüße von Guma

[dedlfix]

echo $begrüßung;

ich verstehe gut, dass hier und da Fehler auftreten können, wenn SQL und Textdateien zusammen arbeiten.

Sie treten nur auf, wenn man (aus Unwissenheit) die entsprechenden verwendeten Kodierungen aller Beteiligten nicht beachtet.

Um dem aus dem weg zu gehen bin ich am überlegen, ob ich die Wertetabelle nicht besser als SQL-Tabelle anlege und damit arbeite. Dann müssen keine Umkodierungen stattfinden.

Du solltest dich auf eine Kodierung festlegen, und die dann konsequent überall verwenden:

• Default-Einstellung des MySQL-Servers
• Datenbank
• Tabelle
• (String-)Felder
• Verbindung zu Clients (PHP)
• Editor/IDE muss mit der Kodierung umgehen können
• PHP-Quellcode- und Template-Dateien
• die mit PHP erzeugten Webseiten (korrekte Angabe in HTTP-Header und HTML-Meta-Element)

Nur: Was mache ich mit den alten Datensätzen in der relationalen Datenbank?

Wenn sie schon in der Datenbank drinstehen, und mit phpMyAdmin richtig angezeigt werden, reicht es, die Kollation[*] der einzelnen Felder umzustellen, anschließend die der Tabelle und die der Datenbank.

Die Zusammenarbeit von Textfiles mit SQL ist etwas komplizerter und umfangreicher.

Beim Importieren ist auf die richtige Kodierungsangabe zu achten, dann klappt das auch.

echo "$verabschiedung $name";

[*] So nennt es phpMyAdmin. Eigentlich müsste es "Zeichenkodierung und Kollation" heißen.

[Guma]

Hallo nochmal, ich will kurz schildern was ich hier für ein Problem habe:

Ich habe folgende Tabelle in MySQL 5.0
-- Tabellenstruktur für Tabelle logo\_leistungen

CREATE TABLE logo\_leistungen (
  id\_firma int(11) NOT NULL default '0',
  leistung varchar(100) collate latin1_german2_ci NOT NULL,
  KEY id\_firma (id\_firma)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci;

Jetzt beim Update mit PHPMyAdmin wird vom selbst in utf8 convertiert:

UPDATE logo\_leistungen SET leistung = 'Aqua' WHERE id\_firma =1 AND CONVERT( leistung USING utf8 ) = 'Aqua\n' LIMIT 1 ;

Warum passiert das? ist der vorhandene datensatz nicht UFT8 und wird deshalb umgewandelt? Ich bekomme dann dieses /n hinter meinen eintrag, das mir dann später Probleme bei der Select-Ausgabe macht.

Wer kann mir hierzu Auskunft geben?! Guma

[dedlfix]

echo $begrüßung;

Jetzt beim Update mit PHPMyAdmin wird vom selbst in utf8 convertiert:

UPDATE logo\_leistungen SET leistung = 'Aqua' WHERE id\_firma =1 AND CONVERT( leistung USING utf8 ) = 'Aqua\n' LIMIT 1 ;

Warum passiert das? ist der vorhandene datensatz nicht UFT8 und wird deshalb umgewandelt?

Das hängt ganz sicher mit den Einstellungen der Zeichenkodierungen zusammen. Es ist wichtig, dass du das Thema verstehst, weil es sonst zu Datenverlust kommen kann. Kodierungen lassen sich nicht beliebig verlustfrei hin- und herwandeln. Eine Korrektur ist dann nur mit menschlichem Verstand möglich, weil nur dieser weiß, dass das Ersatzzeichen "?" an dieser Stelle ein "ä" und an jener ein "ö" sein sollte.
Das Zeichenkodierungskonzept von MySQL ist sehr mächtig, aber auch sehr komplex. Hinzu kommen noch die verschiedene Schnittstellen zwischen allen beteiligten Komponenten (MySQL, PHP, Browser, phpMyAdmin, ...).

Warum phpMyAdmin dort eine Konvertierung vorgenommen hat lässt sich nur aus den Einstellungen von MySQL und der Konfiguration von phpMyAdmin erklären. Auf der Startseite von phpMyAdmin stehen zwei Werte zu den Punkten:

• MySQL-Zeichensatz
• Zeichensatz / Kollation der MySQL-Verbindung

Wenn phpMyAdmin meint, eine Umwandlung vornehmen zu müssen, dann ist das aus seiner Sicht sicherlich richtig.

Ich bekomme dann dieses /n hinter meinen eintrag, das mir dann später Probleme bei der Select-Ausgabe macht.

Vielleicht hast du das irgendwo unbewusst in einer Textarea eingegeben.

echo "$verabschiedung $name";