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

• thon73 tag

  #1177

  #1176 Karma

  2013-10-04 18:57:25

  Ú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

  #1176 Karma

  #1176 Karma

  Három főbenjáró bűn lebeg a levegőben ennél a történetnél:

  1) Fel akarod találni újra a kereket. Rengeteg különböző, de jure vagy de facto szabványos alternatív kódolás van arra, hogy az ilyen karaktereket könnyen olvasható formára hozd, nem kell újon törnöd magad(*). Pl. pofonegyszerű használni az URLEncoder osztályt, vagy a Commons Lang StringEscapeUtils osztályát.

  2) Hacsak nem mérési eredményeid vannak arról, hogy a vázolt megközelítésed lassan működik és ez az egykarakteres Stringek miatt van, ne állj neki túlkomplikálni. A premature optimization esete állhat fenn.

  3) A Unicode olyan, mint a medve: nem játék. Persze, magyar karakterekkel el tudsz lavírozni akár egy kézi look up table-lel amikor az UTF-8 "konverteredet" írod, de a helyes megoldás bőven meghaladja a "fél délután alatt a garázsban összedobom" szintet. Gondolok pl. a surrogate-ek kezelésére, ami UTF-16-ban két karakter, UTF-8-ban meg pl. három...

  (*): Kivéve persze, ha valaki más követte el ezt a hibát egy szerveroldalon, és ahhoz kell idomulnod. Ez esetben tekintsd az első pontot tárgytalannak.

  Szóval röviden: ha nincs valami életbevágóan fontos és pontos oka ennek, keress valami más megoldást.

  ((A new line/tab átalakítást csak példának írtam, (és ebben az esetben az első pont teljesen jogos) Esetemben egy kicsit összetettebb dologról van szó: tényleges szövegfeldolgozás történik, a mentett oldalon - értelmezést könnyítendő - a rövid bejegyzéseket mintegy kibontja a program, és egy hosszú file-ban tárolja. Igazából ez is egy decoder, csak épp elég speciális. De ez a programozási probléma szempontjából lényegtelen.))

  A röviden pont történt meg most (vagyis megoldást kerestem), és a választ is köszönöm: És meg is fogadom, (2. pont), mert igazad van: nem foglalkozok a teljesítménnyel. Én is gondoltam arra, hogy ha a teljesítmény ilyen fontos tényező, akkor ezt a részt natívan kellene elkészíteni, de ebben (még) nincs tapasztalatom. Egyébként nem olyan félelmetesen hosszú a feldolgozás: vmivel több, mint 200e bejegyzésre 20-40 perc jelenleg
  ((Arra az indiszkrét kérdésre, hogy akkor miért a telefonom csinálja, csak azt tudom mondani: az mindig nálam van. De egyébként a teljes adatbázist csak egyszer kell megcsinálni, a többi meg már rövid...))

  ((A 3. pontban is nagy igazság van, bár egyszer beleástam magam az unicode-ba, és írtam konvertáló algoritmust is, tehát az van. Az UTF16->UTF8 irány elég egyszerű, hiszen ott (felső részek kivételével) minden karakter létezik. A fordított irány az érvénytelen szekvenciák miatt egy kicsit izgalmasabb.
  A gond egyébként pont abban van, hogy az UTF8 nem egyforma hosszú részekből áll (na persze ez az előnye is), és ez - saját kód nélkül - megnehezíti a szövegfeldolgozást. A legegyszerűbb példa: nagyon nehéz effektív UTF8 beolvasást csinálni, mert nem tudod, hogy pontosan hány byte-ot kell/lehet a pufferbe olvasni, és ezért pl. vagy "görgetni" kell a puffert, vagy figyelni a végén az eltört karakterekre. Ezért is gondoltam, hogy egyfajta stream-szerű beolvasás (szerű, mert UTF8 karakterenként olvas/ír) egyszerűsíteni az életet, de még nem találtam ilyet készen. Ettől függetlenül masszívan igaz, hogy meglehetősen túlkomplikálja a programot. Bocs a hosszú okfejtésért.))

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