Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Could you use hex for (var)binary fields, both when displaying and editing them?
Currently you're showing them as text, but those fields most likely don't contain valid UTF-8 characters.
I've added this feature because we wanted to view and insert UUIDs as binary. I couldn't commit it to svn (no account/permission?), so here's the patch:
The setting is adjustable in the display table options and can be switched on by default using the DisplayBinaryAsHex config option
patch from maatendieleman
Moved to Patches
in browse mode your patch works fine, however when editing, showing hex may bring a problem if the user changes the hex values.
Not 100% sure what you mean, browsing as well as editing in hex is the sole purpose of this patch. If you have binary values exceeding the encoding range of your character set (most likely utf-8), the browser cannot display them correctly thus changing the actual value when 're-saving' such a record even when you haven't actually changed the data yourself. This is by all means very very bad. Editing and saving binary values in hex format keeps the value 'as-is' at all times and makes it possible to copy-paste binary-hex values to and from the database (and other records) which is not possible when displaying binary data in any character encoding that cannot handle such values (this includes utf-8).
So 'changing the hex values' is exactly what you want, if the user is incapable of editing hex values correctly then they shouldn't be using a database administration tool with binary fields in the first place :) But they could also just switch the 'show binary as hex' option off (in the table options) to display and edit the binary values as usual.
Hope this clarifies things!
Ok, here is what I tested. My config is
$cfg['ProtectBinary'] = false;
I have a table with a VARBINARY field. I put the value abc in it. Now when I tick the new option, it shows 616263. If I edit this, changing 63 by 64 because I'm editing in hex and I want the field to contain abd, the result is that my field now contains 363136323634.
Then most likely there is a problem with your installation (other version that interferes with this patch maybe?). When 'display binary as hex' is on, in edit mode, the patch sets the default function for binary fields to UNHEX which turns the hex value into binary. It appears that your installation doesn't set the function to UNHEX which makes it put in the hex value as the true binary value.
The default function is set in tbl_change.php on line 543 based on the field variable of 'display_binary_as_hex' which is set on line 443 after detecting that the field is binary.
(not sure if the line numbers match on your end, but it's easy to spot)
Ok, with the default value of
$cfg['ShowFunctionFields'] = true;
this works; the problem happens if this is set to false, or if the user chooses not to display the Function column. In these cases, the UNHEX() is not applied.
Aha! Alright, my bad :) I've never used that option.
I've added the extra check to the patch:
Merged in subversion, thanks.
Olaf van der Spek
Could "Show binary contents as HEX" be enabled by default?
Otherwise you're still showing invalid UTF-8 (and useless data).
You can use this config option in config.inc.php to enable it by default:
$cfg['DisplayBinaryAsHex'] = true;
Olaf van der Spek
I'm asking for that to be done by default. ;)
Thanks Olaf. In fact I had forgotten to define this in config.default.php. Now defined with true value.