Я записал этот небольшой сценарий несколько лет назад и использовал его с тех пор. В любом случае это - интересное злоупотребление printf
и использует прекрасную функцию Bash, который я, к сожалению, редко вижу в сценариях: typeset
.
#!/usr/bin/env bash
# Released into public domain
# Aaron Bockover, 2005
# http://abock.org
typeset -i length; length=$1
typeset -i rounds; rounds=$2
[ $rounds -lt 1 ] && rounds=1
[ $length -lt 1 ] && {
echo "Usage: $0 <length> [<rounds>]" 2>/dev/null; exit 1;
}
for ((i=0; i < $rounds; i++)); do
for ((j=0; j < $length; j++)); do
set=$(($RANDOM % 20))
if [ $set -le 6 ]; then o=65; l=26; # 35% uppercase
elif [ $set -le 13 ]; then o=97; l=26; # 35% lowercase
elif [ $set -le 17 ]; then o=48; l=10; # 20% numeric
elif [ $set -le 18 ]; then o=58; l=7; # 10% symbolic
elif [ $set -le 19 ]; then o=33; l=15; fi
ord=$(($o + $RANDOM % $l))
printf \\$(($ord / 64 * 100 + $ord % 64 / 8 * 10 + $ord % 8))
done
echo
done
То, что Вы имеете, является на самом деле ASCII (в его обычном кодировании в 8-разрядных байтах) с небольшим количеством UCS-2 (Unicode, ограниченный основной плоскостью (BMP), где каждый символ кодируется поскольку два 8-разрядных байта), или возможно UTF-16 (расширение UCS-2, который может закодировать весь Unicode при помощи кодирования многословного для кодовых точек выше U+D7FF).
Я сомневаюсь, что Вы найдете инструмент, который может обработать такую безобразную смесь из поля. Нет никакого способа декодировать файл в полной общности. В Вашем случае, что, вероятно, произошло, то, что некоторые данные ASCII были закодированы в UTF-16 в какой-то момент (Windows, и Java любят UTF-16; они практически неслыханны в мире Unix). Если Вы идете предположением, что исходными данными был весь ASCII, можно восстановить применимый файл путем снятия изоляции со всех пустых байтов.
<bizarre tr -d '\000' >ascii
Файл, который является "ASCII, за исключением нескольких символов UTF-8" является, ну, в общем, просто файлом UTF-8.
Это видимо/доступно для поиска/доступно для редактирования, пока Вы используете локаль UTF-8.
Вы не можете преобразовать его в ASCII, поскольку у последнего нет эквивалентного представления для Ваших специальных символов UTF-8.
Вы могли бы хотеть преобразовать в изолатынь с
iconv -f UTF-8 -t ISO-8859-1
Если у Вас есть файл, который содержит ASCII с несколькими символами UTF-8, то это - по определению файл UTF-8. Чистый ASCII-файл является также допустимым UTF-8.
Это походит на то, что Вы имеете, соединение ASCII, UTF-8 и некоторого другого однобайтового кодирования как латинский 1. Это трудно очистить. Но трудно дать хороший совет, не зная то, что на самом деле содержит файл. Попытайтесь отправить вывод hexdump -C file
(сокращение его к нескольким строкам, которые содержат проблемные символы).
Попробовать chardet
от пакета python-chardet
- Я сейчас попробовал его на файле который enca
не мог распознать... chardet
обнаруженный тип набора символов. (accordint к странице справочника, enca обозначает Чрезвычайно Наивный Набор символов, Анализируют :)
Если Вы не можете обнаружить тип, то перекодирование довольно бесполезно, поскольку перекодер должен знать формат ввода (см. наборы символов Обнаружения, ниже),
Можно попробовать toopen файл в другом текстовом редакторе, например. emacs
, vim
, jedit
, и т.д.
gedit
имеет опцию Choose/Add/Remove, в он - Файл Открытое диалоговое окно. Можно выбрать/добавить наборы символов к списку набора символов (после того как Вы знаете то, что это).. gedit
только открывает типы, показанные в том списке.
Далее, это может быть файл Текстового процессора.. Попытайтесь открыть его с OpenOffice.org.
Другой (отчаянная (?) опция, пользователю strings
.
strings
распечатает строки печатаемых символов в файлах.
Обнаружение наборов символов чревато проблемами. Для многих основанных на латинском сценарии языков (который Ваш, кажется), существует много изменений набора символов. Единственной общей темой для этих наборов символов является базовый 7-разрядный набор символов ASCII, который состоит из 128 возможностей для шестнадцатеричного \x00 к \x7F..
Любой из многих однобайтовых наборов символов, который использует 8-й бит (еще 128 букв) использует этот верхний диапазон в в качестве многих различных путей, поскольку существуют наборы символов..
Если Вы не знаете, каково кодирование, это часто - игра статистической вероятности для обнаружения его (инженерный анализ), потому что программа обнаружения понятия не имеет, что обозначает буквами, это смотрит на; это только видит значения байта. Когда не исключительно определение differnce обнаруживается (не простая задача), затем единственный курорт должен выбрать чаще всего используемый набор символов, который соответствует.
Нижняя строка - то, что, даже если файл содержит абсолютно допустимый набор символов A, это может выглядеть одинаково допустимым к программе обнаружения, как делает набор символов B... Это - самая причина, почему нужно знать кодирование charcter! - специально для наборов символов, которые используют только однобайтовое.
Многобайтовый набор символов имеет намного более очевидный отпечаток пальца, но даже затем, если демонстрационный набор не является достаточно большим, это - снова игра предположения...