Byte

Was byte in Go bedeutet

In der Go-Sprachspezifikation steht es klar:

byte is an alias for uint8.

Das ist wörtlich gemeint. byte und uint8 sind identische Typen — kein eigener Typ, kein Wrapper, keine Definition. Der Compiler behandelt beide vollkommen austauschbar:

package main

import (
    "fmt"
    "reflect"
)

func main() {
    var b byte = 65
    var u uint8 = b // keine Konvertierung nötig

    fmt.Println(b, u)              // 65 65
    fmt.Println(reflect.TypeOf(b)) // uint8
}

65 65
uint8

reflect.TypeOf(b) liefert uint8, nicht byte — der Alias verschwindet beim Type-Check. Warum trotzdem den Namen byte? Weil er Absicht kommuniziert: Wer byte schreibt, denkt an Binärdaten oder Text-Bytes; wer uint8 schreibt, denkt an einen kleinen vorzeichenlosen Integer für Arithmetik.

byte vs. rune — wann was nutzen

Go hat zwei Aliase für „ein Zeichen”: byte (= uint8, 8 Bit) und rune (= int32, 32 Bit). Sie lösen unterschiedliche Probleme:

Der Unterschied wird sichtbar, sobald Multibyte-UTF-8 ins Spiel kommt:

s := "Café"

fmt.Println(len(s))                    // 5 — 5 Bytes (é = 2 UTF-8-Bytes)
fmt.Println(len([]rune(s)))            // 4 — 4 Codepoints

for i, b := range []byte(s) {
    fmt.Printf("byte %d = 0x%X\n", i, b)
}

for i, r := range s {
    fmt.Printf("rune at %d = %c (U+%04X)\n", i, r, r)
}

5
4
byte 0 = 0x43
byte 1 = 0x61
byte 2 = 0x66
byte 3 = 0xC3
byte 4 = 0xA9
rune at 0 = C (U+0043)
rune at 1 = a (U+0061)
rune at 2 = f (U+0066)
rune at 3 = é (U+00E9)

Faustregel: byte für rohe Daten und ASCII, rune sobald es um sichtbare Zeichen in beliebigen Sprachen geht.

[]byte als Standard-Container

Praktisch nirgendwo siehst du ein einzelnes byte — fast immer ist es ein []byte, also ein Slice. Das ist der Quasi-Standard für:

• Datei-Inhalte — os.ReadFile liefert []byte.
• HTTP-Bodies — io.ReadAll(r.Body) liefert []byte.
• JSON-Encoding — json.Marshal liefert []byte.
• Crypto — Hashes, Signaturen, AES-Keys: alles []byte.
• Netzwerk-Pakete — TCP/UDP-Payloads sind Byte-Slices.
• String-Bytes, wenn du sie verändern willst (string ist immutable).

data, err := os.ReadFile("config.json")
if err != nil {
    return err
}

var cfg Config
if err := json.Unmarshal(data, &cfg); err != nil {
    return err
}

Anders als string ist []byte veränderbar: data[0] = 'X' funktioniert. Genau deshalb arbeiten Buffer und Streams mit Byte-Slices statt mit Strings.

Konvertierung zwischen string und []byte

Beide Richtungen sind Sprache-eingebaute Type-Conversions:

s := "Hallo"
b := []byte(s) // string -> []byte
b[0] = 'M'

fmt.Println(s)         // Hallo (string ist immutable)
fmt.Println(string(b)) // Mallo

Hallo
Mallo

Wichtig: Beide Konvertierungen kopieren in der Regel die Bytes. Ein string ist immutable, ein []byte mutable — wenn beide denselben Speicher teilen würden, könnte man durch das Slice den String verändern. Das verbietet die Sprache.

In Heißpfaden lohnt es sich, die Anzahl dieser Conversions zu minimieren — bei einem Megabyte-String spürst du die Allokation. Seit Go 1.20 erkennt der Compiler einige Spezialfälle, in denen die Kopie wegfällt (z. B. bei string([]byte) direkt vor einem map-Lookup), aber als Regel gilt: jede Konvertierung kostet eine Allokation.

Byte-Literale

Ein einzelnes Byte schreibst du in Go auf vier Arten:

var (
    dezimal byte = 65
    hex     byte = 0x41
    oktal   byte = 0o101
    binaer  byte = 0b01000001
    ausChar byte = 'A' // Char-Literal als untyped constant -> uint8
)

fmt.Println(dezimal, hex, oktal, binaer, ausChar)
// 65 65 65 65 65

65 65 65 65 65

Achtung beim Char-Literal: 'A' ist eine untypisierte Konstante mit Default-Typ int32 (rune). In einem Kontext, der byte erwartet (z. B. eine byte-Variablen-Deklaration), wird sie zu byte umgedeutet. Aber c := 'A' ohne expliziten Typ ergibt eine Rune, nicht ein Byte:

c := 'A'
fmt.Printf("%T\n", c) // int32 — nicht uint8!

int32

Das bytes-Paket

Das bytes-Paket aus der Standardbibliothek ist das Pendant zu strings, nur für []byte. Es enthält zwei zentrale Typen und eine Reihe nützlicher Funktionen:

• bytes.Buffer — ein wachsender Puffer, der io.Reader und io.Writer zugleich implementiert. Zero-Value ist sofort nutzbar.
• bytes.Reader — ein read-only-Reader über einem festen []byte (implementiert io.Reader, io.Seeker, io.ReaderAt).

var buf bytes.Buffer
buf.WriteString("Hallo, ")
fmt.Fprintf(&buf, "%s!", "Welt")

fmt.Println(buf.String()) // Hallo, Welt!

Hallo, Welt!

Funktionen für direkte Byte-Slice-Operationen:

io.Reader und io.Writer

Die beiden wichtigsten Interfaces der gesamten Standardbibliothek arbeiten mit []byte:

type Reader interface {
    Read(p []byte) (n int, err error)
}

type Writer interface {
    Write(p []byte) (n int, err error)
}

Der Caller stellt einen []byte-Puffer bereit, das Interface füllt ihn (Reader) oder konsumiert daraus (Writer). Damit ist alles, was lesen oder schreiben kann — Files, Sockets, HTTP-Bodies, Crypto-Streams, gzip-Decoder, bytes.Buffer, os.Stdout — über genau dieselbe API ansprechbar:

// File -> stdout (Streaming, ohne alles in den Speicher zu laden)
f, _ := os.Open("daten.bin")
defer f.Close()

io.Copy(os.Stdout, f)

Warum []byte und nicht string? Weil string immutable ist — der Reader müsste bei jedem Aufruf einen neuen String allokieren. Mit []byte kann derselbe Puffer in einer Schleife wiederverwendet werden. Das ist das Fundament für streaming-fähige, allokationsarme I/O.

Performance-Aspekte

Wenn du viel an Text-Daten arbeitest, ist die Wahl zwischen string und []byte ein Performance-Faktor:

• Konkatenation in einer Schleife — bytes.Buffer oder strings.Builder sind drastisch schneller als s = s + ..., weil sie einen wachsenden Puffer wiederverwenden statt jedes Mal neu zu allokieren.
• Vermeide unnötige Conversions — jedes []byte(s) und jedes string(b) allokiert (mit ein paar Compiler-Ausnahmen). Wenn du eine API hast, die string will, und Daten als []byte vorliegen, frage dich, ob die API auch ein []byte annehmen kann.
• bytes.Equal statt == — Slices sind in Go nicht vergleichbar (a == b ist ein Compile-Fehler bei []byte); bytes.Equal macht das richtig und ist auf typische CPU-Pfade optimiert.
• Pre-Sizing — make([]byte, 0, expected) oder buf.Grow(n) sparen Re-Allokationen, wenn die ungefähre Größe vorher bekannt ist.
• Wiederverwendung — in Hot-Pfaden lohnt ein sync.Pool mit Byte-Buffern, um GC-Druck zu reduzieren.

Weiterführende Ressourcen

Externe Quellen

• Numeric types – Go Specification
• String types – Go Specification
• Paket bytes – pkg.go.dev
• Paket io – pkg.go.dev

Verwandte Artikel

• Rune – Unicode-Codepoints, int32-Alias
• String – UTF-8 und Bytes vs. Runes
• Slice – []byte ist ein Slice
• Int – uint8 vs. andere Integer-Typen