|
|
Publisert på 31.07.2023 18:36:01
|
|
|
|
En solrik morgen satt jeg foran laptopen min og omstrukturerte litt C#-kode. Alt går bra, og det blir en produktiv dag. Så la jeg til for mange likhetstegn i den konstante strengen, og ting eksploderte. Produktiviteten er borte. Søndagens rolige gjenoppbygging er bak oss. Selv solen bestemte seg for å gjemme seg bak skyene.
Etter å ha brukt 30 til 40 minutter på å finne ut hva jeg gjorde galt, innså jeg at det ikke var meg. Det er Microsoft. Tilsynelatende kom jeg over en gammel feil i Base64-dekodingsfunksjonen.Convert.FromBase64StringDenne feilen har definitivt eksistert siden .NET 1.1 ble introdusert i 2003. Jøss! Det er gammelt. Og det er ikke særlig vanskelig å reprodusere. Bra jobb:
Teknisk sett er dette ulovlig Base64. Den juridiske versjonen er "abc=". Merk at bare ett fylltegn =. Base64-koding representerer hver 6. bits binær input i ett ASCII-tegn. Dette betyr at hver 4. tegn i en Base64-kodet streng representerer 3 byte. Når de kodede dataene ikke er et multiplum av 3 byte, legger Base64-koderen til et fylltegn for å gjøre Base64 til et multiplum av 4 tegn. Dette vil generere en Base64-streng som er korrekt utfylt med "abc=". Å legge til en annen = vil ugyldiggjøre den.
Base64 "abc=" dekodes som to byte [105, 183]. Det stemmer. Å legge til et ekstra utfyllingstegn på slutten bør egentlig ikke endre den kodede verdien. Det er som å legge til et mellomrom på slutten av en setning. Ja, det er der, men det endrer ikke meningen med setningen. Men .NET mener ikke det. "abc==" dekodes som en byte [109]. Ikke bare ble det kortere, noe som var rart fordi vi gjorde innføringen lengre. Det har også blitt annerledes. Den første byten går fra 105 til 109. Og det var heller ikke noe unntak. Legg til en til = og du får et unntak. Forbausende!
Kode:
Ytelse:
'abc=' -> [105, 183]
'abc==' -> [109]
Først kunne jeg ikke tro det og begynte å undersøke. Jeg googlet en stund og fant ikke mye. Så postet jeg på StackOverflow og hadde heller ikke mye hell. Da jeg først fant ut hva som foregikk, måtte jeg til og med svare på mine egne spørsmål. Etter å ha lett på GitHub en stund, kom jeg over en løsning laget i .NET Core i juli 2018. Så den nyeste .NET Core-versjonen håndterer dette problemet korrekt og gir et unntak:
Ubehandlet unntak: System.FormatException: Inndataen er ikke en gyldig Base-64-streng da den inneholder et ikke-base 64-tegn, mer enn to utfyllingstegn, eller et ulovlig tegn blant Fyller ut karakterer.
på System.Convert.FromBase64CharPtr(Char* inputPtr, Int32 inputLength)
på System.Convert.FromBase64String(String s)
på Program.DecodeAndPrint (Streng base64) i ./base64/Program.cs:linje 13
på Program.Main() i ./base64/Program.cs:linje 8
Convert.FromBase64() har en subtil feil der det andre ulovlig polstrede tegnet på slutten av strengen får dekodingen til å "lykkes" ved å fjerne nest siste tegn.
Vi er på . Denne feilen ble utilsiktet rettet da API-et ble optimalisert i NetCore 2.1. Legg til tester for å logge feil og sørg for at vi ikke går bakover.
Løsningen i .NET 4.7.2 er å fylle på den feilfylte strengen med noe som dette:
Original:Innloggingen med hyperkoblingen er synlig.
|
Foregående:Azure DevOps (viii) Kompilerer ASP.NET MVC-prosjekter ved bruk av Pipelines BuildNeste:En ny timer i .NET 6, PeriodicTimer, brukes
|
Vert|
Publisert på 31.07.2023 18:39:50
|
