De tekens die je niet kunt zien
Elk onzichtbaar teken wordt benoemd in plaats van stil verwijderd, met zijn codepunt, aantal en eerste regel: Unicode-spatiescheiders, opmaaktekens zonder breedte, bidirectionele stuurtekens, en de vijf regeleindes die geen \n of \r\n zijn.
Vaste spatie, U+00A0. Word zet hem neer op Ctrl+Shift+Spatie, kopiëren uit een getekende pagina maakt van elke er een, en tekst uit een PDF halen levert ze op overal waar de opmaakmotor een vaste tussenruimte had. Hij ziet er precies uit als een spatie en is er geen, dus split(' ') splitst er niet op en een CSV-veld met New York matcht niet meer met je database.
Spatie zonder breedte, U+200B. CMS'en en chatapps zetten hem binnen lange URL's neer om de browser een plek te geven om af te breken, en een gekopieerde waarde zakt daarna voor een vergelijking die zou moeten slagen. trim() verwijdert U+00A0 maar deze niet: U+200B is een opmaakteken en geen witruimte, dus hij overleeft elke trim, elke replace(/\s/g, '') en de meeste validatie. Een zero-width joiner, U+200D, binnen een emojireeks is het mechanisme en geen fout, dus joiners met aan weerskanten een emoji blijven staan.
Byte order mark, U+FEFF. PowerShell 5.1 schrijft er standaard een, net als ouder Kladblok en de export "CSV UTF-8" van Excel. Een CSV-parser meldt dan dat de eerste kolom ontbreekt, een shellscript faalt met "bad interpreter" omdat de kernel op byte nul geen shebang meer ziet, en JSON.parse gooit een fout op positie 0. Datzelfde codepunt elders in het bestand is een spatie zonder breedte die niet afbreekt, geen BOM.
Een tab is een tabstop, geen vier spaties
Tabs naar spaties omzetten betekent doorschuiven naar de volgende tabstop. Op breedte 4 levert de tab in a\tb drie spaties op, want de a gebruikte al een kolom. Tools die er altijd vier neerzetten zijn de reden dat tekst waar de tabs uit gehaald zijn scheef terugkomt; deze houdt de kolom bij, net als expand uit GNU coreutils. Andersom wordt alleen de inspringing vooraan omgezet, net als unexpand zonder --all: rijen spaties midden in een regel zijn meestal uitlijning, en die tabben breekt het bij elke andere tabbreedte. Zolang een van beide conversies aanstaat laten trimmen en samenvouwen de inspringing vooraan met rust, want juist die inspringing wordt omgezet en hem in dezelfde ronde weghalen zou de instelling niets te doen geven.
Veelvoorkomende problemen
- Een regel oogt nog steeds leeg, of na trimmen blijft er iets staan. Er staat een vaste spatie of een ander onzichtbaar teken in. Trimmen verwijdert alleen spaties en tabs, dus de rest wordt benoemd in plaats van te verdwijnen.
- Twee teksten zien er identiek uit maar zijn niet gelijk. Plak ze allebei hier. Noemt de een een teken zonder breedte en de ander niet, dan heb je je antwoord.
- Door elkaar gebruikte regeleindes. Regels worden weer aan elkaar gezet met het regeleinde dat elk al had, dus een gemengd bestand blijft gemengd tot je Type regeleinde op LF of CRLF zet.
Veelgestelde vragen
Wordt mijn tekst ergens geüpload?
Nee. Alleen je instellingen gaan de URL in, dus een gedeelde link geeft de configuratie terug en niet de inhoud.
Wat is het verschil tussen LF en CRLF?
LF is één newline, gebruikt door Linux, macOS en elke moderne toolchain. CRLF is een carriage return plus een newline, de conventie van Windows en HTTP. De verkeerde toont in sommige editors als één lange regel, en in andere als een los teken aan het eind van elke regel.
Breekt dit mijn emoji?
Niet als je alleen opschoont. Een zero-width joiner tussen twee pictografische tekens blijft staan. Alle witruimte weghalen is de uitzondering: die haalt elk witruimte- en opmaakteken weg, joiners inbegrepen.
Wat is dat teken dat mijn editor niet ziet?
Meestal een vaste spatie, U+00A0, geplakt uit een tekstverwerker of een webpagina. Hij ziet er precies uit als een spatie, hij is er geen, en hij breekt tekstvergelijkingen, CSV-kolommen en code. Deze pagina benoemt elk onzichtbaar teken dat hij vindt in plaats van het stil te verwijderen.