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

• Karma félisten

  #1176

  #1175 thon73

  2013-10-04 17:42:37

  Ú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

  

  Karma

  félisten

  #1175 thon73

  #1175 thon73

  Igen, ez világos. Igyekeztem a kérdést a problémás részig egyszerűsíteni, ebből a félreértés. De a szélesebb problémára is szívesen fogadok ötleteket:

  Adott egy String, ami EditText-ből, vagyis a felhasználótól származik (és egy adatbázis tárolja). Ezt a Stringet szeretném UTF-8 kódolású txt file-ba menteni. Ez idáig egyszerű, és két sorban megoldható.

  DE!

  Mentés előtt a String-en utólagos feldolgozást végez a program, néhány részét cseréli. (Gondoljunk pl. arra, hogy pl. tab-ot \\t-re, new-line-t \\n-re, vagy esetemben speciális, de olvasható tag-okat szúr be.) Erre a legegyszerűbb mód, ha StringReader-ként kiveszem a karaktereket, átalakítom, és az eredményből egy új folyamot hozok létre. A karakterek 99%-a változatlanul (vagyis egy karakterként) fut tovább, de néha a karakter helyett egy rövid szövegrész megy ki. Nem akartam új String-et készíteni, hanem azonnal az UTF-8 típusú kimenetre küldeném az adatokat.
  Eddig csak olyan megoldást találtam, ami String-et, vagyis hosszabb szöveget alakít UTF-8-ra. Az 1%-nyi részben ez tökéletes, de 99%-ban ez a String csupán egyetlen karakter hosszú lesz. Van vajon erre frappáns megoldás, vagy egyszerűbben járok egy UTF-8 kódoló megírásával?
  Vagy esetleg lehet-e az egész gondolatmenetet előnyösebben elrendezni?

  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.

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