[ASP]Vreemde Byte in de eend

[mulder]

Naar een webapplicatie word door een Java app een binary post gedaan van een xml bericht, hier is niks aan te veranderen, deze word met BinaryRead uitgelezen in VBscript. Ipv een ë verschijnt nu een vierkantje; onder een hexloep blijken er 2 bytes in gebruik C2 89. Die 89 is de ë die ik zoek, maar wat is die C2 en hoe krijg ik die weg?

[OZ-Gump]

Is de encoding die gebruikt wordt binnen het XML bericht en 't VBscript wel hetzelfde? Lijkt er niet op namelijk...

[Sybr_E-N]

Heb je niet te maken met een verschil in character encoding. Dus dat vbs standaard een andere encoding gebruikt vergeleken met de Java applicatie? Ik denk dat als je dezelfde encoding gaat toepassen in vbs, aangezien die Java appicatie niet kan wijzigen, je wel het gewenste resultaat krijgt.

[mulder]

Als ik de data binnen krijg, sla ik het binair op, en dan is het karakter dus al zo gecodeerd. Ik kan allerlei encodings boven de xml gaan zetten, maar dan word het karakter nog steeds niet goed getoond. Volgens mij moet ik voordat het een xmldocument word zorgen dat de codering goed is.

[JochemK]

Volgens mij moet je gebruik maken van UTF8 encoding / decoding. Ik weet dat het in php zo werkt, en neem daarom aan dat het in Java ook wel zo zal gaan.

[mulder]

Het xml bericht/bestand is idd utf-8, maar dan is het al te laat zeg maar. Door het met andere condering op te slaan verandert het karakter niet.

[OZ-Gump]

Als je het karakter inleest om deze vervolgens naar de juiste te zetten, wat gebeurt er dan?
Meer info.....

[mulder]

Ik sla de stream op, ik weet in principe niet wanneer er een vreemd karakter voorkomt. Ik heb de codepage en charset van het ontvangende script ook al naar utf-8 gezet, maar het blijft 'vierkantjes' tonen/opslaan.

[azuidhof]

@TS: ik denk dat je probleem opgelost kan worden door de encoding van je webapp te veranderen van UTF-8 naar ISO-8859-1. Heb hier zelf onlangs ook nog behoorlijk mee lopen stoeien, uiteindelijk bleek dit het probleem op te lossen (tenminste een van mijn problemen, want als je hier eenmaal serieus mee aan de slag wilt komt er steeds een nieuw probleem opduiken . Zie ook http://arjansworld.blogsp...4/debugging-xml-code.html).

[MSalters]

Als je een binary read doet, dan heb je geen ë. Dat is een karakter, geen byte. De ë komt inderdaad doordat je met een encoding de transformatie byte-sequence->karakter-sequence doet. Je opmerking

Als ik de data binnen krijg, sla ik het binair op, en dan is het karakter dus al zo gecodeerd.

is dus onzinnig. Je hebt nog geen karakter

De correcte oplossing is inderdaad je XML header binair parsen, daar de encoding uit halen. Dat is mogelijk zonder dat je de encoding weet, omdat de header alleen maar de ASCII-subset gebruik, en geen NUL karakter bevat. Elke 0 byte is dus een onderdeel van een groter karakter.

Als je die encoding hebt, dan kun je vervolgens daarmee het hele bericht vertalen van bytes naar (Unicode) karakters.

Je weet blijkbaar al dat het UTF-8 is. In dat geval is het vrij duidelijk: UTF-8 heeft geen 1-byte karakters >= 80h. 89h is dus geen UTF-8 karakter, en dus ook geen ë. Ik weet niet waarom je eerste post dat suggereert. C2,89 is een valide UTF-8 karakter. Het formaat is 110yyyyy 10xxxxxx, unicode waarde is dan yyyyyxxxxxx, in dit geval is yyyyy=00010, xxxxxx=001001 dus het is karakter 00000000 10001001 ==U+0089 en dat is wel ë

Table 3-6. Well-Formed UTF-8 Byte Sequences

Code Points	1st Byte	2nd Byte	3rd Byte	4th Byte
U+0000..U+007F	00..7F
U+0080..U+07FF	C2..DF	80..BF
U+0800..U+0FFF	E0	A0..BF	80..BF
U+1000..U+CFFF	E1..EC	80..BF	80..BF
U+D000..U+D7FF	ED	80..9F	80..BF
U+E000..U+FFFF	EE..EF	80..BF	80..BF
U+10000..U+3FFFF	F0	90..BF	80..BF	80..BF
U+40000..U+FFFFF	F1..F3	80..BF	80..BF	80..BF
U+100000..U+10FFFF	F4	80..8F	80..BF	80..BF

[ Voor 35% gewijzigd door MSalters op 05-04-2005 14:11 . Reden: tabelletje ]

[mulder]

Ik snap er dus geen reet van, de binaire string, de byte array is dus in UTF-8 als ik em krijg gepost. De codering vermeld in het xml bericht is UTF-8. Als ik dit bestand opslaat zou de cedring dan toch goed moeten wezen? Kennelijk niet, ik snap nu niet wanneer ik wat moet doen? Ik leid geloof ik ook een beetje aan project-moeheid, ik zie/snap het allemaal niet meer

[MSalters]

Hoe sla je het bestand op? Als je gewoon de bytes opslaat (nog steeds allemaal binair) dan krijg je gewoon een UTF-8 bestand op disk. Dat is wat ongewoon, en een domme viewer die dat niet snapt zal dan gekke tekens laten zien, maar IE's xml viewer bijvoorbeeld struikelt daar niet over.

[mulder]

Ik gebruik een ado stream om het binair bestand op te slaan, maar IE lust het ook niet, nog steeds niet de goede karakters.

[vinnux]

Zoals reeds gezegd onstaat dat vierkantje doordat de charset die je gebruikt om te displayen niet gelijk is aan de originele charset toen het xml bericht gemaakt werd.
Je moet nagaan wat de charset was toen je het xml bericht maakte, via welke charset hij geconverteerd is naar binaire vorm en via welke charset hij terugvertaald is naar tekstvorm.

Deze fout komt helaas in heel veel systemen voor.

Java zal wel een xml in Unicode aanleveren en je zal het wel displayen in UTF-8, hierdoor veranderen vreemde tekens in vierkantjes. Download TextPad bijvoorbeeld eens en speel es met de charsets ...

[ Voor 8% gewijzigd door vinnux op 05-04-2005 14:51 ]

[MSalters]

Don Facundo schreef op dinsdag 05 april 2005 @ 14:39:
Ik gebruik een ado stream om het binair bestand op te slaan, maar IE lust het ook niet, nog steeds niet de goede karakters.

ADO streams zijn uit m'n hoofd karakterstreams, terwijl we net hadden vastgesteld dat je geen karakters hebt.

[MSalters]

vgouw schreef op dinsdag 05 april 2005 @ 14:50:
Java zal wel een xml in Unicode aanleveren en je zal het wel displayen in UTF-8, hierdoor veranderen vreemde tekens in vierkantjes. Download TextPad bijvoorbeeld eens en speel es met de charsets ...

Helaas, klok en klepel. Unicode is geen encoding, maar een code point assignment. Daarin staat bijvoorbeeld dat het karakter U+00000089 een ë is. De volgende vraag is hoe je U+00000089 overstuurt. De simpele methode is 4 bytes, namelijk 0x00000089. Dat is wel bekend als UTF-32 encoding. Voor tekst die voornamelijk ASCII is, is het effectiever om een UTF-8 encoding te gebruiken, en die is terug te vinden in de tabel die ik eerder postte.

En voor alle duidelijkheid: in Unicode zijn er geen vrijwel geen "vreemde tekens" meer.

[Gert]

Java is intern UTF-16 maar misschien dat het afhankelijk is van de standaard encoding van het systeem waarmee het binair wordt weggeschreven.

[mulder]

MSalters schreef op dinsdag 05 april 2005 @ 15:44:
[...]

ADO streams zijn uit m'n hoofd karakterstreams, terwijl we net hadden vastgesteld dat je geen karakters hebt.

Is het uberhaupt wel te doen dan in VBScript vraag ik me af... Volgens mij krijg ik van de Response.BinaryRead een SafeArray terug, en moet ik een recht toe recht aan ByteArray hebben om deze te converteren?

Pffffff

[foske]

Ik had een soortgelijk probleem, ik heb het toen eenvoudig opgelost door de HTML code neer te zetten aan de kant waar de XML feed wordt gegeven. (In jouw geval dus bij de JAVA app, of eventueel in de database). Bijvoorbeeld: &euml ; voor ë

[MSalters]

Don Facundo schreef op dinsdag 05 april 2005 @ 16:39:
[...]
Is het uberhaupt wel te doen dan in VBScript vraag ik me af... Volgens mij krijg ik van de Response.BinaryRead een SafeArray terug, en moet ik een recht toe recht aan ByteArray hebben om deze te converteren?

Altijd mogelijk, soms moeilijk. De worst-case is dat je zelf de tabel implementeert die ik daarboven heb aangehaald.

[mulder]

Nou in ieder geval bedankt voor de info, gaan maar eens kijken wat er hier mee doen, moet me al in 10.000 duizend bochten wringen om deze koppeling te realiseren... derde partijen zijn nooit leuk!