Hej Peter
> Jeg har løst en del af problemet, men jeg synes det er en lidt fusket
> løsning. Den er korrekt nok, men jeg ville gerne klare mig uden.
Det tegn er vist en indikation af at en Reader - eller en af de andre
klasser som konverterer udefra kommende data til stringe (der er nogle nye i
java.nio) - har f?et et tegn i indsugningen som den ikke kan konvertere til
et tilsvarende Unicode (Java bruger UTF-8 internt throughout).
Jeg vil tippe p? at din JDBC driver forventer en anden encoding end hvad den
faktisk faar. Hvis der forsvinder et tegn efter hvert ae, oe, aa vil jeg
osse tro at driveren forventer UTF-8.
Jeg havde selv engang et lign. problem (det hed SDK1.3 dengang) som jeg var
nede i org.gjt.mm.mysql og lave et fix for ;). Men for mig var det nok fordi
min platform er KINESISK. Det saa for mig ogsaa ud som om at dataene "laa
fint" i databasen, men det var saa bare fordi mappingfejlen ikke var DER.
Kan ikke huske detajlerne, men mm.mysql (som nu hedder
com.mysql.etellerandet) kan passes et Properties objekt et eller andet sted
hvor man laegger encodingen ned i.
Overvejet at koere med UTF-8 konsekvent over hele linien ? Eller lige nu,
bare se efter om det virker ? Det vil jeg i hvert fald selv paa sigt.
(du skal goere som jeg siger, ikke som jeg goer - MIT system defaulter til
GB2312, specielt Outlook
Hvad er dine user.language, file.encodig properties ?
import java.util.Enumeration;
import java.util.Properties;
public class SystemEnvTest {
public static void main(String[] args) {
Properties bundprop = System.getProperties();
Enumeration numse = bundprop.keys();
while (numse.hasMoreElements()) {
Object el = numse.nextElement();
System.out.println(el + "\t:\t" + bundprop.getProperty((String)el));
}
}
}
Hvis du vil deltage i en analyse af alle resultater, kan jeg overtales til
at grave min modificerede JDBC driver frem :)
MVH
Soren