han: größe eines string in byte

Hi,

kann ich die Größe eines string überpüfen?
Wie groß der string st in byte?

gruß

  1. kann ich die Größe eines string überpüfen?

    => Ja

    Wie groß der string st in byte?

    => 1 Zeichen/Char hat 8 bit == 1 byte

    MFG
    Jungesmedium

    1. Hallo Jungesmedium.

      kann ich die Größe eines string überpüfen?
      => Ja

      Wie groß der string st in byte?
      => 1 Zeichen/Char hat 8 bit == 1 byte

      Zumindest in normalen ASCII-artigen Kodierungen. Ab UTF-8 kann ein Zeichen auch mehrere Byte lang sein.

      Einen schönen Freitag noch.

      Gruß, Mathias

      --
      ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
      debian/rules
      1. hi, ist dann ein text feld in mysql überhaupt sinnvoll besuchertexte?
        aber varchar geht auch nur bis 200irgendwas

        1. P.S. wären bei text ja über60.000 zecihen wer braucht das

        2. Moin!

          hi, ist dann ein text feld in mysql überhaupt sinnvoll besuchertexte?
          aber varchar geht auch nur bis 200irgendwas

          VARCHAR geht in älteren Versionen bis 255 Bytes (woraus folgt, dass UTF-8 beispielsweise in ungünstigen Fällen nur 1/4 dieser Bytezahl an Zeichen speichern kann - wenn jedes UTF-8-Zeichen nämlich 4 Byte benötigt).

          In neueren Versionen (ab MySQL 4.1) ist UTF-8 bekannt und wird berücksichtigt, die Längenangabe ist also eine echte Zeichenanzahl - das Feld benötigt dann ggf. einfach mehr Bytes, was aber nicht stört, da die benötigte Speichermenge sowieso dynamisch ist und sich an den Daten orientiert.

          Wenn du dagegen etwaige Performancevorteile durch konstante Feldlängen nutzen willst (MySQL kann dann genau berechnen, wo ein einzelner Datensatz liegt, und muß auch keinen Platz schaffen, um diesen Datensatz mit evtl. längeren Daten zu überschreiben), müssen alle Felder einer Tabelle konstante Längen haben. Du mußt also für alle Felder CHAR statt VARCHAR verwenden, und auch TEXT bzw. BLOB sind dann verboten. Der Nachteil ist, dass MySQL für ein CHAR-Feld die dreifache Menge der Länge an Bytes fest reserviert, wenn du Unicode (z.B. UTF-8) benutzt. Die dadurch entstehende Leere bläht die Datenbank wiederum ziemlich auf, so dass die Performance durch größere Lesevorgänge dann wieder aufgefressen wird.

          Auch Textfelder wie TEXT sind nur in ihrer maximalen Länge begrenzt, verbrauchen jedoch immer nur so viel Speicherplatz, wie aktuell im jeweiligen Datensatz drinsteht (plus ein paar Byte zusätzlich als Längenangabe).

          - Sven Rautenberg

          --
          "Love your nation - respect the others."
      2. Hallo Mathias,

        Wie groß der string st in byte?
        => 1 Zeichen/Char hat 8 bit == 1 byte

        Zumindest in normalen ASCII-artigen Kodierungen. Ab UTF-8 kann ein Zeichen auch mehrere Byte lang sein.

        stimmt - aber wir hatten doch vor einiger Zeit schon einmal herausgefunden, dass strlen() sowohl in PHP als auch in C einfach stur die Anzahl der Bytes zählt und sich einen feuchten Kehricht um Zeichencodierungen kümmert.

        Ergo liefert strlen() tatsächlich die Länge des Strings in Bytes - aber nicht unbedingt die Anzahl der Zeichen. Die Anzahl der Zeichen unter Berücksichtigung der Codierung erhält man in PHP mit mb_strlen().

        Ciao,
         Martin

        --
        Kleine Geschenke erhalten die Freundschaft.
        Große verderben sie aber meist auch nicht.
        1. hi,

          sind alle zeichen, die ein user bei einer iso seite in ein eingabefeld dann 1byte?

          wenn ich nämlcih das eingabefeld auf 100 begrenze begrezne ich ja die zeichenanzahl, muss aber in meiner mysl_tabelle möglihcerweise mehr angeben oder?

          1. echo $begrüßung;

            sind alle zeichen, die ein user bei einer iso seite in ein eingabefeld dann 1byte?

            Das kommt, wie schon erwähnt, auf die verwendete Zeichenkodierung an. Bei ISO-8859-x wird jedes Zeichen mit einem Byte kodiert. Damit lassen sich dann auch nur jeweils 255 Zeichen repräsentieren.

            wenn ich nämlcih das eingabefeld auf 100 begrenze begrezne ich ja die zeichenanzahl, muss aber in meiner mysl_tabelle möglihcerweise mehr angeben oder?

            Das kommt, wie Sven schon erwähnte, auf die MySQL-Version an und auch auf die verwendete Zeichenkodierung.

            Es kann auch noch passieren, dass du a) zwar die Länge des Input-Feldes auf 1 Zeichen begrenzt, du b) jedoch eine ISO-8859-Zeichenkodierung verwendest, und c) der Nutzer ein Zeichen eingibt, das damit nicht darstellbar ist, z.B. ǒ (ein o mit Caron). Der Browser schickt dir daraufhin eine Ersatzdarstellung in der Form &#466;. Das sind trotz maxlength=1 schlappe 6 Zeichen. Was nun?

            Verwende lieber eine Zeichenkodierung mit der praktisch alle Zeichen repräsentierbar sind, beispielsweise UTF-8. Verwende einen Editor, der damit umgehen kann. Verwende eine Datenhaltung, die mit solchen Multibyte-Kodierungen umgehen kann. Verwende Daten verarbeitende Systeme, die entweder die Daten nur durchreichen oder die mit Multibyte-Kodierungen umgehen können. Und da fangen dann auch die Probleme an. Nicht alle Ausgaben von MySQL können mit Multibyte-Kodierungen umgehen (sprich: Versionen kleiner als 4.1). Datenbank und Clients müssen sich über die verwendete Kodierung abstimmen. PHP kann noch nicht vollständig mit UTF-8 umgehen oder entsprechende Erweiterungen sind beim Provider nicht installiert. Und so weiter und so fort. Nichtsdestotrotz ist UTF-8 derzeit die sinnvollste Möglichkeit, Probleme mit der Repräsentierung von Zeichen zu lösen.

            echo "$verabschiedung $name";

            1. Moin!

              Der Browser schickt dir daraufhin eine Ersatzdarstellung in der Form &#466;. Das sind trotz maxlength=1 schlappe 6 Zeichen. Was nun?

              Diese Ersatzdarstellung schicken nur kaputte Browser. Leider muß man derzeit dem Firefox attestieren, in diesem Fall kaputt zu sein. Der Bug ist schon seit Jahren offen, wird aber anscheinend ignoriert, oder bereitet zu große Probleme beim Programmierteam.

              Verwende lieber eine Zeichenkodierung mit der praktisch alle Zeichen repräsentierbar sind, beispielsweise UTF-8.

              Diesen Rat kann ich uneingeschränkt unterstützen. Insbesonder aufgrund der ziemlich kaputten Verhaltensweisen mancher Browser, wenn es darum geht, nicht-codierbare, aber vom User eingegebene Zeichen in einem Formular abzuschicken.

              Und da fangen dann auch die Probleme an. Nicht alle Ausgaben von MySQL können mit Multibyte-Kodierungen umgehen (sprich: Versionen kleiner als 4.1). Datenbank und Clients müssen sich über die verwendete Kodierung abstimmen. PHP kann noch nicht vollständig mit UTF-8 umgehen oder entsprechende Erweiterungen sind beim Provider nicht installiert. Und so weiter und so fort. Nichtsdestotrotz ist UTF-8 derzeit die sinnvollste Möglichkeit, Probleme mit der Repräsentierung von Zeichen zu lösen.

              Sagen wir es mal so: Die entstehenden Probleme sind beherrschbar, wenn man bei der Entwicklung bedenkt, dass sie auftreten können.

              strtolower() ist beispielsweise eine nette PHP-Funktion - sie funktioniert aber mit UTF-8-Strings überhaupt nicht, man kann also aus einem UTF-8-Ü kein kleines ü machen, sondern zerstört damit das Zeichen komplett. Aber oftmals gibt es Ersatz. Eine UTF-8-fähige Datenbank bietet ja auch Stringfunktionen, man muß die Wandlung in Kleinbuchstaben also eventuell einfach nur ins SQL-Statement verschieben.

              PS: Javascript arbeitet grundsätzlich in Unicode, da gibt es gar keine alternativen Codierungen. Genauso wie HTML grundsätzlich alle Unicode-Zeichen unterstützt, das Resultat von beispielsweise Formularfeldvorbelegungen (die man mit Javascript abfragen kann) ist, unabhängig von der Codierung der HTML-Quelltexte, also immer ein Unicode-String (wobei man sich in Javascript nicht mal um die konkrete Codierung, also UTF-8 etc., kümmern muß - es funktioniert einfach).

              - Sven Rautenberg

              --
              "Love your nation - respect the others."
              1. Hallo Sven.

                strtolower() ist beispielsweise eine nette PHP-Funktion - sie funktioniert aber mit UTF-8-Strings überhaupt nicht, man kann also aus einem UTF-8-Ü kein kleines ü machen, sondern zerstört damit das Zeichen komplett.

                Bei mir werden die grossgeschriebenen nicht-ASCII-Zeichen einfach unverändert zurückgegeben.

                Einen schönen Samstag noch.

                Gruß, Mathias

                --
                ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
                debian/rules
                1. Moin!

                  strtolower() ist beispielsweise eine nette PHP-Funktion - sie funktioniert aber mit UTF-8-Strings überhaupt nicht, man kann also aus einem UTF-8-Ü kein kleines ü machen, sondern zerstört damit das Zeichen komplett.

                  Bei mir werden die grossgeschriebenen nicht-ASCII-Zeichen einfach unverändert zurückgegeben.

                  Komisch. Bei mir wurde aus dem "großen A-Tilde" ein "kleines A-Tilde" - und das hat natürlich alle Umlaute zerstört, die in UTF-8 immer mit dem großen A-Tilde beginnen.

                  - Sven Rautenberg

                  --
                  "Love your nation - respect the others."
                  1. Hallo Sven.

                    strtolower() ist beispielsweise eine nette PHP-Funktion - sie funktioniert aber mit UTF-8-Strings überhaupt nicht, man kann also aus einem UTF-8-Ü kein kleines ü machen, sondern zerstört damit das Zeichen komplett.

                    Bei mir werden die grossgeschriebenen nicht-ASCII-Zeichen einfach unverändert zurückgegeben.

                    Komisch. Bei mir wurde aus dem "großen A-Tilde" ein "kleines A-Tilde" - und das hat natürlich alle Umlaute zerstört, die in UTF-8 immer mit dem großen A-Tilde beginnen.

                    Das klingt, als würdest du die UTF-8-Bytesequencen als ASCII anzeigen lassen. Hierbei ist das Resultat natürlich nicht abzuschätzen.

                    Sowohl auf der Kommandozeile als auch in einem Script bleiben bei mir die Zeichen unangetastet. (Also auch „Æ“ beispielsweise bleibt unverändert an statt zu „æ“ zu werden.)

                    Einen schönen Sonntag noch.

                    Gruß, Mathias

                    --
                    ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
                    debian/rules
                    1. Moin!

                      Komisch. Bei mir wurde aus dem "großen A-Tilde" ein "kleines A-Tilde" - und das hat natürlich alle Umlaute zerstört, die in UTF-8 immer mit dem großen A-Tilde beginnen.

                      Das klingt, als würdest du die UTF-8-Bytesequencen als ASCII anzeigen lassen. Hierbei ist das Resultat natürlich nicht abzuschätzen.

                      Ist doch klar. PHP kennt nur "ASCII". Und strtolower() bearbeitet auf Basis von ISO-8859-1.

                      Die einzelnen Bytes eines UTF-8-Zeichens werden also unabhängig voneinander "verkleinert".

                      Sowohl auf der Kommandozeile als auch in einem Script bleiben bei mir die Zeichen unangetastet. (Also auch „Æ“ beispielsweise bleibt unverändert an statt zu „æ“ zu werden.)

                      Nein, diesen Effekt würde ich auch nicht erwarten. Stattdessen sollte eher sowas wie "?" erscheinen, oder sonst ein Zeichenfragment.

                      - Sven Rautenberg

                      --
                      "Love your nation - respect the others."
                      1. Hallo Sven.

                        Komisch. Bei mir wurde aus dem "großen A-Tilde" ein "kleines A-Tilde" - und das hat natürlich alle Umlaute zerstört, die in UTF-8 immer mit dem großen A-Tilde beginnen.

                        Das klingt, als würdest du die UTF-8-Bytesequencen als ASCII anzeigen lassen. Hierbei ist das Resultat natürlich nicht abzuschätzen.

                        Ist doch klar. PHP kennt nur "ASCII". Und strtolower() bearbeitet auf Basis von ISO-8859-1.

                        Die einzelnen Bytes eines UTF-8-Zeichens werden also unabhängig voneinander "verkleinert".

                        Oder, wie in meinem Fall, nicht angerührt, da offenbar kein Äquivalent für die Kleinschreibung bekannt ist.

                        Sowohl als UTF-8 als auch als ISO-8859-15 eingegebene Umlaute verhalten sich bei mir gleich.

                        Sowohl auf der Kommandozeile als auch in einem Script bleiben bei mir die Zeichen unangetastet. (Also auch „Æ“ beispielsweise bleibt unverändert an statt zu „æ“ zu werden.)

                        Nein, diesen Effekt würde ich auch nicht erwarten. Stattdessen sollte eher sowas wie "?" erscheinen, oder sonst ein Zeichenfragment.

                        Also kann ich davon ausgehen, dass dies bei dir der Fall ist?

                        Einen schönen Dienstag noch.

                        Gruß, Mathias

                        --
                        ie:% fl:| br:< va:) ls:& fo:) rl:( n4:~ ss:) de:] js:| mo:| zu:)
                        debian/rules