Díky moc. Vyzkouším večer po práci, až odložím pracovní počítač a posunu se na pohovku s Geogetím počítačem. Že jsem tak smělý, pořešils, prosím, nějak červená kolečka na mapě?
Tak z těch drobností jsem se koukl na názvy států ve filtru - ano, opraveno.
A začal jsem přemýšlet, jak předělat jména polygonů do UTF - a zatím jsem bezradný. Polygony mi kompletně dělá dávkový soubor (.BAT) a v něm nemohou být UTF informace. Momentálně mne napadá jediná možnost - názvy polygonů mít jako jediný řádek v pomocném souboru, který by se do výsledného polygonu vkopírovával. Což je realizovatelné, jenom to nebude přehledné. Upravil jsem polygony Andorry, kde je jedno území se znaky které potřebují UTF (za chvíli to pošlu na server).
V té souvislosti - ať mne HaLuMa opraví, jestli se mýlým - předpokládám, že bude vhodné opravit všechny polygony, které mají non-ASCII název, protože v jiném než česko/slovensko/polském prostředí Windows se asi zblázní.
Teď si nedovedu představit, čemu by to pomohlo, vzteká se to totiž na BOM (a to i v případě, kdy tu code page změním předem).
Ale není to nepřekonatelný problém, pokud toho není moc tak se UTF sekvence dají vkopírovat do BATu jednorázově - je to sice škaredé, ale vyhoví.
Anebo - pokud bude BOM na začátku aby se to dalo editovat, tak se to vztekne na první příkaz, ale to je většinou poznámka, takže je to jen o té škaredé hlášce.
Teď zase nerozumím já tobě. Já myslel, ze chceš mít v bát řetězce v utf, abys je mohl zapisovat do výsledného textaku. Na to přece samotný bat nemusí začínat na bom. Pak je to jen o používání vhodného textového editoru. Ale možná fakt jen nechápu šíří problému.
Teď zase nerozumím já tobě. Já myslel, ze chceš mít v bát řetězce v utf, abys je mohl zapisovat do výsledného textaku. Na to přece samotný bat nemusí začínat na bom. Pak je to jen o používání vhodného textového editoru. Ale možná fakt jen nechápu šíří problému.
Rozumněls správně, jen neznám editor který by mi tam dal UTF znaky a nedal tam BOM. Ale je pravda, že nemám nastudovanou tu spoustu textových editorů která existuje. Vždycky mi stačil integrovaný editor ve FARu doplněný obyčejným Notepadem.
Už jsem se kdysi ptal, ale nějak to zapadlo - nešlo by zrychlit načítání listu? Načtení 130000 záznamů trvá 14 minut - a to je fakt hodně dlouho. Nějaké quick&dirty řešení, když použiju SQLite engine pro výběr podle obsahu v jiné tabulce, je to mnohem rychlejší.)
A taky pro každou Kes hledáš waypointy a listingy, vyrábís počítaná pole a hromady dalších operaci, které tam jsou potřeba? Nějaký výkon taky padne na oběť objektových střev, což se už několikrát hodně hodilo zachránilo to mě duševní zdraví. Taky záleží na filtrech, co používáš. Některé potřebuji nemalý strojový čas.
Občas se mi i tam daří nějaká menší optimalizace. Ale že bych teď vytáhl špunt, a ono to běželo dvakrát rychleji, to nemohu sloužit.
Jestli to nebude i hardwarem. Mých 123000 záznamů se zobrazí za necelou minutu. Jen nevím, jaký by mělo vliv např. ubrat sloupce nebo nenačítat waypointy?
Bom u utf8 se standardně používá právě na autodetekci tohoto formátu.
Jinak bom není vyžadován nikde, pokud nepotřebuješ autodetekovat formát a poradí bytu…
ok. holt si to pamatuji z Javy, ze ta to nedavala pokud zdrojak v UTF-8 zacinal BOM. ale jak se divam, tak to uz pred 10 lety fixnuli:) a byl to problem v JDK6. Sakra to uz je doba.