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

  • 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

  • #2
    Die Daten waren beim Import falsch (in einem anderen Encoding) kodiert...

    Kommentar


    • #3
      Das hatte ich fast schon vermutet

      Kann ich das irgendwie ohne Reimport beheben?


      mfg

      Kommentar


      • #4
        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...

        Kommentar


        • #5
          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.

          Kommentar


          • #6
            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

            Kommentar


            • #7
              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.

              Kommentar


              • #8
                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?

                Kommentar


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

                  Kommentar


                  • #10
                    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

                    Kommentar

                    Lädt...
                    X