[Vienna-pm] Re: unicode

[Peter J. Holzer]

On 2004-09-29 00:44:30 +0200, peter pilsl wrote:
> Ich habe gerade ein script hingebogen, dass aktuell alles tut, was ich 
> will (JUCHUU !!!). Die Frage ist nur, ob das "Zufall" ist oder ein 
> annehmbares Konzept.
> 
> also, ich verzichte auf binmode(STD,":utf8") und muss dafür die 
> eingehenden parameter decoden und vor dem ausschreiben wieder encoden. 
> Klingt das vernünftig?

Ja. (Wobei encoden und decoden von und nach utf8 wohl eh ein nop ist, da
die Strings intern auch als utf-8 dargestellt werden).


> Damit das sortieren mit dem sort funktioniert mache ich ein downgrade 
> und damit das mit dem lc() funktioniert, mache ich vorher wieder ein 
> upgrade.
> Klingt das zu schwindelig?

Es klingt nach Bug im sort oder falscher Locale-Einstellung. Eigentlich
sollte Sortieren auch mir utf-8-Strings funktionieren. Wie hast Du die
locale gesetzt? (und welche Perl-Version, welches OS, welche
libc-Version etc. ist das?)

> macht das irgendwo sinn oder schreit das nach Problemen?

IMHO hast Du spätestens ein Problem, wenn Zeichen außerhalb des
Latin-1-Repertoires auftauchen, z.B. ein Euro-Zeichen oder ein z mit
Hacek. 

> downgrade heisst ja, dass das utf8-flag intern nicht mehr gesetzt ist. 
> das heisst also, dass der string nicht mehr als 2-byte-folge gelesen 
> wird (was ja imho die probleme beim sortieren macht),

Eine 2-Byte-Folge ist es intern ohnehin nicht, sondern eine
UTF-8-Kodierung - d.h., ein Zeichen kann eine variable Anzahl von 1 bis
6 Bytes belegen.

> sondern einfach als folge von \x{...}-Zeichen. 

Wenn Du jetzt noch definierst, was ein \x{...}-Zeichen sein soll ... :-)

\x{...} ist ein Konstrukt im Perl-Source-Code. Intern schaut ein "A"
genau gleich aus, ob Du nun "A" geschrieben hast, oder "\101" oder
"\x{41}".

> Warum dann das lc nicht funktioniert ist 
>  fraglich. Oder hab ich das mit dem utf-8 flag immer noch nicht gecheckt.
> Ist das flag "gut" oder "schlecht".

Das Flag ist weder "gut" noch "schlecht", es dient dazu, zwei
Datentypen zu unterscheiden. Wenn es gesetzt ist, repräsentiert die
Bytefolge C3 A4 ein "ä", wenn es nicht gesetzt ist, repräsentiert sie
die zwei Zeichen mit den Codes C3 und A4 im lokalen Zeichensatz (in
Latin-1 LATIN CAPITAL LETTER A WITH TILDE und CURRENCY SIGN). 

In einer ganzzahligen Variable (gibt's sowas in Perl, oder sind
numerische Variablen immer double?) würde sie den Wert 42179
repräsentieren (little-endian).

RAM besteht nur aus Bytes, aber jedes Programm muss wissen, wie es die
Bytes interpretieren soll. Bei Sprachen wie Perl, wo Variablen den
Datentyp zur Laufzeit ändern können, muss diese Information mit jeder
Variable mitgeführt werden. Wenn die Information aus irgendeinem Grund
falsch ist, kommt Blödsinn raus.

> Mir kommt schon vor, dass unicode noch sehr _bleeding edge_ ist und 
> nicht ganz ausgereift ...

Durchaus möglich, dass da noch Bugs drin sind. Das größere Problem ist
aber meistens zwischen Tastatur und Sessel. Es ist ziemlich leicht, den
Überblick zu verlieren, was wo wie umgewandelt oder verarbeitet wird.

	hp


-- 
   _  | Peter J. Holzer      | Shooting the users in the foot is bad. 
|_|_) | Sysadmin WSR / LUGA  | Giving them a gun isn't.
| |   | hjp at wsr.ac.at        |	-- Gordon Schumacher,
__/   | http://www.hjp.at/   |     mozilla bug #84128
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 388 bytes
Desc: not available
Url : http://mail.pm.org/archives/vienna-pm/attachments/20040929/96b11d22/attachment.bin