una ruta obtener carpeta java cross-platform

carpeta - jfilechooser java obtener ruta



¿Cuál es la forma multiplataforma de obtener la ruta al directorio de datos de la aplicación local? (7)

Lo que necesito es una forma independiente de la plataforma para obtener la ruta al directorio de datos de la aplicación local. System.getenv("LOCALAPPDATA") parece funcionar solo con Windows. ¿Cómo hago esto?


El problema es que otros sistemas operativos ni siquiera tienen un concepto bien definido de "el directorio de datos de la aplicación". Por lo general, es solo un subdirectorio oculto en el directorio de inicio del usuario con un nombre convencional que puede ser o no el nombre de la aplicación.

Caracol mecánico comenta así:

No es verdad. Linux tiene uno (~ / .local por defecto), y creo que OS X también lo hace.

En primer lugar, no es ~/.local . Es ~/.local/share . (O al menos está en mi máquina Linux).

En segundo lugar, esta es una idea nueva. Parece originarse del folk "freedesktop.org", a través de la especificación de directorio base de XDG . No se menciona en otras especificaciones más ampliamente reconocidas sobre cómo deberían organizarse los sistemas de archivos Linux / UNIX. Y tenga en cuenta lo que dicen sobre sus "estándares" en esta página: http://www.freedesktop.org/wiki/

Finalmente, esta idea no está implementada por la mayoría de los comandos de Linux. Esto es bastante poco científico, pero mirando los directorios ocultos en mi cuadro de Linux puedo ver signos de al menos 40 aplicaciones distintas, ya sea usando ~/ o un subdirectorio personalizado. Por el contrario, hay signos de solo 16 aplicaciones en ~/.local/share .

Una convención de nomenclatura implementada por menos de 1/3 parte de las aplicaciones no es un "concepto bien definido" ... y ciertamente no de una manera que permita encontrar un directorio de datos de una aplicación arbitraria de manera portátil.


La búsqueda es antigua, pero me falta una respuesta que enumere los entornos vars en lugar de algunas rutas absolutas divertidas. No sé nada sobre OSX. esta publicación solo contiene información sobre Windows y Linux.

No tengo suficientes puntos para extender una respuesta ya existente, así que tengo que escribir una nueva.

Linux: Como se mencionó anteriormente, existe algo así como freedesktop.org que define un estándar que las distribuciones de Linux están tratando de cumplir. También hay una subpágina que define las variables de entorno y sus valores predeterminados (si no están configurados, están vacíos por defecto. La aplicación tiene que coincidir con la variable por defecto). Enlace a esa página: freedesktop.org env vars

Vars definido relevante para esta pregunta:

  • $ XDG_DATA_HOME ( local ) (predeterminado en: $ HOME / .local / share )
  • $ XDG_CONFIG_HOME ( local ) (predeterminado en: $ HOME / .config )
  • $ XDG_DATA_DIRS ( global ) (predeterminado en: / usr / local / share / o / usr / share / )
  • $ XDG_CONFIG_DIRS ( global ) (predeterminado a: / etc / xdg )

Windows XP:

  • % APPDATA% (predeterminado en: C: / Documents and Settings {username} / Application data )

  • % CommonProgramFiles% (predeterminado en: C: / Archivos de programa / Archivos comunes ) (archivos de programa compartidos)

  • % CommonProgramFiles (x86)% (predeterminado en: C: / Archivos de programa (x86) / Archivos comunes ) (solo 64 bits) (archivos de programa compartidos)

  • % ProgramFiles% (predeterminado en: % SystemDrive% / Archivos de programa )

  • % ProgramFiles (x86)% (predeterminado en: % SystemDrive% / Archivos de programa (x86) (solo en la versión de 64 bits)) (¡solo para 64 bits!)

Windows Vista +:

  • % APPDATA% (predeterminado en: C: / Users {username} / AppData / Roaming ) (Compartido entre estaciones de trabajo vinculadas. Usuario local. Guardar archivos y configuraciones)
  • % LOCALAPPDATA% (predeterminado en: C: / Users {username} / AppData / Local ) (Usuario local. Guardar archivos y configuraciones)
  • % CommonProgramFiles% (predeterminado en: C: / Archivos de programa / Archivos comunes ) (archivos de programa compartidos)
  • % CommonProgramFiles (x86)% (predeterminado en: C: / Archivos de programa (x86) / Archivos comunes ) (solo 64 bits) (archivos de programa compartidos)

  • % ProgramFiles% (predeterminado en: % SystemDrive% / Archivos de programa ) (Datos estáticos que no cambiarán después de la instalación)

  • % ProgramFiles (x86)% (predeterminado en: % SystemDrive% / Archivos de programa (x86) (solo en la versión de 64 bits)) (solo 64 bits) (datos estáticos que no cambiarán después de la instalación)

  • % ProgramData% (predeterminado en: % SystemDrive% / ProgramData ) (datos modificables que afectan a todos los usuarios)

En resumen: Linux tiene dos variables de entorno que pueden no estar configuradas (una para las configuraciones, otra para los archivos). Windows tiene por lo que puedo decir solo un entorno var para configuraciones y archivos. Utilice estos en lugar de rutas absolutas.


No existe una forma de plataforma cruzada para eso, porque los conceptos que los diferentes OS-s usan son demasiado diferentes para "abstraerse". No estoy familiarizado con las convenciones de * nix y Mac, pero en Windows no existe una "carpeta de inicio" y la aplicación debe especificar si desea almacenar cosas en el perfil móvil ( C:/Users/<username>/AppData/Roaming/<application vendor>/<application name>/ de forma predeterminada) o el perfil local ( C:/Users/<username>/AppData/Local/<application vendor>/<application name>/ de forma predeterminada).

Tenga en cuenta que no puede codificar estas rutas, porque en una instalación en red pueden estar en otro lugar. Tampoco debe confiar en las variables de entorno porque pueden ser modificadas por el usuario. Su aplicación debe llamar a la función SHGetKnownFolderPath de la API de Windows.

La diferencia entre los dos es que el perfil local es específico para el usuario y la máquina, mientras que el perfil móvil es específico para el usuario, por lo que en una configuración como mi universidad, las aplicaciones de material incluidas en el perfil móvil se cargan en el servidor y sincronizado con cualquier computadora en la que me conecte.

Las aplicaciones deben ser las responsables de elegir si las configuraciones que desean almacenar son locales o en itinerancia. Desafortunadamente, Java no permite que las aplicaciones decidan esto. En cambio, hay una configuración global configurable por el usuario que determina qué carpeta obtendrá.


Para cantidades moderadas de datos, considere java.util.prefs.Preferences , mencionado here , o javax.jnlp.PersistenceService , discutido here . Ambos son multiplataforma.


Personalmente, encontré que los appdirs son muy útiles para casos de uso similares. Tiene funciones que ubican diferentes tipos de directorios útiles:

  • getUserDataDir
  • getUserConfigDir
  • getUserCacheDir
  • getUserLogDir
  • getSiteDataDir ← parece que este es el que necesita
  • getSiteConfigDir

Las ubicaciones que devuelve son más o menos estándar:


Probablemente puedas decir algo como (contradícenme si estoy equivocado, o si este es un mal enfoque)

private String workingDirectory; //here, we assign the name of the OS, according to Java, to a variable... private String OS = (System.getProperty("os.name")).toUpperCase(); //to determine what the workingDirectory is. //if it is some version of Windows if (OS.contains("WIN")) { //it is simply the location of the "AppData" folder workingDirectory = System.getenv("AppData"); } //Otherwise, we assume Linux or Mac else { //in either case, we would start in the user''s home directory workingDirectory = System.getProperty("user.home"); //if we are on a Mac, we are not done, we look for "Application Support" workingDirectory += "/Library/Application Support"; } //we are now free to set the workingDirectory to the subdirectory that is our //folder.

Tenga en cuenta que, en este código, aprovecho al máximo que Java trata ''/'' lo mismo que ''//' al tratar con directorios. Windows usa ''//' como pathSeparator, pero también está contento con ''/'' . (Al menos Windows 7 sí lo es). Tampoco distingue entre mayúsculas y minúsculas en sus variables de entorno; podríamos haber dicho fácilmente workingDirectory = System.getenv("APPDATA"); y hubiera funcionado igual de bien.


Puedes usar esto

String currentDir = new File(".").getAbsolutePath();

o esto:

System.getProperty("user.dir")

Prefiero la primera opción

Saludos