Now this looks very interesting!
NetworkWorld.com · Feb 12, 2013 · Steve Patterson
"While the cellphone network in Haiti survived the devastating earthquake in 2010, the added load of international aid workers who arrived in the aftermath caused it to crash. Josh Thomas and Jeff Robble, both working at Mitre, saw this problem and created a working prototype backup network using only the Wi-Fi chips on Android smartphones. This capability won’t be shipped on new mobile phones anytime soon, but it is a really interesting open innovation project to understand and follow, and for some an Android project to which they might contribute."
Howdy Neil!
Hi Jim. Any movement on the fix for the weird character yet?
http://search.cpan.org/~barbie/Data-FormValidator-Filters-Demoroniser-0.03/lib/Data/FormValidator/Filters/Demoroniser.pm
No, apparently a lot of news pages are developed using Microsoft software and it embeds fancy "smart" character symbols like thin spaces, curly quotes and smart apostrophe's and long dashes, etc., into the text. When you cut and paste it to another page, it doesn't work so well. Did find a perl module to "demoronise" (assuming they're referring to Microsoft there) but I'm going to need John's help to install and test it. Link embedded above.
Reposting from above... to this relevant thread
We had the MS high order quotes problem too. Since the database could handle it, and java could handle it, we looked at the jdbc driver. Yup, there was a optional parm for the connection uri that we set to pass through high order ascii as-is. I think it can be set in the connection manager too. (public static final JDBC_LOCALE set to i.e. US_819 - which is what our database encodes chars in) made them play well together. It's the only change we had to make.
I'll have to check that out. Hacked in a tidy clean routine here to convert them
John told me I'd have to set various parameters to charset=UTF-8 then he took off on a trip before I could figure it out.
When we went from client server to web, our old data had comments entered which had been copied from Word. At first, the jdbc driver replaced the high order ascii chars with question marks. No biggie.
We then started using Hibernate, had some problems with timeouts on fetches (Hibernate waits for NO man!), so we upgraded the jdbc driver (which supported a wait/retry param.
That worked fine, but they "fixed" the high order ascii issue, so instead of replacing characters with a question mark, it threw a fatal exception! Aaargh!
That's when I learned about the locale. It might be just IBM/DB2 and Oricle drivers that have it as a parameter though... dunno. Maybe your db has a similar param.
http://jhy.io/tools/convert-word-to-plain-text
The javascript routine in the source of the page embedded worked here as a temporary fix. Hopefully John will have a little time later to explain the parameters I need to set to eliminate the problem.
Yah, utf-8 is what java uses in our apps, and is happy. If you use Eclipse, I believe it's in the java settings. The jdbc driver was defaulted to 7 bit ascii, so it lopped off the high bit... until they fixed it so it conviently threw a stack trace.
I set the jdbc param (or connection manager setting if your driver doesn't take params) to what the *database* uses, then java handled the chars fine. Since I didn't mess with the connection manager, I can't advise on that. The beauty of it was that we didn't have to parse anything, which could be a not insignificant performance factor... in fact we changed no application code.
I'm just trying to clarify what I did. YMMV :o)
You know, this software stuff is fun. I love puzzles.
Good plan. The server-side "tidy" routine looks like a good solution too if the driver is immutable.