Kreten8 napsal/a:
Takže pokud gc.com některé znaky kóduje do HTML entit a ještě špatně - jaké jsou to znaky (co je na nich špatně), a kde je najdu jako příklad na vyzkoušení?
S temi entitami je to takto:
Vezmeme nejaky ten smajlik, treba ten vyse zmineny unicode znak U+1F601 Pokud bych jej chtel zakodovat jako HTML entitu, vypadala by takto: 😁 nebo 😁
Zcela ted pomijim fakt, ze v XML textu nemaji HTML entity co delat! Spravne by tam vubec zadna takova entita nemela byt. To XML ma udane kodovani jako UTF-8, a tak by vsechny znaky (vcetne diakritiky) mely byt kodovany jako nativni UTF-8. Tak to napriklad vyleze pri exportu z Geogetu.
Ale Groundspeak, nejen ze to zakoduje do entit, ale on ten znak zakoduje jako dve samostatne entity:  颁
Tedy tvari se, jako by slo o dva samostatne znaky. Jenze oba ty samostatne znaky maji hodnotu, kterou unicode znak nesmi mit! Na to apliakce reaguji ruzne, od ignorovani, pres chybu ci pad.
A tady je kamen urazu - Drive se Geoget choval tak, ze ty znaky proste vzal a ulozil si je... a pri exportu je vysypal ven, tak jak lezi a bezi. Protoze data byla vadna uz na vstupu, byla vadna i na vystupu. A POIloader se klidne mohl na ty zakazane unicode znaky zachovat tak, ze ten soubor odmitl zpracovat. Nelze se mu divit!
Kdyz jsem vsak zjistil, jakou prasarnu Groundspeak generuje, prizpusobil jsem import tak, ze z takovehle dvojice neplatnych znaku dokaze zpet zrekonstruovat puvodni unicode znak, a ten korektne ulozi do dat. Exportovana data jsou pak formalne validni, a POIloader si nestezuje.
Proto od sameho zacatku rikam, ze jestli ma nekdo s temito znaky problem, je treba ty postizene kese naimportovat znovu novym Geogetem, protoze ten ta vadna data nahradi spravnymi a problem zmizi.