---

Hejsa

Jeg kan sgutte gennemskue det her med encoding...

Jeg har skrevet en lille web crawler i Python, som - givet en startside -
henter en side, finder links på siden og så fremdeles. De hentede sider
gemmes på disken i et format der ser ud som følger:

<url>
<antal tegn>
<den hentede side>
<... og så det samme igen indtil filen bliver større end 10 MB>

Hvis jeg henter denne fil ind i f.eks. Quanta og kigger på den i
ISO-8859-1 encoding, så er danske tegn fine - det er de så ikke hvis jeg
i stedet bruger UTF-8.

Det er så ikke forstår er, at hvis jeg printer filen til en terminal,
hvori jeg har

export LANG="en_us.ISO-8859-1"

så er (et udsnit af) resultatet som følger:

JP Master vil rumme en lang r<C3><A6>kke fordele og en ny m<C3><A5>de at
l<C3> <A6>se avis p<C3><A5>. Som en lille appetitv<C3><A6>kker har vi
p<C3><A5> denne side samlet en oversigt med hovedelementerne og de mange
tilbud, som de best<C3><A5>r af.

Men hvis jeg i stedet har

export LANG="en_us.UTF-8"

så fejler de danske tegn intet.

Forklaring ønskes for nu har jeg snart råbt mange grimme om til
computeren, men det hjæler ikke...

Mvh.
/Thomas

---

On Sun, 26 Sep 2004 14:42:28 +0200, Thomas Lindgaard wrote:

> Det er så ikke forstår er, at hvis jeg printer filen til en terminal,
> hvori jeg har
>
> export LANG="en_us.ISO-8859-1"
>
> så er (et udsnit af) resultatet som følger:
>
> JP Master vil rumme en lang r<C3><A6>kke fordele og en ny m<C3><A5>de at
> l<C3> <A6>se avis p<C3><A5>. Som en lille appetitv<C3><A6>kker har vi
> p<C3><A5> denne side samlet en oversigt med hovedelementerne og de mange
> tilbud, som de best<C3><A5>r af.
>
> Men hvis jeg i stedet har
>
> export LANG="en_us.UTF-8"
>
> så fejler de danske tegn intet.
>
> Forklaring ønskes for nu har jeg snart råbt mange grimme om til
> computeren, men det hjæler ikke...
>
Danske tegn har andre koder i iso-8859-1 og utf-8. De resterende fra
latin1 - ascii7, er ens. Du kan gøre følgende:
iconv -f utf8 -t latin1 -o nyfil fil. En tilsvarende metode findes også
til python.

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Make input easy to proofread.
- The Elements of Programming Style (Kernighan & Plaugher)

---

On Sun, 26 Sep 2004 14:59:57 +0200, Michael Rasmussen wrote:

> Danske tegn har andre koder i iso-8859-1 og utf-8. De resterende fra
> latin1 - ascii7, er ens. Du kan gøre følgende:
> iconv -f utf8 -t latin1 -o nyfil fil. En tilsvarende metode findes også
> til python.

Joh men... det forklarer ikke (for mig i hvert fald) hvorfor en fil i
iso-8859-1 kommer til at se mærkelig ud i en gnome-terminal, hvor
encoding via menuen er sat til iso-8859-1, og hvor
LANG="en_us.ISO-8859-1".

Hvis jeg fyrer iconv-kommandoen af, så fejler den på første danske
tegn, da filen netop ikke er i utf8-format.

Med andre ord: Det der undrer mig er, at følgende kombination er det der
virker:

1) en fil i iso-8859-1
2) en gnome-terminal hvor encoding er sat til iso-8859-1
3) export LANG="en_us.UTF8"

Hvorfor skal LANG sættes til noget andet end de andre?

Mvh.
/Thomas

---

On Sun, 26 Sep 2004 15:10:58 +0200, Thomas Lindgaard wrote:

>
> Joh men... det forklarer ikke (for mig i hvert fald) hvorfor en fil i
> iso-8859-1 kommer til at se mærkelig ud i en gnome-terminal, hvor
> encoding via menuen er sat til iso-8859-1, og hvor
> LANG="en_us.ISO-8859-1".
Hvad er default for din disp?
>
> Hvis jeg fyrer iconv-kommandoen af, så fejler den på første danske
> tegn, da filen netop ikke er i utf8-format.
Hvis filen er i iso-8859-1, er det nok fordi din disp. har andet tegnsæt
som default
>
> Hvorfor skal LANG sættes til noget andet end de andre?
>
beats me
--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
mir <at> datanom <dot> net
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plaugher)

---

On Sun, 26 Sep 2004 16:23:32 +0200, Michael Rasmussen wrote:

>> Joh men... det forklarer ikke (for mig i hvert fald) hvorfor en fil i
>> iso-8859-1 kommer til at se mærkelig ud i en gnome-terminal, hvor
>> encoding via menuen er sat til iso-8859-1, og hvor
>> LANG="en_us.ISO-8859-1".
>
> Hvad er default for din disp?

Jeg kører Gentoo på en AMD64 og echo $LANG i en ny term giver intet
output.

>> Hvis jeg fyrer iconv-kommandoen af, så fejler den på første danske
>> tegn, da filen netop ikke er i utf8-format.
> Hvis filen er i iso-8859-1, er det nok fordi din disp. har andet tegnsæt
> som default

Mjaeh - jeg går da ud fra at filen er i iso-8859-1 :) En

iconv -f iso-8859-1 -t ... <fil>

brokker sig i hvert fald ikke.

>> Hvorfor skal LANG sættes til noget andet end de andre?
>>
> beats me

Me too :'(

Mvh.
/Thomas

---

On Tue, 28 Sep 2004 12:03:01 +0200, Thomas Lindgaard wrote:

>> Hvis filen er i iso-8859-1, er det nok fordi din disp. har andet tegnsæt
>> som default
>
> Mjaeh - jeg går da ud fra at filen er i iso-8859-1 :) En
>
> iconv -f iso-8859-1 -t ... <fil>
>
> brokker sig i hvert fald ikke.

Hvad er egentlig den nemmeste måde at bestemme en fils encoding på?

Mvh.
/Thomas

---

Thomas Lindgaard skrev:

> Hvad er egentlig den nemmeste måde at bestemme en fils encoding på?

Hvis du mener kigge på en fil og gætte dens tegnkodning, så er det
praktisk taget umuligt, hvis du ikke ved noget om hvem der har lavet
den.

Jacob
--
»I'm perfectly happy with my current delusional system.«
-- Mirabel Tanner

---

On Tue, 28 Sep 2004 14:10:34 +0200, Jacob Sparre Andersen wrote:

> Hvis du mener kigge på en fil og gætte dens tegnkodning, så er det
> praktisk taget umuligt, hvis du ikke ved noget om hvem der har lavet
> den.

Okaj - så det er sårn lidt happy-go-lucky... hvis det virker er det
rart, hvis ikke så prøv noget andet...?

Alternativt

iconv -f foo -t bar fil > fil2
iconv -f bar -t foo fil2 > fil3

og så

diff fil fil3

Hvis begge iconv-kald lykkes og diff ikke finder noget må man vel være
glad... men _lidt_ omstændigt er det da :)

Mvh.
/Thomas

---

Thomas Lindgaard skrev:
> Jacob Sparre Andersen skrev:

> > Hvis du mener kigge på en fil og gætte dens tegnkodning, så er det
> > praktisk taget umuligt, hvis du ikke ved noget om hvem der har
> > lavet den.
>
> Okaj - så det er sårn lidt happy-go-lucky... hvis det virker er det
> rart, hvis ikke så prøv noget andet...?

Ja, men typisk, så _ved_ du noget om hvem der har lavet tekstfilerne.
Det er for eksempel sjældent at en dansker bruger andet end
ISO-8859-1, ISO-8859-15 og UTF-8.

> Alternativt
>
> iconv -f foo -t bar fil > fil2
> iconv -f bar -t foo fil2 > fil3
>
> og så
>
> diff fil fil3

Nej. Bortset fra at det ikke er alle byte-sekvenser der er lovlige
UTF-8-strenge, så er det eneste du tjekker der er om de byte-sekvenser
der er i filen svarer til nogle tegn i kodningen "foo" der også kan
repræsenteres i kodningen "bar".

Jacob
--
"The same equations have the same solutions."

---

Den Sun, 26 Sep 2004 14:59:57 +0200 skrev Michael Rasmussen:
> On Sun, 26 Sep 2004 14:42:28 +0200, Thomas Lindgaard wrote:
>
>> Det er så ikke forstår er, at hvis jeg printer filen til en terminal,
>> hvori jeg har
>>
>> export LANG="en_us.ISO-8859-1"
>>
>> så er (et udsnit af) resultatet som følger:
>>
>> JP Master vil rumme en lang r<C3><A6>kke fordele og en ny m<C3><A5>de at
>> l<C3> <A6>se avis p<C3><A5>. Som en lille appetitv<C3><A6>kker har vi
>> p<C3><A5> denne side samlet en oversigt med hovedelementerne og de mange
>> tilbud, som de best<C3><A5>r af.
>>
>> Men hvis jeg i stedet har
>>
>> export LANG="en_us.UTF-8"
>>
>> så fejler de danske tegn intet.
>>
>> Forklaring ønskes for nu har jeg snart råbt mange grimme om til
>> computeren, men det hjæler ikke...
>>
> Danske tegn har andre koder i iso-8859-1 og utf-8. De resterende fra
> latin1 - ascii7, er ens.

Som jeg læser spørgsmålet drejer det sig om hvorfor man skal vælge
iso8859-1 for at det ser rigtigt ud på skærmen, men utf-8 for at det
ser rigtigt ud på printeren.

Tegnene må da være i enten latin1 eller utf-8 format, ikke begge dele.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

On Sun, 26 Sep 2004 13:14:09 +0000, Kent Friis wrote:

> Som jeg læser spørgsmålet drejer det sig om hvorfor man skal vælge
> iso8859-1 for at det ser rigtigt ud på skærmen, men utf-8 for at det
> ser rigtigt ud på printeren.

Øhm - det var måske en dårlig formulering fra min side at skrive
"printe til terminalen"...

Problemet har udelukkende noget med xterm, gnome-terminal, m.fl. at gøre
- ikke printere :)

Mvh.
/Thomas

---

Den Sun, 26 Sep 2004 15:16:13 +0200 skrev Thomas Lindgaard:
> On Sun, 26 Sep 2004 13:14:09 +0000, Kent Friis wrote:
>
>> Som jeg læser spørgsmålet drejer det sig om hvorfor man skal vælge
>> iso8859-1 for at det ser rigtigt ud på skærmen, men utf-8 for at det
>> ser rigtigt ud på printeren.
>
> Øhm - det var måske en dårlig formulering fra min side at skrive
> "printe til terminalen"...
>
> Problemet har udelukkende noget med xterm, gnome-terminal, m.fl. at gøre
> - ikke printere :)

Så fortæl hvilket program du bruger til at "printe" filen, når det
altså ikke er lpr.

Mvh
Kent
--
Help test this great MMORPG game - http://www.eternal-lands.com/

---

On Sun, 26 Sep 2004 13:26:00 +0000, Kent Friis wrote:

> Så fortæl hvilket program du bruger til at "printe" filen, når det
> altså ikke er lpr.

OK - det var så også dårligt formuleret :)

Der er INGEN printer involveret her. Det eneste jeg har gang i er et
PHP-script, som læser input fra en fil og skriver sit output til min
gnome-terminal (og nogle gange ryger det lige en tur gennem less). Altså
ingen printer - kun en kommando-prompt.

Mvh.
/Thomas

---

Hmmm... en lille krølle:

$ echo æøåáéíóúÆØÅÁÉÍÓÚäëïöüÄËÏÖÜ > specialtegn.txt
$ more specialtegn.txt
æøåáéíóúÆØÅÁÉÍÓÚäëïöüÄËÏÖÜ
$ less specialtegn.txt
"specialtegn.txt" may be a binary file. See it anyway?
<E6><F8><E5><E1><E9><ED><F3><FA><C6><D8><C5><C1><C9><CD><D3><DA><E4><EB><EF><F6><FC><C4><CB><CF><D6><DC>
specialtegn.txt (END)

?

Mvh.
/Thomas

---

Thomas Lindgaard skrev:

> Hmmm... en lille krølle:
>
> $ echo æøåáéíóúÆØÅÁÉÍÓÚäëïöüÄËÏÖÜ > specialtegn.txt
> $ more specialtegn.txt
> æøåáéíóúÆØÅÁÉÍÓÚäëïöüÄËÏÖÜ
> $ less specialtegn.txt
> "specialtegn.txt" may be a binary file. See it anyway?
> <E6><F8><E5><E1><E9><ED><F3><FA><C6><D8><C5><C1><C9><CD><D3><DA><E4><EB><EF><F6><FC><C4><CB><CF><D6><DC>
> specialtegn.txt (END)

Det ser ud til at `less` har en anden opfattelse af hvilken
tegnkodning du bruger, end `more` og din kommandofortolker.

Kan du supplere med uddata fra `locale` og fra `env | egrep
'MORE|LESS|CHARSET'`?

Jacob
--
"In space, no-one can press CTRL-ALT-DEL"
-- An Ada programmer

---

On Sun, 26 Sep 2004 19:42:21 +0200, Jacob Sparre Andersen wrote:

> Det ser ud til at `less` har en anden opfattelse af hvilken
> tegnkodning du bruger, end `more` og din kommandofortolker.
>
> Kan du supplere med uddata fra `locale` og fra `env | egrep
> 'MORE|LESS|CHARSET'`?

Jup - kommer her (fra en "ren"/uden indstillingsmingelering term"):

$ locale
LANG=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

$ env | egrep 'MORE|LESS|CHARSET'
LESS=-R
LESSOPEN=|lesspipe.sh %s

Hvis jeg laver en export LANG=en_us.UTF-8 først ser det således ud:

$ export LANG=en_us.UTF-8
$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_us.UTF-8
LC_CTYPE="en_us.UTF-8"
LC_NUMERIC="en_us.UTF-8"
LC_TIME="en_us.UTF-8"
LC_COLLATE="en_us.UTF-8"
LC_MONETARY="en_us.UTF-8"
LC_MESSAGES="en_us.UTF-8"
LC_PAPER="en_us.UTF-8"
LC_NAME="en_us.UTF-8"
LC_ADDRESS="en_us.UTF-8"
LC_TELEPHONE="en_us.UTF-8"
LC_MEASUREMENT="en_us.UTF-8"
LC_IDENTIFICATION="en_us.UTF-8"
LC_ALL=
$ env | egrep 'MORE|LESS|CHARSET'
LESS=-R
LESSOPEN=|lesspipe.sh %s

Bliver du klogere af det? :)

Mvh.
/Thomas

---

Thomas Lindgaard skrev:

> $ locale
> LANG=
> LC_CTYPE="POSIX"
[...]

Jeg mener at tegnkodningen for "POSIX" er ISO-646. Hvis jeg har ret i
det, så er enhver håndtering af tekster med æ, ø og å i bedste fald
udefineret og i værste fald en fejl.

> $ env | egrep 'MORE|LESS|CHARSET'
> LESS=-R
> LESSOPEN=|lesspipe.sh %s

Som du muligvis har fået at vide, så er `less` lidt tungnemt og skal
selvstændigt have besked om hvilken tegnkodning du bruger (rigtige
programmer bruger "locale" til det).

> $ export LANG=en_us.UTF-8

Det ville muligvis hjælpe, hvis du satte det til "en_US.UTF-8".

Jacob
--
»USA kæmper for individets rettigheder.«
»Ja. Individet George W. Bushs rettigheder.«
-- med tak til Olfax

---

Thomas Lindgaard wrote :

> Hmmm... en lille krølle:

Jeg vil tro at 'export LESSCHARSET=latin1' kan løse problemet.
--
Thomas O.

This area is designed to become quite warm during normal operation.

---

On Sun, 26 Sep 2004 21:16:10 +0200, Thomas Overgaard wrote:

> Jeg vil tro at 'export LESSCHARSET=latin1' kan løse problemet.

Jup - det løser problemet med sære besværgelser i noget less'et output.

Mvh.
/Thomas

---

On 28 Sep 2004 14:23:05 +0200, Jacob wrote:

> Som du muligvis har fået at vide, så er `less` lidt tungnemt og skal
> selvstændigt have besked om hvilken tegnkodning du bruger (rigtige
> programmer bruger "locale" til det).

Fra afsnittet "National character sets" i less(1):

If neither LESSCHARSET nor LESSCHARDEF is set, but the
string "UTF-8" is found in the LC_ALL, LC_TYPE or LANG
environment variables, then the default character set is
utf-8.

If that string is not found, but your system supports the
setlocale interface, less will use setlocale to determine
the character set. setlocale is controlled by setting the
LANG or LC_CTYPE environment variables.

Finally, if the setlocale interface is also not available,
the default character set is latin1.

Det lyder da som om less bruger locale lidt, i det mindste?


Mvh.

--
"Instruments: SYNTH, CRUSH, FEAR, DEATH" Adam Sjøgren
asjo@koldfront.dk

---

Thomas Lindgaard <thomas@it-snedkeren.BLACK_HOLE.dk> writes:

> Alternativt
>
> iconv -f foo -t bar fil > fil2
> iconv -f bar -t foo fil2 > fil3
>
> og så
>
> diff fil fil3
>
> Hvis begge iconv-kald lykkes og diff ikke finder noget må man vel
> være glad...

Det er sikkert en tilstrækkelig betingelse, men det er faktisk ikke en
nødvendig betingelse.

Hvis man starter med iso-2022-7bit og konverterer til utf-8, så får
man ikke nødvendigvis den samme fil, når man konverterer tilbage til
iso-2022-7bit.

--
Jesper Harder <http://purl.org/harder/>

---

Jesper Harder skrev:
> Thomas Lindgaard skrev:

> > iconv -f foo -t bar fil > fil2
> > iconv -f bar -t foo fil2 > fil3
> >
> > og så
> >
> > diff fil fil3
> >
> > Hvis begge iconv-kald lykkes og diff ikke finder noget må man vel
> > være glad...
>
> Det er sikkert en tilstrækkelig betingelse, men det er faktisk ikke
> en nødvendig betingelse.

Det er _ikke_ en tilstrækkelig betingelse. En demonstration:

Hvis du bruger tegnkodningen ISO-8859-1, så giver kommandoen:

echo $'\346\370\345'

"æøå" som uddata.

Men `iconv` har alligevel ikke noget imod at du fortæller den at
strengen er kodet i ISO-8859-2. Det kan ses ved at kommandoen:

echo $'\346\370\345' \
| iconv -f ISO-8859-2 -t UTF-8

ikke resulterer i en fejlmeddelelse.

Og hvis man bruger Thomas eksempel med at konvertere tilbage til den
antagede tegnkodning igen, så ser strengen rigtig nok ud. Kommandoen:

echo $'\346\370\345' \
| iconv -f ISO-8859-2 -t UTF-8 \
| iconv -f UTF-8 -t ISO-8859-2

giver samme uddata som `echo`-kommandoen alene.

Jacob
--
»Hvis vi foruden de to fuldtræffere har 3 missere får vi
overskud« -- Kurt

---

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Jesper Harder skrev:
>> Thomas Lindgaard skrev:
>>
>> > Hvis begge iconv-kald lykkes og diff ikke finder noget må man vel
>> > være glad...
>>
>> Det er sikkert en tilstrækkelig betingelse, men det er faktisk ikke
>> en nødvendig betingelse.
>
> Det er _ikke_ en tilstrækkelig betingelse.

Nå, nej. Så testen kan faktisk slet ikke bruges til noget: den kan
melde OK selvom gættet er forkert, og fejl selv om gættet er rigtigt.

--
Jesper Harder <http://purl.org/harder/>