C file operation font in arabic - c

I've written a C program consisting of file operations (a .txt file).
When I open the output file in notepad, I don't read the contents in Latin script (or in simpler words - letters of the English alphabet), but some other script.
However when I open the file in C (using fopen etc.), I get the output in English (Latin script) again.
How do I view the output in English (Latin script) in notepad??

Sounds like the classic "Bush hid the facts" problem.
In the Notepad file open dialog, you can see a drop-down that allows specifying an encoding. Since the file does not start with an unicode BOM, Notepad has to guess the encoding of the file (it does so as soon as you highlight the file in the list). And sometimes, it guesses wrong (but that's visible in the drop-down, and you can change it before clicking OK).

Related

I have a text file which begins with LZ2TreeFile. How do I open and read it correctly in Linux or Windows?

If I try to open with notepad++ or Kwrite, it displays some characters properly but mostly it is garbled characters. I tried several encoding options apart from utf-8 and it doesn't work. Any ideas?

Is it possible to prevent adding BOM to output UTF-8 file? (Visual Studio 2005)

I need some help.
I'm writing a program that opens 2 source files in UTF-8 encoding without BOM. The first contains English text and some other information, including ID. The second contains only string ID and translation. The program changes every string from the first file by replacing English chars to Russian translation from the second one and writes these strings to output file. Everything seems to be ok, but there is BOM appears in destination file. And i want to create file without BOM, like source.
I open files with fopen function in text mode with ccs=UTF-8
read string with fgetws function to wchar_t buffer
and write with fputws function to output file
Don't use text mode, don't use the MS ccs= extension to fopen, and don't use fputws. Instead use fopen in binary mode and write the correct UTF-8 yourself.

Same file: different when opened with notepad vs. wordpad

Was accessing a file in a code with both C# and C++. When file is opened in notepad it looks like this (one integer at left and the rest of numbers are double):
But the same file when opened with WordPad looks like this (one integer next to each double):
Why do they look different?
It has to do with the way that newlines are encoded in your file. Windows recognizes a newline as consisting of two characters (\r\n) whereas some other operating systems, namely Unix-based ones, use only \n or \r. WordPad is smart enough to recognize both newline types, but Notepad is not.
Because notepad and Wordpad use different ways to read out files, apperantly this file is written in a way that both read it differently...
Because Notepad and WorkPad understand \r\n differently
Notepad and WordPad treat "new line" differently - one accepts just \n, another requires \r\n to recognize "new line" (and some would be ok with \n\r).
Similar goes for many other editors. I.e. if your try to open the file in Visual Studio it is likely to ask something like "Do you want to convert Unix new lines to Windows new lines".
If you are writing file with C# use WriteLine rather than manually adding \n or at least use Envirnment.NewLine to write "new line" to stream.
Similarly in C++ you can write "\r\n" instead of just "\n" if you must open file in Notepad or other editor that requires such sequence (most editors/viewers would be ok with either).

JPG file won't open after editing

When I open a ".jpg" picture file with notepad and edit it, after saving the file doesn't open. As an error, it says that file is damaged. And even when I delete some symbol and rewrite it, in the same place, in the same way, and save changes after that, it still won't open. Why?
JPG is a binary format, by that we mean that it represents a series of numbers. Notepad is for editing text files, in a text file those numbers refer to letters (using the ASCII table). Editing a binary file in a text editor is likely to cause corruption as the text editor may not be able to represent all of the file properly (it's not actually text) and may modify it to force it to be text before storing it.
In particular, many numbers are used as control codes (eg. the new line character). As JPG is a binary format those control codes have no meaning and will be dispersed throughout the file creating more havok than just displaying gobbledegook.

Understanding compile errors due to copying code from a doc file and not a txt file

SITUATION:
My instructor for my micro-controller class refuses to save sample code to a text file and instead saves it to a word document file instead. When I open up the doc file and copy/paste the code into my IDE "CodeWarrior" it causes errors upon compile time.
I am having to rewrite all the code into a text editor and then copy/paste it into my IDE.
MY UNDERSTANDING:
I was told to always save code as a text file because when you save code as a word document file it will bring in unwanted characters when your copy/pasting the code into your IDE for compiling.
MY QUESTIONS TO YOU:
1.)
Can someone explain this dilemma to me so I can understand it better? I would like to present a better case next time when I receive errors and to also know more about what is happening.
2.)
Is it possible to write a script that will show me all the characters that are being copied and pasted into a file when the code is coming from a word document vs. a text file? In otherwords is there a program that will allow me to see what is going on between copying/pasting code from a word doc file versus a txt file?
Saving source code as a Word document is just silly. If your instructor is insisting on this, chances are no matter how well-reasoned and thorough your argument, they're not going to listen. They're beyond help.
However, to answer your questions: 1) It depends on what you're pasting the thing into. Programs that copy onto the clipboard usually make the data available in several different formats, ranging from their own internal format to plain ASCII text, to maximize compatibility so that the data can be pasted into pretty much any target program. Most text editors will only accept the plan-text version, in which case no extra characters should be transferred. However if your text editor supports RTF or HTML, this may not be true. I'm not sure what CodeWarrior supports but it is certainly possible.
A workaround if this is the case: First paste into a PURE text editor like Notepad. Then copy from Notepad into CodeWarrior. This should eliminate any hidden formatting. As shoover said above, make sure double-quotes " are really double-quotes and not the fancy left- and right-specific quotes that Word sometimes uses.
Use a hex editor like XVI32 to see the raw contents of the file, including nonprinting characters. Or use a text editor with support for showing nonprinting characters (vi/vim, etc.).
I'm studying C and I've just had the same problem. When coping a piece of code from a PDF file and trying to compiling it, gcc would return a serie of errors. Reading the answer above I had an idea: "What if I converted the utf8 into ascii?". Well, I found a website that does just that (https://onlineutf8tools.com/convert-utf8-to-ascii). But instead of also converting the utf8 characters into ascii, it showed them as hexadecimals (Copying from the website to the text editor you can see it better). From there i realised that the problem were mostly the quote marks "".
I then copied the ascii "translation" into my code editor (I must add that it worked fine with Sublime, while VScode read the same utf8 code as it was in the original file, even after cp from the website) and replaced all the hex with the actual ascii characters that were needed to compile the code properly. I used the function find and replace from my editor to do it. I must say that it wasn't very fast doing it. But I believe that in some cases, if the code you're trying to copying is too long, doing it the way I've just described could be faster than rewriting the entire code.

Resources