Tach!
Und aus gegebenem Anlass: Bytesemantic in MySQL
Mir erschließt sich nicht, was du beweisen möchtest, aber es sieht mir nicht sinnvoll aus, was du da beschreibst. Wenn man mit Bytes arbeiten möchte, nimmt man nicht (VAR)CHAR / TEXT sondern (VAR)BINARY / BLOB als Feldtyp.
Zudem hast du ausgelassen, was bei derartig falschen Feldtypen passiert, wenn die Verbindungskodierung auf UTF-8 steht (SET NAMES utf8).
Wenn du eine Ein-Byte-Kodierung als Feldtyp deklarierst und diese Ein-Byte-Kodierung ebenfalls als Verbindungskodierung nimmst, heißt das noch lange nicht, dass MySQL dann die Daten durchgehend als Bytes behandelt. Aber was sonst sollte man denn für ein Verhalten bei Ein-Byte-Kodierungen erwarten, als dass da die Zeichen als 1 Byte abgelegt werden? Dass es doch nicht nur nackige Bytes sind, sieht man, wenn Umkodierungen ins Spiel kommen. Schreib mal deinen Binärstrom in ein Latin1-Feld, wenn die Verbindungskodierung auf Latin1 steht, und dann lies die Daten mal aus, wenn die Verbindungskodierung auf UTF-8 steht. Da bekommst du die Zeichen oberhalb CodePoint 127 in bester UTF-8-Kodierung geliefert, also 2 bis 3 Bytes, wenn du das Resultat als Bytes statt als Zeichen behandelst.
dedlfix.