Új hozzászólás Aktív témák

• thon73 tag

  #1187

  #1186 sztanozs

  2013-10-07 17:51:20

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  thon73

  tag

  #1186 sztanozs

  #1186 sztanozs

  Random access-t nem erre találták ki, hanem jól strukturált fájlokra, ahol a mező/rekord-szélesség ismert.
  BTW, Stream-ben is tudsz pozicionálni.

  Más: Ha UTF-et használsz, akkor ne legyenek olyan prekoncepcióid, hogy nem fogsz nem base charset-et használni, mert ha később mégiscsak szeretnéd, akkor aztán igazán szívás lesz az ékezetes karaktereket belehackelned a saját algoritmusodba...

  A RandomAccess akkor is nagyon jól használható, ha a file tartalma indexelve van. Itt pont ez a helyzet: az első olvasás után minden bekezdés pozíciója ismert, a programnak csak a megjelenő bekezdéseket kell feldolgoznia.
  A Stream-ek között nem találtam könnyen pozícionálható megoldást, csak a reset/skip párost. RAF esetén viszont rögtön adott ez a lehetőség; ráadásul a C-hez (és én C-ből akartam áthozni a programot) nagyon hasonló módon.
  Csak az utf-8-on akadtam el (pontosabban indultam a fenti szálakon). ((Az eredeti adatok pdb-ben voltak))

  A pozícionálható Stream az kiváló megoldás lenne. ((A jelenlegi megoldás egy olyan "stream" osztály lett, ami háttérként RAF elérést használ, így pozícionálható is, meg a read() révén "stream" is. Ráadásul Utf8-at olvas.))

  (((Az UTF-8-ról annyit érdemes megemlíteni, hogy az első közel 65 ezer karakter a Basic Multilingual Plane. Ez nem csak az összes ékezetes betűt, hanem az összes ismert nyelv betűit tartalmazza. Ebben az a nagyszerű, hogy 16 biten tárolható, vagyis épp egy karakteren. Ami ezen felül van, ahhoz UTF-16-on már két karakter kell. Az UNICODE saját dokumentációja állítja, hogy ez a rész nem kellőképpen tesztelt és megvalósított. Az ANDROID sem következetes, uis. ezt néha egyetlen 4 byte-os int-en ábrázolja, néha két egymás utáni karakteren. Mivel nekem még a beszélt nyelvek közül sem kell az összes, ezért a dekódoló algoritmus figyeli a non-BMP karaktereket, de helyettük egy sima '*' hibajelölést tesz, ami bármilyen kódolásban ábrázolható. Nem lenne nehéz egyébként a dekódolást erre a részre sem kiterjeszteni, csak akkor az egész program működését is ki kellene terjeszteni. ASCII-ról nem volt nehéz ITF-16-ra áttenni, de ha néhol két karakternyi ábrázolással kellene számolnom, az megnehezítené a dolgot.)))

  Bocsánat egyébként, ha nagyon triviálisakat kérdezek, de az Android/Java párost csak most tanulom. Némely. engem érdeklő részbe már mélyen beleástam magam, de a legtöbb részt egyáltalán nem ismerem. Ezért örültem az előző tanácsoknak is, mert így új koncepcióban készítettem el a megfelelő részt.

Új hozzászólás Aktív témák