The Encoding 'Utf-8' Is Not Supported by the Java Runtime

The encoding 'UTF-8' is not supported by the Java runtime

According the documentation "Every implementation of the Java platform is required to support the following standard charsets... US-ASCII, ISO-8859-1, UTF-8, UTF-16BE, UTF-16LE, UTF-16." So I doubt that Sun have released a build without UTF-8 support.

The actual error message appears to be from here, which is part of the Xerces XML parser. I imagine it is the XML parser where the problem is occurring.

Setting the default Java character encoding

Unfortunately, the file.encoding property has to be specified as the JVM starts up; by the time your main method is entered, the character encoding used by String.getBytes() and the default constructors of InputStreamReader and OutputStreamWriter has been permanently cached.

As Edward Grech points out, in a special case like this, the environment variable JAVA_TOOL_OPTIONS can be used to specify this property, but it's normally done like this:

java -Dfile.encoding=UTF-8 … com.x.Main

Charset.defaultCharset() will reflect changes to the file.encoding property, but most of the code in the core Java libraries that need to determine the default character encoding do not use this mechanism.

When you are encoding or decoding, you can query the file.encoding property or Charset.defaultCharset() to find the current default encoding, and use the appropriate method or constructor overload to specify it.

UTF-8 not supported message from logging subsystem, Fuse ESB 4.4

The problem is that something is attempting to access the UTF-8 character set (probably via Charset.forName("UTF-8")) which is attempting to instantiate a class in a package sun.nio.cs.UTF_8.

Although this will exist in the runtime of a JVM with no class loader constraints, in an OSGi runtime the code will fail.

The solution will be to modify the bundle that's generating this error message with the following:

Import-Package: ...,sun.nio.cs;resolution:=optional

That means that should it attempt to instantiate a class in that package, it should be able to find it - however, if it's not present (say, because you are using a different runtime) then it will still work.

Note that this implies the System.bundle is exporting the sun.nio.cs package, which you can do by generating a Fragment (see http://wiki.osgi.org/wiki/Fragment) or by having the system bundle export the sun.nio.cs package with the org.osgi.framework.system.packages property.

Either way, it sounds like something that the logging bundle should fix rather than something you'd need to fix - have you reported the bug upstream?

UTF-8 not supported message from logging subsystem, Fuse ESB 4.4

The problem is that something is attempting to access the UTF-8 character set (probably via Charset.forName("UTF-8")) which is attempting to instantiate a class in a package sun.nio.cs.UTF_8.

Although this will exist in the runtime of a JVM with no class loader constraints, in an OSGi runtime the code will fail.

The solution will be to modify the bundle that's generating this error message with the following:

Import-Package: ...,sun.nio.cs;resolution:=optional

That means that should it attempt to instantiate a class in that package, it should be able to find it - however, if it's not present (say, because you are using a different runtime) then it will still work.

Note that this implies the System.bundle is exporting the sun.nio.cs package, which you can do by generating a Fragment (see http://wiki.osgi.org/wiki/Fragment) or by having the system bundle export the sun.nio.cs package with the org.osgi.framework.system.packages property.

Either way, it sounds like something that the logging bundle should fix rather than something you'd need to fix - have you reported the bug upstream?

UTF-8 does not print characters to the console

Your code are not printing the right characters in the console because your Java program and the console are using different character sets, different encodings.

If you want to obtain the same characters, you first need to determine which character sets are in place.

This process will depend on the "console" in which you are outputting your results.

If you are working with Windows and cmd, as @RickJames suggested, you can use the chcp command to determine the active code page.

Oracle provides the Java full supported encodings information, and the correspondence with other alias - code pages in this case - in this page.

This stackoverflow answer also provides some guidance about the mapping between Windows Code Pages and Java charsets.

As you can see in the provided links, the code page for UTF-8 is 65001.

If you are using Git Bash (MinTTY), you can follow @kriegaex instructions to verify or configure UTF-8 as the terminal emulator encoding.

Linux and UNIX, or UNIX derived systems like Mac OS, do not use code page identifiers, but locales. The locale information can vary between systems, but you can either use the locale command or try to inspect the LC_* system variables to find the required information.

This is the output of the locale command in my system:

LANG="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_CTYPE="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_ALL=

Once you know this information, you need to run your Java program with the file.encoding VM option corresponding to the right charset:

java -Dfile.encoding=UTF8 MainDefault

Some classes, like PrintStream or PrintWriter, allows you to indicate the Charset in which the information will be outputted.

The -encoding javac option only allows you to specify the character encoding used by source files.

If you are using Windows with Git Bash, consider also reading this @rmunge answer: it provides information about a possible bug in the tool that may be the reason for the problem and that prevents the terminal from running correctly out of the box without the need for manual encoding adjustments.

How to solve UTF-8 is not supported encoding name

You can use custom EncodingProvider

public class Utf8EncodingProvider : EncodingProvider
{
    public override Encoding GetEncoding(string name)
    {
        return name == "\"UTF-8\"" ? Encoding.UTF8 : null;
    }

    public override Encoding GetEncoding(int codepage)
    {
        return null;
    }

    public static void Register()
    {
        Encoding.RegisterProvider(new Utf8EncodingProvider());
    }
}

Usage based on your question code:

Utf8EncodingProvider.Register(); //You should call it once at startup of your application
HttpResponseArgs result = //Make the request with HttpClient object ( I am skipping it here)

var stringResult = result?.Content.ReadAsStringAsync().Result; // Must be executed without exception.

Issue with UTF-8 encoding on Windows

Java uses Unicode on the inside, so you don't usually need to set the encoding EXCEPT when you read/write outside resources.

There you need to have it explicitly.

In your case you need to encode the elements of the URL with the class URLEncoder.

Have a look at the documentation.

---

Related Topics