I am not sure if we can simply remove it from the string. That means, when we save the file, the null character will be gone right?

Take a look at last comment in this thread: https://www.c-sharpcorner.com/forums/how-to-write-null-character-in-textbox

I think that the problem is the bug which is located on RichEditBox. It should display the file until encountering the EOF. Let me explain with details:

text = reader.ReadToEnd();

That implementation of reading the file is true and works as intended. It reads and passes the "\0" character, not stops there. But the built-in tool on the Visual Studio that shows the content what the variable has encounters the same error doesn't show the file content after the "\0" character. FileInput and string are not the same thing. The built-in tool and the RichEditBox also behave to file like a just the string. Let me explain with photos:

Before the changes

After the changes

And good news, our implementation works correctly without any problem. It doesn't change the string "\0", just the character one. Also you can try to change RichEditBox thing to display characters correctly but it's just up to you.

Yes, I know it works from reading to representation. I am more concerned about file saving. Did you try open the file and save it? Then take a look if \0 is missing in the output file?

Yes, I know it works from reading to representation. I am more concerned about file saving. Did you try open the file and save it? Then take a look if \0 is missing in the output file?

It is gone from the file but I don't think that is the problem. Also it can surpass the errors that may happen in the future.

And one last note: If you don't want to delete \0, you should look at the behaviour of the RichEditBox. If you can change that thing with their superior, it will definitely more accurate solution than this implementation but I can't see any harm with that.

Yes, I know it works from reading to representation. I am more concerned about file saving. Did you try open the file and save it? Then take a look if \0 is missing in the output file?

It is gone from the file but I don't think that is the problem. Also it can surpass the errors that may happen in the future.

And one last note: If you don't want to delete \0, you should look at the behaviour of the RichEditBox. If you can change that thing with their superior, it will definitely more accurate solution than this implementation but I can't see any harm with that.

No, actually it is a problem, because if the file is intended to have "\0" and it is accepted by another program, then it will cause unwanted behavior. Let me think about it and see what we can do here.

At least, we can(should) let the user know if the file opening has a null character and let the user decide what to do (ignore or remove it).

Ok then I'll close that pull req and try to apply the solution that you're referring to.