Google's gson library: JsonObject string encoding problem
Can somebody give me an idea of what is going on because I keep getting rather strange results from my tests. So, I have a maven project in IntelliJ and if i run this code (note the cyrillic string) inside the IDE the output is as expected.
JsonObject json = new JsonObject();
json.addProperty("message", "тест");
System.out.println("TEST:"+json.get("message").getAsString());
Output in IDE: TEST:тест
But if I package the project in a jar file the encoding of the JsonObject messes up somehow and the code above results in:
Output in console from jar: TEST:????
Things I tried:
forcing the JVM to use -Dfile.enconding=UTF-8 just to see if this affects it but nothing changed.
getting the bytes of the json.get("message").getAsString() and creating a new string with specified encoding new String( bytes, StandardCharsets.UTF_8)
checked the IntelliJ run arguments of the project (nothing is specified)
the problem persists with all characters with ASCII value above 127 (mentioning ASCII because UTF and most of the encodings inherit the first 127 character values from ASCII)
It is not a console related problem because the same issue persists on UI elements that support UTF-8 here is an example: http://prntscr.com/lmca64 . This still persists ONLY on the app of the exported jar!
Do you have any idea what might cause this inconsistent behavior?
link to the GSON library
Update*:
After further testing here is the output of the following code:
JsonObject json = new JsonObject();
json.addProperty("message", "тест");
byte jsonBytes = json.get("message").getAsString().getBytes();
for(byte b : jsonBytes) {
System.out.print(b+" ");
}
System.out.println();
byte stringBytes = "тест".getBytes();
for(byte b : stringBytes) {
System.out.print(b+" ");
}
IDE output:
-47 -126 -48 -75 -47 -127 -47 -126
-47 -126 -48 -75 -47 -127 -47 -126
Compiled jar console output:
63 63 63 63
63 63 63 63
This in terms shows that both of the strings are the same but once packaged into a jar something happens.
Decimal to text converter
Here is my pom.xml. May be I am doing something wrong while exporting the jar in wrong encoding?
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<groupId>me.ivstiv</groupId>
<artifactId>Trapdoor-client</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<finalName>Trapdoor-client-1.0-fat</finalName>
<archive>
<manifest>
<mainClass>core.Main</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>8</source>
<target>8</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<!-- https://mvnrepository.com/artifact/com.google.code.gson/gson -->
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.5</version>
</dependency>
</dependencies>
java json encoding jar gson
|
show 2 more comments
Can somebody give me an idea of what is going on because I keep getting rather strange results from my tests. So, I have a maven project in IntelliJ and if i run this code (note the cyrillic string) inside the IDE the output is as expected.
JsonObject json = new JsonObject();
json.addProperty("message", "тест");
System.out.println("TEST:"+json.get("message").getAsString());
Output in IDE: TEST:тест
But if I package the project in a jar file the encoding of the JsonObject messes up somehow and the code above results in:
Output in console from jar: TEST:????
Things I tried:
forcing the JVM to use -Dfile.enconding=UTF-8 just to see if this affects it but nothing changed.
getting the bytes of the json.get("message").getAsString() and creating a new string with specified encoding new String( bytes, StandardCharsets.UTF_8)
checked the IntelliJ run arguments of the project (nothing is specified)
the problem persists with all characters with ASCII value above 127 (mentioning ASCII because UTF and most of the encodings inherit the first 127 character values from ASCII)
It is not a console related problem because the same issue persists on UI elements that support UTF-8 here is an example: http://prntscr.com/lmca64 . This still persists ONLY on the app of the exported jar!
Do you have any idea what might cause this inconsistent behavior?
link to the GSON library
Update*:
After further testing here is the output of the following code:
JsonObject json = new JsonObject();
json.addProperty("message", "тест");
byte jsonBytes = json.get("message").getAsString().getBytes();
for(byte b : jsonBytes) {
System.out.print(b+" ");
}
System.out.println();
byte stringBytes = "тест".getBytes();
for(byte b : stringBytes) {
System.out.print(b+" ");
}
IDE output:
-47 -126 -48 -75 -47 -127 -47 -126
-47 -126 -48 -75 -47 -127 -47 -126
Compiled jar console output:
63 63 63 63
63 63 63 63
This in terms shows that both of the strings are the same but once packaged into a jar something happens.
Decimal to text converter
Here is my pom.xml. May be I am doing something wrong while exporting the jar in wrong encoding?
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<groupId>me.ivstiv</groupId>
<artifactId>Trapdoor-client</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<finalName>Trapdoor-client-1.0-fat</finalName>
<archive>
<manifest>
<mainClass>core.Main</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>8</source>
<target>8</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<!-- https://mvnrepository.com/artifact/com.google.code.gson/gson -->
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.5</version>
</dependency>
</dependencies>
java json encoding jar gson
1
Sounds like it's just a console issue to me. If you addSystem.out.println("NOT IN JSON: тест");
I suspect you'll see the question marks there too.
– Jon Skeet
Nov 24 '18 at 8:13
@JonSkeet I edited my post and the list with tests. Even though you are right check this out: prntscr.com/lmca64 . It also affects UI elements which are capable of displaying cyrillic text.
– TheSKDown
Nov 24 '18 at 8:33
It's very unclear what your screenshot is actually showing - in particular, we don't know whataddMsg
does. That screenshot doesn't look like valid Java code, either. There's also no sign that you tried what I suggested in terms ofSystem.out.println
- have you tried that directly? I would start by eliminating everything but the console. Once you've got working console output, you'll be in a better position. You could also print out the precise UTF-16 code units in each string (as numbers) to remove the output issues.
– Jon Skeet
Nov 24 '18 at 8:38
I don't think it matters what addMsg does as long as the 2 lines show that it is capable of receiving and displaying cyrillic text. But not if it comes from the JsonObject. I tested what you said initially and my comment started with "you are right" which implies that the console is not capable of displaying the text but this was just a mistake in testing, doesn't resolve the actual issue. The idea of printing the code units is brilliant I will test it and come back with results!
– TheSKDown
Nov 24 '18 at 8:50
@JonSkeet I updated the post and added my pom.xml file. Apparently the problem is not in the library but in the way I produce the jar file... which kind of contradicts with some of the previous tests but at this point I don't trust any previous output i got.
– TheSKDown
Nov 24 '18 at 9:21
|
show 2 more comments
Can somebody give me an idea of what is going on because I keep getting rather strange results from my tests. So, I have a maven project in IntelliJ and if i run this code (note the cyrillic string) inside the IDE the output is as expected.
JsonObject json = new JsonObject();
json.addProperty("message", "тест");
System.out.println("TEST:"+json.get("message").getAsString());
Output in IDE: TEST:тест
But if I package the project in a jar file the encoding of the JsonObject messes up somehow and the code above results in:
Output in console from jar: TEST:????
Things I tried:
forcing the JVM to use -Dfile.enconding=UTF-8 just to see if this affects it but nothing changed.
getting the bytes of the json.get("message").getAsString() and creating a new string with specified encoding new String( bytes, StandardCharsets.UTF_8)
checked the IntelliJ run arguments of the project (nothing is specified)
the problem persists with all characters with ASCII value above 127 (mentioning ASCII because UTF and most of the encodings inherit the first 127 character values from ASCII)
It is not a console related problem because the same issue persists on UI elements that support UTF-8 here is an example: http://prntscr.com/lmca64 . This still persists ONLY on the app of the exported jar!
Do you have any idea what might cause this inconsistent behavior?
link to the GSON library
Update*:
After further testing here is the output of the following code:
JsonObject json = new JsonObject();
json.addProperty("message", "тест");
byte jsonBytes = json.get("message").getAsString().getBytes();
for(byte b : jsonBytes) {
System.out.print(b+" ");
}
System.out.println();
byte stringBytes = "тест".getBytes();
for(byte b : stringBytes) {
System.out.print(b+" ");
}
IDE output:
-47 -126 -48 -75 -47 -127 -47 -126
-47 -126 -48 -75 -47 -127 -47 -126
Compiled jar console output:
63 63 63 63
63 63 63 63
This in terms shows that both of the strings are the same but once packaged into a jar something happens.
Decimal to text converter
Here is my pom.xml. May be I am doing something wrong while exporting the jar in wrong encoding?
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<groupId>me.ivstiv</groupId>
<artifactId>Trapdoor-client</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<finalName>Trapdoor-client-1.0-fat</finalName>
<archive>
<manifest>
<mainClass>core.Main</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>8</source>
<target>8</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<!-- https://mvnrepository.com/artifact/com.google.code.gson/gson -->
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.5</version>
</dependency>
</dependencies>
java json encoding jar gson
Can somebody give me an idea of what is going on because I keep getting rather strange results from my tests. So, I have a maven project in IntelliJ and if i run this code (note the cyrillic string) inside the IDE the output is as expected.
JsonObject json = new JsonObject();
json.addProperty("message", "тест");
System.out.println("TEST:"+json.get("message").getAsString());
Output in IDE: TEST:тест
But if I package the project in a jar file the encoding of the JsonObject messes up somehow and the code above results in:
Output in console from jar: TEST:????
Things I tried:
forcing the JVM to use -Dfile.enconding=UTF-8 just to see if this affects it but nothing changed.
getting the bytes of the json.get("message").getAsString() and creating a new string with specified encoding new String( bytes, StandardCharsets.UTF_8)
checked the IntelliJ run arguments of the project (nothing is specified)
the problem persists with all characters with ASCII value above 127 (mentioning ASCII because UTF and most of the encodings inherit the first 127 character values from ASCII)
It is not a console related problem because the same issue persists on UI elements that support UTF-8 here is an example: http://prntscr.com/lmca64 . This still persists ONLY on the app of the exported jar!
Do you have any idea what might cause this inconsistent behavior?
link to the GSON library
Update*:
After further testing here is the output of the following code:
JsonObject json = new JsonObject();
json.addProperty("message", "тест");
byte jsonBytes = json.get("message").getAsString().getBytes();
for(byte b : jsonBytes) {
System.out.print(b+" ");
}
System.out.println();
byte stringBytes = "тест".getBytes();
for(byte b : stringBytes) {
System.out.print(b+" ");
}
IDE output:
-47 -126 -48 -75 -47 -127 -47 -126
-47 -126 -48 -75 -47 -127 -47 -126
Compiled jar console output:
63 63 63 63
63 63 63 63
This in terms shows that both of the strings are the same but once packaged into a jar something happens.
Decimal to text converter
Here is my pom.xml. May be I am doing something wrong while exporting the jar in wrong encoding?
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<groupId>me.ivstiv</groupId>
<artifactId>Trapdoor-client</artifactId>
<version>1.0</version>
<build>
<plugins>
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<finalName>Trapdoor-client-1.0-fat</finalName>
<archive>
<manifest>
<mainClass>core.Main</mainClass>
</manifest>
</archive>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<appendAssemblyId>false</appendAssemblyId>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.7.0</version>
<configuration>
<source>8</source>
<target>8</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<!-- https://mvnrepository.com/artifact/com.google.code.gson/gson -->
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.8.5</version>
</dependency>
</dependencies>
java json encoding jar gson
java json encoding jar gson
edited Nov 24 '18 at 11:05
TheSKDown
asked Nov 24 '18 at 8:12
TheSKDownTheSKDown
83
83
1
Sounds like it's just a console issue to me. If you addSystem.out.println("NOT IN JSON: тест");
I suspect you'll see the question marks there too.
– Jon Skeet
Nov 24 '18 at 8:13
@JonSkeet I edited my post and the list with tests. Even though you are right check this out: prntscr.com/lmca64 . It also affects UI elements which are capable of displaying cyrillic text.
– TheSKDown
Nov 24 '18 at 8:33
It's very unclear what your screenshot is actually showing - in particular, we don't know whataddMsg
does. That screenshot doesn't look like valid Java code, either. There's also no sign that you tried what I suggested in terms ofSystem.out.println
- have you tried that directly? I would start by eliminating everything but the console. Once you've got working console output, you'll be in a better position. You could also print out the precise UTF-16 code units in each string (as numbers) to remove the output issues.
– Jon Skeet
Nov 24 '18 at 8:38
I don't think it matters what addMsg does as long as the 2 lines show that it is capable of receiving and displaying cyrillic text. But not if it comes from the JsonObject. I tested what you said initially and my comment started with "you are right" which implies that the console is not capable of displaying the text but this was just a mistake in testing, doesn't resolve the actual issue. The idea of printing the code units is brilliant I will test it and come back with results!
– TheSKDown
Nov 24 '18 at 8:50
@JonSkeet I updated the post and added my pom.xml file. Apparently the problem is not in the library but in the way I produce the jar file... which kind of contradicts with some of the previous tests but at this point I don't trust any previous output i got.
– TheSKDown
Nov 24 '18 at 9:21
|
show 2 more comments
1
Sounds like it's just a console issue to me. If you addSystem.out.println("NOT IN JSON: тест");
I suspect you'll see the question marks there too.
– Jon Skeet
Nov 24 '18 at 8:13
@JonSkeet I edited my post and the list with tests. Even though you are right check this out: prntscr.com/lmca64 . It also affects UI elements which are capable of displaying cyrillic text.
– TheSKDown
Nov 24 '18 at 8:33
It's very unclear what your screenshot is actually showing - in particular, we don't know whataddMsg
does. That screenshot doesn't look like valid Java code, either. There's also no sign that you tried what I suggested in terms ofSystem.out.println
- have you tried that directly? I would start by eliminating everything but the console. Once you've got working console output, you'll be in a better position. You could also print out the precise UTF-16 code units in each string (as numbers) to remove the output issues.
– Jon Skeet
Nov 24 '18 at 8:38
I don't think it matters what addMsg does as long as the 2 lines show that it is capable of receiving and displaying cyrillic text. But not if it comes from the JsonObject. I tested what you said initially and my comment started with "you are right" which implies that the console is not capable of displaying the text but this was just a mistake in testing, doesn't resolve the actual issue. The idea of printing the code units is brilliant I will test it and come back with results!
– TheSKDown
Nov 24 '18 at 8:50
@JonSkeet I updated the post and added my pom.xml file. Apparently the problem is not in the library but in the way I produce the jar file... which kind of contradicts with some of the previous tests but at this point I don't trust any previous output i got.
– TheSKDown
Nov 24 '18 at 9:21
1
1
Sounds like it's just a console issue to me. If you add
System.out.println("NOT IN JSON: тест");
I suspect you'll see the question marks there too.– Jon Skeet
Nov 24 '18 at 8:13
Sounds like it's just a console issue to me. If you add
System.out.println("NOT IN JSON: тест");
I suspect you'll see the question marks there too.– Jon Skeet
Nov 24 '18 at 8:13
@JonSkeet I edited my post and the list with tests. Even though you are right check this out: prntscr.com/lmca64 . It also affects UI elements which are capable of displaying cyrillic text.
– TheSKDown
Nov 24 '18 at 8:33
@JonSkeet I edited my post and the list with tests. Even though you are right check this out: prntscr.com/lmca64 . It also affects UI elements which are capable of displaying cyrillic text.
– TheSKDown
Nov 24 '18 at 8:33
It's very unclear what your screenshot is actually showing - in particular, we don't know what
addMsg
does. That screenshot doesn't look like valid Java code, either. There's also no sign that you tried what I suggested in terms of System.out.println
- have you tried that directly? I would start by eliminating everything but the console. Once you've got working console output, you'll be in a better position. You could also print out the precise UTF-16 code units in each string (as numbers) to remove the output issues.– Jon Skeet
Nov 24 '18 at 8:38
It's very unclear what your screenshot is actually showing - in particular, we don't know what
addMsg
does. That screenshot doesn't look like valid Java code, either. There's also no sign that you tried what I suggested in terms of System.out.println
- have you tried that directly? I would start by eliminating everything but the console. Once you've got working console output, you'll be in a better position. You could also print out the precise UTF-16 code units in each string (as numbers) to remove the output issues.– Jon Skeet
Nov 24 '18 at 8:38
I don't think it matters what addMsg does as long as the 2 lines show that it is capable of receiving and displaying cyrillic text. But not if it comes from the JsonObject. I tested what you said initially and my comment started with "you are right" which implies that the console is not capable of displaying the text but this was just a mistake in testing, doesn't resolve the actual issue. The idea of printing the code units is brilliant I will test it and come back with results!
– TheSKDown
Nov 24 '18 at 8:50
I don't think it matters what addMsg does as long as the 2 lines show that it is capable of receiving and displaying cyrillic text. But not if it comes from the JsonObject. I tested what you said initially and my comment started with "you are right" which implies that the console is not capable of displaying the text but this was just a mistake in testing, doesn't resolve the actual issue. The idea of printing the code units is brilliant I will test it and come back with results!
– TheSKDown
Nov 24 '18 at 8:50
@JonSkeet I updated the post and added my pom.xml file. Apparently the problem is not in the library but in the way I produce the jar file... which kind of contradicts with some of the previous tests but at this point I don't trust any previous output i got.
– TheSKDown
Nov 24 '18 at 9:21
@JonSkeet I updated the post and added my pom.xml file. Apparently the problem is not in the library but in the way I produce the jar file... which kind of contradicts with some of the previous tests but at this point I don't trust any previous output i got.
– TheSKDown
Nov 24 '18 at 9:21
|
show 2 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53456379%2fgoogles-gson-library-jsonobject-string-encoding-problem%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53456379%2fgoogles-gson-library-jsonobject-string-encoding-problem%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Sounds like it's just a console issue to me. If you add
System.out.println("NOT IN JSON: тест");
I suspect you'll see the question marks there too.– Jon Skeet
Nov 24 '18 at 8:13
@JonSkeet I edited my post and the list with tests. Even though you are right check this out: prntscr.com/lmca64 . It also affects UI elements which are capable of displaying cyrillic text.
– TheSKDown
Nov 24 '18 at 8:33
It's very unclear what your screenshot is actually showing - in particular, we don't know what
addMsg
does. That screenshot doesn't look like valid Java code, either. There's also no sign that you tried what I suggested in terms ofSystem.out.println
- have you tried that directly? I would start by eliminating everything but the console. Once you've got working console output, you'll be in a better position. You could also print out the precise UTF-16 code units in each string (as numbers) to remove the output issues.– Jon Skeet
Nov 24 '18 at 8:38
I don't think it matters what addMsg does as long as the 2 lines show that it is capable of receiving and displaying cyrillic text. But not if it comes from the JsonObject. I tested what you said initially and my comment started with "you are right" which implies that the console is not capable of displaying the text but this was just a mistake in testing, doesn't resolve the actual issue. The idea of printing the code units is brilliant I will test it and come back with results!
– TheSKDown
Nov 24 '18 at 8:50
@JonSkeet I updated the post and added my pom.xml file. Apparently the problem is not in the library but in the way I produce the jar file... which kind of contradicts with some of the previous tests but at this point I don't trust any previous output i got.
– TheSKDown
Nov 24 '18 at 9:21