Ik ben op zoek naar een aantal bestanden uit US-ASCII omzetten naar UTF-8.

Voor dat, ik gebruik iconv:

iconv -f US-ASCII -t UTF-8 file.php > file-utf8.php

Mijn originele bestanden zijn in de VS-ASCII gecodeerd, waardoor de conversie niet gebeuren. Blijkbaar treedt op omdat ASCII is een subset van UTF-8 …

iconv US ASCII naar UTF-8 of ISO-8859-15

En onder vermelding van:

Er is geen noodzaak voor het tekstbestand anders verschijnen totdat non-ASCII
personages worden geïntroduceerd

True. Als ik de invoering van een niet-ASCII-tekens in het bestand en sla het op, laten we zeggen met Eclipse het bestand coderen (karakterset) wordt omgeschakeld naar UTF-8.

In mijn geval, ik wil graag kracht iconv om de bestanden omzetten naar UTF-8 toch . Of er sprake is van niet-ASCII-tekens in het of niet.

Opmerking: De reden is mijn PHP-code (niet-ASCII-bestanden …) houdt zich bezig met een aantal niet-ASCII-reeks, die de snaren veroorzaakt niet goed te worden uitgelegd (Frans):

Il à © Tait une fois … l’homme sà © rie Anima © e mythique d’Albert

Barilla © (Procidis), 1are

…

• US ASCII– – een subset van UTF-8(zie Ned’s antwoord hieronder)
• Dit betekent dat de Amerikaanse ASCII-bestanden zijn eigenlijk gecodeerd in UTF-8
• Mijn probleem ergens anders vandaan kwam

1, Autoriteit 100%

ASCII is een subset van UTF-8, zodat alle ASCII-bestanden al UTF-8-codering. De bytes in het ASCII-bestand en de bytes die zouden voortvloeien uit “coderen aan UTF-8” zou precies hetzelfde bytes. Er is geen verschil tussen hen, dus er is geen noodzaak om iets te doen.

Het lijkt erop dat uw probleem is dat de bestanden zijn niet echt ASCII. Je moet om te bepalen welke coderen ze gebruiken, en transcoderen ze goed.

2, Autoriteit 60%

Kort antwoord

• fileraadt alleen aan de codering van een bestand en kan verkeerd zijn (in het bijzonder in gevallen waarin speciale tekens pas laat verschijnen in grote bestanden).
• U kunt hexdumpgebruiken om te kijken naar bytes van niet-7-bit-ASCII-tekst en vergelijken met code tabellen voor gemeenschappelijke coderingen (ISO 8859 *, UTF-8) om te beslissen voor jezelf wat de codering.
• iconvzal gebruiken wat input / output coderen u opgeven, ongeacht wat de inhoud van het bestand zijn. Als u de verkeerde invoercodering opgeeft, wordt de uitgang vervormd.
• , zelfs na het uitvoeren van iconv, filemag geen melding van eventuele wijzigingen als gevolg van de beperkte manier waarop filepogingen om te raden bij de codering. Voor een specifiek voorbeeld, zie mijn lange antwoord.
• 7-bits ASCII (aka US ASCII) identiek is op byte-niveau UTF-8 en de 8-bit ASCII verlengingen (ISO 8859 *). Dus als uw bestand slechts 7-bits tekens, dan kunt u bellen UTF-8, ISO 8859 * of US ASCII omdat op een byte-niveau zijn ze allemaal identiek zijn. Het heeft alleen zin om te praten over UTF-8 en andere coderingen (in deze context) Zodra uw bestand tekens buiten de 7-bit ASCII range.

Lange antwoord

Ik kwam dit vandaag de dag en kwam over uw vraag. Misschien kan ik een beetje meer informatie toe te voegen om te helpen andere mensen die lopen in deze kwestie.

ASCII

Ten eerste is de term ASCII is overbelast, en dat leidt tot verwarring.

7-bits ASCII tekens bevat alleen 128 (00-7F of 0-127 decimaal). 7-bit ASCII wordt ook wel aangeduid als US-ASCII.

ASCII

UTF-8

UTF-8-codering gebruikt dezelfde codering als 7-bits ASCII voor de eerste 128 tekens. Dus een tekstbestand bevat alleen tekens uit dat bereik van de eerste 128 tekens identiek op een byte-niveau wordt ook gecodeerd met UTF-8 of 7-bits ASCII.

Codepagina-indeling

ISO 8859-* en andere ASCII-extensies

De term uitgebreide ASCII(of hoge ASCII) verwijst naar tekencoderingen van acht bits of groter die de standaard zeven-bits ASCII-tekens bevatten, plus extra tekens.

Uitgebreide ASCII

ISO 8859-1 (ook bekend als “ISO Latin 1”) is een specifieke 8-bits ASCII-uitbreidingsstandaard die de meeste tekens voor West-Europa dekt. Er zijn andere ISO-normen voor Oost-Europese talen en Cyrillische talen. ISO 8859-1 bevat codering voor tekens zoals Ö, é, ñ en ß voor Duits en Spaans (UTF-8 ondersteunt deze tekens ook, maar de onderliggende codering is anders).

“Extensie” betekent dat ISO 8859-1 de 7-bits ASCII-standaard bevat en karakters toevoegt door gebruik te maken van de 8e bit. Dus voor de eerste 128 tekens is ISO 8859-1 op byteniveau equivalent aan zowel ASCII- als UTF-8-gecodeerde bestanden. Wanneer u echter begint te werken met tekens die verder gaan dan de eerste 128, bent u niet langer UTF-8-equivalent op byteniveau en moet u een conversie uitvoeren als u wilt dat uw “uitgebreide ASCII”-gecodeerde bestand UTF-8-gecodeerd is.

ISO 8859 en eigen aanpassingen

codering detecteren met file

Een les die ik vandaag heb geleerd, is dat we fileniet kunnen vertrouwen om altijd de juiste interpretatie te geven van de tekencodering van een bestand.

bestand (opdracht)

De opdracht vertelt alleen hoe het bestand eruitziet, niet wat het is (in het geval dat het bestand naar de inhoud kijkt). Het is gemakkelijk om het programma voor de gek te houden door een magisch getal in een bestand te plaatsen waarvan de inhoud er niet mee overeenkomt. Het commando is dus niet bruikbaar als beveiligingshulpmiddel, behalve in specifieke situaties.

filezoekt naar magische getallen in het bestand die verwijzen naar het type, maar deze kunnen fout zijn, geen garantie voor correctheid. fileprobeert ook de tekencodering te raden door naar de bytes in het bestand te kijken. In feite heeft fileeen reeks tests die het helpen raden naar het bestandstype en de codering.

Mijn bestand is een groot CSV-bestand. filemeldt dit bestand als ASCII-gecodeerd in de VS, wat VERKEERDis.

$ 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

Mijn bestand bevat umlauten (bijv. Ö). De eerste niet-7-bit-ascii verschijnt pas na meer dan 100.000 regels in het bestand. Ik vermoed dat dit de reden is waarom filezich niet realiseert dat de bestandscodering geen US-ASCII is.

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

Ik gebruik een Mac, dus gebruik PCRE’sgrep. Met GNU grep zou je de optie -Pkunnen gebruiken. Als alternatief kan men op een Mac coreutilsinstalleren (via Homebrewof andere) om GNU grep te krijgen.

Ik heb me niet verdiept in de broncode van file, en de man-pagina bespreekt de tekstcoderingsdetectie niet in detail, maar ik vermoed filekijkt niet naar het hele bestand voordat de codering wordt geraden.

Wat de codering van mijn bestand ook is, deze niet-7-bit-ASCII-tekens breken dingen af. Mijn Duitse CSV-bestand is ;-gescheiden en het uitpakken van een enkele kolom werkt niet.

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

Let op de cut-fout en dat mijn “tmp”-bestand slechts 102320 regels heeft met het eerste speciale teken op regel 102321.

Laten we eens kijken hoe deze niet-ASCII-tekens zijn gecodeerd. Ik dump de eerste niet-7-bit-ascii in hexdump, doe een beetje opmaak, verwijder de nieuwe regels (0a) en neem alleen de eerste paar.

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

Een andere manier. Ik weet dat het eerste niet-7-bit-ASCII-teken op positie 85 staat op regel 102321. Ik pak die regel en zeg hexdumpom de twee bytes te nemen vanaf positie 85. Je kunt de speciale ( non-7-bit-ASCII) teken vertegenwoordigd door een “.”, en de volgende byte is “M”… dus dit is een enkelbyte tekencodering.

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

In beide gevallen zien we dat het speciale teken wordt weergegeven door d6. Aangezien dit teken een Ö is, wat een Duitse letter is, vermoed ik dat ISO 8859-1 dit zou moeten bevatten. En ja hoor, je kunt zien dat “d6” een match is (ISO/ IEC 8859-1).

Belangrijke vraag… hoe weet ik of dit teken een Ö is zonder zeker te zijn van de bestandscodering? Het antwoord is context. Ik opende het bestand, las de tekst en bepaalde vervolgens welk teken het zou moeten zijn. Als ik het in Vimopen, wordt het weergegeven als een Ö omdat Vim het beter doet taak van het radenvan de tekencodering (in dit geval) dan filedoet.

Mijn bestand lijkt dus ISO 8859-1 te zijn. In theorie zou ik de rest van de niet-7-bit-ASCII-tekens moeten controleren om er zeker van te zijn dat ISO 8859-1 goed past… Er is niets dat een programma dwingt om slechts één enkele codering te gebruiken bij het schrijven van een bestand naar schijf (behalve goede manieren).

Ik sla de controle over en ga verder met de conversiestap.

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

Hmm. filevertelt me ​​nog steeds dat dit bestand US ASCII is, zelfs na conversie. Laten we het nogmaals controleren met hexdump.

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

Zeker een verandering. Merk op dat we twee bytes niet-7-bit-ASCII hebben (weergegeven door de “.” aan de rechterkant) en de hexadecimale code voor de twee bytes is nu c3 96. Als we kijken, lijkt het erop dat we nu UTF-8 hebben (c3 96is de codering van Öin UTF-8) UTF-8-coderingstabel en Unicode-tekens

Maar filemeldt ons bestand nog steeds als us-ascii? Nou, ik denk dat dit teruggaat naar het punt dat fileniet naar het hele bestand kijkt en het feit dat de eerste niet-7-bit-ASCII-tekens pas laat in het bestand voorkomen.

Ik gebruik sedom een ​​Ö aan het begin van het bestand te plakken en kijk wat er gebeurt.

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

Cool, we hebben een umlaut. Merk echter op dat de codering c3 96(UTF-8) is. Hmm.

Onze andere umlauts in hetzelfde bestand opnieuw controleren:

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

ISO 8859-1. Oeps! Het laat maar weer eens zien hoe gemakkelijk het is om de coderingen te verknoeien. Voor alle duidelijkheid: het is me gelukt om een ​​mix van UTF-8- en ISO 8859-1-coderingen in hetzelfde bestand te maken.

Laten we proberen ons verminkte (gemengde codering) testbestand te converteren met de umlaut (Ö) aan de voorkant en kijken wat er gebeurt.

$ 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

De eerste umlaut die UTF-8 was, werd geïnterpreteerd als ISO 8859-1 aangezien dat is wat we iconvvertelden…niet wat we wilden, maar dat is wat we iconf vertelden te doen . De tweede umlaut is correct geconverteerd van d6(ISO 8859-1) naar c3 96(UTF-8).

Ik zal het opnieuw proberen, maar deze keer zal ik Vim gebruiken om de Ö-invoeging te doen in plaats van sed. Vim leek de codering eerder beter te detecteren (als “latin1” oftewel ISO 8859-1) dus misschien zal het de nieuwe Ö invoegen met een consistente codering.

$ 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

Vim heeft inderdaad de juiste/consistente ISO-codering gebruikt bij het invoegen van het teken aan het begin van het bestand.

Nu de test: herkent een bestand de codering met speciale tekens aan het begin van het bestand beter?

$ 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

Ja, dat doet het! Moraal van het verhaal. Vertrouw niet op fileom altijd uw codering goed te raden. Het is gemakkelijk om coderingen binnen hetzelfde bestand te mixen. Kijk bij twijfel naar de zeshoek.

Een hack die deze specifieke beperking van filezou aanpakken bij het omgaan met grote bestanden, zou zijn om het bestand in te korten om ervoor te zorgen dat speciale (niet-ascii) tekens vroeg in het bestand verschijnen, zodat fileheeft meer kans om ze te vinden.

$ 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

Je zou dan (vermoedelijk correcte) gedetecteerde codering kunnen gebruiken als invoer voor iconvom ervoor te zorgen dat je correct converteert.

Bijwerken

Christos Zoulas heeft filebijgewerkt om het aantal bekeken bytes configureerbaar te maken. Een dag ommekeer op het functieverzoek, geweldig!

http://bugs.gw.com/view.php?id=533
Sta wijzigen toe hoeveel bytes te lezen van geanalyseerde bestanden vanaf de opdrachtregel

De functie is uitgebracht in fileversie 5.26.

Het kost tijd om meer naar een groot bestand te kijken voordat je een gok doet over codering. Het is echter prettig om de optie te hebben voor specifieke gebruikssituaties waarbij een betere schatting opweegt tegen extra tijd en I/O.

Gebruik de volgende optie:

−P, −−parameter name=value
    Set various parameter limits.
    Name    Default     Explanation
    bytes   1048576     max number of bytes to read from file

Zoiets als…

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

… het zou voldoende moeten zijn als je filewilt dwingen het hele bestand te bekijken voordat je een gok doet. Dit werkt natuurlijk alleen als je file5.26 of nieuwer hebt.

Dwingen fileom UTF-8 weer te geven in plaats van US-ASCII

Sommige van de andere antwoorden lijken te zijn gericht op het proberen om fileUTF-8 weer te geven, zelfs als het bestand alleen gewone 7-bits ascii bevat. Als je hier goed over nadenkt, zou je dit waarschijnlijk nooit willen doen.

1. Als een bestand alleen 7-bits ascii bevat, maar de opdracht filezegt dat het bestand UTF-8 is, betekent dit dat het bestand enkele tekens bevat met UTF-8-specifieke codering. Als dat niet echt waar is, kan dit op den duur voor verwarring of problemen zorgen. Als fileUTF-8 weergeeft terwijl het bestand alleen 7-bits ascii-tekens bevat, zou dit een fout zijn in het programma file.
2. Alle software die invoerbestanden in UTF-8-indeling vereist, zou geen enkel probleem moeten hebben om gewone 7-bits ascii te gebruiken, aangezien dit op byteniveau hetzelfde is als UTF-8. Als er software is die de uitvoer van het file-commando gebruikt voordat het een bestand als invoer accepteert en het bestand niet zal verwerken tenzij het UTF-8 “ziet”, dan is dat een behoorlijk slecht ontwerp. Ik zou zeggen dat dit een bug in dat programma is.

Als u absoluut een gewoon 7-bits ascii-bestand moet nemen en dit naar UTF-8 moet converteren, voegt u gewoon een enkel niet-7-bit-ascii-teken in het bestand met UTF-8-codering voor dat teken en u bent klaar . Maar ik kan me geen use-case voorstellen waarin je dit zou moeten doen. Het gemakkelijkste UTF-8-teken om hiervoor te gebruiken is de Byte Order Mark (BOM ) wat een speciaal niet-afdrukbaar teken is dat aangeeft dat het bestand niet-ascii is. Dit is waarschijnlijk de beste keuze omdat het visueel geen invloed mag hebben op de inhoud van het bestand, aangezien het over het algemeen wordt genegeerd.

Microsoft-compilers en -interpreters, en veel stukjes software op
Microsoft Windows, zoals Kladblok, behandelt de stuklijst als een vereiste magie
getal in plaats van heuristieken te gebruiken. Deze tools voegen een stuklijst toe bij het opslaan
tekst als UTF-8, en kan UTF-8 niet interpreteren tenzij de stuklijst aanwezig is
of het bestand bevat alleen ASCII.

Dit is de sleutel:

of het bestand bevat alleen ASCII

Sommige tools op Windows hebben dus problemen met het lezen van UTF-8-bestanden, tenzij het stuklijstteken aanwezig is. Dit heeft echter geen invloed op gewone 7-bits ascii-bestanden. D.w.z. dit is geen reden om gewone 7-bits ascii-bestanden te dwingen UTF-8 te zijn door een stuklijstteken toe te voegen.

Hier is meer discussie over mogelijke valkuilen van het gebruik van de stuklijst wanneer deze niet nodig is (het IS nodig voor daadwerkelijke UTF-8-bestanden die door sommige Microsoft-apps worden gebruikt). https://stackoverflow.com/a/13398447/3616686

Als u het echter nog steeds wilt doen, zou ik graag uw gebruiksvoorbeeld horen. Hier is hoe. In UTF-8 wordt de stuklijst weergegeven door de hexadecimale reeks 0xEF,0xBB,0xBFen dus kunnen we dit teken gemakkelijk toevoegen aan de voorkant van ons gewone 7-bits ascii-bestand. Door een niet-7-bits ascii-teken aan het bestand toe te voegen, is het bestand niet langer alleen 7-bits ascii. Merk op dat we de originele 7-bit-ascii-inhoud helemaal niet hebben gewijzigd of geconverteerd. We hebben een enkel niet-7-bit-ascii-teken aan het begin van het bestand toegevoegd, zodat het bestand niet langer volledig uit 7-bit-ascii-tekens bestaat.

$ 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

Antwoord 3, autoriteit 24%

Mensen zeggen dat je het niet kunt en ik begrijp dat je misschien gefrustreerd bent als je een vraag stelt en een dergelijk antwoord krijgt.

Als je echt wilt dat het wordt weergegeven in UTF-8 in plaats van in US ASCII, moet je dit in twee stappen doen.

Eerst:

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

Tweede:

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

Als u vervolgens een file -idoet, ziet u dat de nieuwe tekenset UTF-8 is.

Antwoord 4, autoriteit 2%

Er is geen verschil tussen US ASCII en UTF-8, dus het is niet nodig om het opnieuw te converteren.

Maar hier een kleine hint, als je problemen hebt met speciale tekens tijdens het hercoderen.

Voeg //TRANSLIT toe na de source-charset-Parameter.

Voorbeeld:

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

Dit helpt me met vreemde soorten aanhalingstekens, die altijd het hercoderingsproces van de tekenset verbreken.

Antwoord 5, autoriteit 2%

Hier is een script dat alle bestanden vindt die overeenkomen met een patroon dat u het doorgeeft, en ze vervolgens converteert van hun huidige bestandscodering naar UTF-8. Als de codering US ASCII is, wordt deze nog steeds weergegeven als US ASCII, aangezien dat een subset is van 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

Antwoord 6

U kunt file -i file_namegebruiken om te controleren wat uw oorspronkelijke bestandsindeling precies is.

Zodra je die hebt gekregen, kun je het volgende doen:

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

Antwoord 7

Ik heb per ongeluk een bestand gecodeerd in UTF-7 en had een soortgelijk probleem. Toen ik file -i name.filetypte, kreeg ik charset=us-ascii.

iconv -f us-ascii -t utf-9//translit name.filezou niet werken omdat ik heb begrepen dat UTF-7 een subset is van US ASCII, net als UTF-8 .

Om dit op te lossen, heb ik meegedaan

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

Ik weet niet zeker hoe ik de codering kan bepalen, behalve wat anderen hier hebben gesuggereerd.

Antwoord 8

vim -es '+set fileencoding=utf-8' '+wq!' file

-esvoert vim uit in de modus exen script, dus er wordt niets weergegeven. Dan voert het de opdracht uit waar de bestandscodering is ingesteld (vim zorgt voor de details) en dan wordt het bestand gesloten ‘+wq!’.

Ik ben laat met de vraag, maar de eerdere antwoorden met iconvvoldeden gewoon niet en lieten het bestand in een staat achter zonder utf-8-tekens, zelfs bij het toevoegen van -com die te laten vallen.

Antwoord 9

Het volgende converteert alle bestanden in een map.

Maak een back-upmap van originele bestanden.

mkdir backup

Converteer alle bestanden in Amerikaanse ASCII-codering naar UTF-8 (opdracht met één regel)

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

Converteer alle bestanden in codering ISO 8859-1 naar UTF-8 (opdracht van één regel)

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

Antwoord 10

Veel geïnspireerd door Mathieu’s antwoorden Marcelo’s antwoord:

Ik heb de behoefte om file -i myfile.htmte zien om UTF-8 weer te geven in plaats van US ASCII (ja, ik weet dat het een subset van UTF-8 is).

Dus hier is een one-liner geïnspireerd op eerdere antwoorden die op Linux alle *.htm-bestanden van US ASCII naar UTF-8 zal converteren, zodat file -iu UTF-8 zal laten zien. U kunt *.htm (twee plaatsen in de onderstaande opdracht) naar wens wijzigen.

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

Antwoord 11

Ter info, filecontroleert niet de hele inhoud (zoals al vermeld in het lange antwoord van mattpr) om standaard de codering van een bestand te detecteren. Om ervoor te zorgen dat de hele inhoud wordt gescand voor detectie van tekensets, kan deze code worden gebruikt…

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

Zie ook de bijbehorende handleiding https://man7.org/linux /man-pages/man1/file.1.html