LINUX.ORG.RU
 

[21 век][технологии] iconv


0

0

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

Где я возьму столько памяти? НЕНАВИСТЬ!

Неужели так трудно конвертировать на лету?


 ← 1 2 →
[#]  
elf

>Где я возьму столько памяти? НЕНАВИСТЬ!

Это что же ты такое конвертируешь?

()
[#] Ответ на: комментарий от NekoExMachina 10.04.2010 1:45:32  

Можно написать костыль для выдирания небольших кусков и последующего конвертирования. Но мне почему-то кажется, что лучше такой костыль засунуть сразу в iconv. Не?

*** ()
[#] Ответ на: комментарий от elf 10.04.2010 1:45:54  

> Это что же ты такое конвертируешь?

Файлы. Большие. Гига по три.

*** ()
[#] Ответ на: комментарий от melkor217 10.04.2010 1:46:44  
NekoExMachina

патч@отправляй
._.
btw, так, емнип, все coreutils'ы поступают.

* ()
[#] Ответ на: комментарий от melkor217 10.04.2010 1:47:08  
elf

3 гига в текстовом файле это какой-то нонсенс

()
[#]  

Уже говорили: перепиши. Т.к. для детального анализа доминирующей кодировки, все-таки, надо просмотреть весь файл. А как-то не предполагается, что бывают текстовые файлы гигабайтных размеров. Я вообще не представляю, что в таком файле может быть?

**** ()
[#] Ответ на: комментарий от elf 10.04.2010 1:48:49  

Зато в сжатом виде - 200 метров всего ._.

*** ()
[#] Ответ на: комментарий от Eddy_Em 10.04.2010 1:49:52  

> Уже говорили: перепиши. Т.к. для детального анализа доминирующей кодировки, все-таки, надо просмотреть весь файл.

вообще-то, я её явно указываю

> А как-то не предполагается, что бывают текстовые файлы гигабайтных размеров. Я вообще не представляю, что в таком файле может быть?

текст

*** ()
[#]  
NekoExMachina

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

* ()
[#] Ответ на: комментарий от NekoExMachina 10.04.2010 1:59:30  
NekoExMachina

iconv (GNU libiconv 1.13)
Copyright (C) 2000-2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.

* ()
[#]  
dan@dan-desktop:~$ iconv -f cp1251 -t utf8 file
iconv: невозможно открыть входной файл «file»: Значение слишком велико для такого типа данных
dan@dan-desktop:~$ iconv --version
iconv (Debian EGLIBC 2.10.2-6) 2.10.2
Copyright (C) 2009 Free Software Foundation, Inc.
Это свободная программа; подробности об условиях распространения
смотрите в исходном тексте.  Мы НЕ предоставляем гарантий; даже гарантий
КОММЕРЧЕСКОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ КАКОЙ-ЛИБО ЦЕЛИ.
Автор программы -- Ulrich Drepper.
dan@dan-desktop:~$
*** ()
[#] Ответ на: комментарий от melkor217 10.04.2010 2:02:11  
NekoExMachina

file1: data
1.2G file1
Mem: 568M Active, 275M Inact, 731M Wired, 21M Cache, 360M Free
свопа нету.
все нормально проходит и файл конвертируется.
единственный минус - файл взят из /dev/random.

* ()
[#] Ответ на: комментарий от melkor217 10.04.2010 1:47:08  
AP

> Оказывается, оно перед тем, как начать конвертировать, загоняет весь файл в оперативку.
> Файлы. Большие. Гига по три.

Может хватит уже заниматься пермутацией Торы? :)

***** ()
[#] Ответ на: комментарий от NekoExMachina 10.04.2010 2:00:09  

Хм, у меня iconv из eglibc вообще. Вот кого надо пинать )

*** ()
[#] Ответ на: комментарий от melkor217 10.04.2010 1:47:08  
petrosyan

>Файлы. Большие. Гига по три.

Сурово

*** ()
[#] Ответ на: комментарий от NekoExMachina 10.04.2010 2:04:41  

> файл взят из /dev/random.

точно из /dev/random? быстро там гигабайт набежал?)

*** ()
[#]  

Переконвертируй в потоке

***** ()
[#] Ответ на: комментарий от annoynimous 10.04.2010 2:07:02  

> Переконвертируй в потоке

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

*** ()
[#]  

Скорее всего, дело в простенькой реализации в eglibc

*** ()
[#]  

Кстати, гугль выдает костыли по запросу "iconv large file", так что дерзай.

* ()
[#] Ответ на: комментарий от melkor217 10.04.2010 1:50:58  
elf

>> Это что же ты такое конвертируешь?

>Файлы. Большие. Гига по три.

>>не представляю, что в таком файле может быть?

>текст

КЭП конвертирует файлы

()
[#] Ответ на: комментарий от anotheranonymous 10.04.2010 2:11:44  

> Кстати, гугль выдает костыли по запросу "iconv large file", так что дерзай.

Да там и свои недолго написать. Это нытик-тред же, тег забыл просто. Ваш линукс не готов для десктопа и все дела )

*** ()
[#] Ответ на: комментарий от NekoExMachina 10.04.2010 2:13:53  

> чуть больше двух минут.

удивительно. по-хорошему, для таких целей urandom надо использовать, не?

*** ()
[#] Ответ на: комментарий от melkor217 10.04.2010 2:14:34  

>Ваш линукс не готов для десктопа и все дела )
Попробовал бы ты в винде такую же проблему обойти в гуевой проге какой нибудь, посмотрел бы я на тебя :D

* ()
[#] Ответ на: комментарий от melkor217 10.04.2010 2:14:34  

костыль уже есть -- piconv

***** ()
[#]  
f3ex 
$ split -b 100M text.txt
$ for file in $(ls ./x*); do iconv -c -f -t ... $file > $file.utf8; done
$ cat x*.utf8 > newtext.txt
* ()
[#] Ответ на: комментарий от f3ex 10.04.2010 2:19:15  

А вот и не угадал. Тот же utf8 под такое пустить нельзя.

*** ()
[#] Ответ на: комментарий от melkor217 10.04.2010 2:21:14  
f3ex

ну побьется у тебя пару символов =)

* ()
[#] Ответ на: комментарий от f3ex 10.04.2010 2:22:26  

Можно резать по строкам или пробелам - но их тоже может не быть. Так что написать хороший костыль не так уж и легко.

*** ()
[#] Ответ на: комментарий от f3ex 10.04.2010 2:22:26  
f3ex

ну или по строкам разбить.

* ()
[#] Ответ на: комментарий от melkor217 10.04.2010 2:15:59  
NekoExMachina

[3970] [neko][1]%time dd if=/dev/urandom of=/dev/null bs=4M count=250 [part2/null]
250+0 records in
250+0 records out
1048576000 bytes transferred in 13.241987 secs (79185699 bytes/sec)
dd if=/dev/urandom of=/dev/null bs=4M count=250 0.00s user 13.24s system 99% cpu 13.244 total
[3971] [neko][0]%time dd if=/dev/random of=/dev/null bs=4M count=250 [part2/null]
250+0 records in
250+0 records out
1048576000 bytes transferred in 13.241083 secs (79191105 bytes/sec)
dd if=/dev/random of=/dev/null bs=4M count=250 0.00s user 13.24s system 99% cpu 13.244 total

* ()
[#] Ответ на: комментарий от NekoExMachina 10.04.2010 2:25:33  

а может и такое быть

dan@dan-desktop:~$ dd if=/dev/urandom of=/dev/null bs=4M count=25
25+0 записей считано
25+0 записей написано
скопировано 104857600 байт (105 MB), 21,6888 c, 4,8 MB/c
dan@dan-desktop:~$ dd if=/dev/random of=/dev/null bs=4M count=25
^C0+8 записей считано
0+8 записей написано
скопировано 80 байт (80 B), 21,2269 c, 0,0 kB/c

*** ()
[#] Ответ на: комментарий от NekoExMachina 10.04.2010 2:25:33  

Это в каком-таком дистрибутиве такой говно-/dev/random ?

***** ()
[#] Ответ на: комментарий от sdio 10.04.2010 2:30:42  

Или просто очень много шумов

*** ()
[#] Ответ на: комментарий от melkor217 10.04.2010 2:31:04  

Нет, их просто не может быть так много >_<

*** ()
[#]  
f3ex

Если из 1251 в UTF-8, то за час можно было бы уже написать утилитку для побайтного чтения исходного файла и посимвольной перекодировки и записи в новый файл. Если наоборот кодировка, то да, будет посложнее, но думаю решаемо =)

* ()
[#] Ответ на: комментарий от sdio 10.04.2010 2:30:42  
NekoExMachina

FreeBSD, по документации разница между random и urandom такая же, как и в линуксах
алсо, скорее всего urandom должен быстрее random'а обрабатываться, однако скорость их обработки упирается в потолок где-нибудь в более другом месте, нежели cpu.

* ()
[#] Ответ на: комментарий от f3ex 10.04.2010 2:34:01  

Конечно решаемо. Я думал, что iconv примерно так и написан )

*** ()
[#] Ответ на: комментарий от melkor217 10.04.2010 2:36:51  
f3ex

Когда он был задуман, наверно думали, что 640Кб (или сколько там) хватит всем =)

Как можно замерить сколько памяти занял процесс при выполнении?

* ()
[#] Ответ на: комментарий от NekoExMachina 10.04.2010 2:35:12  

NekoExMachina> FreeBSD, по документации разница между random и urandom такая же, как и в линуксах

Гонишь:

The FreeBSD operating system implements a 256-bit variant of the Yarrow algorithm to provide a pseudorandom stream — this replaced a previous Linux style random device. Unlike the Linux /dev/random, the FreeBSD /dev/random never blocks. It is similar to the Linux /dev/urandom, intended to serve as a cryptographically secure pseudorandom number generator rather than based on a pool of entropy (FreeBSD links urandom to random).

***** ()
[#] Ответ на: комментарий от f3ex 10.04.2010 2:38:17  

> Когда он был задуман, наверно думали, что 640Кб (или сколько там) хватит всем =)

Думаешь, лишние проходы прибавляют производительности? Это ведь настолько очевидно, что нужно посимвольно обрабатывать ._.

*** ()
 ← 1 2 →
Talks