la cuestión es que cuando carga la ñ para sumarla con los otros caracteres 6D(m), 67(g)...etc, en vez de cargar FFFF FFA4 (ñ) , carga FFFF FFB1 que no tiene nada que ver con la ñ...por lo que pienso que alguna tabla del CP437 de freepascal está equivocada...
No es eso, pero se parece. He estado haciendo algunas pruebas (entre bocado y bocado
) y parece que hay alguna interacción entre las funciones de conversión, la página de la cadena, alguna conversión interna y, quizá, el tiempo en Timbuctú (o algo así).
Tras darle unas cuantas vueltas he llegado al siguiente código que parece que funciona bien; al menos da -113 para "miguelitoññ"
type
TCharInt = packed record
case Boolean of
True: (AChar: Char);
False: (AShort: ShortInt);
end;
procedure TForm1.Button1Click(Sender: TObject);
var
nombre: RawByteString;
i: integer ;
temp : integer = -550;
CI: TCharInt;
begin
nombre := UTF8ToCP437(Edit1.Text, True);
if length(nombre) < 10 then begin
if nombre = '' then
ShowMessage('Debes introducir un nombre')
else
ShowMessage('El nombre debe tener 10 caracteres como minimo');
Edit1.SetFocus;
Exit;
end;
for i:= 1 to Length(nombre) do
If Odd(i) then begin
CI.AChar := nombre[i];
temp := temp + CI.AShort;
end;
Edit2.Text := Format('%d = $%0:.2x', [temp]);
end;
El
quid del asunto parece estar en usar
RawByteString para que el compilador no añada ninguna conversión intermedia a la que hacemos nosotros con
UTF8ToCP437().
Por cierto, tras examinar unas cuantas tablas de códigos las únicas que valen para esto son IBM437 e IBM850; ninguna de las de Windows (125x) o ISO-8859-x que he consultado tiene las "Ñ" en ese preciso lugar.
Te adjunto mi proyecto de prueba completo, que tiene unas cuantas cositas más para ver qué va haciendo en cada vuelta, etc.