I could reproduce this issue and found lots of other issues on analyzing it.
UltraEdit for Windows is a full Unicode aware application since v24.00. And it looks like it converts also ANSI encoded files with Windows-1252 encoding to Unicode in memory since v24.00.
Following happens on positioning the caret left to character
“ and pressing
Alt+RETURN to get the
Character Properties displayed for this character.
- UE v25.00.0.58 displays as hexadecimal value 0x201c instead of 0x93.
0x201c is the correct Unicode code value while 0x93 is the correct Windows-1252 code value of this character.
- UltraEdit v24.00.0.43 to v24.20.0.62 display in Character Properties for this character wrong 0x1c.
This is just the low byte of the Unicode code value of this character.
- Older UltraEdit for Windows versions up to v23.20.0.43 display in Character Properties correct 0x93 for “ stored in a Windows-1252 encoded file.
In my opinion it is wrong that
Character Properties displays the decimal and hexadecimal Unicode code value of the character as hold in memory instead of the code values of this character as stored in Windows-1252 encoded file. I expect to get displayed the code values of the Windows-1252 encoded character even if the character is hold in memory currently as Unicode character.
Running a Perl regular expression
Find or
Replace on current file with
\x93 as search string works for UE < 24.00, but does not find Windows-1252 encoded character
“ with UE v24.00.0.43 to UE v25.00.0.58. It is necessary with those full Unicode aware versions of UltraEdit to search with
\x{201c} to find/replace this character in Windows-1252 encoded file using
Find or
Replace. That is in my opinion not correct as I would expect to search for single byte encoded character with the code value as stored in file and not as hold in memory.
There is one more issue. A Perl regular expression
Find in Files or
Replace in Files with search string
\x93 with option
In set to
Open files finds the character
“ in opened Windows-1252 encoded file on using UltraEdit for Windows < v2
5.00. Yes, a Perl regular expression
Find/Replace in Files works with a hexadecimal search in open files works different to
Find/Replace with same options in UE v24.xx. But it is necessary to use Perl regular expression search string
\x{201c} in
Find in Files or
Replace in Files with option
In set to
Open files with the up to now public released builds 25.00.0.53 and 25.00.0.58 of UE version 25.00.
(I have not run Find/Replace in Files on Windows-1252 encoded files not opened in UltraEdit.)
All these issues are extremely confusing for users to whom I belong too. I expect to get displayed in
Character Properties the code value of a non Unicode encoded character as stored in file and not as hold in memory. And I expect to run hexadecimal Perl regular expression finds and replaces with the code values of the characters as stored in file and not as hold in memory.
My suggestion is to use in your macros at the moment
\x{201c} to find
“ and
\x{201d} to find
” and
\x{201e} to find
„ or use in macros simple the characters as macros are since UE v24.00 also full Unicode aware.
I have just reported all these issues by email to IDM support.
