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...
    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

    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...
        Je grösser der Dachschaden, desto schöner der Ausblick zum Himmel. - [WIKI]Karlheinz Deschner[/WIKI]

        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.
          [COLOR="#F5F5FF"]--[/COLOR]
          [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
          [COLOR="#F5F5FF"]
          --[/COLOR]

          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.
              Je grösser der Dachschaden, desto schöner der Ausblick zum Himmel. - [WIKI]Karlheinz Deschner[/WIKI]

              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?
                [COLOR="#F5F5FF"]--[/COLOR]
                [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                [COLOR="#F5F5FF"]
                --[/COLOR]

                Kommentar


                • #9
                  Zitat von nikosch Beitrag anzeigen
                  Außerdem - wozu der AUfwand, wenn die Importdaten noch existieren?
                  Frag das den TE!
                  Je grösser der Dachschaden, desto schöner der Ausblick zum Himmel. - [WIKI]Karlheinz Deschner[/WIKI]

                  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