Begin met de oorspronkelijke bytes
De coderingsinspecteur en UTF-8-converter, leest een lokaal bestand voordat een ander programma het decodeert. Kies de oorspronkelijke export in plaats van verminkte tekst uit een editor te kopiëren. Een bestand kan geldige UTF-8-bytes bevatten zonder dat dit bewijst dat UTF-8 de bedoelde codering was.
Een klein, reproduceerbaar voorbeeld
Selecteer Een Windows-1252-voorbeeld laden. Het kunstmatige bestand bevat precies acht bytes: 43 61 66 E9 20 80 0D 0A. Windows-1252 wordt expliciet geselecteerd. De verwachte Unicode-tekst is Café €\r\n: de laatste notatie staat voor een echte CR gevolgd door LF, niet voor vier letterlijke tekens.
De Unicode-codepunten zijn U+0043 U+0061 U+0066 U+00E9 U+0020 U+20AC U+000D U+000A. Strikte UTF-8-decodering van de oorspronkelijke bytes mislukt: E9 wordt niet gevolgd door de vereiste vervolgbytes. Dit is een reden om de broncodering na te gaan, geen bewijs dat elk dergelijk bestand Windows-1252 gebruikt.
- Laat Windows-1252 geselecteerd en klik op Conversievoorbeeld bekijken.
- Controleer of het voorbeeld Café € toont, met één CRLF en een afsluitend regeleinde in de details.
- Laat de BOM voor het uitvoerbestand uitgevinkt, tenzij de ontvangende toepassing die expliciet vereist.
- Download het UTF-8-bestand. De exacte elf bytes zijn
43 61 66 C3 A9 20 E2 82 AC 0D 0A. - Vink de BOM-optie aan en bekijk het voorbeeld opnieuw: de uitvoer heeft veertien bytes en begint met
EF BB BF, vóór die elf bytes.
Waarom “ANSI” niet genoeg informatie geeft
Het label “ANSI” in een toepassing is dubbelzinnig. Windows-1252 koppelt byte 80 aan het euroteken; ISO-8859-1 koppelt die aan U+0080, een C1-besturingsteken dat deze tool weigert. De bytes 81, 8D, 8F, 90 en 9D zijn niet gedefinieerd in de strikte Windows-1252-mapping van deze tool en stoppen de conversie. Vraag de maker van de export naar de daadwerkelijke codering, in plaats van opties te proberen totdat de tekst aannemelijk lijkt.
BOM, UTF-16 en beschadigde eindsequenties
FF FE 41 00 0D 00 0A 00 is een UTF-16LE-voorbeeld met een BOM. Dit wordt 41 0D 0A in UTF-8 zonder BOM: A plus CRLF. Zonder BOM moet je UTF-16 expliciet selecteren. Een ongepaarde laatste byte of een ongepaard surrogaat stopt de conversie, ook buiten het zichtbare voorbeeld. Een UTF-32-BOM wordt herkend maar geweigerd.
Wat conversie behoudt en niet kan herstellen
Spaties, tabs, gemengde CRLF/LF/CR-regeleinden, de aanwezigheid of afwezigheid van een afsluitend regeleinde en vooraf samengestelde Unicode-tekens versus combinaties van tekens blijven behouden. Alleen de eerste BOM van de bron wordt verwijderd; je kiest zelf of de uitvoer een BOM krijgt. Staat U+FFFD al in de bron, dan blijft het staan. Het converteren van al beschadigde tekst als “Café” herstelt de oorspronkelijke bytes niet.
De limiet is 5 MiB (5.242.880 bytes); het voorbeeld toont maximaal 16.000 UTF-16-code-eenheden, terwijl validatie en export het hele bestand omvatten. Bekende binaire bestandskenmerken en NUL/C0/C1-besturingstekens anders dan tab, CR en LF worden geweigerd. Deze voorzichtige beveiliging kan ongebruikelijke maar geldige tekst weigeren. Downloads gebruiken .utf8.txt en platte tekst als inhoud. Je bronbestand wordt niet overschreven.
Converteer bij een CSV-werkproces eerst de codering en gebruik daarna CSV naar JSON, om de structuur te wijzigen. De coderingstool zelf verwerkt de CSV-structuur niet en wijzigt geen scheidingstekens. De verwerking gebruikt browsergeheugen, zonder netwerkverzoeken of opslag door de tool; normale websiteverzoeken laden nog steeds pagina’s en bestanden. Ga terug naar de coderingsinspecteur, om het exacte voorbeeld te proberen.