I've just started to work with PHPMyAdmin 3 and stumbled over a change in display that is wrong in my eyes. It is probably related to this patch that asked for display of binary fields in binary by default:
However, it seems this default setting is also applied to (var)char fields that have some sort of binary collation. This produces very inconsistent (and in my eyes wrong) results.
I have the following three fields:
LangID type binary(2)
ar type varchar(40) collation utf8_bin
de type varchar(20) collation utf8_bin
The content in these fields is displayed as follows.
edit record display:
ar "content in Arabic"
So, LangID is displayed non-binary although it is a binary field. However, when editing it suddenly is displayed in binary. (And I don't understand why this would have to be unhexed when submitting to the db.)
On the other hand, of the varchar fields one is displayed in binary, the other isn't. But when editing both are displayed with the string content.
1. Whatever "display mode" may seem to be correct, a mix is surely not correct.
2. I think the varchar binary fields should not be displayed in binary by default. According to http://dev.mysql.com/doc/refman/5.1/en/binary-varbinary.html: The BINARY and VARBINARY data types are distinct from the CHAR BINARY and VARCHAR BINARY data types. For the latter types, the BINARY attribute does not cause the column to be treated as a binary string column. Instead, it causes the binary collation for the column character set to be used, and the column itself contains nonbinary character strings rather than binary byte strings.
As a workaround I have set $cfg['DisplayBinaryAsHex'] to FALSE. This seems to give the desired results for both display and edit. But I think this should get corrected as the current behavior is very unexpected for the binary collation fields. I'm neither convinced that the binary display of binary fields by default is a good idea as this is a change to the version 2 default. Deducing from the patch mentioned above only a single person asked for that since the time this setting got introduced (the changelog doesn't mention this variable, so I couldn't check when it got introduced).