Good point, the best storage for binary data with unknown size is varbinary(N) column type.
For example in mysql 8.0, insert will cause an error even if both client and server encodings are the same (utf8mb4):
mysql> create table t1(c varbinary(255));
Query OK, 0 rows affected (0.74 sec)

mysql> insert into t1 values(AES_ENCRYPT(‘Hi, Привет, 你好’,’secret’));
Query OK, 1 row affected (0.39 sec)

mysql> select AES_DECRYPT(‘secret’) from t1;
ERROR 1582 (42000): Incorrect parameter count in the call to native function ‘AES_DECRYPT’
mysql> select AES_DECRYPT(c,’secret’) from t1;
+————————–+
| AES_DECRYPT(c,’secret’) |
+————————–+
| Hi, Привет, 你好 |
+————————–+
1 row in set (0.00 sec)

mysql> insert into t values(AES_ENCRYPT(‘Hi, Привет, 你好’,’secret’));
ERROR 1366 (HY000): Incorrect string value: ‘\xA5\xF5\x8D\xB5o\x0F…’ for column ‘c’ at row 1

In heterogeneous character set environment the problem will be also with result set, because AES_DECRYPT returns binary and you need additional conversion step:

select cast(AES_DECRYPT(c,’secret’) AS CHAR CHARACTER SET utf8mb4) as c, @@character_set_client, @@character_set_server from t1;
+—————-+————————+————————+
| c | @@character_set_client | @@character_set_server |
+—————-+————————+————————+
| Hi, Привет, ?? | cp1251 | utf8mb4 |
+—————-+————————+————————+

Best regards,
Nickolay