MySQL 5.5, Information_Schema, utf-8

[hotti]

Liebe Mitdenker,

Charset, Collation muss stimmen und das Programm muss mit MySQL per UTF-8 kommunizieren (SET NAMES ...), dann passt alles rein.

Was hat die Collation mit dem Speicherplatzbedarf des Feldes zu tun?

Gar nichts hast rechts. Aber wenn Du richtig mit kodierten Strings arbeiten willst, sollte die schon passen.

Was ist an 'set names' besser, als an der PHP-Funktion mysqli_set_charset()?

Das musst Du selbst rausfinden. In Perl ists so, dass mysql_enable_utf8 => 1 die Kommunikation bidirektional auf utf-8 schaltet, d.h., dass die Abfragen utf-8-kodierte Zeichenketten liefern und dem Statement übergebene Oktetten automatisch zu UTF-8-Strings werden. Mit "set names utf8" allein muss sich der Programmierer selbst um die Kodierung kümmern, er muss für die Inserts aus den Oktetten UTF-8-kodierte Strings machen und das auch aus den Oktetten, welche zurückkommen.

Dein Versuch hinkt allerdings. Du müsstest mal 9 (oder 10?) Zeichen einfügen, die jedes vier Oktetts benötigen. ...

Es funktioniert auch mit text char(10), auch da kann ich 10 €-Zeichen einfügen, das sind 30 Bytes. Ob MySQL je nach Version 3,4 oder gar 5 Bytes für den Charset utf8 reserviert, sollte im Handbuch stehen. Auf jeden Fall wird mit CHARSET=UTF8 mehr Platz reserviert, der jedoch nur dann genutzt werden kann, wenn Charset auch der Kommunikation (Sitzung) bekannt ist, ansonsten gilt die Byte-Semantics: char(10) => 10 Bytes passen da rein.

Set Names UTF8
Character-Semantics: char(10) => 10 Zeichen passen rein

Btw., die neueste JS-Library stringview.js erlaubt 5 Bytes für UTF-8.

MfG