[Bug]: UTF-8 stdout corrupted on Windows

Module

Core

Testcontainers version

1.17.3

Using the latest Testcontainers version?

No (well, tested on 1.17.3, but code snippet below is still from latest main)

Host OS

Windows

Host Arch

x64

Docker version

Client:
 Cloud integration: v1.0.29
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.17.11
 Git commit:        100c701
 Built:             Mon Jun  6 23:09:02 2022
 OS/Arch:           windows/amd64
 Context:           default
 Experimental:      true

Server: Docker Desktop 4.12.0 (85629)
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:01:23 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.8
  GitCommit:        9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

I had utf8 output from the container and I got ? instead of the codepoint I was supposed to get.

Relevant log output

No response

Additional Information

I'm trying to read utf8 stdout, but this method in testcontainers takes utf8 then converts it to the default charset which is messing up my data. Especially since I'm trying to read it as utf8 in the end:

https://github.com/testcontainers/testcontainers-java/blob/98ddbb845583ff07e622077522c49122908c40b6/core/src/main/java/org/testcontainers/containers/output/FrameConsumerResultCallback.java#L133-L138

Is there a way to process stdout as raw? Or a way to customize the charset here? It's not always convenient to set Java's default charset.

Start with core/src/main/java/org/testcontainers/containers/output/FrameConsumerResultCallback.java at lines 133-138 and reproduce the UTF-8 stdout case on Windows. Determine how the callback handles the container output charset; done means UTF-8 output is preserved or its charset can be customized without changing Java’s default charset.