Java - кроссплатформенное чтение UTF-8 файла в одну длинную строку

try(InputStream is = new FileInputStream(fileName)) {
String s = IOUtils.toString(is, StandardCharsets.UTF_8);
}

https://commons.apache.org/proper/commons-io/apidocs/org/apache/commons/io/IO...

да, можно без сторонних библиотек, но ты пока мал для такой магии

Спасибо, пробую, пока нон-статик метод toString не лезет в статик контекст. Но попробую что-то сделать.

public static String toString(InputStream input, String encoding)

нон-статик метод toString

А ты шутник 8)

я прочитал по ссылке public static String toString. но мне то мой компилятор пишет именно то что я написал )

Поздравляю

    public static void loadFile (String fileName) {
        
        Runnable doIt = new Runnable() {
            public void run() {
                String fileAbsolutePath = CurrentDir() + fileName + ".txt";
                try(InputStream is = new FileInputStream(fileAbsolutePath)) {
                    String s = IOUtils.toString(is, StandardCharsets.UTF_8);
                    System.out.println(s);
                } catch (Throwable ex) {
                    System.out.println(ex.getLocalizedMessage());
                }
            }
        };

        try {
            SwingUtilities.invokeAndWait(doIt);
        } catch(Throwable ex) {
            System.out.println(ex.getLocalizedMessage());
        }
    }

Скорее всего я делаю что-то не так, но компилятор продолжает настаивать на нон-статик методе.

Скорее всего я делаю что-то не так

ты импортируешь что-то не то, мне даже странно такое писать.

Возможно я выбрал не то импортировать из списка того. что предложила IDEA. В итоге сердце успокоилось на вот таком коде

                    BufferedReader br = new BufferedReader(
                            new InputStreamReader(
                                    new FileInputStream(fileAbsolutePath), "UTF-8"));
                    final StringBuilder sb = new StringBuilder();
                    String nextString;
                    while ((nextString = br.readLine()) != null) {
                        sb.append(nextString);
                        sb.append("\n");
                    }
                    String s = sb.toString();

Уходи из программирования.

Да ладно, оно большое, всем места хватит :) Спасибо за помощь в любом случае.

Места та хватит, а тот у кого твой код будет незакрытые файлы оставлять спасибо не скажет.

Не, ну я сразу же слазил в первоисточник http://www.skipy.ru/technics/encodings.html и вставил строчку br.close(); Или сам бы потом наткнулся на блокированный файл и устранил причину. Я где-то понимаю вашу категоричность, но все равно продолжу играться.

Вот минимальный код, читающий файл в строку, используя UTF-8.

        File file = new File("test");
        String fileContents;
        try (InputStream fileStream = new FileInputStream(file);
             InputStream bufStream = new BufferedInputStream(fileStream);
             Reader reader = new InputStreamReader(bufStream, StandardCharsets.UTF_8)) {
            StringBuilder fileContentsBuilder = new StringBuilder();
            char[] buffer = new char[1024];
            int charsRead;
            while ((charsRead = reader.read(buffer)) != -1) {
                fileContentsBuilder.append(buffer, 0, charsRead);
            }
            fileContents = fileContentsBuilder.toString();
        } catch (IOException e) {
            throw new RuntimeException(e.getMessage(), e);
        }
        System.out.println(fileContents);

Через массив чаров волшебного размера 1024... А чем плох вот этот код, который я намеревался оставить:

public static String readFileToString (String fileAbsolutePath) throws IOException {

        BufferedReader br = new BufferedReader(
                new InputStreamReader(
                        new FileInputStream(fileAbsolutePath), "UTF-8"));
        final StringBuilder sb = new StringBuilder();
        String nextString;
        while ((nextString = br.readLine()) != null) {
            sb.append(nextString);
            sb.append("\n");
        }
        br.close();
        return sb.toString();
    }

Вызываю этот статический метод везде в попытке, передаю ему или имя только что выбранного файла, или запомненный путь в параметре.

Во-первых, твой код не закрывает файл, если выбрасывается исключение.

Во-вторых он некорректно читает файл. readLine() читает строки с любыми окончаниями: \n, \r, \n\r. Твой код всё это преобразует в \n, т.е. портит исходный текст.

В-третьих он потенциально потребляет больше памяти, когда в файле много длинных строк.

В-четвёртых BufferedReader.readLine использует внутри себя StringBuffer. У этого класса все операции защищены локами, поэтому они могут выполняться дольше аналогичных в StringBuilder-е. В теории JVM может проигнорировать эти локи, но как на практике она себя ведёт, я не знаю.

Мммм, вот так?

String content = (new BufferedReader(new InputStreamReader(new FileInputStream("myfile")))).lines()
            .collect(() -> new StringBuilder(),
                (b, l) -> b.append(l).append(String.format("%n")),
                (b1, b2) -> b1.append(b2))
            .toString()

Нужна Java8.

Еще. Подключаешь Guava и делаешь:

String text = Resources.toString(Resources.getResource("foo.txt"), Charsets.UTF_8);

Legioner, спасибо, я не подозревал о стольких подводных камнях. Текст портит, да, это я понимаю, хотя в моем случае не критично. А остальные моменты буду думать тогда. Или пытаться импортировать что-то другое, чтобы самый первый код у меня все-таки вызывал статический toString.

DiKeert спасибо, попробую. У меня и так требования восьмерки, хотя наверное мое приложение можно было бы написать и на версии меньше. С Guava лаконично смотрится и скорее всего там не дураки - закрывают файлы, лочат что надо и т.п. Сколько она весит только... У меня сейчас все приложение 60 Кб jar-ник, и мне это нравится.

Имхо только для такой маленькой задачки на фоне всего приложения подключать Guava все-таки оверкилл. Буду пробовать остальные варианты, благо их аж 3 предложено уже.

Аааа, я в первом варианте поспешил и согласился с тем, что предложила IDEA - импортировал sun.misc.IOUtils, а надо было org.apache.commons.io.IOUtils :) Или не импортировать и скопипастить вариант Legioner.

Legioner очередное вам спасибо за код и комментарии. Оставлю в проекте ваш вариант - вы не малы для магии, а сторонние либы для таких мелочей я не хочу.

InputStream fileStream = new FileInputStream(file);
             InputStream bufStream = new BufferedInputStream(fileStream);
             Reader reader = new InputStreamReader(bufStream, StandardCharsets.UTF_8)

три обертки, это вин 8)

А что поделаешь, так сделали стандартную библиотеку, максимально разнесли функционал. Зато всё понятно.

Тем временем другие маги подсказали вот такое короткое заклинание

        byte[] fileBytes = Files.readAllBytes(Paths.get(fileAbsolutePath));
        String s = new String(fileBytes, StandardCharsets.UTF_8);

Переходи на python )

Опять же двойной перерасход памяти из-за дублирования. А так нормально. Только Path и File это разные классы, не всегда это может быть удобно.

PS советую подцепить google guava, там очень много полезных методов, она пригождается в любом проекте. С ней это делается ещё проще: Files.toString(file, UTF_8) (класс Files из guava).

советую подцепить google guava,

ТС commons-io не осилил, гуава ему вообще плохо сделает.

ps. Files.readAllBytes оптимальнее гуавы т.к. аллоцирует массив на весь файл сразу, а не по мере наполнения

Legioner, ну мне не Войну и Мир читать, а потом эту строку все равно в АСТ парсить и она соберется коллектором, так что 2 раза по памяти не критично имхо. Что, говорите? Можно сразу из файла в АСТ парсить, минуя строку? Конечно, вы правы. Да еще и небось библиотечным парсером? Наверное, хотя у того, что я пробовал, выделение слов не такое как я хочу. Но это все имхо некритично, если не Война и Мир. За совет про либы спасибо, но пока хотел обойтись своими велосипедами.

subwoofer, кое-кто (а точнее, никто) в этом топике например не осилил дать это двухстрочное заклинание, а ТС не хочет импортить сторонние либы ради утилитарной подзадачи. Так что умерьте ваши понты, выглядит смешно.