laut ASCII-Tabelle wird das Zeichen & als %26 richtig interpretiert.

Deine Tabelle ist fehlerhaft - & ist in ASCII das mit Dezimal 38 und Hexadezimal 26 zu finden, der Unicode-Codepoint ist U+0026.

Eine %-Codierung gibt es in ASCII nicht - du verdrehst hier irgendwas mit URL-Encoding.

Wenn also ein User das &-Zeichen in meinem Formular manuell eingibt, wandel ich dieses in %26 um.

Warum? Das Umwandeln für den Zeitraum der Kommunikation von Client zu Server übernehmen Client und Server selbsttätig - bei dir am Server kommt wieder ein & an dass du 1:1 so in dei Datenbank schreiben kannst.

Das erlaubt mir dann auch diese Variable an andere Scripte zu übergeben.

Es gibt sicher Kontexte in denen % nicht erlaubt ist - z.B. im Kontext URL weil er hier für das %-Encoding verwandt wird.

Letztendlich soll die Eingabe in einer MySql-Datenbank gespeichert werden. Dort wird natürlich nun das Zeichen %26 gespeichert, was natürlich nicht sein soll.

Richtig - darum unterlasse das unsinnige URL-Encoding und speichere Kontextneutral in der Datenbank

Ich dachte mit [...$variable=htmlspecialchars($variable);...] wird das ganze richtig abgespeichert. Ist aber nicht so.

Hier wechselst du in den Kontext HTML - du befindest dich aber immer noch in einem Neutralen Kontext wo du höchstens syntaktische Eigenheiten des DBMS beachten musst.

Was muss ich also mit meiner Variable machen, bevor ich Sie in meiner Datenbank speicherer?

Je nach DBMS jagst du sie durch eine Funktion, die alle für die Abfragesprache spezifischen Zeichen entsprechenden den Vorgaben maskiert.

Im Fall von MySQL ist das z.B. in PHP die Funktion mysql_real_escape_string() - sofern es sich um einen String handelt.

Diesen Lesestoff solltest du dir _unbedingt_ zuführen, bevor du weitere Überlegungen anstellst: Artikel:Kontextwechsel