jaaroverzicht in excell

Dan heeft u zeker een andere bank dan ik heb, zowel bij ING als Rabo heb ik bij downloaden van de afschriften de keuze tussen CSV en PDF, en niet Excel. Bij die 2 banken is er dan wel geen euro-teken voor het bedrag, maar alleen een getal in de CSV file. 

Misschien een idee om de tips ergens te noteren of uit te printen zodat u het makkelijk kunt vinden. De reden voor gebruik van CSV is eerder al gegeven in het topic waar Robert vorig jaar naar linkte. Het is dus een keuze, niet een fout die gefixt moet worden.

De fout en oplossing is helemaal niet zo moeilijk. Het bestand dat gegenereerd wordt is in het formaat ‘UTF-8’ echter zonder BOM (Byte Order Mark). 

Windows (en dus Excel) vereisen echter als de karakterset UTF-8 is dat deze dan altijd voorzien is van zo'n Byte Order Mark. De eerste 3 tekens moeten een specifieke waarde hebben.

Zie ook: https://en.wikipedia.org/wiki/Byte_order_mark

Als je het gedownloade bestand opent in notepad++ en dan kiest voor converteren naar UTF-8 met BOM en daarna opent dan gaat het wel goed. Volgens mij gaat MsExcel er vanuit dat als er geen BOM aanwezig is dat het ASCII is en geen UTF-8.

Dus inderdaad iets dat een ontwikkelaar aan Mijn-Ns gemakkelijk kan oplossen door bij de export in UTF-8 deze 3 tekens toe te voegen.

Mijn eerste inschatting was ook dat Excel dit beter zou moeten doen, ik heb daar zelfs al eens een bug voor ingediend bij MS. Echter is MS van mening dat UTF-8 met BOM de enige juiste methode is omdat je anders geen onderscheid kan maken tussen ASCII en UTF-8(zonder BOM en zonder UTF-8 tekens).

Want hoewel een mens prima kan inschatten of de ASCII weergave van dit voorbeeld onjuist is kan een computer dit niet. Want en computer weet niet dat het logisch is om op dit punt een Euroteken te plaatsen en niet het de â en nog een teken.   Dus aan het bestand zelf kan je niet zien dat het UTF-8 moet zijn. Alleen een BOM toevoegen als er gebruik gemaakt is van de UTF-8 karakters zou het voor dit geval niets uit maken omdat er altijd een euro teken in het bestand staat  (als UTF-8)

Een programma dat nu nog geen UTF-8 kan lezen is echt aan vervanging toe, ik kan me niet voorstellen dat daar nog actuele versies van zijn die onderhouden worden.

Dat kan juist wel omdat de eerste 128 karakters van UTF-8 bestaan uit ASCII. Als nieuwe software nou gewoon UTF-8 ondersteunt, dan heb je helemaal geen BOM nodig. Ergo, het dient eigenlijk alleen om andere Unicode encodings te kunnen herkennen. Ik heb zo’n idee dat, terwijl meer dan 95% v.d. websites UTF-8 gebruikt, het Unicode consortium zich niet wil mengen in de discussie welke encoding de ‘de facto’ standaard is.

Als dat zo zou zijn dan zou dit probleem niet bestaan. Excel opent het bestand alsof het ASCII is en omdat ASCII voor iedere 2 bytes een een karakter gedefinieerd heeft kan een PC niet bepalen dat het om iets anders dan ASCII gaat. Dat is het grote nadeel van ASCII, de inhoud heeft geen enkel aanduiding of het echt ascii is. Door ook UTF-8 te gebruiken zonder BOM creëer je een probleem omdat de ontvangen moet gokken of het ASCII is (met mogelijk rare tekens, maar sja dat kan best de bedoeling zijn) of UTF-8 waar deze rare tekens eigenlijk multi-byte tekens blijken te zijn.

Maar we dwalen af. Als de NS voor het merendeel van haar klanten een goed werkende export wil aanbieden kunnen ze het beste er netjes UTF-8 met BOM van maken. Los van de discussie over de zin en onzin van BOM is het gewoon zo dat het zonder BOM nu fout gaat bij de Office pakketen die heel veel gebruikt worden.

Volgens mij is het punt hier niet of het de echte ASCII is met inderdaad 128 tekens of extended. Maar  dat het aangeboden bestand in UTF-8 is en niet zodanig gecodeerd dat de software van de klant hier goed mee om kan gaan en het dus verkeerd toont.  Punt blijft gewoon dat het voor de NS goed zou zijn om wel de UTF-8 + BOM te gebruiken. 

Verder maakt het voor mijn argumentatie niet uit of je uit gaat van 1 of 2 bytes. Was inderdaad een foutje van mij om uit te gaan van 2 bytes omdat ik al zo lang niet meer met ASCII gewerkt heb dat ik me niet kon voorstellen dat het inderdaad slechts 1 byte was.

Zonder BOM vraagt Excel bij importeren om handmatig een ‘bronbestand codering’ te kiezen uit een hele lijst mogelijkheden. Je moet dan maar weten dat het UTF-8 is, alhoewel dat wel de meest gebruikte is natuurlijk, en het voorbeeldvenstertje de uiteindelijke opmaak toont.

Is het wel duidelijk aangegeven in de header, dan kan je die handeling in ieder geval overslaan, net zoals bij Open/LibreOffice er bij geen header vanuit gegaan wordt dat het wel UTF-8 zal zijn.