[Java] Determinar extensão de ficheiro

[saramgsilva]

Topico original

Devilishly' timestamp='1136854504' post='11408']

Aqui fica uma solução mais robusta para retirar a extensao do ficheiro:

import java.io.File;

public class ParsePathname {
    
    public ParsePathname() { }
    
    public static void main(String[] args) throws Exception {
       File f = new File("c:/program files/adobe/Acrobat 5.0/Reader/acrord32.exe");
       System.out.println("dir : " + f.getParent());
       System.out.println("file : " + f.getName());
       System.out.println("ext : " + getFileExtension(f.getName())); 
       System.out.println("url : " + f.toURL());         
       System.out.println("uri : " + f.toURI()); 
       /*
          output :
          dir : c:\program files\adobe\Acrobat 5.0\Reader
          file : acrord32.exe
          ext : exe
          url : file:/c:/program files/adobe/Acrobat 5.0/Reader/acrord32.exe
          uri : file:/c:/program%20files/adobe/Acrobat%205.0/Reader/acrord32.exe
        */
    }
    
    public static String getFileExtension(String f) {
        String ext = "";
        int i = f.lastIndexOf('.');
        if (i > 0 &&  i < f.length() - 1) {
            ext = f.substring(i+1).toLowerCase();
        }
        return ext;
    }
}

link: http://www.rgagnon.com/javadetails/java-0514.html

Pesquisa no google: http://www.google.pt/search?q=getFileextension+%22.java%22&hl=pt-PT&lr=&start=10&sa=N

É preferivel criar uma classe q implemente a interface Runnable e dp criar uma Thread q chama essa(par a usar o temporizador). Basicamente é isso o q faz a classe Timer de uma forma mais robusta..

[Knitter]

Dois pormenores em relação a esta solução, sim eu sei que é apenas um exemplo mas...

Não é necessário a presença do construtor e o mais importante as excepções são ferramentas de controlo de erros, neste caso a excepção deveria ser apanhada.

Como boa politica as excepções não devem ser propagadas para fora do programa, um utilizador não sabe, nem quer saber, o que é uma "Exception", o que lhe interessava era saber porque raio é que o programa estoirou.

[Dabubble]

Tens razao em relação ao contrutor. Em relação ás excepcoes, não interessa que se apanhem sempre, elas normalmente precisam de ser propagadas até ao utilizador acontece que em pequenos programas a maneira mais simples e facil das propagar simplesmente e por o main a devolver uma excepcao cujo stacktrace e automaticamente impresso na consola, porque apanhar a excepcao e fazer o mesmo?

[Knitter]

A ideia de apanhares as excepções não é para depois escreveres para o output a excepção.

A excepção ao ser apanhada, neste caso sendo uma excepção causada pelo método 'toURL' deveria ser apanhada e ser indicado ao utilizador que as informções do ficheiro estão erradas, se o url não está certo e tendo em conta que o url define uma forma de espressar caminhos de modo universal, então o caminho para o ficheiro não é válido.

É claro que isto é um exemplo e o 'catch' da excepção vai depender do problema em questão, vai depender de onde é aplicada a solução.

Isto é agora opinião pessoal, uma excepção não deve ser propagada até ao utilizador, se existe a necessidade de apanhar uma excepção, o que é o caso uma vez que o método 'toURL' obriga a que seja tratada a excepção, então o que o utilizador deve ver é uma mensagem de erro explicando o que aconteceu. Penso que todos nós gostamos mais de saber que, neste caso, o caminho para o ficheiro está errando em vez de recebermos uma mensagem que diz 'MalformedURLException' 😁

Mas claro que tudo depende do problema, tudo depende da aplicação a ser desenvolvida.

Fiquem bem.

[Dabubble]

quando eu disse propagadas ate ao utilizador referia-me a que o utilizador deve receber feedback, quer sob a forma de stacktrace quer sob a forma de um output que tu produzas, para aplicacoes simples e nao comerciais e como e o caso acho que o stacktrace basta porque podes-te concentrar na logica da aplicacao em vez de andar a mandar outputs bonitos... mas e so uma opiniao.

[Knitter]

Tomei nota opinião 😁 e na realidade subscrevo da mesma opinião, quiz apenas realçar a importância das excepções. Mas tens toda a razão, em casos como este é muito mais importante o programa.

[Knitter]

Deixo aqui uma pequena alternativa ao código apresentado antes.

import java.io.File;

public class FileUtils {

    /**
     * Método que, dando um nome de um ficheiro, devolve a extensao em minusculas
     * De notar que a extensao de um ficheiro apenas tem significado em alguns 
     * sistemas operativos, nomeadamente sistemas operativos Windows. Outros 
     * 
     * @param filename o nome do ficheiro, absoluto ou nao.
     * @return uma String com a extensao do ficheiro convertida para minusculas ou 
     * uma String vazia caso nao seja encontrada uma extensao.
     */
    public static String findExtension(String filename) {
        int x = -1;
        return ((x = filename.lastIndexOf(".")) > 0 ? filename.substring(x + 1) : "").toLowerCase();
    }

    /**
     * Método de conveniência que usa uma instância de java.io.File.
     * 
     * @param file ficheiro para o qual se pretende obter a extensão.
     * @return uma String com a extensão do ficheiro convertida para minúsculas ou 
     * uma String vazia caso não seja encontrada uma extensão.
     */
    public static String findExtension(File file) {
        return FileUtils.findExtension(file.getName());
    }

    /**
     * Remove a extensao de um nome de ficheiro.
     * 
     * @param filename o nome a ler, absoluto ou nao.
     * @return uma String construida atraves da remocao do texto apos o ultimo 
     * ponto, '.', e do proprio ponto ou o nome inalterado caso nao seja encontrada
     * uma extensao
     */
    public static String stripFileExtension(String filename) {
        int x = -1;
        return (x = filename.lastIndexOf(".")) > 0 && x < filename.length() - 1 ? filename.substring(0, x) : filename;
    }
}

Código colocado na wiki em http://wiki.portugal-a-programar.org/java:snippets:fileutils