michael-o commented on a change in pull request #60:
URL: https://github.com/apache/maven-shared-utils/pull/60#discussion_r462164339
##########
File path:
src/test/java/org/apache/maven/shared/utils/cli/CommandLineUtilsTest.java
##########
@@ -168,4 +169,25 @@ private void assertCmdLineArgs( final String[] expected,
final String cmdLine )
assertEquals( expected.length, actual.length );
assertEquals( Arrays.asList( expected ), Arrays.asList( actual ) );
}
+
+ @Test
+ public void testChineseEncodingIssue()
Review comment:
> As far as i am concerned, the parameter commandLine of
CommandLineUtils.executeCommandLineAsCallable is used to create a Process
object, which is a result of Runtime.getRuntime().execute(). This execute()
method uses different encoding depending on different system.
Why do you think so? It uses the same encoding as the surrounding Java
process does. You cannot change this really on Windows, on Unix you can pass
LC_ALL to the env.
> Any idea of producing GBK bytes using
CommandLineUtils.executeCommandLineAsCallable? Or i can modify the test to use
system encoding rather than using GBK.
You have two options:
1. Modify `file.encoding` and set back in the finally block. Implies you
read the output stream. I don't exactly know whether tests can run in parallel
in the same JVM, this could break other tests.
2. Write a simple Java program, put it in `src/test/java`, call the `.class`
file with Java from within the test. It should use `System.out` as a
byte-oriented stream which will write bytes according to GBK. Read those with
the consumer and check when normalized back to UTF-16.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
