Jdbc mot Sql-ascii enkodet database

[starving]

Hei!

Jeg kobler til en postgresql-database med encoding sql-ascii(bruker java og jdbc). Problemet er at æ, ø og å kommer gjennom som � .

Jeg har ikke noen kontroll over databasen, så jeg kan ikke gjøre noe på den siden.

 

Slik jeg har forstått det kobler jdbc til med utf-8 eller utf-16, og har prøvd å endre tilbkoblingsencoding, standard systemencoding lokalt og andre encodingsting uten hell.

 

Noen vet noe som kan gjøres for å få æ, ø og å rett?

[terjeelde]

Jeg kobler til en postgresql-database med encoding sql-ascii(bruker java og jdbc). Problemet er at æ, ø og å kommer gjennom som � .

 

Det er jo ikke rart... Særnorske tegn er ikke en del av ASCII.

 

Jeg har ikke noen kontroll over databasen, så jeg kan ikke gjøre noe på den siden.

 

Trenger ikke det.

 

Når du har koblet til, så gjør ett forsøk på f.eks:

SET CLIENT_ENCODING TO 'utf-8';

 

Koble gjerne til med UTF-8 istedet for SQL-ASCII også.

[starving]

Ser jeg formulerte meg litt tvetydig.

Det er enkodingen på databasen som er sql-ascii.

Og jeg vet at det går å få særnorske tegn ut av databasen siden de dukker opp på "orginalsiden" skikkelig. Orginalsiden er basert på php, men jeg vet ikke hva som ligger i bunnen av den servern den kjører på.

 

Jeg vet at alt på min side er utf-8, og er rimelig sikker på at tilkoblinger er utf-8 siden jeg har prøvd SET CLIENT_ENCODING TO 'utf-8'; og ingen forskjell. Men da jeg prøvde en annen enkoding fikk jeg feilmelding fra jdbc om at den krevde utf-8.

[blackbrrd]

Antar du bruker pgadmin?

 

Når du trykker på databasen der, hva står det der?

 

Hos meg står det:

 

CREATE DATABASE xyz

WITH OWNER = abc

ENCODING = 'UTF8';

 

Problemet ditt kan like gjerne være at du har satt opp feil encoding på websiden som på databasen.

[terjeelde]

Ser jeg formulerte meg litt tvetydig.

Det er enkodingen på databasen som er sql-ascii.

Og jeg vet at det går å få særnorske tegn ut av databasen siden de dukker opp på "orginalsiden" skikkelig. Orginalsiden er basert på php, men jeg vet ikke hva som ligger i bunnen av den servern den kjører på.

 

Jeg vet at alt på min side er utf-8, og er rimelig sikker på at tilkoblinger er utf-8 siden jeg har prøvd SET CLIENT_ENCODING TO 'utf-8'; og ingen forskjell. Men da jeg prøvde en annen enkoding fikk jeg feilmelding fra jdbc om at den krevde utf-8.

 

Ahh, da er jeg med.

 

Har en mistanke om at data kanskje er lagret feil i databasen, fra PHP.

 

Se for deg følgende:

 

Database er satt opp med SQL-ASCII

PHP kobler til med encoding SQL-ASCII

PHP lagrer likevel UTF-8, eller noe annet.

 

Dette ser ut som gyldig SQL-ASCII, så PostgreSQL lagrer det som det, uten å klage.

 

Ikke heeelt sikker på at det er dette som skjer, men har en mistanke om at det kan være dette som ligger bak.

 

Hva med å prøve å kjøre SQL-ASCII mot databasen, gjøre en spørring som gir data med æ, ø og/eller å, og så sjekke hva du får tilbake?

 

Siden du ikke styrer med databasen kan enkleste løsning kanskje være å kjøre SQL-ASCII mot databasen, og så selv convertere fra "hva nå enn du får tilbake" til f-eks UTF-8.

 

Finner du ut at det er dette som går feil, så kan du jo alltids kontakt vedkommende som styrer med databasen, og be ham ordne opp.

[blackbrrd]

Personlig foretrekker jeg databaser i UTF-8 og websider i UTF-8, så slipper jeg å bry meg noe mer om encoding...

[terjeelde]

Personlig foretrekker jeg databaser i UTF-8 og websider i UTF-8, så slipper jeg å bry meg noe mer om encoding...

 

Finnes noen unntak, men stort sett *veldig* enig!

[blackbrrd]

Ble nysgjerrig nå, hva er unntakene?

[starving]

Problemet er at jdbc kobler til med utf-8.

Når jeg kobler til databasen manuelt er sql_ascii default client_encoding, og da får jeg opp karakterer som er forskjellig for æ,ø og å.

Men siden jdbc absolutt skal koble opp med utf-8 blir disse bare �.

Så det jeg lurer på er om noen vet hvordan man tvinger jdbc til å koble til med noe annet enn utf-8.

[terjeelde]

Ble nysgjerrig nå, hva er unntakene?

 

Mulig jeg husker litt feil mellom server-locale og database encoding her, men ihvertfall:

 

PostgreSQL har default operator class, som for C/SQL_ASCII brukes til både nøyaktig og pattern-matching.

 

For pattern-matching med noe annet enn C/SQL_ASCII brukes ikke en index med default operator class. Da ender man fort med full table scan.

 

Alternativt kan man ha en index med varchar_pattern_ops, slik:

 

CREATE INDEX test_index ON test_table (col varchar_pattern_ops);

 

Denne kan brukes til pattern-matching, men ikke til nøyaktig matching. Man trenger derfor to indexer, en for nøyaktig matching, og en for pattern matching.

 

Dette er neppe noe problem for de aller fleste, men dersom totale størrelsen på indexene blir større enn hva man har av RAM, og man oppdaterer dem mye, så kan det være litt... nedtur for ytelse.

 

Neppe noe problem for de fleste i prasksis, men har du database i noe annet enn C/SQL_ASCII, og indexene ikke brukes for pattern-matching, så er dette greit å ha i tankene.

[blackbrrd]

I teorien er jeg helt enig med deg, man kan bli tvunget til å ha to indekser.

 

I databasen jeg drifter så har vi f.eks en tabell med kundenavn. Disse er indeksert med funksjonen upper og text_pattern_ops. Ser ikke poenget med å ha en nøyaktig matching indeks på denne tabellen. Strengt tatt burde vi nok ha brukt fulltekst indeksering. Det hadde vært nyttig når man er usikker på hvilket av etternavnene kunden er registrert på.

 

Ser veldig få tilfeller hvor du har lyst på nøyaktig indeksering av tekst.

 

Som du selv sier: "Neppe noe problem for de fleste i prasksis".

 

Det er ett unntak til tror jeg. Ikke at jeg har testet det, men UTF-8 er tregere og tar større plass.

[terjeelde]

I databasen jeg drifter så har vi f.eks en tabell med kundenavn. Disse er indeksert med funksjonen upper og text_pattern_ops. Ser ikke poenget med å ha en nøyaktig matching indeks på denne tabellen. Strengt tatt burde vi nok ha brukt fulltekst indeksering. Det hadde vært nyttig når man er usikker på hvilket av etternavnene kunden er registrert på.

 

Morsomt alternativ er å splitte mellom fornavn og etternavn, kjøre pattern-index, og også index på soundex-verdien av hver av disse.

 

F.eks:

 

SELECT soundex( 'Foo');

gir:

F000

 

Gjerne koke opp en liten stored procedure for å finne rett bruker, og gjøre noe ala:

 

SELECT * FROM find_user( 'Terje', 'Elde' );

 

find_user kan da først prøve å slå opp nøyaktig, og så se etter relativt like navn.

 

soundex-greiene er i contrib/fuzzystrmatch

 

Lite eksempel:

 

Bruker "Geir Samuelson" ringer inn. Kunde-behandler hører "Geir Samuelsen".

 

Man kjører:

SELECT * FROM find_user( 'Geir', 'Samuelsen' );

 

Som først prøver:

 

SELECT * FROM users WHERE firstname='Geir' AND lastname='Samuelsen';

 

Denne finner ingen hits. man prøver igjen:

 

SELECT * FROM users WHERE firstname=soundex('Geir') AND lastname=soundex('Samuelsen');

 

soundex-verdiene blir:

 

Geir = G600

Samuelsen = S542

Samuelson = S542

 

Siden soundex-verdien for Samuelsen og Samuelson er identisk, blir rett person funnet.

 

Finnes nok bedre algoritmer, men er morsomt og enkelt å ta i bruk.