[Oracle] Omzetten diakrieten

[PaulZ]

Met mijn probleem ben ik al redelijk lang bezig.

Ik haal een naam uit een Oracle 10 database (NLS_CHARSET= AL32UTF8). In die naam zitten diakrieten, alleen die staan op een rare manier in de database: KriÏckoviÂc ipv Kričković bijvoorbeeld.
Het eerste rare teken voor de letter c is een Ï en heeft ascii-waarde 50063 . Inmiddels ben ik er wel achter dat het een multibyte teken is. Maar dan... Ik moet iets doen met dat multibyte teken en de letter 'c' om er weer een č van de maken.
Ik mag niets in en aan de database wijzigen overigens.

Veel gezocht op internet, dba'ers gevraagd en ben veel termen tegengekomen die ik in wat testjes heb gebruikt (asciistr, unistr, substrb, utl_i18n etc).
Maar de gedachte die ik heb werkt dus niet: oracle maakt tijdens het opslaan van één karakter twee karakters -> voeg ze samen en je hebt weer het originele karakter.

Is er iemand die hier ervaring mee heeft en me een klein beetje in de goede richting kan helpen?

[Voor 3% gewijzigd door PaulZ op 24-05-2011 15:47]

[justmental]

select convert('KriÏckoviÂc','AL32UTF8','WE8ISO8859P1') from dual;

[PaulZ]

Bedankt. Die had ik ook al geprobeerd (niet in mn lijstje erbij gezet, sorry). Maar dat levert bij mij 'KriÏckoviÂ,c' op...
Misschien dat ik ergens wel een denkfout maak, maar daar ben ik nog niet achter...

[RobIII]

PaulZ schreef op dinsdag 24 mei 2011 @ 15:41:
Maar de gedachte die ik heb werkt dus niet: oracle maakt tijdens het opslaan van één karakter twee karakters -> voeg ze samen en je hebt weer het originele karakter.

Is er iemand die hier ervaring mee heeft en me een klein beetje in de goede richting kan helpen?

PaulZ schreef op dinsdag 24 mei 2011 @ 16:02:
Misschien dat ik ergens wel een denkfout maak, maar daar ben ik nog niet achter...

Ik vermoed dat dit je wel op weg helpt:
The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

Dan is het volgende interessant: zit het in je presentatielaag (weergave) of gaat 't al "fout" eerder in de pijplijn van connectie, tabellen met collaties, (in het geval van websites) charsets in HTTP-headers en/of metatages etc. ? Kortom: het is wel handig als je ons even voorziet van wat meer info

[Voor 15% gewijzigd door RobIII op 24-05-2011 16:08]

[PaulZ]

Daar ga ik eens even rustig voor zitten.

Wat meer informatie:
Ik ontwikkel een windows-applicatie in vb.net die gegevens uit een Oracle database moet weergeven.

De fout zit ergens aan de invoerkant. Wanneer ik in SQL-Developer het karakter 'ç' insert in een tabel, dan komt exact dat karakter ook in de tabel in Oracle te staan.

Alleen, de invoerkant is geautomatiseerd. Naam etc. wordt in de database gepompt/bijgewerkt op gezette tijden. Daar heb ik allemaal geen invloed op.

Het enige waar ik wat kan betekenen is aan de presentatiekant, waar ik dus die 'foute' data om moet zetten naar leesbare tekst.

[Voor 88% gewijzigd door PaulZ op 24-05-2011 16:13]

[KabouterSuper]

En de functie TO_MULTI_BYTE ( en TO_SINGLE_BYTE)? Of doet die wat anders?

[PaulZ]

Beide functies ook al gevonden op internet, heel even mee gespeeld, maar daar nog geen bevredigend resultaat mee gekregen helaas. Misschien dat ik van alles wat moet gaan combineren...

[RobIII]

PaulZ schreef op dinsdag 24 mei 2011 @ 16:17:
Beide functies ook al gevonden op internet, heel even mee gespeeld, maar daar nog geen bevredigend resultaat mee gekregen helaas. Misschien dat ik van alles wat moet gaan combineren...

Als het het probleem al bij de import (of dus in de DB zélf) zit zou ik me toch echt eerst daar op gaan concentreren om dat, linksom of rechtsom, gefixed te krijgen. Je kunt wel allerlei workarounds en "fixes" gaan verzinnen maar uiteindelijk is je data gewoon fout en ga je dat nooit (helemaal) goed krijgen. En dat wordt een nachtmerrie om te (blijven) supporten. Bij elke (bijv. zoek)query die je doet moet je er aan denken allerlei converts en whatnots los te laten op de invoer zodat 'ie weer "matched" met de meuk in de DB wil je er iets zinnigs uit krijgen.

[PaulZ]

Ik snap jouw redenering en denk er zelf ook zo over. Zowel de database als de import-/bijwerkfunctie is niet van mij en wijzigingen die de boel kunnen fixen zitten er op korte termijn niet in.
De leverancier heeft wel een vertaaltabel meegeleverd (daarin staat bv dat 'Ïc' = c< combinatie, maar goed, ik dacht aan een simpelere constructie via een standaard functie. Mocht die niet mogelijk zijn, dan houdt het hele verhaal op.

[RobIII]

PaulZ schreef op dinsdag 24 mei 2011 @ 16:29:

De leverancier heeft wel een vertaaltabel meegeleverd (daarin staat bv dat 'Ïc' = č combinatie

WTF? Je kunt zeker geen namen noemen?

[PaulZ]

Laat ik dat maar niet doen ...

Toevallig loop ik nét tegen de COMPOSE functie in Oracle aan. Even kijken wat ik daarmee kan...

BTW: Grappig dat de Quote-functie van GOT dit wel meteen vertaalt )

[Voor 21% gewijzigd door PaulZ op 24-05-2011 16:39]

[RobIII]

PaulZ schreef op dinsdag 24 mei 2011 @ 16:38:
BTW: Grappig dat de Quote-functie van GOT dit wel meteen vertaalt )

Grappig dat ik dat even handmatig fixte in de verondersteling dat jij je post wel even zou editten om 't te fixen

[PaulZ]

RobIII schreef op dinsdag 24 mei 2011 @ 16:42:
[...]

Grappig dat ik dat even handmatig fixte in de verondersteling dat jij je post wel even zou editten om 't te fixen

Nee, in de vertaaltabel staat dus dat c-caron moet worden opgebouwd uit de karakters 'c' en '<' vandaar dat ik die los heb laten staan.

* PaulZ gaat ff eten...

[Voor 4% gewijzigd door PaulZ op 24-05-2011 16:54]

[The Eagle]

Ik neem aan dat je smakelijk gegeten hebt

Persoonlijk denk ik dat je dit het makkelijkste op kunt lossen met een ON INSERT, UPDATE trigger op de tabel waar het zaakje in terecht moet komen.
Da's wel ff prutsen omdat je bij iedere mutatie de string moet controleren op zaken die in de vertaaltabel staan, maar ik zie zo 123 geen andere oplossing. Voordeel is dan wel weer dat je de zaken die al in je DB staan, en masse kunt update met als basis het zelfde script / functie dat je in je trigger gebruikt

Rest me nog te zeggen dat die leverancier een flinke veeg uit de pan verdient, maar ik geloof dat we het daar allemaal al wel over eens waren

[PaulZ]

Dank je voor deze tip. Helaas kan ik die ook niet toepassen:
1. ik mag deze velden niet wijzigen
2. er zit een controlegetal in het record die ik dan ook moet wijzigen wil het gehele record geldig zijn. Alleen hoe dat is opgebouwd, geen idee (wordt niet vrijgegeven door de leverancier).

En ik heb lekker gegeten

Ben inmiddels nu een blog uit 2009 hierover aan het lezen.

[Voor 32% gewijzigd door PaulZ op 24-05-2011 23:35]

[joppybt]

PaulZ schreef op dinsdag 24 mei 2011 @ 16:08:
De fout zit ergens aan de invoerkant. Wanneer ik in SQL-Developer het karakter 'ç' insert in een tabel, dan komt exact dat karakter ook in de tabel in Oracle te staan.

Dit is een uitspraak die je gemakkelijk op het verkeerde spoor kan zetten. Hoe weet jij zo 100% zeker dat dat karakter ook daadwerkelijk goed in de tabel staat? Heb je het met SQL-Developer weer opgevraagd? Dat geeft namelijk geen 100% uitsluitsel.
In sommige configuraties doet Oracle namelijk helemaal geen karakter conversies en dan geldt een Garbage-in-Garbage-out principe: alles wat je aanbiedt wordt byte-voor-byte blind opgeslagen en ook weer identiek opgeleverd zonder dat Oracle weet (of controleert!) welke encoding het is.
De enige manier om *echt* zeker te weten wat in de tabel zit is door

code:

SELECT DUMP(kolomnaam), kolomnaam FROM tabel

te doen en die resultaten te interpreteren.

[PaulZ]

Dump gedaan:

dump(naam,17) -> Typ=1 Len=13: K,r,i,c3,8f,c,k,o,v,i,c3,82,c
dump(naam,1016) -> Typ=1 Len=13 CharacterSet=AL32UTF8: 4b,72,69,c3,8f,63,6b,6f,76,69,c3,82,63

Als ik zelf de speciale karakters insert:
č -> dump(column1,17) -> Typ=1 Len=2: c4,8d
ć -> dump(column1,17) -> Typ=1 Len=2: c4,8f

[Voor 44% gewijzigd door PaulZ op 25-05-2011 15:13]

[joppybt]

PaulZ schreef op woensdag 25 mei 2011 @ 09:03:
Dump gedaan:

dump(naam,17) -> Typ=1 Len=13: K,r,i,c3,8f,c,k,o,v,i,c3,82,c
dump(naam,1016) -> Typ=1 Len=13 CharacterSet=AL32UTF8: 4b,72,69,c3,8f,63,6b,6f,76,69,c3,82,63

Blijkbaar is de &#269 geëncodeerd als C3 8F, de hoofdletter I met puntjes. Het zit dus echt gewoon fout in de database als je karakterset AL32UTF8 is

Als ik zelf de speciale karakters insert:
č -> dump(column1,17) -> Typ=1 Len=2: c4,8d
ć -> dump(column1,17) -> Typ=1 Len=2: c4,8f

č is in UTF8 geëncodeerd als C4 8D dus als jij het insert gaat het goed.

Waarschijnlijk is er in het verleden met een verkeerde configuratie gewerkt.
Als er dan ondertussen ook records zijn waar wel de goede encodering is gebruikt dan heb je een probleem wat niet geautomatiseerd op te lossen is.
Als het om dit ene record gaat kun je misschien nog proberen met de REPLACE functie karakters te vervangen maar of je daar blij van wordt?

[PaulZ]

Dank je joppybt. Ik ga er idd niet blij van worden. Ik denk dat ik het maar even een tijdje laat liggen.

Alhoewel ik nog steeds op zoek ben naar een artikel waar ik iets heb gelezen over bitshiften dat mogelijk een oplossing zou zijn. Mocht iemand die tegenkomen, dan houd ik me aanbevolen, want ik kan die pagina niet meer vinden.

[RobIII]

PaulZ schreef op donderdag 26 mei 2011 @ 09:29:
Alhoewel ik nog steeds op zoek ben naar een artikel waar ik iets heb gelezen over bitshiften dat mogelijk een oplossing zou zijn.

Ik zie niet hoe "bitshiften" hier in enige wijze iets in kan betekenen; in de verste verte niet.
Ik zou als ik jou was eens gaan kijken hoe/waarom die data zo in de DB komt. Misschien ligt 't wel aan de connectie settings oid en kun je dat met een instelling her-of-der in je import-proces ofzo wel wijzigen. Maar ik val in herhaling: RobIII in "[Oracle] Omzetten diakrieten"

[Voor 8% gewijzigd door RobIII op 26-05-2011 09:57]

[PaulZ]

Herhalen is niet zo erg hoor . Ben bang dat dit topic een langzame dood gaat sterven, maar zodra ik een oplossing heb zet ik het nog wel neer hier.

Topic met bitrommelen gevonden: AskTom alleen was het dat niet ...

[Voor 37% gewijzigd door PaulZ op 26-05-2011 12:02]

[Janoz]

Je probleem is op zich heel duidelijk. Garbage in == garbage out. De boel steekt ruk in elkaar precies op het punt waar jij er blijkbaar niet bij mag komen. Zolang je dat probleem niet op mag lossen blijft het een ruk probleem. Het is alsof je een lek dak gaat repareren door een complete sarcofaag over je huis te zetten.

Doe een bugreport bij de leverancier en zeg (op vriendelijke wijze) dat ze een stel prutsers zijn en dat ze het artikel van Joel moeten lezen.

[BasieP]

Janoz schreef op donderdag 26 mei 2011 @ 11:13:
...t ze een stel prutsers zijn en dat ze het artikel van Joel moeten lezen.

Joel?

[Janoz]

Ja, Joel Spolsky.

[BasieP]

Janoz schreef op donderdag 26 mei 2011 @ 11:25:
Ja, Joel Spolsky.

ow die kerel van stackoverflow

[Creepy]

En lees anders eerst ff de draad voordat je ..... precies RobIII heeft dat artikel waar Janoz aan refereert ook al gelinkt.

[BasieP]

Creepy schreef op donderdag 26 mei 2011 @ 12:18:
En lees anders eerst ff de draad voordat je ..... precies RobIII heeft dat artikel waar Janoz aan refereert ook al gelinkt.

mja volgende keer zal ik alle linkjes in het topic lezen, kijken wie daar aan heeft bijgedragen, en vervolgens mijn best doen om een - in een reactie genoemde - persoon te koppelen aan zo'n link..

/farfetched

[Remus]

BasieP schreef op donderdag 26 mei 2011 @ 13:18:
[...]

mja volgende keer zal ik alle linkjes in het topic lezen, kijken wie daar aan heeft bijgedragen, en vervolgens mijn best doen om een - in een reactie genoemde - persoon te koppelen aan zo'n link..

/farfetched

Als het over character encoding en Joel gaat, dan zou je naar mijn idee echt wel moeten weten over wie het gaat. Dat stuk is echt wel required reading vind ik.