Ankündigung

Einklappen
Keine Ankündigung bisher.

2 Verschiedene Kodierungen in einer Tabelle?

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Runnerle
    hat ein Thema erstellt 2 Verschiedene Kodierungen in einer Tabelle?.

    2 Verschiedene Kodierungen in einer Tabelle?

    Hallo alle zusammen, ich weiß zwar nicht ob es jetzt eine Anfängerfrage ist oder nicht.

    Ich habe ein Problem mit den Daten die ich von Mysql bekomme.

    Ich habe eine Tabelle text. Da sind nun ca 1000 einträge drin. Manche wurden übers cms eingepflegt und die anderen wiederum wurder per csv importiert.

    So weit so gut, wenn ich jedoch jetzt texte auslese wird die eine hälfte korrekt dargestellt und die andere zeigen nur kodierungsfehler.

    Wie kann das sein? Eine Tabelle kann doch nur eine Kodierung unterstützen, was für mich hieße das die daten die da drin stehen ebenfalls alle gleich kodiert sind

    Wäre für jede hilfe Dankbar

    mfg Runnerle

  • Runnerle
    antwortet
    Zitat von feeela Beitrag anzeigen
    Frag das den TE!
    Import Daten existieren nicht mehr, und zum teil wurden Datensätze schon angepasst.

    Zitat von feeela Beitrag anzeigen
    In meinem Fall waren da alle Möglichen Sprachen (inkl. ru, ja & zh) in den Kodierungen ISO-8859-1, ISO-8859-15 und UTF-8 (jeweils teilweise mit HTML-Entities) wild durcheinander gespeichert. Das geht schon, ist aber ein Riesenaufwand. Ein paar ä sind nix im Vergleich zu japanisch in ISO-8859-1.
    Hört sich wirklich sehr exrem an, sind aber gott seit dank nur Deutsch.

    Werd mich jetzt mal ans script setzen und hoffen, dass die Rechnung aufgeht.

    Vielen Dank an alle!

    mfg

    Einen Kommentar schreiben:


  • feeela
    antwortet
    Zitat von nikosch Beitrag anzeigen
    Außerdem - wozu der AUfwand, wenn die Importdaten noch existieren?
    Frag das den TE!

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    Unrettbar ist aber gar nix.
    Ich denke schon, dass es Konvertierungen gibt, die nicht umkehrbar sind.

    Außerdem - wozu der AUfwand, wenn die Importdaten noch existieren?

    Einen Kommentar schreiben:


  • feeela
    antwortet
    Zitat von Runnerle Beitrag anzeigen
    aber wenn ich alle texte durchlaufen würde und per str_replace oä.
    aus einem ä ein ä machen würde?
    Wenn du nur deutsche Texte hast, ist das eine (umständliche) Möglichkeit. Solltest du noch andere Sprachen mit Sonderzeichen dabei haben ist das ein enormer Aufwand. Von Sprachen, deren Zeichen in Mulitbyte-Kodierungen gespeichert werden ganz zu schweigen...

    Zitat von nikosch Beitrag anzeigen
    Ein Feld...
    Mmmh, hatte ich wohl erst anders verstanden. In einer Spalte wirds natürlich schwer. Unrettbar ist aber gar nix. Die Variablen sind nur der investierte Zeitaufwand und die nervliche Belastbarkeit. Ich habe auch schon eine vermurkste DB wieder her gestellt. Das hat dann ca. eine volle Woche gedauert, um ein Skript zu bauen, welches alle Sonderfälle abdeckt - immerhin bezahlt.
    In meinem Fall waren da alle Möglichen Sprachen (inkl. ru, ja & zh) in den Kodierungen ISO-8859-1, ISO-8859-15 und UTF-8 (jeweils teilweise mit HTML-Entities) wild durcheinander gespeichert. Das geht schon, ist aber ein Riesenaufwand. Ein paar ä sind nix im Vergleich zu japanisch in ISO-8859-1.

    Einen Kommentar schreiben:


  • Runnerle
    antwortet
    Zitat von feeela Beitrag anzeigen
    2. Wenn du jeweils weißt, wie die ursprüngliche Kodierung war und wie die Daten jetzt gespeichert sind, kannst du durchaus die Umwandlungsfunktionen von MySQL nuzten um was zu retten...
    Zitat von nikosch Beitrag anzeigen
    Ein Feld... , ja. Das Problem bei Dir ist, dass die Codierung des nicht passenden Imports/CMS-INSERT als das entspr. Charset interpretiert wurde und damit Murx ist. Zu retten ist da i.A. nix. Schon gar nicht, wenn Du die Datensätze nicht unterscheiden kannst.
    Die meinungen sind da wohl gespalten :/

    aber wenn ich alle texte durchlaufen würde und per str_replace oä.
    aus einem ä ein ä machen würde?

    Wer mich mal dahinter klemmen.

    mfg

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    Eine Tabelle kann doch nur eine Kodierung unterstützen
    Ein Feld... , ja. Das Problem bei Dir ist, dass die Codierung des nicht passenden Imports/CMS-INSERT als das entspr. Charset interpretiert wurde und damit Murx ist. Zu retten ist da i.A. nix. Schon gar nicht, wenn Du die Datensätze nicht unterscheiden kannst.

    Einen Kommentar schreiben:


  • feeela
    antwortet
    Zitat von Runnerle Beitrag anzeigen
    Das hatte ich fast schon vermutet

    Kann ich das irgendwie ohne Reimport beheben?


    mfg
    1. Es können in einer Tabelle sehr wohl mehrere Kodierungen in verschiedenen Spalten existieren;

    2. Wenn du jeweils weißt, wie die ursprüngliche Kodierung war und wie die Daten jetzt gespeichert sind, kannst du durchaus die Umwandlungsfunktionen von MySQL nuzten um was zu retten...

    Einen Kommentar schreiben:


  • Runnerle
    antwortet
    Das hatte ich fast schon vermutet

    Kann ich das irgendwie ohne Reimport beheben?


    mfg

    Einen Kommentar schreiben:


  • lstegelitz
    antwortet
    Die Daten waren beim Import falsch (in einem anderen Encoding) kodiert...

    Einen Kommentar schreiben:

Lädt...
X