In that case a little properties file containing mappings should do the job.
Add new mappings as and when the need arises.  You could allow multiple
candidate replacements, so that your aenima example (which I can't type in to
this newsreader correctly) could be matched by any of
   the correct version
   aenima
   anima
   enima

Odd that you should say that; quite a lot of programmers seem to feel the
same...

   -- chris

I am not sure :-) My understanding of ICU after checking the
documentation is that it doesn't do the destructive thing the OP might
want to do. It looks more as if the authors of ICU tried very hard to
get every aspect of Unicode right. Mapping an accented character to a
single non-accented  "equivalent" is certainly not right in the scope of
Unicode, and also not in the scope of non-ascii languages.

The effort to invest in a solution also depends on how good the solution
has to be. Since the original text is anyhow supposed to be butchered, I
don't see a reason for 100% accuracy.

So, scripting the parsing of the UCD for finding the interesting values
should not take that much time. I would guess less than an hour. That
should include scripting of checking the decomposition values for these
"bad" accents (probably code points starting at 0x300 up to some value I
forgot). The result should be a map of a bunch of characters.

Some more scripting to get that output into a Java data structure, add a
lookup method, compile, and that's it.

Probably because people don't know about it (I didn't). And probably
because it solves problems not many people have each day.

/Thomas

Thomas seemed to think I was removing accents from a document.

The easiest solution would have been to rename all the files/titles of the
media so that I didn't have to deal with accented characters at all.    But
to me ça is not ca, muñeca is not muneca.   So I would have to agree with
him.

My desire to get a "better solution" is just to make my functions more
future ready (I hesitate to say future proof)

--
LTP

...

What about o-umlaut and oe? As in "Goedel".

Google can deal with this - I tried a search for "Goedel" and got a
page,
http://www-gap.dcs.st-and.ac.uk/~history/Mathematicians/Godel.html, that
spells the name with o-umlaut.

Patricia

...

You decided to go for the "accent-removing" way though there
are many different ways to achieve the functionality you're after.

To me this looks very similar to a spelling algorithm (even though
you're using several languages at once).

For every search word entered you could:
-check exact matches
-check "one typo" matches (eg "Pixes" instead of "Pixies")
-check "two typos" matches (eg "Spellshaker" instead of "Spellchecker")
-check all "sound-alike" words (using eg Soundex or Double-Metaphone)
-rank all the propositions found using these various techniques by
their "closeness" to the search term entered (using Levenhstein's
edit distance, implemented using a DP algorithm).

This should allow to enter really badly written band names/song
names and still find back the song(s) you're after.

For example, my home-made spellchecker's first proposition for
"paulitiquale" ("political" spelled in a strange french-phonetical
way) is, surely enough, "political" (note that Un*x' aspell/ispell
works the same way).

Now of course this is lots of work for a simple functionality, but
you could still use something similar but much much simpler
(take could be implemented very easily):

- for every correct name you have in your database, you create
a hashmap with all vowels removed

Pixies -> Pxs
Pink Floyd -> Pnk Fld
rückenwind -> rckwnd

etc.

Then, when someone enters a search term, *if you don't find
an exact match*, you try to remove every vowels
from the entered search terms and sees if this corresponds
to something in your hashmap.

You can get a little more fancy by checking if the entry (or
entries) in the hashmap really correspond to something close
to the entered search term by calculating the "edit distance"
between the two strings.

It really looks like what a spellchecker would do: the whole
point is not using a single technique, but a variety of
techniques.  Each one augmenting the probability that
the search gives back a meaningfull result.

FWIW,

Alex

P.S: this post directly edited in groups.google.com, without
bothering to copy&paste in a spellchecker ;)