Nach Shop-Umzug werden Umlaute falsch angezeigt

Hallo,

nach einem Shop-Umzug (Providerwechsel) werden plötzlich Umlaute falsch angezeigt.

Es wurden die Daten 1:1 übernommen.

Statt “Strümpfe” steht dann eben “Strümpfe”

Lang Dateien habe ich bereits alle auf ISO-8859-15 überprüft

Hi,
woher kommt denn der Text?
Ist das ein Kategorietext oder Artikeltext?
Wenn ja, dann liegt das am falschen charset der Datenbank-Tabellen. Dann wurden die Daten in utf8 exportiert und als latin1 importiert (oder andersrum).

Grüße
Fabian

Bei Kategorien und Artikel wird es falsch angezeigt

Wie kann ich das denn fixen?

so?

http://blog.bartlweb.net/2012/08/mysql-datenbank-in-utf-8-konvertieren/

hab das anhand der Oxid Beschreibung eigentlich schon gemacht, mit der .sql und update.php Datei

[QUOTE=Hebsacker;113860]so?

http://blog.bartlweb.net/2012/08/mysql-datenbank-in-utf-8-konvertieren/[/QUOTE]

hab ich jetzt auch noch probiert, aber keine Änderung merkbar ;/

Es werden Umlaute generell falsch angezeigt, egal ob in Artikel, Kategorien, auch bei Texten, die von lang Dateien stammen, wobei die lang Dateien definitiv das richtige ISO hinterlegt haben

und Texte die von CMS Seiten von OXID stammen, auch da werden Umlaute falsch angezeigt

Gibt’s auch eine Url zum Shop? Könnte sein dass die Einstellung iUtfMode in config.inc.php falsch ist, vergleiche die mal mit dem alten Shop.

@MissV,

  1. Informationen aus dem Export der alten Datenbank:
    Öffne den SQL-Dump (Export) von der alten Datenbank in einem Texteditor. Gleich am Anfang steht dort etwa folgende Information:

-- MySQL dump 10.9
--
-- Host: localhost    Database: usrdb_.........
-- ------------------------------------------------------
-- Server version 4.1.26
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `oxaccessoire2article`
--
DROP TABLE IF EXISTS `oxaccessoire2article`;
CREATE TABLE `oxaccessoire2article` (
  `OXID` varchar(32) collate latin1_german2_ci NOT NULL default '',
  `OXOBJECTID` varchar(32) collate latin1_german2_ci NOT NULL default '',
  `OXARTICLENID` varchar(32) collate latin1_german2_ci NOT NULL default '',
  PRIMARY KEY  (`OXID`),
  KEY `OXOBJECTID` (`OXOBJECTID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci;
 
...
 

Zu jeder Tablle sind weitere Infons im Dump enthalten.

  1. Vergleiche alt/neu
    Dann vergleichst Du das o.g. mit den Einstellungen der neuen Datenbank und stellst erstmal die Unterschiede und damit das konkrekte Problem fest.

Dann sehen wir weiter …

Hi,

ich tippe aufveine simple Servereinstellung in der php.ini :wink:

Gruß

Also die Sicherungsdatei sieht so aus:

CREATE TABLE IF NOT EXISTS `ag_pending_orders` (
  `oxid` char(32) collate latin1_general_ci NOT NULL,
  `userid` char(32) collate latin1_general_ci NOT NULL,
  `useraddr` text collate latin1_general_ci NOT NULL,
  `deladdr` text collate latin1_general_ci NOT NULL,
  `basket` text collate latin1_general_ci NOT NULL,
  `date` datetime NOT NULL,
  `totalprice` varchar(255) collate latin1_general_ci NOT NULL,
  `sessionid` char(32) collate latin1_general_ci NOT NULL,
  `transid` char(32) collate latin1_general_ci NOT NULL,
  PRIMARY KEY  (`oxid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci;

Die neue Datenbank (jedoch bereits nach UTF8 Update wie bei Oxid und in dem Blogpost oben beschrieben) so:

CREATE TABLE `ag_pending_orders` (
  `oxid` char(32) NOT NULL,
  `userid` char(32) NOT NULL,
  `useraddr` mediumtext NOT NULL,
  `deladdr` mediumtext NOT NULL,
  `basket` mediumtext NOT NULL,
  `date` datetime NOT NULL,
  `totalprice` varchar(255) NOT NULL,
  `sessionid` char(32) NOT NULL,
  `transid` char(32) NOT NULL,
  PRIMARY KEY (`oxid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Darf in der neuen Datenbank gar kein latin1 mehr stehen?
Oder wie hilft mir das jetzt weiter? :confused:

[QUOTE=leofonic;113892]Gibt’s auch eine Url zum Shop? Könnte sein dass die Einstellung iUtfMode in config.inc.php falsch ist, vergleiche die mal mit dem alten Shop.[/QUOTE]

Die Einstellung in der config stimmt
die Url ist muso-koroni.com

Herr Doktor, Herr Doktor… alle ignorieren mich…

Nach einer Umstellung auf UTF-8 sollten alle Datenbankkollationen auf UTF-8 stehen, es muss also konsistent sein.

Weil die Sprachkonstanten sauber aussehen, ist es also tatsächlich ein reines Datenbankproblem.

Gruß

Ich möcht kurz generell mal beschreiben, wie ich mit dem Shop umgezogen bin und vielleicht sieht einer von euch dann gleich einen Fehler:

Also:
1.) Ich hab den Shop [U]nicht[/U] inaktiv gestellt, sondern einfach FTP und mysql Datenbank gesichert
2.) FTP und mysql Datenbank eingespielt
3.) config Datei angepasst
4.) Habe dann noch die .htaccess aus der aktuellen OXID Version hochgeladen, da keine übertragen wurde

Muss ich denn generell auch noch chmod Rechte anpassen?
Habe dazu nichts gefunden.

Mittlerweile habe ich ja noch ein zweites Problem.
Das Hosting ist mit zwei Domains aufrufbar, wenn ich es nun aber auf die richtige Domain in der config ändere, funktioniert nichts. Wenn ich z.B. den Admin Bereich aufrufen will, kommt eine Fehlermeldung
Bin bei domainfactory

DANKE!

[QUOTE=Marco Steinhaeuser;113965]Herr Doktor, Herr Doktor… alle ignorieren mich…

Nach einer Umstellung auf UTF-8 sollten alle Datenbankkollationen auf UTF-8 stehen, es muss also konsistent sein.

Weil die Sprachkonstanten sauber aussehen, ist es also tatsächlich ein reines Datenbankproblem.

Gruß[/QUOTE]

Habe gerade den aktuellen Dump nach “latin” durchsucht, und er hat nichts gefunden, daher sollte alles auf UTF-8 sein

Sprachdateien finde ich ja nur bei out/de bzw out/en oder liegen generell noch wo Sprachdateien?

So müsste es gehen:

Beim Importieren die Codierung des SQL-Dumps wählen. Also bei: Zeichencodierung der Datei: latin1.

Zusätzlich, falls die alte DB unter php4 lief, beim SQL-Kompatibilitätsmodus im Drop-Down-Menü entsprechend wählen.

Das Problem ist, dass der Shop trotzdem aktiv ist.
d.h. es gibt zwischenzeitlich neue Artikel, Artikelbestände, Kunden, Bestellungen,… etc

Ein neuer Import ist also nicht wirklich möglich :confused:

Und es werden auch NEUE Einträge mit falschen Umlauten angezeigt.
z.B. eine Bestellung aus Österreich wird im Admin unter Bestellungen so angezeigt: “Österreich”

Dann leg halt zur Sicherheit erstmal eine zweite DB an und importier den alten Dump wie beschrieben dort hinein. Die neuen Daten, die in der neuen DB dazukommen kannst Du dann mit “Update” dazuspielen.

Wie kann ich das denn mit Update dazuspielen?