Tipo de campo Delphi XE2 Dataset ¿TStringField no es compatible con Unicode?

He estado buscando a través de la clase TDataset y sus campos de cadena, en Delphi XE2 y he notado que AsWideString devuelve un tipo de UnicodeString. Sin embargo, obtiene el valor de la función TField.AsString: String que a su vez llama a TFIeld.AsAnsiString: AnsiString. Por lo tanto, ¿se perderían los caracteres Unicode? También el buffer que se pasa a TDataset.GetFieldData se declara como una matriz de AnsiChar.Tipo de campo Delphi XE2 Dataset ¿TStringField no es compatible con Unicode?

¿Lo entiendo bien?

Fuente

2012-02-27 There is no spoon

+1 Dado que este comportamiento es en mi humilde opinión una implementación incorrecta de VCL. En mi humilde opinión es una denominación errónea, * incompatible con el resto, la VCL/RTL * y una fuente de mucha confusión/malentendido. Tu pregunta tiene un sentido perfecto. –

No, debe examinar la clase TWideStringField que es para campos Unicode y la clase TStringField que es para cadenas que no son Unicode. TField es solo una clase base y TField.GetAsWideString es un método virtual con una implementación alternativa que se reemplaza por descendientes que conocen Unicode.

Fuente

2012-02-27 02:14:04

Bonito efecto secundario de tener dos clases de campo de cadena: migraciones de base de datos a Unicode requieren reemplazar todo TStringField en DFM con TWideStringField (y muchos otros cambios de código fuente), donde los desarrolladores esperarían una transición suave – mjn

@mjn, este enfoque le permitirá hacer la transición a Unicode en su aplicación sin cambiar los campos de base de datos subyacentes.TWideStringField ha existido durante años y no está relacionado con Delphi al cambiar a Unicode. Si el campo en la base de datos ha sido unicode antes, ya tenía que usar TWideStringField en decir Delphi 5 de todos modos. Utiliza TStringField si el campo de la base de datos es solo un AnsiString. Delphi no cambiará su definición de datos y datos en la base de datos automágicamente. –

@mjn En realidad no, ya que normalmente depende de la base de datos si el valor es unicode o no. Entonces, si su base de datos era unicode en la versión anterior de Delphi, ya era TWideStringField. Si no, ¿por qué debería estar en la versión más nueva si la base de datos aún no tiene unicode? –

Sí, lo entendió correctamente. Esto es el VCL y su documentación que están rotos. ¡Tu confusión tiene mucho sentido!

En el 2009+ aplicación Delphi, usted tiene que utilizar AsString propiedad de AnsiString y AsWideString para string=UnicodeString.

De hecho, los As*String propiedades se definen como tal:

property AsString: string read GetAsString write SetAsString; 
property AsWideString: UnicodeString read GetAsWideString write SetAsWideString; 
property AsAnsiString: AnsiString read GetAsAnsiString write SetAsAnsiString;

Cómo en la tierra que seamos capaces de descubrir que devuelve un AsStringAnsiString? Simplemente no tiene sentido en absoluto, en comparación con el resto de la VCL/RTL.

La aplicación, que utiliza TStringField clase para AnsiString y TWideStringField para string=UnicodeString está roto.

Además, la documentation is also broken:

Data.DB.TField.AsString

Representa el valor del campo como una cadena (Delphi) o un AnsiString (C++).

Esto no representa un string en Delphi, sino una AnsiString! El hecho de que la propiedad use un tipo simple string=UnicodeString es perfectamente engañoso.

Desde el punto de vista de la base de datos, depende del controlador de base de datos manejar Unicode o trabajar con un juego de caracteres específico. Pero en el punto de vista de VCL, en Delphi 2009+ solo debe conocer el tipo de string y tener la seguridad de que al usar AsString: String estará listo para Unicode.

Fuente

2013-04-22 05:32:13

Tipo de campo Delphi XE2 Dataset ¿TStringField no es compatible con Unicode?

Respuesta

Cuestiones relacionadas