java - Finding the default file encoding of a remote jvm -

java - Finding the default file encoding of a remote jvm -

i need find out default file encoding on remote java vm, in java program.

is there way execute charset.defaultcharset() on remote vm , value back... without altering programme running on remote jvm?

update:

i trying find out default charset weblogic 11g or weblogic 12c server... did not start, cannot restart , not have 'right' deploy code onto it.

i need able determine default charset of server process within java programme writing. may execute on same machine server... or not. doubtful the server , programme start same environment.

i prefer method depends on few assumption... means more code...

i cannot execute charset.defaultcharset() on server... should not have said 'execute charset.defaultcharset()'. sorry folks. need provide reply right executing charset.defaultcharset() within server process.

edit: after writing answer, discovered it's @ to the lowest degree partially based on faulty assumption, in charset.defaultcharset() isn't guaranteed homecoming same value. of approaches below should still work provided they're tried on same host target application, recommend read first 2 answers of this question more background.

in particular might easier forcibly override file.encoding instead of trying figure out is.

as javadoc of defaultcharset states:

the default charset determined during virtual-machine startup , typically depends upon locale , charset of underlying operating system.

meaning defaultcharset() read-only within jvm process , homecoming same charset jvm processes started on same machine unless environment has been changed explicitly prior starting process (eg. wrapper/launcher script starting jvm , setting different locale current process , children). if you're sure sure 2 processes started in same way, charset.defaultcharset() should homecoming same charset application you're asking for.

with backdrop, , in increasing order of annoyance/effort:

if host running unix/linux, seek procfs. eg. /proc/<vmpid>/environ , /proc/<vmpid>/cmdline (on linux) great places start because show how process actually started without obfuscation of wrapper script. solution gets bonus points because doesn't need restart/alter application inspection. things out for: lang , lc_* variables (intro locale on linux) , jvm command line parameters affecting locale. other operating systems have form of process inspection can utilize show information.

next up: compile , run on particular host/jvm:

import java.nio.charset.charset; public class dumpcharset { public static void main(string[] args) { system.out.println(charset.defaultcharset().displayname()); } }

as mentioned, if processes started in same way, charset.defaultcharset() should homecoming same value (on same host). close, replace application's jar containing main method jar containing above code temporarily (make sure class names match).

if doesn't give info need (it should), seek launching process accepts debugger, attach debugger, , drill downwards locale, and/or execute expressions similar above code.

if still doesn't give info need, can go radical , utilize dynamic bytecode weaving @ class-load time. achieved existing aop framework based on load time weaving (eg. aspectj), or straight asm 4 , java.lang.instrument api. aware there pitfalls create work, it's hard justice whether going reasonably straightforward or not in case. expect (much?) more work above methods.

java character-encoding