Speicherzugriffsfehler beim einlesen von Dateien mit Umlauten


tgs_chris

Grünschnabel
Hallo zusammen,

ich bin jetzt schon seit Tagen auf der Suche und verzweifle jetzt langsam echt daran.

Ich habe eine C++ Anwendung geschrieben, die als Dienst auf einem Debian (4.0) Server läuft und regelmäßig Dateien, die in einem bestimmten Ordner abgelegt werden in eine MySQL Datenbank importiert. Bei den Dateien handelt es sich um txt-Dateien, die Tabulator-getrennte Werte enthalten.
Ich dachte eigentlich, dass ich inzwischen schon fertig war, da der Dienst die letzten fünf Tage ohne Probleme lief und die Daten korrekt in die Datenbank geschrieben hat. Doch gestern Nacht habe ich vom Server eine Mail bekommen mit der Meldung, dass das Programm unerwartet beendet wurde und zwar auf Grund eines "Speicherzugriffsfehler".

Daraufhin habe ich die aktuellen Dateien heruntergeladen und das Programm über den Debugger gestartet. Dieser lief auch die ersten 35 Datensätze ohne Probleme durch, endete dann aber mit einer Exception. Leider konnte ich an der Stelle lange nichts finden, bis ich rausgefunden hab, dass an dieser Stelle ein Umlaut (ö) enthalten ist. Daraufhin wollte ich mir die Variable ausgeben lassen (über cout) und habe festgestellt, dass an der entsprechenden Stelle wo der Umlaut stehen müsste der String aufhört. Da er in der Datei korrekt drin steht ist also der Fehler irgendwo im Code. Ich dachte jetzt daran die Codierung der Datei irgendwo einzustellen damit c++ weiß wie er den String einlesen soll. In C# würde ich das mit
Code:
Encoding enc = Encoding.GetEncoding("iso-8859-1");
machen, aber wie bzw. ob es unter C++ geht weiß ich nicht. Die Codierung der Datei ist anscheinend ISO-8859-1.

Leider konnte ich noch keine Lösung finden, obwohl ich schon mehrfach Google bemüht habe. Habt ihr vielleicht einen Hinweis, wie ich die Codierung fürs einlesen ändern kann?

Anbei mal der Codeschnipsel der zum auslesen der Datei benutzt wird:
PHP:
    #include <sys/types.h>
    #include <unistd.h>
    #include <iostream>
    #include <time.h>
    #include <mysql/mysql.h>
    #include <fstream>
    #include <string>
    #include <sstream>
    [...]
    ifstream DataStream(filename);

    while (getline(DataStream, Record))
    {
        istringstream record(Record);
        string DataItem;

        for (int ColumnCounter = 1; getline(record, DataItem, '\t'); ColumnCounter++) 
        {
            RecordArr[ColumnCounter] = DataItem;
            /**
             * hier passiert noch mehr, was aber nicht von Bedeutung ist...
             */
        }
    }
Das auslesen klappt anscheinend auch noch, denn dort meckert er noch nicht rum, aber hier kommt dann der Speicherzugriffsfehler:
PHP:
sprintf(query,
          "SELECT * FROM `table` "
          "WHERE `column` = '%s' LIMIT 2",
          RecordArr[1].c_str()); // HIER HÄLT DER DEBUGGER AN!

Ich hoffe Ihr könnt mir ein wenig weiter helfen.
Vielen Dank schonmal im voraus.
 

GillBates

Mitglied
Hi,

wenn er bei einem Umlaut abschmiert, würde ich es mal mit Wide Strings( wchar_t, ... ) versuchen. Ausserdem mal mit Unicode testen.
Ist z. B. unter Windows so.


grüssle :)
 

devDevil

Erfahrenes Mitglied
Pff ... std::local :p

Nja so also das liegt eigtl. nicht an umlauten. Zeig mal deine Definition von RecordArr
 

tgs_chris

Grünschnabel
PHP:
string  RecordArr[50];

Ein Freund von mir, dessen Informatik-Studium wohl doch nicht ganz umsonst war :rolleyes:, und ich haben es jetzt gelöst. Die Ursache war zwar der Umlaut, aber das Problem lag woanders. Und zwar im sprintf();
Wir haben die sprintf ersetzt und das ganze mit stringstream gemacht. Vollständigkeitshalber mal hier die Lösung:
PHP:
stringstream QueryStream;

[..]

QueryStream << "SELECT * FROM `table` "
                    << "WHERE `column` = '" << RecordArr[1] << "' "
                    <<" LIMIT 2";
mysql_query(MySQLConn, QueryStream.str().c_str());

[..]

Trotzdem vielen Dank an alle die sich Gedanken gemacht haben :)
 

devDevil

Erfahrenes Mitglied
Nja, weil std::stringstream nunmal nicht die Beschränkung auf die Größe hat ... von d.h. würde ich eher auf sowas tippen.
 

Forum-Statistiken

Themen
272.356
Beiträge
1.558.615
Mitglieder
187.830
Neuestes Mitglied
hansmeiser