Krótka Odpowiedź

• file tylko zgaduje kodowanie pliku i może być błędne (szczególnie w przypadkach, gdy znaki specjalne pojawiają się późno tylko w dużych plikach).
• możesz użyć hexdump, aby spojrzeć na bajty nie-7-bitowego tekstu ASCII i porównać z tabelami kodu dla wspólnych kodowań(ISO 8859 -*, UTF-8), aby samodzielnie zdecydować, jakie jest kodowanie.
• iconv użyje dowolnego kodowania wejścia/wyjścia, które podasz, niezależnie od zawartości pliku. Jeśli podaj błędne kodowanie wejściowe, wyjście zostanie zniekształcone.
• nawet po biegu iconv, file nie może zgłaszać żadnych zmian ze względu na ograniczony sposób, w jaki file próbuje odgadnąć kodowanie. Dla konkretnego przykładu, zobacz moją długą odpowiedź.
• 7-bitowy ASCII (znany również jako US ASCII) jest identyczny na poziomie bajtów z UTF-8 i 8-bitowymi rozszerzeniami ASCII (ISO 8859-*). Więc jeśli Twój plik ma tylko 7-bitowe znaki, możesz nazwać go UTF-8, ISO 8859-* lub US ASCII, ponieważ na poziomie bajtów są one wszystkie są identyczne. Sensowne jest mówienie o UTF-8 i innych kodowaniach (w tym kontekście) tylko wtedy, gdy plik ma znaki spoza 7-bitowego zakresu ASCII.

Długa Odpowiedź

ASCII

Po pierwsze, termin ASCII jest przeciążony, co prowadzi do zamieszania.

7-bitowy ASCII zawiera tylko 128 znaków (00-7F lub 0-127 w układzie dziesiętnym). 7-bitowe ASCII jest również czasami określane jako US-ASCII.

ASCII

UTF-8

Kodowanie UTF-8 używa tego samego kodowania co 7-bitowe ASCII dla pierwszych 128 znaków. Tak więc plik tekstowy, który zawiera tylko znaki z tego zakresu pierwszych 128 znaków, będzie identyczny na poziomie bajtów, bez względu na to, czy jest zakodowany w UTF-8, czy 7-bitowym ASCII.

układ strony kodowej

ISO 8859-* i inne ASCII Rozszerzenia

Termin Rozszerzony ASCII (lub wysoki ASCII) odnosi się do ośmiobitowego lub większego kodowania znaków, które zawiera standardowe siedmiobitowe znaki ASCII, plus dodatkowe znaki.

Rozszerzone ASCII

"rozszerzenie" oznacza, że ISO 8859-1 zawiera 7-bitowy standard ASCII i dodaje do niego znaki za pomocą 8-bitowego. Tak więc dla pierwszych 128 znaków jest to równoważne na poziomie bajtów do plików zakodowanych w ASCII i UTF-8. Jednak, gdy zaczniesz radzić sobie z znakami poza pierwszą 128, nie są już równoważne UTF-8 na poziomie bajtów i musisz wykonać konwersję, jeśli chcesz, aby twój "Rozszerzony ASCII " plik do zakodowania w UTF-8.

ISO 8859 i dostosowania własne

Wykrywanie kodowania za pomocą file

Jedną z lekcji, której się dzisiaj nauczyłem, jest to, że nie możemy ufać file, aby zawsze podawać poprawną interpretację kodowania znaków pliku.

plik (polecenie)

Polecenie mówi tylko jak plik wygląda, a nie jak jest (w przypadku, gdy plik patrzy na zawartość). Łatwo jest oszukać program poprzez umieszczenie magicznej liczby w pliku, którego zawartość nie pasuje. W związku z tym polecenie nie może być użyte jako narzędzie bezpieczeństwa inne niż w określonych sytuacjach.

file szuka magicznych liczb w pliku, które podpowiedzą o typie, ale mogą być błędne, nie ma gwarancji poprawności. file próbuje również odgadnąć kodowanie znaków, patrząc na bajty w pliku. Zasadniczo file ma serię testów, które pomagają odgadnąć Typ pliku i kodowanie.

Mój plik to duży plik CSV. file zgłasza ten plik jako zakodowany w US ASCII, co jest błędne.

$ ls -lh
total 850832
-rw-r--r--  1 mattp  staff   415M Mar 14 16:38 source-file
$ file -b --mime-type source-file
text/plain
$ file -b --mime-encoding source-file
us-ascii

Mój plik ma umlauty w nim (ie Ö). Pierwsze nie-7-bitowe ascii pojawiają się dopiero po ponad 100k linii w pliku. Podejrzewam, że to dlatego file nie zdaje sobie sprawy, że kodowanie plików nie jest US-ASCII.

$ pcregrep -no '[^\x00-\x7F]' source-file | head -n1
102321:�

Jestem na Macu, więc używam PCRE grep. W GNU grep moĹźna uĹźyÄ ‡ opcji -P. Alternatywnie na Macu można zainstalować coreutils (via Homebrew lub inne) w celu uzyskania GNU grep.

Nie zagłębiłem się w kod źródłowy file, a strona podręcznika nie omawia detekcji kodowania tekstu w szczegółach, ale domyślam się, że file nie przegląda całego pliku przed odgadnięciem kodowania.

Jakiekolwiek jest kodowanie mojego pliku, te nie-7-bitowe znaki ASCII psują rzeczy. Mój niemiecki plik CSV jest ;-oddzielony i wyodrębnianie pojedynczej kolumny nie działa.

$ cut -d";" -f1 source-file > tmp
cut: stdin: Illegal byte sequence
$ wc -l *
 3081673 source-file
  102320 tmp
 3183993 total

Uwaga na cut błąd i że mój plik " tmp " ma tylko 102320 linii z pierwszym znakiem specjalnym w linii 102321.

Przyjrzyjmy się, jak te znaki nie-ASCII są kodowane. Wrzucam pierwsze nie-7-bitowe ascii do hexdump, robię małe formatowanie, usuwam nowe linie (0a) i biorę tylko kilka pierwszych.

$ pcregrep -o '[^\x00-\x7F]' source-file | head -n1 | hexdump -v -e '1/1 "%02x\n"'
d6
0a

Inny sposób. Wiem, że pierwszy nie-7-bitowy znak ASCII znajduje się na pozycji 85 na linii 102321. Chwytam tę linię I mówię hexdump, aby wziąć dwa bajty zaczynając od pozycji 85. Możesz zobaczyć specjalny (nie-7-bitowy-ASCII) znak reprezentowany przez ".", a następnym bajtem jest "M"... jest to więc kodowanie jednobajtowe.

$ tail -n +102321 source-file | head -n1 | hexdump -C -s85 -n2
00000055  d6 4d                                             |.M|
00000057

W obu przypadkach widzimy, że znak specjalny jest reprezentowany przez d6. Ponieważ znak ten jest literą Ö, która jest niemiecką literą, domyślam się, że ISO 8859-1 powinien to zawierać. Na pewno widać, że " d6 " pasuje (ISO / IEC 8859-1).

Więc mój plik wydaje się być ISO 8859-1. Teoretycznie powinienem sprawdzić resztę nie-7-bitowych znaków ASCII, aby upewnić się, że ISO 8859-1 dobrze pasuje... Nie ma nic, co zmusza program do używania tylko jednego kodowania podczas zapisu pliku na dysk (inne niż dobre maniery).

$ iconv -f iso-8859-1 -t utf8 source-file > output-file
$ file -b --mime-encoding output-file
us-ascii

Hmm. file nadal mówi mi, że ten plik jest nam ASCII nawet po konwersji. Sprawdźmy z hexdump Jeszcze raz.

$ tail -n +102321 output-file | head -n1 | hexdump -C -s85 -n2
00000055  c3 96                                             |..|
00000057

Ale file nadal zgłasza nasze akta jako us-ascii? Cóż, myślę, że to wraca do punktu o file nie patrząc na cały plik i fakt, że pierwsze nie-7-bitowe znaki ASCII pojawiają się dopiero pod koniec pliku.

Użyję sed aby przykleić Ö na początku pliku i zobaczyć, co się stanie.

$ sed '1s/^/Ö\'$'\n/' source-file > test-file
$ head -n1 test-file
Ö
$ head -n1 test-file | hexdump -C
00000000  c3 96 0a                                          |...|
00000003

Super, mamy umlaut. Uwaga kodowanie to c3 96 (UTF-8). Hmm.

Sprawdzanie jeszcze raz naszych innych umlautów w tym samym pliku:

$ tail -n +102322 test-file | head -n1 | hexdump -C -s85 -n2
00000055  d6 4d                                             |.M|
00000057

ISO 8859-1. UPS! To tylko pokazuje, jak łatwo jest schrzanić kodowanie. Żeby było jasne, udało mi się stworzyć mieszankę kodowania UTF-8 i ISO 8859-1 w tym samym pliku.

Spróbujmy przekonwertować nasz nowy plik testowy za pomocą umlaut (Ö) z przodu i zobaczmy, co się stanie.

$ iconv -f iso-8859-1 -t utf8 test-file > test-file-converted
$ head -n1 test-file-converted | hexdump -C
00000000  c3 83 c2 96 0a                                    |.....|
00000005
$ tail -n +102322 test-file-converted | head -n1 | hexdump -C -s85 -n2
00000055  c3 96                                             |..|
00000057

UPS. Pierwszy umlaut, który był UTF-8 został zinterpretowany jako ISO 8859-1 ponieważ to właśnie powiedzieliśmy iconv. Drugi umlaut jest poprawnie konwertowany z d6 (ISO 8859-1) do c3 96 (UTF-8).

Spróbuję jeszcze raz, ale tym razem użyję Vima do wstawienia Ö zamiast sed. Vim wydawał się lepiej wykrywać kodowanie (jako" latin1 " aka ISO 8859-1), więc być może wstawi nowe Ö ze spójnym kodowaniem.

$ vim source-file
$ head -n1 test-file-2
�
$ head -n1 test-file-2 | hexdump -C
00000000  d6 0d 0a                                          |...|
00000003
$ tail -n +102322 test-file-2 | head -n1 | hexdump -C -s85 -n2
00000055  d6 4d                                             |.M|
00000057

$ file -b --mime-encoding test-file-2
iso-8859-1
$ iconv -f iso-8859-1 -t utf8 test-file-2 > test-file-2-converted
$ file -b --mime-encoding test-file-2-converted
utf-8

Hack (również podatny na awarie), który rozwiązałby to specyficzne ograniczenie file W przypadku dużych plików polegałoby na skróceniu pliku, aby upewnić się, że znaki specjalne (nie-ascii) pojawiają się na początku pliku, więc file jest bardziej prawdopodobne, aby je znaleźć.

$ first_special=$(pcregrep -o1 -n '()[^\x00-\x7F]' source-file | head -n1 | cut -d":" -f1)
$ tail -n +$first_special source-file > /tmp/source-file-shorter
$ file -b --mime-encoding /tmp/source-file-shorter
iso-8859-1

Można wtedy użyć (prawdopodobnie poprawnego) kodowania do feed jako wejście do iconv, aby upewnić się, że konwertujesz poprawnie.

Update

Christos Zoulas zaktualizował file, aby ilość bajtów była konfigurowalna. Jeden dzień turn-around na żądanie funkcji, niesamowite!

Http://bugs.gw.com/view.php?id=533 Zezwalaj na zmianę liczby bajtów do odczytania z analizowanych plików z linii poleceń

Funkcja została wydana w file wersji 5.26.

Patrząc na bardziej Duże plik zanim zgadniesz o kodowaniu wymaga czasu. Jednak dobrze jest mieć opcję dla konkretnych przypadków użycia, w których lepsze odgadnięcie może przeważyć dodatkowy czas i wejścia/Wyjścia.]}

Użyj następującej opcji:

−P, −−parameter name=value

    Set various parameter limits.

    Name    Default     Explanation
    bytes   1048576     max number of bytes to read from file

file_to_check="myfile"
bytes_to_scan=$(wc -c < $file_to_check)
file -b --mime-encoding -P bytes=$bytes_to_scan $file_to_check

... powinno to zadziałać, jeśli chcesz zmusić file do obejrzenia całego pliku przed zgadnięciem. Oczywiście działa to tylko wtedy, gdy masz file 5.26 lub nowszy.

Zmuszanie file do wyświetlania UTF-8 zamiast US-ASCII

Niektóre inne odpowiedzi wydają się skupiać na próbie wyświetlenia UTF-8, nawet jeśli plik zawiera tylko zwykły 7-bitowy ascii. Jeśli to przemyślasz, prawdopodobnie nigdy nie powinieneś tego robić.

1. Jeśli plik zawiera tylko 7-bitowe ascii, ale polecenie file mówi, że plik jest UTF-8, oznacza to, że plik zawiera niektóre znaki z kodowaniem UTF-8. Jeśli to nie jest prawda, może to spowodować zamieszanie lub problemy w dół linii. Jeśli file wyświetla UTF-8, gdy plik zawiera tylko 7-bitowe znaki ascii, byłby to błąd w programie file.
2. każde oprogramowanie, które wymaga sformatowanych plików wejściowych UTF-8, nie powinno mieć problemu z używaniem zwykłego 7-bitowego ascii, ponieważ jest to takie samo na poziomie bajtów jak UTF-8. Jeśli istnieje oprogramowanie, które używa polecenia output file przed zaakceptowaniem pliku jako wejścia i nie przetworzy pliku, chyba że" zobaczy " UTF-8...to kiepski projekt. Argumentowałbym, że jest to błąd w tym programie.

Jeśli bezwzględnie musisz wziąć zwykły 7-bitowy plik ascii i przekonwertować go do UTF-8, po prostu włóż pojedynczy znak nie-7-bitowy ascii do pliku z kodowaniem UTF-8 dla tego znaku i gotowe. Ale nie wyobrażam sobie zastosowania, w którym musiałbyś to zrobić. Najprostszym do użycia znakiem UTF-8 jest znak kolejności bajtów(BOM) który jest specjalnym niedrukowalnym znakiem, który wskazuje, że plik nie jest ASCII. To jest prawdopodobnie najlepszy wybór, ponieważ nie powinien wpływać wizualnie na zawartość pliku, ponieważ na ogół będzie ignorowany.

Kompilatory i Interpretatory Microsoftu, oraz wiele elementów oprogramowania na Microsoft Windows takie jak Notatnik traktują BOM jako wymaganą magię liczba zamiast używać heurystyki. Te narzędzia dodają BOM podczas zapisywania tekst jako UTF-8 i nie może interpretować UTF-8, chyba że bom jest obecny lub plik zawiera tylko ASCII .

To jest klucz:

Lub plik zawiera tylko ASCII

Więc niektóre narzędzia w systemie windows mają problemy z odczytaniem plików UTF-8, chyba że znak BOM jest obecny. Nie ma to jednak wpływu na zwykłe 7-bitowe pliki ascii. Oznacza to, że nie jest to powód zmuszania zwykłych 7-bitowych plików ascii do UTF-8 przez dodanie znaku BOM.

Tutaj jest więcej dyskusji na temat potencjalnych pułapek korzystania z BOM, gdy nie jest to potrzebne (jest to potrzebne dla rzeczywistych plików UTF-8, które są zużywane przez niektórych Microsoft apps). https://stackoverflow.com/a/13398447/3616686

Niemniej jednak, jeśli nadal chcesz to zrobić, byłbym zainteresowany wysłuchaniem twojego przypadku użycia. Oto jak. W UTF-8 BOM jest reprezentowany przez sekwencję hex 0xEF,0xBB,0xBF, więc możemy łatwo dodać ten znak do przodu naszego zwykłego 7-bitowego pliku ascii. Dodając do pliku nie-7-bitowy znak ascii, plik nie jest już tylko 7-bitowym ascii. Zauważ, że nie zmodyfikowaliśmy ani nie przekonwertowaliśmy oryginalnego 7-bitowego ascii treść w ogóle. Dodaliśmy pojedynczy znak nie-7-bitowy ascii na początku pliku, więc plik nie jest już w całości złożony z 7-bitowych znaków ascii.

$ printf '\xEF\xBB\xBF' > bom.txt # put a UTF-8 BOM char in new file
$ file bom.txt
bom.txt: UTF-8 Unicode text, with no line terminators
$ file plain-ascii.txt  # our pure 7-bit ascii file
plain-ascii.txt: ASCII text
$ cat bom.txt plain-ascii.txt > plain-ascii-with-utf8-bom.txt # put them together into one new file with the BOM first
$ file plain-ascii-with-utf8-bom.txt
plain-ascii-with-utf8-bom.txt: UTF-8 Unicode (with BOM) text

Ludzie mówią, że nie możesz i rozumiem, że możesz być sfrustrowany, gdy zadajesz pytanie i otrzymujesz taką odpowiedź.

Jeśli naprawdę chcesz, aby wyświetlał się w UTF-8 zamiast W US ASCII, musisz to zrobić w dwóch krokach.

Pierwszy:

iconv -f us-ascii -t utf-16 yourfile > youfileinutf16.*

Drugi:

iconv -f utf-16le -t utf-8 yourfileinutf16 > yourfileinutf8.*

Jeśli wykonasz file -i, zobaczysz, że nowy zestaw znaków to UTF-8.

Myślę, że Ned ma sedno problemu -- twoje pliki nie są w rzeczywistości ASCII. Try

iconv -f ISO-8859-1 -t UTF-8 file.php > file-utf8.php

Nie ma różnicy między ASCII a UTF-8, więc nie ma potrzeby go rekonwerterować.

Ale tutaj mała wskazówka, jeśli masz problemy z znakami specjalnymi podczas rekodowania.

Dodaj / / TRANSLIT po parametrze source-charset -.

Przykład:

iconv -f ISO-8859-1//TRANSLIT -t UTF-8 filename.sql > utf8-filename.sql

Pomaga mi to w dziwnych typach cudzysłowów, które zawsze przerywają proces ponownego kodowania zestawu znaków.

Oto skrypt, który znajdzie wszystkie pliki pasujące do podanego wzorca, a następnie przekonwertuje je z bieżącego kodowania plików do UTF-8. Jeśli kodowanie jest US ASCII, to nadal będzie wyświetlane jako US ASCII, ponieważ jest to podzbiór UTF-8.

#!/usr/bin/env bash
find . -name "${1}" |
    while read line;
    do
        echo "***************************"
        echo "Converting ${line}"

        encoding=$(file -b --mime-encoding ${line})
        echo "Found Encoding: ${encoding}"

        iconv -f "${encoding}" -t "utf-8" ${line} -o ${line}.tmp
        mv ${line}.tmp ${line}
    done

Możesz użyć file -i file_name, aby sprawdzić, jaki dokładnie jest twój oryginalny format pliku.

Gdy już to dostaniesz, możesz zrobić:

iconv -f old_format -t utf-8 input_file -o output_file

Przypadkowo zakodowałem plik w UTF-7 i miałem podobny problem. Kiedy wpisywałam file -i name.file dostałabym charset=us-ascii.

iconv -f us-ascii -t utf-9//translit name.file nie działa, ponieważ zebrałem UTF-7 jest podzbiorem US ASCII, podobnie jak UTF-8.

Aby to rozwiązać, wpisałem

iconv -f UTF-7 -t UTF-8//TRANSLIT name.file -o output.file

Nie jestem pewien, jak określić kodowanie inne niż to, co inni tu zasugerowali.

Poniższe konwertuje wszystkie pliki w folderze.

Utwórz folder kopii zapasowej oryginalnych plików .

mkdir backup

Konwertuj wszystkie pliki w kodowaniu US ASCII na UTF-8 (Komenda jednowierszowa)

for f in $(file -i * .sql | grep us-ascii | cut -d ':' -f 1); do iconv -f us-ascii -t utf-8 $f -o $ f.utf-8 && mv $f backup / && mv "$f.utf-8" $f; done

Konwertuj wszystkie pliki w kodowaniu ISO 8859-1 na UTF-8 (polecenie jednoliniowe)

for f $(file -i * .sql | grep iso-8859-1 | cut -d ':' -f 1); do iconv -f iso-8859-1 -t utf-8 $f -o $f.utf-8 && mv $f backup / && mv "$f.utf-8" $f; done

Zainspirowany przez odpowiedź Mathieu i odpowiedź Marcelo :

Muszę zobaczyć file -i myfile.htm, aby pokazać UTF-8 zamiast US ASCII (tak, Wiem, że jest to podzbiór UTF-8).

Oto jeden liner zainspirowany poprzednimi odpowiedziami, które przekonwertują na Linuksie wszystkie *.plik htm z US ASCII do UTF-8 więc file -i pokaże Ci UTF-8. Możesz zmienić *.htm (dwa miejsca w poleceniu poniżej), aby dopasować się do Twoich potrzeb.

mkdir backup 2>/dev/null; for f in $(file -i *.htm | grep -i us-ascii | cut -d ':' -f 1); do iconv -f "us-ascii" -t "utf-16" $f > $f.tmp; iconv -f "utf-16le" -t "utf-8" $f.tmp > $f.utf8; cp $fic backup/; mv $f.utf8 $f; rm $f.tmp; done; file -i *.htm