[Creat0R]

Альтернатива подобной функции:

Код:

Func _FileReadToArray($sFilePath)
    ;==============================================
    ; Local Constant/Variable Declaration Section
    ;==============================================
    Local $hFile = FileOpen($sFilePath, 0)
    Local $RetArr[1], $Line, $i=1

        If $hFile = -1 Then Return SetError(1)

        While 1
        $Line = FileReadLine($hFile, $i)
        If @error = -1 Then ExitLoop
        If $Line <> "" Then
            ReDim $RetArr[UBound($RetArr)+1]
            $RetArr[UBound($RetArr)-1] = $Line
        EndIf
        $i += 1
    WEnd
    $RetArr[0] = UBound($RetArr)-1

        FileClose($hFile)
    Return $RetArr
EndFunc

Возможно немного(?) медленней, но зато в массив не попадают пустые строки

[Diamond]

Creat0R
Они туда попадают, потому что ты их с самого начала записываешь в текстовой файл.
Пожалуй возьму эту функцию на вооружение... Но всё таки, мне кажется что я сделал всё правильно...

[Creat0R]

Diamond

Я посмотрел содержимое файла в редакторе "Bred" и... оказалось что полученный массив полностью соответствует текстовому файлу... 6 строк, первая и последняя пустые.

Это я вижу и в Notepad(2 ), но мне кажется в массив не должны попадать пустые строки, и я считал что пустая строка, это и есть сочетание символов @LF и @CR, и что функция StringSplit() должна поделить на элементы которе не будут содержать тот символ на который делим (используя к примеру, в качестве третьего параметра, 1 - использовать все символы разделителя как метку деления, т.е не вносить сами символы в полученные элементы).

[amel27]

Creat0R, Diamond

Теперь у меня началось - надеюсь это не заразно

нет, этого нельзя так оставлять ...для начала нужно ответить на вопросы:

- считать ли пустой строкой промежуток между началом файла и разделителем (@LF/@CR);
- считать ли пустой строкой промежуток между и спецсимволом и концом файла;
- как разбивать на пустые строки произвольную последовательность разделителей.

Обычно за разделитель считают именно @LF, а все вхождения @CR просто удаляют, соответственно последовательность @LF@LF будет означать "разделитель-пустая строка", при этом ответ на первые два вопроса чаще положительный... Можно договориться считать за разделители @CR и @LF, тогда последовательность @CRLF опять же вернет пустую строку (между ними). Мне представляется наиболее удобным следующий вариант:

- ДА
- НЕТ
- разделители: пары @CRLF/@LFCR и в последнюю очередь одиночные @CR и @LF

реализация через RegExp:

Код:

$array = StringRegExp(FileRead ("Test.txt"),'(?s)(.*?)(?:\n\r|\r\n|[\n\r])', 3)

P.S. Ктати, в RegExp метасимволы '^' и '$' по умолчанию различают только позиции в начале и конце файла (т.е. всей строки), а с модификатором '(?m)' указывают на позиции после- и перед- @LF соответственно...

[Creat0R]

amel27

реализация через RegExp:

Хм... попробуй подобный пример:

Код:

#include <Array.au3>

$TestFileHandle = FileOpen("Test.txt", 2)

FileWrite($TestFileHandle, @CR & "Line1" & @LF & @CR & @LF & @CR & @LF & @CR & "Line2" & @CR & "Line3" & @LF & "Line4" & @CRLF)

FileClose($TestFileHandle)

Dim $Array
_FileReadToArray("Test.txt", $Array)

_ArrayDisplay($Array)

Func _FileReadToArray($sFilePath, ByRef $RetArr)
    Local $hFile = FileOpen($sFilePath, 0)
    If $hFile = -1 Then Return SetError(1)

        $RetArr = StringRegExp(FileRead($hFile), '(?s)(.*?)(?:\n\r|\r\n|[\n\r])', 3)
    $RetArr[0] = UBound($RetArr)-1

        FileClose($hFile)
    Return $RetArr
EndFunc

В массив попадают несколько пустных строк...

Кстати, я проверил скорость выполнения функции - С использованием RegExp, в 5-6 раз быстрее чем используя цикл, но зато при использовании цикла возвращаются только текстовые строки

[amel27]

Creat0R

В массив попадают несколько пустных строк

Все правильно, так и запрограммировано - (@LFCR & @LFCR & @LFCR) это разделитель из двух пустых строк... проблема не в том, что остаются пустые строки (почему бы им не быть?), а в том что этими строками считать... Проигнорировать пустые строки как раз проще:

Код:

$RetArr = StringRegExp(FileRead($hFile),'(?s)(.*?)[\n\r]+', 3)

ADD: или так:

Код:

$RetArr = StringRegExp(FileRead($hFile),'([^\n\r]+)', 3)

З.Ы. StringRegExp() возвращает массив без счетчика.. т.е. первый элемент занят!

[Diamond]

amel27

Обычно за разделитель считают именно @LF, а все вхождения @CR просто удаляют

Т.е. получается... что функция _FileReadToArray() написана правильно?

- ДА - НЕТ - разделители: пары @CRLF/@LFCR и в последнюю очередь одиночные @CR и @LF

Я думал что символы @LFCR не могут сосуществовать вместе, т.е. должна получаться пустая строка...
...Если общего правила не существует - то этот вариант, как мне кажется, наиболее подходит.
-Да

[Creat0R]

amel27

или так:

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

StringRegExp() возвращает массив без счетчика.. т.е. первый элемент занят!

Хм... а вот это уже немного досадно... а самой функцией StringRegExp нельзя подвинуть все полученные элементы? пусть даже первый элемент будет содержать пустую строку, его то потом просто можно заменить ($RetArr[0] = Ubound($RetArr)-1).

[amel27]

Diamond

Если общего правила не существует

в отличие от никсов текстовый файл, сформировнный в Windows не должен содержать одиночных @LF или @CR, только в паре @CRLF - для таких файлов _FileReadToArray() работает правильно

Creat0R

нельзя подвинуть все полученные элементы?

а оно того стоит?... зачем городить огород, для совместимости?.. не вижу смысла оформлять UDF ради одной строчки кода

[Creat0R]

amel27

а оно того стоит?.

Если нет необходимости перебирать массив, то да.

не вижу смысла оформлять UDF ради одной строчки кода

Иногда в скрипте нужно по несколько раз вызывать _FileReadToArray(), не писать же каждый раз одну и туже строку содержащюю две-три комманды