???.txt

[ide.ne.irj at freemail.hu]

Thus spake hwsw famulus:

>> Pl a vilag legnepszerubb operacios rendszere,
>
> Tudtommal eleg regota jol kezeli, es az aalkalmazasok is

Olvasni kene a listat. Itt panaszkodott egy kollega hogy nem torli.
Mondtam hogy exploderrel torolje, az ment.
Nekem is volt gondom vele, es gondolom meg a fel listanak.
Tehat a lenyeg, hogy nem jol tudod.

> csak bekell meg epiteni egy csomo oskovulet
> miatt az ide-oda konvertalo megoldasokat is....egyelore

En nem ertem hogy miert kene. Progi lekerdezi OS-tol a dirt, megkapja
unikodban, eltarolja. A megjeleniteshez meg egyeb belso vacakolashoz
ugy konvertalja ahogy akarja, egyeni szoc problema. Ha valamit akar
kezdeni egy fajllal, akkor visszaadja az OS-nek ugyanazt a nevet mint
amit kapott a listazaskor, az pedig torli vagy elvegzi az egyeb
muveletet. Ha a progi nem tamogatja az unikodot, es nem unikod formaban
keri le a sztringeket az OS-tol, majd igy is adja neki vissza azt, es
megsem mukodik, akkor az OS a hibas. Ha belul unikoddal dolgozik a
progi, es nem mukodik, akkor is az OS a hibas.
Ha a progi konvertalgat a kapott es a visszaadott nev kozott (minek tenne?),
es elrontja, akkor a progi a hibas.
De hat ki tudja mi van... En azon akadtam ki, hogy a FAT32 eseten, ami
zsir unikod, szinten tud kodlap hibara panaszkodni.

> Amuyg tegnap pl. szivtam egy MS ACCES2000 listaval amit a PostgreSQL ala
> akartam importalni es ilyneket irt  a pgAdmin a magyar ekezetekre
> ---------
> WARNING:  ignoring unconvertible UTF-8 character 0xf37468
> CONTEXT:  COPY cimek, line 1
> WARNING:  ignoring unconvertible UTF-8 character 0xe16c6d
> CONTEXT:  COPY cimek, line 1
> ---------

Hat ez ciki. Latom mas is sziv vele :)

> Ugyan akkor a psql (azaz  console modban) siman megette ugyanezt a file-t!
> Az osszes MS alkalmazas ACCES, EXCEL,WORD, aztan  a program editor
> a PHP es egy halom mas is siman kezeli hibatlanul au UNOCODE-os 
> file-imet....

Meg jo. Miert ne kezelne? A gond akkor van, amikor elkezdjuk a
ganyolast...

> A vilag halad, a codepage kaoszt jelent, kifog halni.
> Az oprendszerek belul UNICODE alapuak, tudtommal

A codepage sohasem fog kihalni, hardver okok miatt. Ez tuti, 100% biztos
lehetsz benne. Persze sok helyen at fogja venni a helyet az unikod.
Nagyon helyes. Csak nem ugy kene csinalni, mint most, hogy ennyi
problemat okozunk a felhasznalonak. Amint latom, nekes is...

> Most egy nagyhalom eroforrast forditanak arra, hogy
> emulaljak a a codepage vilagot...foloslegesen.

De az nem vesz karba, mert fele annyi adatot kell mozgatni.
Felfoghatod egy tomoritesnek is, ami iszonyu hatekony, es ahhoz kepest
nevetsegesen keves eroforras kell neki.

> Szerintem szinte minden feladatra van mar native UNICODE alapu sw  megoldas 
> is....

Ok, akkor nezz korul egy kicsit a mikrovezerlo vilagban, vagy keress
barmely gyartonal unicode kompatibilis HD44780-at!
Az unicode gyakorlatilag csak a PC szoftverek egy reszenel terjed.
Tudom, neked ez a vilag :), massal nem talalkozol.

> Az MCU-k piacan is jonnek a 32 bitesek!

Ez itt a listan most van leirva kb szazadszor. Mindig jonnek. Mint az
oroszok :) Sot, mar a spajzban vannak. Komolyan, en is hasznalom oket.
Unicode-t speciel nem, nem is fogok mostanaban.
Megegyszer kiemelnem: az unicode egyetlen problemat old meg hatekonyan,
ha egyszerre, pl egy fajlban kell tobb nyelv specialis karaktereit kezelni.
Amennyiben tobb nyelv kell ugyan, de egyszerre mindig csak egyet kell
hasznalni, akkor a sima kodlapos megoldas sokkal hatekonyabb, kevesebb
helyet foglal, kevesebb CPU ido kell hozza, es SEMMI HATRANYA SINCS!!
A gondok ott kezdodnek, ha _egyszerre_ kell a sok nyelv.
Gondold vegig a mindennapi felataid, hogy mekkora reszet erinti ez.

> Ahol lesz teljesitmeny dogivel, es ezert lesz unicode-os, javas, stb

Es hogy kapcsolodik ez a temahoz? Barmely procival meg lehet oldani.
Egy tipikus feladatban, ahol nem a szovegfeldolgozas a kulcsproblema,
elhanyagolhato overheadet jelent.
Viszony ketszer annyi adatot kell tarolni, ketszer nagyobb savszelessegu
kommunikacios vonalak, ketszer akkora tarolo kell, stb...
A proci szinte lenyegtelen.

> opsys mag is a harom relet kapcsolo kutyuben is, mert

Nem lesz, mert megbizhatatlan, es draga. Illetve a barkacs es
felbarkacs eszkozoknel elofordul ma is, a sorozatgyartasu profi
termekeknel ki van zarva. Szerintem errol is tudnanak meselni egyes
listatarsak. Nagy volumenu gyartasnal egyetlen tranzisztoron kepesek
napokig vitatkozni. Ezt persze te nem feltetlenul latod, mert nem
ilyesmivel foglalkozol.

> az arak a tomegtermeles miatt a bekasegge ala esnek
> Mivel a tomeggyartasu Si chipek vilagaban az
> arat messze nem a gyartas onkoltsege szabja meg.
> Az ar lenyegeben profit optimalizalasi kerdes ezeknel...
> (a kelloen nagy sorozatok eseteben, legalabbis biztosan)

Akarmeddig esnek az arak, mindig lesznek olcso es draga eszkozok.
Aki a feladathoz optimalis eszkozt valaszt, piaci elonybe kerul azzal
szemben, aki feleslegesen draga eszkozt hasznal. Egyreszt az ar miatt,
ez trivialis, masreszt minel bonyolultabb a kutyu, annal gyakrabban
fog bedogleni, es annal nehezebb lesz a hibat megkeresni, stb...
De almodozni lehet :)

> Szoval kihal a codepage, ahogy kihalt a jegesember es a szodas is...

:)

> KJ

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"Magyar egre magyar ufot!"