Problem mit Character Sets

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

  • Problem mit Character Sets

    Hallo,

    vielleicht kann mir hier jemand einen Hinweis zu folgenden Problem geben. Ich muss in einer Tabelle teilweise polnische Inhalte verwalten können. Nur werden zur Zeit einige poln. Sonderzeichen nicht richtig in die DB geschrieben. Kein Problem habe ich mir gedacht und wollte mir mal die Einstellungen zu den Character Sets ausgeben lassen. Nur irgendwie scheint keiner der Befehle zu Character Sets (z.B. "SHOW CHARACTER SET" mal als einfaches Beispiel) zu funktionieren.
    Hat dazu jemand eine Idee?

    Ach ja, MySQL läuft auf auf einer Debian Sarge Kiste und ich habe auch Zugriff als Root darauf.
    Freundliche Grüße
    avo

  • #2
    MySQL läuft auf auf einer Debian Sarge Kiste
    dann ist das wohl noch eine 4.0 version, die kann das nocht nicht. erst ab 4.1 oder 5.0 läuft das mit character sets

    gruß
    peter
    Nukular, das Wort ist N-u-k-u-l-a-r (Homer Simpson)
    Meine Seite

    Kommentar


    • #3
      SHOW CHARACTER SET gibt es seit Version 4.1.0.

      Welche Version setzt du ein?
      Ich denke, also bin ich. - Einige sind trotzdem...

      Kommentar


      • #4
        ein mal für immer!
        wenn du mit mehreren Sprachen arbeiten willst nur utf-8 benutzen.
        dabei spielt charset von db bei einer php-Anwendung kaum eine rolle.
        bei älteren mysql versionen muss man aber auf die länge von felder aufpassen, da für darschtellung von einer Kyrilischer Buchstabe etwa 4 lataeinischen rein passen.
        Slava
        bituniverse.com

        Kommentar


        • #5
          Ok, dann habe ich noch 'ne ältere Version (4.0). Kein Wunder, dass es nicht funktioniert hat.
          Original geschrieben von Slava
          dabei spielt charset von db bei einer php-Anwendung kaum eine rolle.
          Wie darf ich das jetzt verstehen? Wenn ich mit PHP einen Text utf-8 kodiere ist es egal wenn die DB z.B. den Latin1-Zeichensatz hat? Oder meintest du, dass es egal ist wenn die DB utf-8 hat?
          Freundliche Grüße
          avo

          Kommentar


          • #6
            ersteres ....
            INFO: Erst suchen, dann posten![color=red] | [/color]MANUAL(s): PHP | MySQL | HTML/JS/CSS[color=red] | [/color]NICE: GNOME Do | TESTS: Gästebuch[color=red] | [/color]IM: Jabber.org |


            Kommentar


            • #7
              ja es wird auch mit Latin1 funktionieren.
              wenn formulare in utf-8 gesendet sind und bei anzeige auch utf-8 verwendet wird, dann gibt es kein problem mit ausnahme von der länge von Strings.
              Ä ist jetzt 2 zeichen lang.
              PHP-Code:
              header('Content-Type: text/html; charset=utf-8');
              $ding="дфгххтреыÄswüüöÖ";//russische buchstaben
              $str="Ä";//Ä
              echo "<html>";
              echo 
              $ding."<br />";
              echo 
              $str." ist ".strlen($str)." zeichen Lang ";
              echo 
              "</html>"
              EDIT:
              es ist aber utf-8 tabellen zu empfehlen, da sie extra für utf-8 ausgedacht sind.
              mit PHP6 wird die sache noch leichter, da wir die ganze code in utf-8 erstellen können.

              Zuletzt geändert von Slava; 25.10.2006, 16:52.
              Slava
              bituniverse.com

              Kommentar


              • #8
                Original geschrieben von Slava
                ja es wird auch mit Latin1 funktionieren.
                wenn formulare in utf-8 gesendet sind und bei anzeige auch utf-8 verwendet wird, dann gibt es kein problem mit ausnahme von der länge von Strings.
                Na ja, wenn man mal von Sortierungen etc. absieht ...
                I don't believe in rebirth. Actually, I never did in my whole lives.

                Kommentar


                • #9
                  Original geschrieben von wahsaga
                  Na ja, wenn man mal von Sortierungen etc. absieht ...
                  mit sortirung gibt es eigentlich kein problem, da es eigentlich kein sinn hat japanische zeichen mit deutschen zu vergleichen.
                  die tabelle muss in utf-8 sein,
                  damit es ein japanische zeichen als "1" zeichen erkannt wird und nicht als 4 deutsche buschstaben,
                  damit die stringfunctionen, die zeichenlängen brauchen wie z.b.s "left" die buchstaben und nicht bytes zählt .

                  edit: dabei habe ich vergessen, dass ein japanische zeihen nicht unbedingt eine Buchstabe ist, sondern kann auch ein ganzes satz bedeuten
                  Zuletzt geändert von Slava; 25.10.2006, 17:56.
                  Slava
                  bituniverse.com

                  Kommentar


                  • #10
                    Original geschrieben von Slava
                    mit sortirung gibt es eigentlich kein problem, da es eigentlich kein sinn hat japanische zeichen mit deutschen zu vergleichen.
                    die tabelle muss in utf-8 sein,
                    damit es ein japanische zeichen als "1" zeichen erkannt wird und nicht als 4 deutsche buschstaben,
                    damit die stringfunctionen, die zeichenlängen brauchen wie z.b.s "left" die buchstaben und nicht bytes zählt .

                    edit: dabei habe ich vergessen, dass ein japanische zeihen nicht unbedingt eine Buchstabe ist, sondern kann auch ein ganzes satz bedeuten
                    Es ist vollkommener Schwachsinn dem DBMS vorzugaukeln, dass die Daten einen anderen Zeichensatz haben, als sie eigentlich haben.
                    Sowas führt spätestens bei der Wiederverwertung der Daten durch einen anderen, vernünftig programmierten, Client zu Problemen, die man *dann* aufgrund der schon vorhandenen, ggf. großen, Datenmenge nur noch durch weitere hässliche workarounds umgehen kann.

                    Vor MySQL 4.1 blieb einem leider nichts anderes übrig als die Daten utf8-kodiert in die latin1 Datenbank zu schreiben, seit der eben genannten Version kann man allerdings angeben welchen Zeichensatz die Daten haben und soll das auch in Gottes Namen bitte korrekt tun. Ansonsten kann man sein Projekt eigentlich auch gleich im Papierkorb speichern...

                    Und @php6
                    Man kann auch jetzt schon seinen php Code mit UTF8 speichern, mache ich, machen viele andere auch schon.
                    PHP ignoriert einfach jede Art von Mehrbyte-Zeichen, deshalb ist es ja überhaupt möglich jetzt zum Beispiel schon UTF8 zu verwenden.

                    Der Unterschied, bzw. die Änderung, umfasst die Beachtung des aktuellen Zeichensatzes durch PHP um dem Programmierer einige Probleme abzunehmen; z.B. Einfacher Vergleich von Strings, keine gesonderten Funktionen mehr, Anpassen der Ausgabe von Text vom Zeichensatz der Datei an den Zeichensatz des Outputs, ... weiteres findet sich auf http://www.zend.com/zend/week/php-unicode-design.txt
                    Generell ändert das nichts daran, dass man die Zeichenkodierung der Verbindung korrekt einstellen muss; Änderungen sind in Hinsicht der Datenbankschnittstelle aber wohl eher nicht zu erwarten, demnach hat das absolut nichts mit dem Thema zutun.

                    Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                    bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                    Wie man Fragen richtig stellt

                    Kommentar


                    • #11
                      Original geschrieben von Slava
                      mit sortirung gibt es eigentlich kein problem
                      Doch, gibt es.

                      Ein ä in UTF-8, als Latin-1 abgespeichert sieht so aus: ä
                      Wenn du das jetzt einsortieren willst, kannst du nicht erwarten dass dieses ä zwsichen a und b einsortiert wird - weil ä eben "größer" als a und größer als b ist.

                      die tabelle muss in utf-8 sein,
                      Natürlich, dann gibt es kein Problem.

                      Aber vorher war doch vom anderen Fall die Rede - dass die DB eben noch kein UTF-8 unterstützt, und man deshalb eben UTF-8 kodierte Daten als Latin-1 o.ä. ablegt.
                      I don't believe in rebirth. Actually, I never did in my whole lives.

                      Kommentar


                      • #12
                        1) nach kurzem überlegen, nehme ich die Aussage
                        dabei spielt charset von db bei einer php-Anwendung kaum eine rolle.
                        zurück.
                        die verschiedene Kollation von utf-8 bei mysql sind auch dafür gemacht worden um die sortierung und andere Sprachen-spezifische Funktionalitäten zu ermöglichen.
                        wenn aber in der Tabelle mit kollation utf8_swedish_ci auf ein mal ein paar chinesische wörter rein kommen, dann gibt es leider fast die gleiche probleme wie bei latain_1 tabellen.

                        OffTopic:
                        wann kommt endlich der Tag als ASCII für immer begraben wird?
                        char muss langsam in char32 für immer umwandeln
                        Slava
                        bituniverse.com

                        Kommentar

                        Lädt...
                        X