XML UTF-8 azbuka

[JaroB]

zapomněl jsem na konverzi na datasetu

Kód: Delphi [Vybrat]

1. procedure TForm3.cdsruGetText(Sender: TField; var Text: string;
2.   DisplayText: Boolean);
3. begin
4.   if DisplayText then
5.      Text := utf8tostring(Sender.AsAnsiString)
6. end;

[pf1957]

Chybí zřejmě funkce typu GetAsUtf8String, protože není jednoduché z povahy zdroje určit, co se vespod Field skrývá za data, proto je tam to čtení jako Ansi.

No ale funkci datasetu neni konvertovat kodovani! Ta se ma odehrat na urovni vnejsich hranicich systemu tj. v DB clientovi tj. mimo Delphi pri normalnim pristupu k RDBMS a nebo v TXMLTransformeru, ktery muze dostat ten XML vpodstate v jakemkoli kodovani, ve kterem lze dane znaky zobrazit a treba pokazde v jinem a vysledek by mel byt vzdy spravne dekodovany text. Dal uz by v unicodifikovanem programu nemelo nikde existovat nic jineho nez unicode, na platforme Wintel tedy UTF-16le. Vubec mi nejde narozum, kvuli cemu takovou p*icovinu udelali.

[František]

tesujem to teraz s VCL a DBgrid
keď som pridal

Kód: Delphi [Vybrat]

1. DefaultSystemCodePage := CP_UTF8;

tak to zobrazuje DBGrid správne, ListView nie

ale dbgrid mi stačí

neviem či je to definitívne riešenie, ale skúsim to, ďakujem

[František]

ešte nie je koniec

pri cds.ApplyUpdate sa to rozsype za zapíše to zle (do tých nečitateľných znakov)
a samozrejme po refreši je to zle

[JaroB]

používáte to i pro zápis dat zpět do datasetu?

[František]

chceli by sme ... ale nejedeto..

[Ondřej Pokorný]

chceli by sme ... ale nejedeto..

kdo maže, ten jede... vy jste nějaká firma? nechcete si zaplatit někoho, kdo tomu rozumí?

[Marek Weyda]

kdo maže, ten jede... vy jste nějaká firma? nechcete si zaplatit někoho, kdo tomu rozumí?

Tak to se také přidávám k otázce od Oxo

Jinak s těmito různými konverzemi a totálním rozoráním diakritiky a dalšího jsem se setkal v Delphi už X krát a většinou to byla prasárna programátora, ale je fakt, že zejména ve starších Delphi je tam i nějaká ta prasárna občas v jejich komponentách, což možná bude i tento případ od Františka. Klasický příklad je ale starší SOAP, jak už se tady řešilo v souvislosti s EET.

Ale jinak se dost často setkávám s tím, že programátor jaksi netuší, že při různých konverzích stringů může dojít ke ztrátě informace - diakritiky.

Někdy si říkám, co je lepší. Jestli starý přístup, kdy programátor měl absolutní kontrolu, ale zároveň i absolutní zodpovědnost za všechno, nebo dnešní - programátor v podstatě už nemusí přemýšlet, co se děje "ve střevech". Když ale řešíme nějaký opravdu vážný problém, tak programátoři odchovaní prvním principem absolutně vedou :-) Takže asi tak.

[JaroB]

Já nechápu tohle použití transformace xml do datasetu.
Myslím, že by bylo jednodušší natáhnout data z nějakého primitivnějšího formátu se zaručeným kódováním než řešit transformace, utf-8 je dobrý formát, ale musí se použít důsledně všude. Zvlášť, když se požaduje zobrazení jako z databáze a to s následnou úpravou zpět

[pf1957]

Já nechápu tohle použití transformace xml do datasetu.

No zrejme si rekl, ze CDS ma metodu LoadFromFile, pak zjistil, ze je to jen pro proprietarni format DataSnapu, ktery znasilnuje XML format a hodnoty sackuju jak atributy (!) elementu, predstavujiciho jeden zaznam a ze na doporuceni dokumentace ma pouzit TXmlTransform, ktery na zaklade XSD schematu mu ten proprietarni format z obecneho XML vytvori. Myslenka jednoducha, vsechno by se teoreticky melo dat naklikat... Ovsem evidentne se jim neco nepovedlo.

Myslím, že by bylo jednodušší natáhnout data z nějakého primitivnějšího formátu se zaručeným kódováním než řešit transformace, utf-8 je dobrý formát, ale musí se použít důsledně všude. Zvlášť, když se požaduje zobrazení jako z databáze a to s následnou úpravou zpět

Jak vsude? V Delphi programu by vsechny stringy uvnitr aplikace mely byt v UTF-16le. Tak byl Delphi unicodifikovan. A konverze do/z jinych kodovani ma existovat jen na hranicich systemu. Vsechno ostatni je neudrzovatelny paskvil.

Samozrejme se muze vykaslat na TXmlTransform a pokud tech dat nejsou obrovska kvanta, ze by se to naraz neveslo do pameti, tak predhodit vzorek tech dat XML bindingu, ten vytvori DOM model a metody pro jeho na cteni, vsechno samozrejme v URF-16le a iteraci presypat data z DOM do CDS potazmo do DB.
A pak uz s tim pracovat jen jako s DB a do DB si to treba zase strcit v UTF-8, ale to uz jde deklarativne, tam neni co programovat.

[JaroB]

Tomu rozumím. Já mám slovníček překlepáček pro češtinu, má jen 800000 slov a nijaké problémy s pamětí ani výkonem uživatelé nepociťují, a to je hloupý formát a la excel

[František]

takto to je:
mám dokument vo formáte xml (štruktúru ste videli), (este asi v roku 2006 som rišeil SOAP, stiahnutie xml a nasledný import do DB a vtedy som našiel transformácie, ktoré my jednoducho pomocou XMLmaperu, dovolili importovat rôzne štruktúry dát), tak ma napadlo použiť ten postup ktorý poznám, ale ako som už spomínal, vrhnem sa do toho nabindovania - čo už mám, čo nemám sú skúsenosti s týmto spôsobom spracovania XML

takže ešte raz:
mám dokument vo formáte xml, potrebujem ho zobraziť, editovať a uložiť späť do pôvodného súboru.. to je celé

[pf1957]

takže ešte raz:
mám dokument vo formáte xml, potrebujem ho zobraziť, editovať a uložiť späť do pôvodného súboru.. to je celé

A musis po Save zachovavat ten puvodni format? Nemuzes to treba jenom naimportovat a pak pouzivat ten proprietarni format DataSnapu?

[František]

nie, ten XML súbor spracováva iný program, ja k nemu robím len editor

BTW: vytiahol som Cantú-ovu Delphi 7, a čítam o DOM a SAX - vtedy som tomu nerozumel, teraz je to lepšie

[Ondřej Pokorný]

takže ešte raz:
mám dokument vo formáte xml, potrebujem ho zobraziť, editovať a uložiť späť do pôvodného súboru.. to je celé

Já taky ještě jednou: někoho si na to zaplaťte, když to neumíte sami