• Advertisement
Sign in to follow this  

I/O File new line problem

This topic is 1833 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working on a program to (en-)cipher files. With some experiments concerning I/O on Windows and Linux (later on Mac OS) I recognized a difference in file length. I heard that Windows uses 2 Bytes "\r\n" for new line while UNIX systems uses just 1 Byte "\n". I fear that my file (en-)ciphering program wouldn't be platform independent. Is there a way to avoid this?

 

Main problem: Person A uses Windows and cipher a file which he sends this file to Person B who uses UNIX.

 

lg

Share this post


Link to post
Share on other sites
Advertisement

It depends on the text file encoding. Different OS will use different encodings. Many tools can detect the encoding automatically (e.g. ultraedit), e.g. by checking for special chars or combinations of it.

 

The easiest way is to request/process only files in a certain format (utf-8 etc.).

Share this post


Link to post
Share on other sites

Does UTF-8 really determine this? Doesn't an encoding such as UTF-8 just specify how a character is laid out in memory? I guess a UTF-8 file can still contain one- or two-character newlines.

 

I might be wrong though...

Share this post


Link to post
Share on other sites

It depends on the encoding, ok utf-8 was a bad example smile.png

You could try to use an encoding, like unicode 16, which support (hopefully) all neccessary newline-variations as single (16bit) chars.

Edited by Ashaman73

Share this post


Link to post
Share on other sites
Did you try opening your files in binary mode instead of text mode?

Share this post


Link to post
Share on other sites

Well, the first thing to note is that your program isn't introducing a new problem. If the original file was sent from a Unix to Windows machine, the user would still have to deal with it. Many text editors will handle this gracefully. In addition, savvy Unix users will be aware of tools such as "dos2unix" and "unix2dos" if the program they want to read the file in is clueless.

 

Now, you know that solving this problem is optional. The simplest approach is to read/write file in binary mode, which should result in an identical file.

 

Of course, you might want to save the user the hassle I mentioned earlier. However, by choosing to do this you also have to deal with a much harder problem: determining if the file is a text file to be translated or a binary file that must be left "as is", or a text file that requires newline encoding. One way is to ask the user (or force them to provide the information e.g. a command line switch), which is great if your target audience is technical.

Share this post


Link to post
Share on other sites
Did you try opening your files in binary mode instead of text mode?

 
It works. I opened a file in binary mode:
 

std::ofstream os("test.txt", std::ios::binary);
os << "\n";

and except for "\r\n" it wrote "\n" on Windows. This means I have to read and write in binary mode and the ciphered file can be read on any OS. Now I don't have to worry about this problem anymore. I forgot that std::ios::in/out opens files in text mode.

 

PS: My program is in it's final stage. You enter an integer key and the algorithm ciphers it. Only the correct key can decipher it. The only question is what shall happen if you need too many tries for entering the correct key.

Share this post


Link to post
Share on other sites
PS: My program is in it's final stage. You enter an integer key and the algorithm ciphers it. Only the correct key can decipher it. The only question is what shall happen if you need too many tries for entering the correct key.

 

Fill the screen with penguins.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement