# io.github.libtmux.exception.UnencodableTextException

- **Module:** io.github.libtmux.exception
- **Package:** io.github.libtmux:libtmux
- **Language:** Java
- **Kind:** class
- **Source:** https://github.com/libtmux/libtmux-java/blob/f56392b5d9bc7f1f9c1631842333fb90f3d82d40/libtmux/src/main/java/io/github/libtmux/exception/UnencodableTextException.java#L21
- **Page:** https://libtmux.org/en/java/latest/reference/io-github-libtmux-exception-unencodabletextexception-unencodabletextexception/

Text this JVM cannot hand to tmux intact, with no route left to send it by.

A child process receives its arguments as bytes, and the JVM encodes them with the platform's
native encoding — which is the locale's, decided before {@code main} runs. In a locale that is
not UTF-8 that encoding cannot carry most of Unicode, so tmux would receive {@code ?} where a
caller wrote {@code é}. The process transport therefore sends such a command over tmux's standard
input instead, which this library encodes itself, and this is raised only when that route is
already taken — a command that reads standard input — or when the text is in the endpoint, the
binary or socket path, which nothing but an argument can carry.

Only the environment removes the limit: start the JVM with {@code LC_ALL} or {@code LANG}
naming a UTF-8 locale. {@code -Dsun.jnu.encoding} and {@code -Dfile.encoding} do not, because the
native encoding is read before either is applied.

ASCII text is unaffected on every locale, and so is everything tmux sends back: a reply is
decoded as the UTF-8 tmux wrote rather than through the platform's encoding.

## Members

### Other members

- `UnencodableTextException` (method): Text refused because of {@code cause}, such as a path the platform cannot represent.