the &0xFF is needed in the Java version of the code because java bytes are signed, but this is not needed here (char is unsigned).
Also, there is an implicit cast from char to int.
Finally, you shouldn't name them "byteArray" since they're char arrays 😉

I believe the size should be 256. You may encounter all values from 0 to 255 inclusive, so that's 256 different values.

utf8 cannot be null

The Java version of the code applies the filtering on the UTF8 bytes because it needs to return an UTF8BytesString (so it saves one encoding step).
Here you're returning a string, so encoding the string is just adding extra overhead. You should instead convert the string to a char array:

var str = sql.ToCharArray();

Then apply the same algorithm on the char array. Later we can even add extra logic to have that array allocated lazily

Hey @kevingosse thank you for the comments! In my lasted commit you can see the changes I've applied:
c6fc4e4

One thing to note is that for the IsSplitter function I end up adding a logic to return false if converting the char to bye/int leads to a value larger than the index of the array it is supposed to for the character in.

When I used to do the encoding to byte the Kanji characters there were converted to 3 different bytes [231, 189, 191] representing it, but now that we manipulate the Kanji character directly when converted to byte/int the result is [32639] and that would lead to a IndexOutOfRangeException for which I simply added the if to prevent using this large index numbers, please let me know your thoughts on that.

Yeah that sounds correct 👍

NIT: end == 0 means that the string is empty. We should probably check this at the very beginning of the method and exit early when that happens

Earlier I added the logic to not even call the method if the string was empty on the ObfuscatorTraceProcessor.cs file instead: https://github.com/DataDog/dd-trace-dotnet/pull/2498/files#diff-35a4636a4a751afda8b9ae23ab84ccc0f42591704b2ed3d70a6289ad902e42a3R50-R53

Is that good or should I moved it to the method instead as we expect most strings to not be empty anyways?

Indeed, it gives the same result. Checking this here seem better as you don't ask the caller to do it.

Indeed, it gives the same result. Checking this here seem better as you don't ask the caller to do it.

nitpicking again - (and clearly don't mind me)
But as it's not a class, but a function I'd change that to a verb. So ObfuscateSql or ObfuscateSqlResource would be better IMO

TIL, yeah that does make, sense, made the new commits, will wait for the checks to run so I can merge.