25 respuestas en este tema

[Fenareth]

Buenas noches a todos amigos, ando aquí con una gran duda para poder descifrar una cadena en Android.

 

Les cuento. Tengo una cadena que cifro mediante el código para cifrar con AES256 que Seoane nos compartió y que funciona en una aplicación Delphi sin problemas. Ahora requiero descifrar esa misma cadena pero en Android. El método que descifra en Delphi funciona perfecto pero en Android me marca un error: Out of Memory.

delphi

function Convierte(Str,Clave: String): String;
var
  Src: TMemoryStream;
  Dst: TStringStream;
  Size: Integer;
  Key: TAESKey;
  ExpandedKey: TAESExpandedKey;
begin
  Result:= EmptyStr;
  Src:= TMemoryStream.Create;
  try
    Dst:= TStringStream.Create(Str);
    try
      StrToStream(Str,Src);
      Src.Position:= 0;
      FillChar(Key,Sizeof(Key),#0);
      if Length(Clave) > Sizeof(Key) then
        move(PChar(Clave)^,Key,Sizeof(key))
      else
        move(PChar(Clave)^,Key,Length(Clave));
      AESExpandKey(ExpandedKey,Key);
      // Leemos el tamaño del texto
      Src.ReadBuffer(Size,Sizeof(Size));
      ConvierteStreamECB(Src,Dst,ExpandedKey);
      Dst.Size:= Size;    //  AQUI DA EL ERROR DE OUT OF MEMORY
      Result:= Dst.DataString;
    finally
      Dst.Free;
    end;
  finally
    Src.Free;
  end;
end;

Sigo investigando... alguna idea ?

 

Saludox !

[Agustin Ortu]

Fenareth

 

Hay que tener muy en cuenta que en los compiladores mobile (iOs y Android, y ahora no recuerdo si para OS X tambien aplica)

 

Los string son de indice 0-based

 

En el "Delphi tradicional" para Win32 y Win64, los string son de indice 1-based

 

Ademas, Windows agrega un nulo al final de todas las cadenas

 

Todo esto hace que el codigo que trabaja a bajo nivel, con streams, punteros y buffers de memoria haya que "revisarlo un poco"

 

No soy un experto en bajo nivel, pero tiene toda la pinta de que hay un desborde de memoria por alli

 

Revisa este enlace

[Fenareth]

Amigo Agustin muchas gracias por la ayuda, revisaré lo que comentas y les retroalimento...

 

Saludox !

[seoane]

Hola Fenareth, cuanto tiempo sin pasarme por aqui ...

 

Vamos al tema que nos ocupa. El problema esta aqui:

delphi

Src.ReadBuffer(Size,Sizeof(Size));

Cuando se lee el tamaño original de la cadena.

 

El problema es que la forma de representar un integer en un PC y en un telefono es diferente, debido a que utilizan diferentes tipos de CPU. En la wikipedia lo explican con mas detalle: https://es.wikipedia...wiki/Endianness

 

 Para solucionarlo vamos a tener que leer el tamaño de una forma un poco mas rudimentaria pero independiente de la arquitectura que estemos usando:

delphi

// Declaramos esta funcion
function ReadInteger(Stream: TStream): Integer;
var
  P: array[0..3] of byte;
  i: Integer;
begin
  Stream.ReadBuffer(P,4);
  Result:= P[3];
  for i:= 2 downto 0 do
  begin
    Result:= Result * $100;
    Result:= Result + P[i];
  end;
end;
 
// Y cambiamos la linea problematica por esta otra
Size:= ReadInteger(Stream);

Con esto solucionamos el problema. Y si queremos dejarlo ya todo bien atado, y que el telefono cifre bien, en la funcion de cifrado debemos de usar esto para guardar el tamaño:

delphi

procedure WriteInteger(Stream: TStream; value: Integer);
var
  B: Byte;
  i: Integer;
begin
  for i:= 1 to 4 do
  begin
    B:= value mod $100;
    Stream.WriteBuffer(B,1);
    value:= value div $100;
  end;
end;

Aunque si en el telefono solo vas a descifrar podemos saltarnos esta parte.

 

Saludos

[seoane]

Se me olvidaba. Si puedes usa mejor el tipo AnsiString en vez de String.

[Fenareth]

Hola amigo Seoane muchas gracias por tu ayuda, el día de ayer estuve implementando el cambio sugerido pero el error de Out Of Memory sigue ocurriendo en la misma línea donde sucedía en un principio. Te muestro el cambio como quedó:

delphi

function ReadInteger(Stream: TStream): Integer;  //NUEVA FUNCIÓN INTEGRADA
var
  P: array[0..3] of byte;
  i: Integer;
begin
    Stream.ReadBuffer(P,4);
    Result:= P[3];
    for i:= 2 downto 0 do
    begin
      Result:= Result * $100;
      Result:= Result + P[i];
    end;
end;
 
function Convierte(Str,Clave: String): String;
var
  Src: TMemoryStream;
  Dst: TStringStream;
  Size: Integer;
  Key: TAESKey;
  ExpandedKey: TAESExpandedKey;
begin
  Result:= EmptyStr;
  Src:= TMemoryStream.Create;
  try
    Dst:= TStringStream.Create(Str);
    try
      StrToStream(Str,Src);
      Src.Position:= 0;
      FillChar(Key,Sizeof(Key),#0);
      if Length(Clave) > Sizeof(Key) then
        move(PChar(Clave)^,Key,Sizeof(key))
      else
        move(PChar(Clave)^,Key,Length(Clave));
      AESExpandKey(ExpandedKey,Key);
      // Leemos el tamaño del texto
      Size:= ReadInteger(Src);  // CAMBIO DE LÍNEA POR NUEVA FUNCIÓN
      ConvierteStreamECB(Src,Dst,ExpandedKey);
      Dst.Size:= Size;   // ERROR DE OUT OF MEMORY
      Result:= Dst.DataString;
    finally
      Dst.Free;
    end;
  finally
    Src.Free;
  end;
end;
 

Estoy viendo lo de tu sugerencia de cambiar los String por AnsiString y ver si por ahí pudiera ser el problema
 
Gracias de nuevo y ojalá tengas oportunidad de seguir echándome la mano
 
Saludox !

[Fenareth]

He hecho el cambio por AnsiString y tampoco lo he logrado.

 

Dando vueltas por las funciones que se ejecutan al momento de asignarle el size al TStringStream que es donde me salta el error, veo que ingresa a esta función:

delphi

function _ReallocMem(var P: Pointer; NewSize: NativeInt): Pointer;
{$IFDEF PUREPASCAL}
begin
  if P <> nil then
  begin
    if NewSize > 0 then
    begin
      Result := MemoryManager.ReallocMem(P, NewSize);  // AQUÍ INGRESA Y REGRESA NIL 
      if Result = nil then
        Error(reOutOfMemory);  // CON NIL MANDA EL ERROR DE OUT OF MEMORY
    end
    else
    begin
      if MemoryManager.FreeMem(P) <> 0 then
        Error(reInvalidPtr);
      Result := nil;
    end;
    P := Result;
  end else
  begin
    if NewSize <= 0 then
      Exit(nil);
    Result := MemoryManager.GetMem(NewSize);
    if Result = nil then
      Error(reOutOfMemory);
    P := Result;
  end;
end;
{$ELSE !PUREPASCAL}

Al regresar NIL la función de asignación de "reubicación" ? manda el mentado Out of Memory 

 

Sigo buscando solución

 

Saludox !

[Delphius]

Fíjate si puedes entrear a ReallocMem() del MemoryManager y ver que hace. Prueba también examinando el valor de las variables.

El problema del endianness surge cuando se va a estar intercambiando archivos entre dispositivos de distintos endianness. Si se va a cifrar y descrifrar únicamente con Android no hace falta hacer un SwapEndian como sugiere Domingo.

 

Ahora bien, si efectivamente dicho archivo cifrado se va a estar intercambiando entre una PC y un Android las cosas si deben cuidarse. La enorme mayoría de las PCs son LittleEndian mientras que los celulares, tablet y la enorme mayoría de los ARM en general son BigEndian.

El truco está en guardar todo en un Endian prefijado: o todo se guarda en BigEndian o todo se guarda en LitteEndian, es decir tomamos el dato entero del tipo nativo que tiene el equipo y procedemos a guardado en BigEndian o en LittleEndian. Luego al momento de leer se procede a efectuar el paso de BigEndian al nativo o bien LittleEndian al nativo según cual criterio se ha adoptado.

 

Lazarus al menos cuenta ya con funciones que hacen esto:

BEToN(): BigEndian to Native

LEToN(): LittleEndian to Native

NToBE(): Native to BigEndian

NToLE(): Native to LittleEndian

 

La magia del compilador hace el trabajo solo. Gracias a esas funciones, es que el se procede a intercambiar los bytes solamente cuando es absolutamente necesario.

El código debería andar en Android como también lo debiera de hacer bajo una PC. Cuando uno hace:

 

MiVariable := 123456789;

 

Ya sea en LittleEndian o en BigEndian el compilador internamente guarda eso en su estado Nativo. Por tanto mientras esté en su mismo "entorno" las cosas debieran de funcionar.

 

Si tu fuerzas el código a invertir los bytes para la variable Size y luego intentas reservar memoria con ese tamaño, obviamente lo que hay en esa variable ya no es el valor esperado ¡Es cualquier otra cosa! Y eso va a suceder tanto en un BigEndian como en un LittleEndian.

 

¿Cuál es el verdadero error? La verdad lo desconozco. No he compilado ni desarrollado nada para Android, y las cosas en Delphi han cambiado mucho comparado con el D6 que yo solía usar. Sólo quiero ilustrar esa pequeña falla en el tema del endianness.

 

Aquí yo estuve deliberando un poco sobre el tema para que te hagas una idea.

 

Saludos,

[seoane]

Lo que necesitamos saber es que valor toma la variable "Size". 

 

Sospecho que el problema esta en que tiene un valor muy alto, y cuando se intenta reservar esa memoria da el error de "out of memory".

 

¿Podrias cifrar un texto cualquiera y ponerlo aqui para que le eche un vistazo?

 

Siento no poder ayudarte mas, pero no tengo una version de delphi que compile para android

[Fenareth]

Hola amigo Seoane

 

Fíjate que desde el principio algunas de mis sospechas fue el tamaño de la memoria que se intentaba asignar. Revisando las características del dispositivo donde estaba haciendo pruebas puedo ver que tiene 3 GB de memoria RAM lo que no me parece que sea poco, pero no sé si estén siendo insuficientes.

 

El valor que toma Size lo venía ya monitoreando desde el inicio y es de 939524096 ¿bytes?. De ser así, estaría intentando reservar una memoria de casi 1 GB (0.875 para ser más exactos).

 

La cadena ya cifrada que intento recuperar es: UAAAAOPJ/T7n9CG6Dd1Jnzifw7IRl/6niVgWlq74U3PnIDUWErbL5RLw30H8PzQ+y+ZA2hHZH9DtRy1yrMYdaSTqCDPrFSJL7FGlNXTqUya0XKEK. Con la aplicación de Delphi me da el resultado esperado, con Android pues bueno, estamos atorados con el famoso Out of Memory...

 

Te agradezco el tiempo que te tomas para responder amigo, así como el de todos los que han participado hasta ahora, aún seguimos aprendiendo mucho de compilaciones hacia Android, ésto lo podremos solucionar de alguna manera u otra... 

 

Gracias a todos de nuevo

 

Saludox !

[Fenareth]

Se me ocurrió hacer una prueba asignando manualmente la mitad de Size y ver cómo se comportaba el descifrado. Les comento los resultados:

 

La asignación al TStringStream fue exitosa (sin el error del Out of Memory) pero al momento de enviar el DataString del TStringMemory como resultado de la función, me arroja otro error que dice: No mapping por the Unicode character exists in the target multy-byte code page. Haciendo un "break" en la aplicación al momento del error me envía a la función TEncoding.GetString de la unidad System.SysUtils. ¿Será resultado de la asignación manual de la mitad de memoria reservada?

 

En fin, seguimos con las pruebas 

 

Saludox !

[Delphius]

Hola Fena, no creo que este segundo error sea por haber hecho la asignación manual. Son dos errores independientes y no creo que tengan relación entre si.

 

Pregunto: ¿Esa cadena cifrada, fue hecha desde una PC? Si es así entonces el código debe ser endianness-friendly puesto que como dije: Si se va a estar llevando archivos entre PCs y Móviles se debe tener en cuenta el endianness tanto al momento de guardar como al de leer.

¿Porqué? Porque si en la cadena está almacenado un valor entero debe leerse y guardarse desde un tipo de endian específico y llevarse al nativo. Lo más lógico es que si se hizo desde una PC es que dicho valor esté guardado en formato little-endian. Ahora cuando este mismo archivo se lee desde un móvil deberá hacerse un LEToN() para tomar ese valor LittleEndian para llevarse al Nativo (BigEndian). Ahora bien si desde el mismo móvil se van a hacer cambios y rehusar el archivo, por cuestiones de compatibilidad deberá aplicarse un NToLE() al momento de guardar el tamaño.

En este ejemplo se consideró que el archivo siempre estará en LittleEndian, puede hacerse con el BigEndian si se desea. Lo importante es que se mantenga siempre esto. Porque si uno genera un archivo en LittleEndian y luego procede a leer y/o sobreguardar con un BigEndian se pierde todo y la cosa truena.

 

El otro problema parece apuntar a una cuestión de encoding. A mi me da entender que se está guardando en un formato y al momento de leer se espera otro. No estoy seguro pero creo que en móviles el encoding por defecto es UTF-8 mientras que en Windows el sistema por defecto es el de WIN1252 en la mayoría de los equipos. WIN1252 es un subconjunto de la ISO 8859-1. En los caracteres imprimibles tiene el mismo formato de bits, pero en los no imprimibles difiere. Y que yo sepa Delphi ya es UTF-16.

Prueba ver esto, quizá esté ahí el problema. Aunque no estoy completamente seguro. El texto del error dice algo sobre el tamaño de página de código... como si se hubiera guardado/leído en formatos de diferentes tamaños de bytes... Tanto UTF-8 como WIN1552 son de 2 bytes... ¿Será que al guardar se usa un formato de 1 byte? ¿O al leer? Si es que Delphi ya es UTF-16 puedo entender entonces que ahora los bytes sean 4.

Deberás verificar esto.

En Lazarus al menos se asume UTF-8 por defecto, y tiene funciones para convertir entre diferentes formatos. Yo ya estuve aprendiendo algunas lecciones sobre el tema, aquí y aquí.

 

Saludos,

[seoane]

No mw pusiste la clave para descifrar el ejemplo

[seoane]

Acabo de hacer una pequeña prueba con freepascal.

 

Compilando el mismo programa en lazarus 32bits en el PC y en freepascal para android.

 

El programa de ejemplo  es (un refrito de mi unit SeEasyAES.pas)

delphi

program test01;
 
{$IFDEF FPC}
  {$MODE delphi}
{$ENDIF}
{$APPTYPE CONSOLE}
 
uses
  SysUtils,
  Classes,
  SeAES256,
  SeBase64,
  SeMD5,
  SeStreams,
  SeSHA256;
 
type
// Cabecera que anteponemos a los datos cifrados
  TEasyAESHeader = packed record
    OriginalDataSize: Integer;
  end;
 
procedure EasyGenKey(var Key: TAESKey; Password: AnsiString);
var
  Temp: TMemoryStream;
begin
  FillChar(Key,Sizeof(Key),#0);
  if Length(Password) > Sizeof(Key) then
    move(PChar(Password)^,Key,Sizeof(key))
  else
    move(PChar(Password)^,Key,Length(Password));
end;
 
procedure EasyAESEnc(Src, Dst: TStream; Password: AnsiString);  overload;
var
  Header: TEasyAESHeader;
  AESKey: TAESKey;
  AESEnc: TAESEnc;
begin
  // Inicializamos la cebecera
  FillChar(Header,Sizeof(Header),0);
  with Header do
  begin
    OriginalDataSize:= Src.Size;
  end;
  // Escribimos la cabecera
  Dst.WriteBuffer(Header,Sizeof(Header));
  // Generamos la clave
  EasyGenKey(AESKey,Password);
  AESEnc:= TAESEnc.Create(Dst,AESKey);
  try
    // Ciframos el stream
    AESEnc.CopyFrom(Src,Src.Size);
  finally
    AESEnc.Free;
  end;
end;
 
procedure EasyAESDec(Src, Dst: TStream; Password: AnsiString);  overload;
var
  Header: TEasyAESHeader;
  AESKey: TAESKey;
  AESDec: TAESDec;
begin
  Src.Position:= 0;
  // Leemos la cabecera
  Src.ReadBuffer(Header,Sizeof(Header));
  // Generamos la clave
  EasyGenKey(AESKey,Password);
  AESDec:= TAESDec.Create(Dst,AESKey);
  try
    // Desciframos el stream
    AESDec.CopyFrom(Src,Src.Size - Sizeof(Header));
    // Restauramos su tamaño original
    if (Header.OriginalDataSize <= Dst.Size) then
      Dst.Size:= Header.OriginalDataSize
    else
     raise Exception.Create('Invalid data size');
  finally
    AESDec.Free;
  end;
end;
 
function EasyAESEnc(Str, Password: AnsiString): AnsiString; overload;
var
  Src, Dst: TMemoryStream;
begin
  Src:= TMemoryStream.Create;
  Dst:= TMemoryStream.Create;
  try
    // Guardamos el texto a cifrar en un stream temporal
    Src.WriteBuffer(PAnsiChar(Str)^,Length(Str)*SizeOf(AnsiChar));
    Src.Position:= 0;
    // Ciframos el stream
    EasyAESEnc(Src,Dst,Password);
    // Codificamos el resultado en base64
    Result:= BinToStr(PByteArray(Dst.Memory),Dst.Size);
  finally
    Src.Free;
    Dst.Free;
  end;
end;
 
function EasyAESDec(Str, Password: AnsiString): AnsiString; overload;
var
  Src, Dst: TMemoryStream;
begin
  Src:= TMemoryStream.Create;
  Dst:= TMemoryStream.Create;
  try
    // Metemos los datos cifrados en un stream:  base64 -> binario
    StrToStream(Str,Src);
    Src.Position:= 0;
    // Desciframos el stream
    EasyAESDec(Src,Dst,Password);
    // Devolvemos el texto descifrado
    Result:= Copy(AnsiString(PAnsiChar(Dst.Memory)),1,Dst.Size div Sizeof(AnsiChar));
  finally
    Src.Free;
    Dst.Free;
  end;
end;
 
procedure EasyAESEnc(SrcFile, DstFile, Password: AnsiString); overload;
var
  Src, Dst: TFileStream;
begin
  Src:= TFileStream.Create(SrcFile,fmOpenRead or fmShareDenyWrite);
  try
    Dst:= TFileStream.Create(DstFile,fmCreate);
    try
      EasyAESEnc(Src,Dst,Password);
    finally
      Dst.Free;
    end;
  finally
    Src.Free;
  end;
end;
 
procedure EasyAESDec(SrcFile, DstFile, Password: AnsiString); overload;
var
  Src, Dst: TFileStream;
begin
  Src:= TFileStream.Create(SrcFile,fmOpenRead or fmShareDenyWrite);
  try
    Dst:= TFileStream.Create(DstFile,fmCreate);
    try
      EasyAESDec(Src,Dst,Password);
    finally
      Dst.Free;
    end;
  finally
    Src.Free;
  end;
end;
 
 
Var
  Ejemplo: AnsiString;
begin
  Ejemplo:= 'Hola mundo';
  Writeln(Ejemplo);
  Ejemplo:= EasyAESEnc(Ejemplo,'Password');
  Writeln(Ejemplo);
  Ejemplo:= EasyAESDec(Ejemplo,'Password');
  Writeln(Ejemplo);
  readln;
end.

El resultado lo puedes ver en la imagen adjunta

 

Archivos adjuntos

•  20160411_182054_HDR.jpg   144,84KB   2 descargas

[seoane]

La pregunta es si tienes que guardar compatibilidad con alguna otra aplicacion antigua, o podemos buscar un formato mejor para guardar el texto comprimido. Un formato en el que no tengamos problemas con el orden de los bytes o el tamao de los caracteres.

 

Porque la unidad easyAES que se encuentra en la ultima version se podria adaptar facilmente, solo tendriamos que corregir unos detalles.

[Fenareth]

Amigos ya los puse a trabajar y a investigar, lo agradezco mucho...

 

 

No mw pusiste la clave para descifrar el ejemplo

 

A poco era necesario ???             

 

 

Llegando a casa pruebo con el código que acabas de sugerir y les comento el resultado ( ojalá sea satisfactorio )...

 

 

La pregunta es si tienes que guardar compatibilidad con alguna otra aplicacion antigua, o podemos buscar un formato mejor para guardar el texto comprimido. Un formato en el que no tengamos problemas con el orden de los bytes o el tamao de los caracteres.

 

Porque la unidad easyAES que se encuentra en la ultima version se podria adaptar facilmente, solo tendriamos que corregir unos detalles.

 

Tengo una aplicación Delphi que es la que genera el cifrado que ahora intento descifrar, de ser necesario la cambiaré pero no por ahora, tal vez en unos 6 meses que es cuando podré generar de nuevo los códigos cifrados que ahora pretendo leer.

 

Por el momento si estoy atada a ese código de cifrado/descifrado (ves amigo Delphius ?, me estoy portando bien, jejeje) pero como te comento amigo Seoane, tengo la posibilidad de cambiar todo pero hasta dentro de unos 4 - 6 meses.

 

Les agradezco bastante la ayuda...

 

Saludox !  

[Delphius]

Domingo, no he probado tu último código, y ni he compilado nunca para Android... Me asalta una duda. ¿Compilaste para cada uno por separado? ¿Es decir, hiciste un stream con la PC por un lado y otro con la app Android? Porque si es así, obviamente que resulta la cosa... cada uno trabaja con lo "suyo". El asunto se va a poner un poco más liado cuando tenga que guardar el contenido cifrado y recuperarlo en y desde diferentes dispositivos.

Prueba guardando el contenido cifrado ya sea desde la applicación PC o la móvil y en llevarlo y leerlo con la aplicación "opuesta". A ver que resulta.

Yo también he llegado a pensar que el conflicto con el Size en Android tuviera que ver con el gran tamaño y que quizá sea que es demasiado para la RAM y/o el espacio disponible en la SD (si es que hay una disponible). Suena como lo más probable.

 

Gaby, yo que vos no esperaría a que llegue ese día y me adelantaría en hacerlo lo más multiplataforma posible. ¡Quien sabe que te espera para ese entonces! Es preferible que prepares la cancha ahora que ya estás en el estadio y calentando... No vaya a ser cosa que al ponerte en el banco y llegue ese día te encuentre con el músculo en frio.

El trabajo justamente implica luchar contra el endianness y apoyo la idea de Domingo en considerar usar algún formato de codificación concreto para que al momento de descifrar proceder a hacer el paso inverso adecuado para la multiplataforma y no tener que lidiar con posibles conflictos de encoding. Algo como usar Base64 y/o UTF8 y hacer UTF8ToSys()/SysToUTF8() que dispone Lazarus (creería que Delphi tiene algo equivalente a estas funciones).

 

EDITO:

Estoy tratando de informarme sobre como se puede detectar que endianness se está empleando. Lazarus cuenta con directiva de compilación para cada uno, lo que hace muy fácil la tarea. No encuentro las mismas o algo parecido en Delphi, y me cuesta creer que no cuente con algo de endianness-friendly.

Voy a tratar de investigar algo más sobre el error encoding, a ver si encuentro por donde más se puede hilar.

 

Saludos,

[Delphius]

La búsqueda rápida sobre No mapping por the Unicode character exists in the target multy-byte code page delphi me ha llevado a resultados como los siguientes:

Link 1

Link 2

Link 3

 

Y hay más. Pareciera apuntar justo a algo que yo estaba comentando. Debes definir desde un principio que encoding usar. En esos enlaces sugieren que al crear el stream se le indique que usen UTF-8. De modo que tanto para el cifrado como descifrado se esté en acuerdo a trabajar con dicho formato.

Puedes ir probando este punto.

 

Saludos,

[Agustin Ortu]

Y hay más. Pareciera apuntar justo a algo que yo estaba comentando. Debes definir desde un principio que encoding usar. En esos enlaces sugieren que al crear el stream se le indique que usen UTF-8. De modo que tanto para el cifrado como descifrado se esté en acuerdo a trabajar con dicho formato.

 

 

Totalmente cierto

 

El tipo "string" dejo de existir. No tenes mas un string; tenes un arreglo de bytes. Agarra el arreglo de bytes, y usa un determinado Encoding, y recien ahi tenes el "texto"

[Delphius]

Totalmente cierto

 

El tipo "string" dejo de existir. No tenes mas un string; tenes un arreglo de bytes. Agarra el arreglo de bytes, y usa un determinado Encoding, y recien ahi tenes el "texto"

 

Visto así, la verdad es que tiene mucho sentido y hasta parece lo más razonable considerando la cantidad de encodings que hay.

 

Hasta se podría encarar el diseño con una clase abstracta TEncoding y derivar de ésta para que éstas se encarguen de interpretar el array de bytes como corresponde.

Estas clases harían todo el trabajo sucio y ya nunca más un tipo string. Necesitas trabajar con UTF-8, tienes la clase UTF-8 y pum... Necesitas Unicode, la clase Unicode. Mierda... peguenme... ¡Acabo de pensar como un Java Boy!

 

Saludos,