There is a misunderstanding. A hexadecimal search must be with 2 characters per byte, not an ASCII search.
In Hex Edit
mode (binary file) you can for example search for the ASCII string UltraEdit
with Find ASCII
But if this string is stored in the binary file in Unicode with UTF-16 Little Endian encoding, you won't find this string. In this case you need to search for UltraEdit
with a hexadecimal search with Find ASCII
option not checked. The hexadecimal search string would be in this case55 00 6C 00 74 00 72 00 61 00 45 00 64 00 69 00 74 00
or alternatively without the spaces55006C007400720061004500640069007400
Now it should be clear what the information below the search string edit field means which is:
UE wrote: Hex strings should have two characters per byte and each byte may be separated with a space.
Example: FF FE FD or FFFEFD
Let us think you make a mistake and miss a hexadecimal digit as in the string 55006C00740072006004500640069007400
. Can you quickly see where the hexadecimal digit is missing? How should UltraEdit find out where the hexadecimal digit is missing in the search string?
But what about a hexadecimal string with each byte separated by a space and one hexadecimal character is missing like in55 00 6C 00 74 00 72 00 6 00 45 00 64 00 69 00 74 00
It would be easy to detect with code that there is a hexadecimal digit missing in this string and also where. But how to handle this? Should the search be now with 0x06
or with 0x60
? Well, both would be wrong and the user who made the typing mistake would be misled to byte sequence not existing in binary file instead of getting noticed about a missing hexadecimal digit in the search string.
See also Find Unicode text in hex edit mode
for a scripting solution to easily find a text encoded in UTF-16 LE in a file displayed currently in hex edit mode.