how can I solve such problem ..Warning:The project encoding (windows-1252) does not match the encoding specified in the Gradle build files (UTF-8). This can lead to serious bugs. More Info...Open File Encoding Settings
The answer may be in the link that you posted.
"When you encounter the above problem (which points to the this page), either change your IDE setting s or** build.gradle to UTF-8 such that the two matches**, or (if necessary) change your encoding to whatever custom encoding you have specified such that the two are in agreement.
(Note: If your source files contain more than plain ASCII characters, you can't "just" change the encoding to UTF-8. If your source files were written with a custom encoding, you'll need to convert them such that the actual characters are read in with the previous encoding and written out with the new encoding.)"
Related
I use Visual Studio 2019 and have added ApprovalTests nuget package. Test class is configured with [UseReporter(typeof(DiffReporter))] and approval is done with Approvals.Verify(result)
It works fine except for the file encoding. In VS I get two files opened. But I also get a warning: "These files have different encodings. Left file: Unicode (UTF-8) with signature. Right file: Western European (Windows). You can resolve the difference by saving the right file with the encoding Unicode (UTF-8) with signature."
I can obviously manually change the right file by saving it with different encoding. That will make the comparison accept the result, but I will the have a content with weird looking escaping in both windows. That makes it much less readable. Example: Simple plus sign is exchanged with \u002B
When debugging the code just before the approval I can verify that the result looks good with all characters as I expect them to look. What happens then? My impression is that the ApprovalTests framework forces an encoding that I can not control.
when i push a package in nuget server (on a local TFS), it will corrupt file's encoding. of course if i open my index.cshtml in notepad it will show me utf-8 encoding but VS can't show unicode characters in run time and i have to open the cshtml file in notepad and saveAs it by utf-8 encoding.
Do you mean that VS can not show the unicode characters correctly, but they can be showed correctly in VS after saving the file with utf-8 encoding?
In order to run UTF-8, you need a Byte Order Mark (BOM) sometimes called a signature. According to the description in this MSDN article:
Unicode characters are now supported in identifiers, macros, string
and character literals, and in comments. Universal character names are
also now supported.
Unicode can be input into a source code file in the following
encodings:
UTF-16 little endian with or without byte order mark (BOM)
UTF-16 big endian with or without BOM
UTF-8 with BOM
For the love of all things decent, do NOT use "UTF-8 with BOM!"
You can try to recreate the nuget package in VS with the utf-8 encoding files, then publish it to the server, then try it again. While please note below things:
Use the UTF-8 character encoding for the *.nuspec
Do not save your *.nuspec files with a Byte Order Mark (BOM). A BOM
is neither required nor recommended for UTF-8, because it can lead to
several issues.
Specify the UTF-8 encoding in the first line of your *.nuspec files
like so: <?xml version="1.0" encoding="utf-8"?>.
Also reference this thread: UTF-8 without BOM
I have an eclipse CDT C project on a windows machine with all files, inc. doxy file, encoded as UTF-8.
UTF-8 has been specified as encoding within the doxy file as well.
Yet the LaTex files produced are encoded in ISO-8859-1.
In fact if I open a .tex file (with TexWorks), change the file encoding, save it and close it, when I re-open it the encoding is still marked as ISO-8859-1.
This means that UTF-8 symbols (such as \Delta) in the source make it through a doxygen build OK, but cause the PDF make to fail.
Im not at all familiar with LaTex, so not sure where to even start searching on this one, Google queries to date have been fruitless. I'm also still not overly sure if this is a Doxygen, Tex or windows issue that causes the .tex file encoding to be ISO-8859-1!
Thus it would be good to know that, even though there's no specific option for setting doxygen .tex output encoding, would it be set to the same as the DOXYFILE_ENCODING setting?
Assuming that is the case, then moving one of the .tex files from the project folder to the desktop and attempting the encoding change via TexWorks still fails to hold, so it leads me to think either windows or TexWorks is preventing the encoding being UTF-8, but lack of knowledge on encodings and LaTex has left me at a loose end here, any suggestions on what to try next?
Thanks
:\ I basically just ended up re-installing everything and making sure git ignored the tex files and handled the PDF files separately to the code files, so that the encoding was forced. Not really a fix, but it builds.
We are working on a large codebase in Visual Studio 2010 using TFS as version control system.
When performing merges we recently get a lot of encoding issues. For the most of them we get an option "Choose encoding and merge" for other files we get:
"The encodings for the files being merged must match or an encoding conversion must be specified."
We normally put every file in UTF-8, although we get conflicts when merging between codepage 1252 and utf-8.
To solve these issues we always perform a manual merge which can be quite cumbersome. How can we avoid these errors? What is the recommended encoding for source-code files in TFS? How can we recursively set the encoding to avoid errors like these in the future?
You are getting the message because TFS thinks (correctly or incorrectly) that a file has different encodings in different branches. To double-check the encoding, go to the properties window of any source-controlled file.
Although TFS detects the encoding when a file is added to source control, if the encoding is later changed TFS will not always pick it up. Click the Set Encoding button and then click Detect to see what the actual encoding is. If it isn't what you expect, then check out the file, modify the encoding in a text editor, and then have TFS re-detect the encoding.
Once the encoding is the same in both branches you shouldn't get this error any longer.
I have problems with files encoding in Visual Studio 2008. While compiling I'm getting such errors:
When I'm trying to open file where particular error occures, encoding window appears:
By defualt auto-detect is set. When I change encoding option to UTF-8, everything works. If I open each problematic file in my project using UTF-8 encoding, project starts to compile. The problem is I have too many files and there is ridiculous to open each file and set encoding to UTF-8. Is there any way to make this in a quick way ?
My VS settings are:
I'm using Windows Server 2008 R2.
UPDATE:
For Hans Passant and Noah Richards. Thanks for interaction. I recently changed my operating system so everything is fresh. I've also downloaded fresh solution from source control.
In OS regional settings I've changed system locale to Polish(Poland):
In VS I've changed international settings to the same as windows:
The problem is still not solved.
When I open some .cs files using auto-detection for encoding, and then check Files -> Advanced Save Options..., some of this .cs files have codepage 1250:
but internally looks following:
It is wired, because when I check properties of such particular files in source control, they seems to have UTF-8 encoding set:
I don't understand this mismatch.
All other files have UTF-8 encoding:
and opens correctly. I have basically no idea what is going wrong because as far as I know my friend has the same options set as me, and the same project compiles for him correctly. But so far he happily hasn't encountered encoding issues.
That uppercase A with circumflex tells me that the file is UTF-8 (if you look with a hex editor you will probably see that the bytes are C2 A0). That is a non-breaking space in UTF-8.
Visual Studio does not detect the encoding because (most likely) there are not enough high-ASCII characters in the file to help with a reliable detection.
Also, there is no BOM (Byte Order Mark). That would help with the detection (this is the "signature" in the "UTF-8 with signature" description).
What you can do: add BOM to all the files that don't have one.
How to add? Make a file with a BOM only (empty file in Notepad, Save As, select UTF-8 as encoding). It will be 3 bytes long (EF BB BF).
You can copy that at the beginning of each file that is missing the BOM:
copy /b/v BOM.txt + YourFile.cs YourFile_Ok.cs
ren YourFile.cs YourFile_Org.cs
ren YourFile_Ok.cs YourFile.cs
Make sure there is a + between the name of the BOM file and the one of the original file.
Try it on one or two files, and if it works you can create some batch file to do that.
Or a small C# application (since you are a C# programmer), that can detect if the file already has a BOM or not, so that you don't add it twice. Of course, you can do this in almost anything, from Perl to PowerShell to C++ :-)
Once you've opened the files in UTF-8 mode, can you try changing the Advanced Save Options for the file and saving it (as UTF-8 with signature, if you think these files should be UTF-8)?
The auto-detect encoding detection is best-effort, so it's likely that something in the file is causing it to be detected as something other than UTF-8, such as having only ASCII characters in the first kilobyte of the file, or having a BOM that indicates the file is something other than UTF-8. Re-saving the file as UTF-8 with signature should (hopefully) correct that.
If it continues happening after that, let me know, and we can try to track down what is causing them to be created/saved like that in the first place.