Export in Excel: UTF8 wordt niet herkend

[kdepuydt]

Hier zou café moeten staan... WNT	caf�	CAF�	znw.(o.,m.)	Koffiehuis, inrichting voor het gebruiken van allerlei dranken (en spijzen).
WNT	caf� complet	Caf�-complet	[behandeld onder CAF�]
WNT	caf� concert	Caf�-concert	[behandeld onder CAF�]

[jan-niestadt]

Leuke lectuur: CSV: An Encoding Nightmare (TL;DR: CSV heeft geen vaste encoding, en Excel gaat er niet goed mee om)

Het meest pragmatische is waarschijnlijk om CSV export in Windows-encoding (Latin-1/iso-8859-1/Windows-1252) te doen. Ik weet niet of dat op Mac Excel ook goed gaat, maar dat is toch een minderheid.

[jan-niestadt]

Zo te zien stuurde het backend altijd al de juiste encoding (ISO-8859-1). Er was wel iets raars met een extra encoding-regel, heb ik gefixt, maar die veroorzaakte dit probleem niet.

Het lijkt er dus op dat het frontend niet gewoon de backend-URL opent als je een export doet, maar zelf de gegevens van het backend ophaalt en als download aan de gebruiker aanbiedt, alleen met een andere encoding-header dan de backend stuurt? Lijkt me iets voor Pieter om naar te kijken.

[kdepuydt]

Pieter is met vakantie. Voor mij is dit geen reden om niet een update te doen. Eens?

[pmasereeuw]

@jan-niestadt ik heb hier hulp bij nodig, want het zou een javascriptprobleem kunnen zijn, al denk ik dat niet, want ik zie niet dat er met een encoding wordt geknutseld.

De export wordt gedaan door een stukje code dat ik op internet heb gevonden - zie de file js/download.js.

De aanroepende functie staat in js/gtb.js:

function exportResult(url, clientFilename, mimetype) {
    $.ajax({
        url: url,
        dataType: "text",
        //success: download.bind(true, mimetype, clientFilename)
        success: function (data, textStatus, jqXHR) {
            download(data, clientFilename, mimetype);
        }
    });
}

En deze functie wordt uit XSLT aangeroepen in gtb.xslt, template ivdnt:export-result.

Voorbeeld van parameters (met een tijdelijke <xsl:message> naar het console gestuurd):

url-for-content="http://localhost/redirect.php?actie=results&conc=true&xmlerror=true&lemmodern=koe&domein=0&conc=true&wdb=onw%2Cvmnw%2Cmnw%2Cwnt%2Cwft&sensitive=false&uitvoer=csv&start=1&aantal=250" client-filename="gtb-export.csv" mimetype="text/csv"

[jan-niestadt]

Dit scriptje doet dus een AJAX call naar de backend, vangt de response op en biedt die dan als download aan. Maar de backend-URL die je opvraagt biedt al een download aan, dus het lijkt me dat dit script niet noodzakelijk is. We kunnen in plaats daarvan gewoon de backend-URL openen als je om een export vraagt, of niet? Zo werkte het vroeger altijd volgens mij. (met jouw query dus bijv. deze URL)

Het kan zijn dat we de backend een klein beetje moeten aanpassen om een nette default-filename mee te sturen, maar dat is zo gebeurd.

[JessedeDoes]

De pagina die Jan noemt suggereert er dan maar utf16 van te maken:

As of this writing, there exists a single usable CSV format that Microsoft Excel can both read and write safely across platforms. Tab delimited UTF-16LE with leading Byte Order Mark.

Is dat een workaround?

[pmasereeuw]

Hallo Jan, Je voorstel om de backend de download (van XML en CSV en niet van HTML?) te laten regelen klinkt mij zinnig. Ik denk dat de huidige opzet ontstaan is door de eis van eertijds dat de backend niet mocht worden aangepast.

Als ik bij de aanpassing nodig of gewenst ben, dan het liefst na mijn vakantie.

Qua UTF-16: dat is iets wat vermoedelijk nu al getest kan worden, want volgens mij stuurt het stukje Javascript gewoon de data door zonder interpretatie.

Ik weet wel dat er bij CSV tegenwoordig een optie is om voorafgaand aan de xxx-gescheiden waardes een paar regeltjes met stuurdata mee te kunnen sturen. Ik weet niet of Excel daar mee kan omgaan en ik weet ook niet of je daar iets van encoding kwijt kunt. Als UTF-16 altijd werkt, lijkt me dat het simpelst, maar ja, ff proberen.

Overigens: er zijn ook libraries (Apache POI) die direct Excelfiles uitspugen. Die zijn ook niet heel moeilijk. Maar het mooie van CSV is natuurlijk dat het agnostisch is m.b.t. het tool dat je gebruikt.

[jan-niestadt]

Ik weet niet of UTF-16 noodzakelijk is, en andere scripts verwachten misschien juist Windows-1252 / UTF-8 of iets dat daarop lijkt (UTF-16 is natuurlijk een beetje een buitenbeentje, veel scripts zullen daarover struikelen denk ik).

Ik ga wel even kijken hoe de download werkt en of ik dat eenvoudig kan aanpassen. Evt. kan het ook in een latere update lijkt me.

[jan-niestadt]

Ik heb nu gewoon de backend-URL geopend in een nieuw window/tab (sluit direct weer omdat het een download is). Heb export=true toegevoegd zodat er een downloadlink gegenereerd wordt met een nette filename. Heb de door het backend voorgestelde filename aangepast (gtb-export.FORMAT ipv resultaten.FORMAT).

[KCMertens]

Het is handig even te verifiëren dat het openen van een nieuw tabje geen problemen oplevert bij gebruikers met een adblocker.

[kdepuydt]

Zouden die dan ook geen probleem hebben de weergave van een artikel, dat ook in een separaat tabje komt?

[kdepuydt]

Hoi, exporteren van karakters gaat goed. Voor de gebruiker gebeurt er wel iets onbegrijpelijks. Er wordt een tabblad geactiveerd, en er verschijn een venstertje, maar beide zijn niet te lezen want flitsen voorbij. Je krijgt wel je csv met de goede karaktercodering. Is wat omschrijf het normale gedrag?

[KCMertens]

Zouden die dan ook geen probleem hebben de weergave van een artikel, dat ook in een separaat tabje komt?

Het is een beetje inexacte wetenschap wanneer het wel of niet geblokkeerd wordt, heb het in het verleden alleen op een paar verschillende manieren zien gebeuren toen ik het het exporteren van resultaten in autosearch aan het bouwen was.

[jan-niestadt]

Als er iets geblokkeerd wordt, krijgen gebruikers als het goed is zo'n waarschuwingbalk te zien waarmee ze het alsnog kunnen toestaan.

Het voorbijflitsen van het tabje is normaal gedrag wat volgens mij vrij gangbaar is op diverse sites. Ik weet niet of er een manier omheen is die niet de "Let op, u verlaat de pagina" alert activeert. Is het een groot probleem denk je?

[kdepuydt]

niet erg, denk ik.