Skip to content

[MSHARED-938] - #60

Closed
nywitness wants to merge 3 commits into
apache:masterfrom
nywitness:MSHARED-938
Closed

[MSHARED-938]#60
nywitness wants to merge 3 commits into
apache:masterfrom
nywitness:MSHARED-938

Conversation

@nywitness

Copy link
Copy Markdown

add charset config

add charset config

@elharo elharo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to test this fix?

@nywitness

Copy link
Copy Markdown
Author

Would it be helpful to add a test case in org.apache.maven.shared.utils.cli.CommandLineUtilsTest?
I'm wondering if you can find the difference in a non-chinese os.
I will paste a test screenshot to clarify the difference. Hope it helps.

@nywitness

Copy link
Copy Markdown
Author

image

@elharo elharo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, a unit test is helpful, especially when fixing a bug. It should fail without the PR and pass with this PR. That was we know the bug is actually fixed.

Add test unit to prove bug is fixed.
public void testChineseEncodingIssue()
throws Exception
{
Commandline commandline = new Commandline( "ping www.baidu.com" );

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we cannot have tests which require outbound access. Espcially ICMP. Please change test.

Exclude ICMP in the test.
}

outputPumper = new StreamPumper( p.getInputStream(), systemOut );
outputPumper = new StreamPumper( p.getInputStream(), systemOut , streamCharset );

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Space before comma is not required.

}

@Test
public void testChineseEncodingIssue()

@michael-o michael-o Jul 28, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test is completely pointless:

  1. The echo will use the encoding supplied by the entire system. There is no guarantee that GBK is the system encoding.
  2. You never verify the output of th command to be what you expect.

What you need is an application that produces GBK bytes , those are read by Java with GBK into a String then you need to compare this value.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Any idea of producing GBK bytes using CommandLineUtils.executeCommandLineAsCallable? Or i can modify the test to use system encoding rather than using GBK.

@nywitness nywitness Jul 29, 2020

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By the way, this test will pass without this PR if system encoding is the same as the result of Charset.defaultCharset(). So the influence of this fix may not be very obvious.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

I tried producing gbk bytes with System.out.println(new String("金色传说".getBytes(), "GBK"). When comparing value in the cousumer, test passes on a windows-gbk platform but fails on a mac-utf-8 platform. Maybe it's not right to produce gbk bytes like that.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's wrong. You need to use System.out as an byte stream, not a char stream: byte[] bytes = "...".getBytes(encoding) then System.out.write(bytes).

@jira-importer

Copy link
Copy Markdown

Resolve #302

@slachiewicz slachiewicz closed this Feb 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants