Base64 encode and decode: retarget net10.0, fix the Tests.cs encoding defect, add files, streams, TryDecode and Base64Url - #2173
Open
vladimir-pecanac-main wants to merge 1 commit into
Conversation
… defect, add files, streams, TryDecode and Base64Url - Tests.cs was not valid UTF-8. It had no BOM and carried five raw 0xA0 bytes inside _shortString, the expected value of two of the four tests. Roslyn does not fail on this: it falls back to the compiling machine's system code page and decodes each 0xA0 as U+00A0, so the expected value of a test about encoding depended on the machine that built it. The file is now valid UTF-8 and pure ASCII, with ordinary spaces in the literal. - Assert argument order: xunit's signature is Assert.Equal(expected, actual) and all four pairs read the other way round. They passed either way; the failure message was the part that lied. - Base64Operations: rename the PascalCase AddLineBreaks parameter to addLineBreaks. - Program.cs: rename the local _base64Operations to base64Operations, convert the four string.Format calls to interpolation, drop the Console.ReadLine() window-holder, and print the Base64Url output. - Retarget both projects from net6.0 to net10.0. - Lift test packages: Microsoft.NET.Test.Sdk 18.9.0, xunit 2.9.3, xunit.runner.visualstudio 4.0.0, coverlet.collector 10.0.1. - New sample code for the article's new sections: EncodeFile/DecodeToFile over File.ReadAllBytes/File.WriteAllBytes; EncodeStream/DecodeStream over CryptoStream with ToBase64Transform and FromBase64Transform; TryDecode over Convert.TryFromBase64String; Base64UrlEncoding/Base64UrlDecoding over System.Buffers.Text.Base64Url. - New tests pin the claims the article makes: the streamed output equals Convert.ToBase64String on the same input, a file round-trips byte for byte, invalid input returns false instead of throwing, Base64Url emits no padding and swaps + and / for - and _, and a UTF-8 encode read back as UTF-16 returns mangled text silently rather than throwing. Build: 0 warnings, 0 errors. Tests: 12 passed, 0 failed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sample update for the republish of Base64 Encode and Decode in C#.
Build: 0 warnings, 0 errors. Tests: 12 passed, 0 failed (SDK 10.0.302).
One real defect
Tests/Tests/Tests.cswas not valid UTF-8. No BOM, and five raw0xA0bytes sat inside_shortString, which is the expected value of two of the four tests. Roslyn does not fail on that file: it falls back to the compiling machine's system code page and decodes each0xA0as U+00A0 NO-BREAK SPACE. So the expected value of a test about encoding depended on the machine that built it. The file is now valid UTF-8 and pure ASCII, with ordinary spaces in the literal.Test quality
xunit's signature is
Assert.Equal(expected, actual)and all four argument pairs read the other way round. They passed either way; the failure message was the part that lied.Tidy
Base64Operations: the PascalCaseAddLineBreaksparameter becomesaddLineBreaks.Program.cs: the local_base64Operationsloses its field-style underscore, the fourstring.Formatcalls become interpolation, and theConsole.ReadLine()window-holder goes.Retarget
Both projects move from
net6.0tonet10.0. Test packages lifted to Microsoft.NET.Test.Sdk 18.9.0, xunit 2.9.3, xunit.runner.visualstudio 4.0.0, coverlet.collector 10.0.1. The retarget is a prerequisite rather than a tidy-up:System.Buffers.Text.Base64Urlis .NET 9+.New sample code
The article gains a file-and-stream section and a Base64Url section, so
Base64Operationsgains the code behind them:EncodeFile/DecodeToFileoverFile.ReadAllBytes/File.WriteAllBytes.EncodeStream/DecodeStreamoverCryptoStreamwithToBase64TransformandFromBase64Transform.TryDecodeoverConvert.TryFromBase64String.Base64UrlEncoding/Base64UrlDecodingoverSystem.Buffers.Text.Base64Url.Eight new tests pin the claims the article makes: the streamed output equals
Convert.ToBase64Stringon the same input, a file round-trips byte for byte, invalid input returnsfalseinstead of throwing,Base64Urlemits no padding and swaps+and/for-and_, and a UTF-8 encode read back as UTF-16 returns mangled text silently rather than throwing.