Search your code for “length()” function –the length function on an ansistring
has returned the size in bytes (8bit), now it returns the size in words
(16bit). Places where you write strings to files and streams are usually places
that need a fix. Do that search and you should probably have like 99% of your
unicode issues found. Switching over to Unicode isn’t that big of a drama.
As for the MD5 issue – there’s actually a bit more to it – you can easily fix
it by typecasting to ansistring and you should then get the same md5 hashes
back again like in older pre-unicode Delphi versions:
function foo(s: String): Integer;
var
s2: AnsiString;
begin
s2 := AnsiString(s); //typecasting to ansistring without getting
compiler warnings
Result := md5(@s2[1], length(s2));
End;
…but the question is if you really want to keep limiting yourself to
ansistring? Now that your program will be unicode enabled you might as well
embrace it fully and for example make your code work with chinese passwords too:
function foo(s: String): Integer;
var
data: TBytes;
begin
data := TEncoding.UTF8.GetBytes(s);
Result := md5(data, length(data));
End;
Kind regards,
Stefan Müller,
R&D Manager
ORCL Toolbox Ltd.
Auckland, New Zealand
P Please consider the environment before printing this email
This message is intended for the adresse named above and may contain privileged
or confidential information.
If you are not the intended recipient of this message you must not use, copy,
distribute or disclose it to anyone.
From: [email protected]
[mailto:[email protected]] On Behalf Of Jeremy Coulter
Sent: Wednesday, 16 November 2016 3:34 p.m.
To: NZ Borland Developers Group - Delphi List
Subject: Re: [DUG] Are these good ideas?
you see my dilema ? agh....what a pain
On Wed, Nov 16, 2016 at 3:21 PM, Jolyon Direnko-Smith <[email protected]>
wrote:
If by your "code that is working" (vs code that isn't) refers to the two
different methods being used to produce an MD5 Hash, then I think there is a
bit of confusion about the problem (hard to say without actual code). i.e. it
is possible that *both* of your MD5 implementations are working absolutely
correctly. The problem is the way that your data is being passed in/out. MD5
is not a string-specific hashing algorithm - it works on bytes, not characters
(otherwise you couldn't produce an MD5 digest for a binary file, for example).
e.g. if you have a function that accepts a string but then treats it as a
pointer to some bytes (which is what a "string" is, after all) and assumes that
the memory referenced by that pointer occupies the number of bytes indicated by
the length of the string:
function Foo(aString: String): Integer;
var
i: Integer;
ptr: PByte;
len: Integer;
begin
len := Length(aString);
ptr := PByte(aString);
for i := 1 to len do
begin
// Do something with each byte then move on to the next one...
Inc(ptr);
end;
// blah blah
end;
This works perfectly well for an ANSI String because an ANSI String is a
sequence of ANSIChar and an ANSIChar is a single byte. But this code will
compile without any warning on Delphi 2009 and later, where "String" is now
synonymous with a "UnicodeString" which is a sequence of WIDEChars. i.e. 2
bytes. But even without ANY warning or hints that anything is amiss, the
function will now process only HALF the string that it is passed (and half of
the bytes it does process will themselves be 0 [zero] - i.e. nulls).
When migrating string handling code from ANSI to Unicode strings, you have to
look for these sorts of issues as well as intermixed ANSI and WIDE types. I
suspect that this is what is going on in your case.
The above function could be "fixed" by correcting the declaration to explicitly
accept an ANSIString:
function Foo(aString: ANSIString): Integer;
Now the assumption in the implementation that each char is 1 byte will be
correct, but you will start seeing warnings about possible data loss resulting
from any implicit conversions from Unicode to ANSI Strings.
NOTE: In the case of an MD5 hash, fixing the implementation to process
UnicodeStrings correctly (processing all bytes in the string by process 2 x
LENGTH bytes of the string) will not result in the same MD5 hash because MD5
works on bytes, not chars. An ANSIString and it's Unicode equivalent may be
visually "equal" when displayed, but the binary representation of them is
different and so the MD5 digest will also be different.
If the binary representation is significant to your algorithm (as it is with
MD5) then what you really need is TWO versions of the above function. One for
ANSIString (working on the basis of 1 byte per char) and a separate
implementation for UnicodeString (2 bytes per char).
You then need to make sure that you correctly convert to and pass strings in
the appropriate encoding to each function as and when required.
On 16 November 2016 at 13:30, Jeremy Coulter <[email protected]> wrote:
Hi Again.I am looking at a Plan B to my last email about converting some code.
What I am thinking is, I COULD just use the code I have that is working, and
may be create a DLL and access it from my new application.
However, the code is actually running a server that listens on a couple of
ports and when "things" happen, it fires an event that is then captured by an
event on the front end.
Can I run a service as above in a DLL and have events that I guess just do a
pass through to the DLL calling application?
The other thought I had was to write a COM DLL, but bit wary of that.
Anyone got any thoughts on the above?
Thanks, Jeremy
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with
Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with
Subject: unsubscribe
_______________________________________________
NZ Borland Developers Group - Delphi mailing list
Post: [email protected]
Admin: http://delphi.org.nz/mailman/listinfo/delphi
Unsubscribe: send an email to [email protected] with
Subject: unsubscribe
