When I scan through the documentation for file component, I saw charset option support encoding. I cannot see any description or reference to encoding list it support. So, what encoding does Camel File Component Charset support?
http://camel.apache.org/file2.html
It supports the charsets that your JRE supports at runtime.
You can find more details in the javadoc of Charset:
https://docs.oracle.com/javase/7/docs/api/java/nio/charset/Charset.html
And there is a standard set of charsets on all JREs:
https://docs.oracle.com/javase/7/docs/api/java/nio/charset/StandardCharsets.html
Related
I want to compress a file to ".tgz" extension using apache camel 3.11.1.
As the gzip format is not supported, I tried GZipDeflater data format but it is not working (the file remains unchanged).
I found a solution, maybe it can help someone else.
The solution was to use gzipDeflater DataFormat, and explicitly provide the extension in the file endpoint when producing the result:
from("file:...../in?noop=true")
.marshal().gzipDeflater()
.to("....../out1?fileName=${file:name.noext}.tgz");
I'm having issues with DevOps using Windows cp1252 file encoding rather than UTF-8 for repositories, resulting in my code breaking. I have certain symbols that are only supported by the UTF-8 format and have not found a possible way to change how I am pushing to the repository, and have no other alternative options to Azure DevOps as a platform just because of the mess that is JetBrains Space, and how there are utterly no other services offering the same concepts / platform for me (features like boards, the integrated CI, I just like having everything in one place and this is the only possible platform I have found, so don't link me elsewhere unless it actually meets the proper requirements.
Build log (custom Maven-based build environment)
9122 [WARNING]
9123 rip.verse.vserver.commands.implementations.VersionCommand [22,36]
9124 unmappable character (0x95) for encoding UTF-8
VersionCommand.java
19 public boolean execute(Sender sender, String[] arguments) {
20 if (arguments.legnth == 0) {
21 // ...
22 sender.sendTranslatedMessage("&8� &7Version: &b1.0");
23 // ...
24 return true;
25 }
26 }
I found the similar issue reported in DeveoperCommunity forum, and the product group gave the following answer.
This is by design. Editing a file (in Git) in the VSTS Code hub will save that file as UTF-8. This behavior was selected since UTF-8 is ubiquitously used, the encoding can be accurately determined, and it can encode all the special characters of the various flavors of ANSI as well as other languages. Of course, this might present a problem if you're specifically expecting special characters with Win 1252 (or other) encoding in another application or particular purpose, and if that's the case then you'll want to avoid editing in the web UI. I'm curious to know if that's the case, but I would personally recommend eventually using UTF-8 if possible to avoid encoding issues of the past.
Therefore, Windows cp1252 file encoding is not supported in Azure Repository, you need to save your file using UTF-8 file encoding. Please review this blog: How TFS Version Control determines a file’s encoding and What is the default encoding for source files in Visual Studio 2017? if you use Visual Studio.
I generated java sources from wsdl file using CXF wsdl2java command :
wsdl2java -impl -server -d <path_to_wsdl> <path_to_generated_java_source>
but the generated comments are in French. How is possible to change the comments language (I want the comments in English). I could not find the option in CXF wsdl2java Documentation.
Thanks very much in advance for your answers.
Unfortunately there is not yet an option to change the language, see JAXB jira issue. If the generated output language (e.g. german) causes encoding problems you can at least specify the encoding of the generated files (since version 2.5.4):
wsdl2java ... -encoding UTF-8 ....
In the batch script you call (like wsdl2java.bat), as well as in the unix shell script file, Java is called with some parameters. There you can set the parameters for country (user.country) and language (user.language).
So the line would looks like this:
"%JAVA_HOME%\bin\java" -Xmx128M -Duser.country=US -Duser.language=en -Dkava-endorsed.dirs=[...]
When you start the converting again, the comments are generated in English (or what ever language you define here).
Worked for me on Windows. Should work on other OS as well, as you directly set Java parameters.
EDIT:
In fact it's enough to only use -Duser.language=US_en or just -Duser.language=en.
Is there a dedicated Mercurial configuration property which specifies the encoding of file contents and hence should be used by a Mercurial client to properly display a file?
I've found web.encoding which does not seem to mean exactly what I'm looking for. Also, Google gave some results for ui.encoding as well, but I couldn't find any hints in the reference.
Mercurial is not concerned with the encoding of the files you put in your repository: Mercurial is happy to store files with any encoding (or maybe not particular encoding at all).
This means that you can add files with UTF-8, Latin-1, or any other encoding to your repository and Mercurial will check them out exactly as they were when you added them.
The encoding of each file is not stored anywhere in Mercurial and it is up to the client to recognize the encoding (perhaps based on file content where it makes sense, e.g., for XML files).
For a Mercurial desktop client (as per your comments below) I suggest looking at the file content:
Can you decode it at UTF-16?
Can you decode it as UTF-8?
Are the NUL bytes in the file? Then stop and declare it to be "binary".
Fallback on a Latin-N encoding such as Latin-1 for Western Europe.
The UTF-16 and UTF-8 encodings are nice since they are structured and this makes it possible for you to detect that a file isn't valid UTF-8 encoded, say. The above list is written with a European perspective — you should probably also consult someone with knowledge about Shift JIS and other encodings used in Asia.
In any case, I would only expect a Mercurial client to do a best effort attempt at showing me a file with an encoding other than ASCII.
Some alternative interpretations of your question:
If you're really asking about how to make your files look "correct" when you view them in hgweb, then it's a matter of using a consistent encoding in the repository and setting `web.encoding.
If you're really asking how to ensure that text files get the OS native line ending character on different platforms (\n on Unix, \r\n on Windows) when take a look at the eol extension that comes with Mercurial.
No. Encoding (charset) is property of file in repository
I want IDEA to use whatever default system encoding is, instead it uses whatever is set through Settings > File Encodings. Which is set to UTF-8.
My application runs fine in Eclipse, which uses default system encoding on windows, but it is having trouble reading some xmi files when running the application through IDEA.
You can select system's default encoding from the same drop down:
Found it in File->Other Settings->Default encoding: http://ufasoli.blogspot.ru/2013/10/intellij-change-default-encoding-for.html