
Nochmal Sprachversionen - knifflige Aufgabe
ich habe das mit meinen Sprachversionen jetzt so gelöst:
Es gibt ein Wörterbuch, das so aussieht:
$texte = array ('kairos' => array ( 0 => 'der richtige Zeitpunkt',
'fi' => 'oikea ajankohta',
'en' => 'the right moment',
'nl' => 'het juiste tijdstip',
'pl' => 'własciwy moment'),
// [...]
'lchange' => array ( 0 => 'Letzte Änderung',
'fi' => 'Viimeinen muutos',
'en' => 'Last change',
'nl' => 'Laatste verandering',
'pl' => 'Ostatnie zmianay'));
Ich greife über eine Klasse darauf zu, die "holende" Funktion sieht so aus:
function getlang ($key) {
$text = isset($this->texte[$key][$this->lang]) ?
$this->texte[$key][$this->lang]
: $this->texte[$key][0];
if (!isset ($text)) {
return ('#name');
} else {
return ($text);
}
Das funktioniert alles ganz super, und mir wird bestimmt noch was
einfallen, wie's noch eleganter geht.
Nun habe ich mir was besonderes überlegt:
Die keys sind immer klein geschrieben, z.B. 'kairos' oder 'lchange'
Nun gibt es manchmal aber eine Anforderung, dass das gefundene Wort oder
der gefundene Satz groß oder in Großbuchstaben geschrieben werden soll.
Nun ist es ja wichtig, dass immer mit dem richtigen Schlüssel
zugegriffen werden soll, also 'Kairos' wäre ja dann falsch, und 'KAIROS'
auch.
Ich möchte nun spezielle Ausgaben erreichen, und zwar in der Art:
kairos -> der richtige Moment
Kairos -> Der richtige Moment
KAIROS -> DER RICHTIGE MOMENT
Dazu müsste in der Funktion erst mal festgestellt werden, ob da lauter
Kleinbuchstaben stehen, denn 'Kairos' oder 'KAIROS' wäre falsch und der
begriff würde nciht gefunden. Wenn der erste Buchstabe groß ist, wird
Status 1 gesetzt und das 'K' wird zum 'k' gemacht. Wenn der zweite
Buchstabe ebenfalls groß ist, wird Status auf 2 gesetzt, und alle
Buchstaben werden vorsorglich klein gemacht.
Bei 1 nun wird im Ergebnisstring der erste Buchstabe groß gemacht, bei
Status 2 alle Buchstaben. Wenn Status 0 ist, dann wird natürlich nichts
verändert, auch wenn im Ergebnisstring Klein- und Großbuchstaben stehen.
ich bin ganz sicher, dass das ganz einfach geht, aber ich weiß nicht
recht, wie. Außerdem habe ich (und das stimmt, ehrlich!) mein PHP-Buch
gerade ausgeliehen.
Danke für Tipps.
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> ich habe das mit meinen Sprachversionen jetzt so gelöst:
>
[...]
ich muss mich jetzt ein bisschen schämen. Natürlich war ich etwas
ungeduldig und habe trotz fehlendem PHP-Buch einfach bei php.net
nachgeschaut und die ganze Sache mit ctype_upper und strtoupper gelöst.
War eigentlich ganz einfach ...
Nix für ungut - ich hab mir's einfacher schwieriger vorgestellt.
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Ich möchte nun spezielle Ausgaben erreichen, und zwar in der Art:
>
> kairos -> der richtige Moment
> Kairos -> Der richtige Moment
> KAIROS -> DER RICHTIGE MOMENT
Du suchst strtolower() und strtoupper(). bzw. deren Multibyte-Pendants
mb_strtolower() und mb_strtoupper().
> Dazu müsste in der Funktion erst mal festgestellt werden, ob da lauter
> Kleinbuchstaben stehen
So lange der Key nur aus Buchstaben (A-Z, a-z) besteht, ist das ja kein
Problem:
$c1 = substr($key, 0, 1);
$c2 = substr($key, 1, 1);
if ($c1 >= 'a' and $c1 <= 'z') { /* 'kairos' */
...
} else if ($c2 >= 'a' and $c2 <= 'z') { /* 'Kairos' */
$text = mb_strtoupper(mb_substr($text, 0, 1)) . mb_substr($text, 1);
...
} else { /* 'KAIROS' */
$text = mb_strtoupper($text);
...
}
Gruß. Claus
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Ich möchte nun spezielle Ausgaben erreichen, und zwar in der Art:
>
> kairos -> der richtige Moment
> Kairos -> Der richtige Moment
> KAIROS -> DER RICHTIGE MOMENT
if ( $key =3D=3D ucfirst( strtolower( $key ) ) ) {
return ucfirst( $lang[$key] );
} elseif ( $key =3D=3D (strtoupper( $key ) ) {
return strtoupper( $lang[$ley] );
} else {
return $lang[$key];
}
Damit umgehst du das Problem, dass ctype_upper bei Ziffern und
Leerzeichen versagt.
MfG
Niels
--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Re: Nochmal Sprachversionen - knifflige Aufgabe
Claus Reibenstein schrieb:
> Werner Partner schrieb:
>
>> Ich möchte nun spezielle Ausgaben erreichen, und zwar in der Art:
>>
>> kairos -> der richtige Moment
>> Kairos -> Der richtige Moment
>> KAIROS -> DER RICHTIGE MOMENT
>
> Du suchst strtolower() und strtoupper(). bzw. deren Multibyte-Pendants
> mb_strtolower() und mb_strtoupper().
>
>> Dazu müsste in der Funktion erst mal festgestellt werden, ob da lauter
>> Kleinbuchstaben stehen
>
> So lange der Key nur aus Buchstaben (A-Z, a-z) besteht, ist das ja kein
> Problem:
Ja, ich habe da so abartige polnische Sachen wie:
własciwy moment, Środa, Piątek
Ich weiß, dass #322 in groß #321 ist, usw., aber da wird's dann wirklich
kriminell. Darüber habe ich jetzt noch gar nicht so recht nachgedacht.
ich könnte natürlich in diesem Fall den String einzeln durchgehen und
untersuchen.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Niels Braczek schrieb:
> Werner Partner schrieb:
>
>> Ich möchte nun spezielle Ausgaben erreichen, und zwar in der Art:
>>
>> kairos -> der richtige Moment
>> Kairos -> Der richtige Moment
>> KAIROS -> DER RICHTIGE MOMENT
>
> if ( $key == ucfirst( strtolower( $key ) ) ) {
> return ucfirst( $lang[$key] );
> } elseif ( $key == (strtoupper( $key ) ) {
> return strtoupper( $lang[$ley] );
> } else {
> return $lang[$key];
> }
>
> Damit umgehst du das Problem, dass ctype_upper bei Ziffern und
> Leerzeichen versagt.
>
Muss ich erst mal drüber nachdenken, das ist ja ganz schön sophisticated.
Wenn ich's völlig verstanden habe, werde ich's wohl genau so machen.
Danke für den Tipp
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Claus Reibenstein schrieb:
>
>> So lange der Key nur aus Buchstaben (A-Z, a-z) besteht, ist das ja kein
^^^
> Ja, ich habe da so abartige polnische Sachen wie:
> własciwy moment, Środa, Piątek
Aber doch nicht im Key, oder? Den (sprachunabhängigen) Key definierst Du
selber. Da sollte es doch kein Problem sein, sicher zu stellen, dass der
nur aus ASCII-Buchstaben besteht.
Gruß. Claus
Re: Nochmal Sprachversionen - knifflige Aufgabe
Claus Reibenstein schrieb:
> Werner Partner schrieb:
>
>> Claus Reibenstein schrieb:
>>
>>> So lange der Key nur aus Buchstaben (A-Z, a-z) besteht, ist das ja kein
> ^^^
>
>> Ja, ich habe da so abartige polnische Sachen wie:
>> własciwy moment, Środa, Piątek
>
> Aber doch nicht im Key, oder? Den (sprachunabhängigen) Key definierst Du
> selber. Da sollte es doch kein Problem sein, sicher zu stellen, dass der
> nur aus ASCII-Buchstaben besteht.
Ja! Da habe ich nciht richtig gelesen. Der key besteht asusschließlich
aus Kleinbuchstaben.
Aber strtoupper (Piątek)
Wird da was draus? Kann strtoupper das?
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Claus Reibenstein schrieb:
> Werner Partner schrieb:
>
>> Claus Reibenstein schrieb:
>>
>>> So lange der Key nur aus Buchstaben (A-Z, a-z) besteht, ist das ja kein
> ^^^
>
>> Ja, ich habe da so abartige polnische Sachen wie:
>> własciwy moment, Środa, Piątek
ich hab das mal getestet, strtoupper wanelt offensichtlich die
diakritischen Zeichen korrekt. D.h., ich wäre eine anstrengende
Demnkleistung erst mal los.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Aber strtoupper (Piątek)
>
> Wird da was draus? Kann strtoupper das?
Wenn Du statt dieser HTML-Codierung z.B. UTF8 verwendest und dann
mb_strtoupper() benutzt, dann ja.
Gruß. Claus
Re: Nochmal Sprachversionen - knifflige Aufgabe
Claus Reibenstein schrieb:
> Werner Partner schrieb:
>
>> Aber strtoupper (Piątek)
>>
>> Wird da was draus? Kann strtoupper das?
>
> Wenn Du statt dieser HTML-Codierung z.B. UTF8 verwendest und dann
> mb_strtoupper() benutzt, dann ja.
Ich schrieb schon, das strtoupper das kann, allerdings setzt er die
Codierung nicht auf Großbuchstaben, sondern bildet sie einfach nur ab.
Damit könnte ich erst mal leben.
ich habe hier stehen:
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
Ich habe jetzt iso-8859-1 durch UTF-8 ersetzt.
Mal ne prinzipielle Frage: Welche Konsequenzen hat diese Änderung, muss
ich etwas besonderes beachten. Muss ich damit rechnen, dass bestimmte
Seiten nicht mehr richtig dargestellt werden, oder habe ich jetzt
einfach nur einen größeren Zeichenvorrat?
Die Funktion mb_strtoupper() ist nicht bekannt, ich nehme an, dass ich
bei PHP etwas nachinstallieren muss. ich kann aber nciht erkennen, was?
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Claus Reibenstein schrieb:
> Werner Partner schrieb:
>
>> Aber strtoupper (Piątek)
>>
>> Wird da was draus? Kann strtoupper das?
>
> Wenn Du statt dieser HTML-Codierung z.B. UTF8 verwendest und dann
> mb_strtoupper() benutzt, dann ja.
Der Effekt ist zunächst verheerend. Wenn ich UTF-8 verwende, muss ich
zunächst alle ä in ä usw. umwandeln, was im Prinzip nicht verkehrt
ist. Wenn ich aber aus meinem Wörterbuch "meidän tiimi" auslese und in
Großbuchstaben auslesen will (mit strtoupper()), dann kommt ein stolzes,
großgeschriebenes "MEID&AUML;N TIIMI" raus.
Möglicherweise kann das der mb_strtoupper besser.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
On Thu, 26 Jul 2007 17:14:09 +0200 Werner Partner wrote:
> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
> umwandeln,
Dumme Frage: warum denn?
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Echte Stänker nimmt der Staat: Stefan!
(Sloganizer)
Re: Nochmal Sprachversionen - knifflige Aufgabe
On Thu, 26 Jul 2007, Stefan Froehlich wrote:
> On Thu, 26 Jul 2007 17:14:09 +0200 Werner Partner wrote:
> > Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
> > umwandeln,
>
> Dumme Frage: warum denn?
Weil ein ä in ISO-8859-1 (oder -2 oder -15) kein ä in UTF-8 ist. Man muss
also *irgendwas* tun, nicht unbedingt das -- nur lassen wie's ist kann
mans nicht.
--
Helmut Richter
Re: Nochmal Sprachversionen - knifflige Aufgabe
Stefan Froehlich schrieb:
> On Thu, 26 Jul 2007 17:14:09 +0200 Werner Partner wrote:
>> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
>> umwandeln,
>
> Dumme Frage: warum denn?
Weil bei Deklaration von UTF-8 bei allen äs ös und üs '?' auftauchen.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Helmut Richter schrieb:
> On Thu, 26 Jul 2007, Stefan Froehlich wrote:
>
>> On Thu, 26 Jul 2007 17:14:09 +0200 Werner Partner wrote:
>>> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
>>> umwandeln,
>> Dumme Frage: warum denn?
>
> Weil ein ä in ISO-8859-1 (oder -2 oder -15) kein ä in UTF-8 ist. Man muss
> also *irgendwas* tun, nicht unbedingt das -- nur lassen wie's ist kann
> mans nicht.
>
Ich denke, es ist sowieso sinnvoll, Sonderzeichen wie ä,ö,ü,&,¤," usw.
in die ensprechenden Sondercodes umzuwandeln. ich habe da ein bisschen
geschludert in letzter Zeit.
Das Problem ist nur folgendes:
Wenn ich in meiner Tabelle zum Beispiel das Wort 'Verständigung"
stehe habe, passiert folgendes:
Wenn ich das Wort normal auslese, wird es in den HTML-Code eingebunden,
und da steht dann "Verständigung", wenn ich es aber in Großbuchstaben
auslesen will, also mit strtoupper ('Verständigung'), dann bekomme
ich "VERST&AUML;NDIGUNG".
'Verständigung' wird mit strtoupper ganz einfach 'VERSTÄNDIGUNG', aber
mit UTF-8 steht da dann natürlich "Verst?ndigung" bzw. "VERST?NDIGUNG".
Claus meinte, ich solle doch UTF-8 nehmen in Verbindung mit
mb_strtoupper(), aber diese Funktion wird bei mir leider nicht gefunden.
Eigentlich funktioniert alles ganz gut, wie's jetzt ist, aber es macht
Sinn, die Sache "richtig" zu lösen. Ich habe vor längerer Zeit mal alle
meine Seiten validiert. Sie haben zwar hinterher auch nicht anders
ausgesehen, aber ich fand es richtig, korrekten Code zu schreiben, weil
das garanteirt, dass die Seiten auch weiterhin lesbar sind.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
..oO(Werner Partner)
>Helmut Richter schrieb:
>
>> Weil ein ä in ISO-8859-1 (oder -2 oder -15) kein ä in UTF-8 ist. Man muss
>> also *irgendwas* tun, nicht unbedingt das -- nur lassen wie's ist kann
>> mans nicht.
>>
>Ich denke, es ist sowieso sinnvoll, Sonderzeichen wie ä,ö,ü,&,€," usw.
>in die ensprechenden Sondercodes umzuwandeln.
ä etc. ist vergangenes Jahrtausend, Schnee von gestern (in den
meisten Fällen jedenfalls). Wenn UTF-8 konsequent durchgezogen wird,
dann funktioniert das auch und Zeichenreferenzen braucht's nicht mehr
(mit Ausnahme von &, < und ggf. ").
Ggf. müssen halt Datenbanktabellen oder andere Datenquellen umcodiert
bzw. die Daten beim Auslesen "on-the-fly" modifiziert werden. Dafür gibt
es durchaus Möglichkeiten.
>Das Problem ist nur folgendes:
>Wenn ich in meiner Tabelle zum Beispiel das Wort 'Verständigung"
>stehe habe, passiert folgendes:
Sowas sollte eigentlich _nie_ in einer Tabelle stehen. Dort gehören
Rohdaten rein, die dann je nach Ausgabemedium angepaßt oder umcodiert
werden können.
>Wenn ich das Wort normal auslese, wird es in den HTML-Code eingebunden,
>und da steht dann "Verständigung", wenn ich es aber in Großbuchstaben
>auslesen will, also mit strtoupper ('Verständigung'), dann bekomme
>ich "VERST&AUML;NDIGUNG".
Ist klar. PHP kann solche Zeichenreferenzen aber auch wieder rückgängig
machen, siehe html_entity_decode().
>'Verständigung' wird mit strtoupper ganz einfach 'VERSTÄNDIGUNG', aber
>mit UTF-8 steht da dann natürlich "Verst?ndigung" bzw. "VERST?NDIGUNG".
>
>Claus meinte, ich solle doch UTF-8 nehmen in Verbindung mit
>mb_strtoupper(), aber diese Funktion wird bei mir leider nicht gefunden.
Das ist eine Erweiterung, die bei Dir möglicherweise nicht aktiviert
ist. Such mal in der php.ini nach "mbstring".
>Eigentlich funktioniert alles ganz gut, wie's jetzt ist, aber es macht
>Sinn, die Sache "richtig" zu lösen.
Das heißt in diesem Fall ganz klar UTF-8 - und zwar konsequent von
Anfang (Datenbank) bis Ende (Browser).
Micha
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Stefan Froehlich schrieb:
>> On Thu, 26 Jul 2007 17:14:09 +0200 Werner Partner wrote:
>>> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
>>> umwandeln,
>>
>> Dumme Frage: warum denn?
>
> Weil bei Deklaration von UTF-8 bei allen äs ös und üs '?' auftauc=
hen.
Nö. Es reicht nicht, den String als UTF zu *deklarieren*, er sollte auc=
h
so *kodiert* sein. ä ist übrigens eine *HTML*-Entity, keine UTF-En=
tity.
MfG
Niels
--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------
Re: Nochmal Sprachversionen - knifflige Aufgabe
Michael Fesser schrieb:
> .oO(Werner Partner)
>
>> Helmut Richter schrieb:
>>
>>> Weil ein ä in ISO-8859-1 (oder -2 oder -15) kein ä in UTF-8 ist. Man muss
>>> also *irgendwas* tun, nicht unbedingt das -- nur lassen wie's ist kann
>>> mans nicht.
>>>
>> Ich denke, es ist sowieso sinnvoll, Sonderzeichen wie ä,ö,ü,&,¤," usw.
>> in die ensprechenden Sondercodes umzuwandeln.
>
> ä etc. ist vergangenes Jahrtausend, Schnee von gestern (in den
> meisten Fällen jedenfalls). Wenn UTF-8 konsequent durchgezogen wird,
> dann funktioniert das auch und Zeichenreferenzen braucht's nicht mehr
> (mit Ausnahme von &, < und ggf. ").
Das verstehe ich nicht ganz. Bei mir stand im header folgendes:
meta http-equiv="Content-Type" content="text/html; charset=UTF-8"
Danach hatte ich statt ä, ö und ü nur noch "?". Diese Fragezeiczhen habe
cih wegbekommen durch ä ö und ü
>
> Ggf. müssen halt Datenbanktabellen oder andere Datenquellen umcodiert
> bzw. die Daten beim Auslesen "on-the-fly" modifiziert werden. Dafür gibt
> es durchaus Möglichkeiten.
>
>> Das Problem ist nur folgendes:
>> Wenn ich in meiner Tabelle zum Beispiel das Wort 'Verständigung"
>> stehe habe, passiert folgendes:
>
> Sowas sollte eigentlich _nie_ in einer Tabelle stehen. Dort gehören
> Rohdaten rein, die dann je nach Ausgabemedium angepaßt oder umcodiert
> werden können.
Das _sind_ Rohdaten, es handelt sich um mein Wörterbuch.
>
> Das heißt in diesem Fall ganz klar UTF-8 - und zwar konsequent von
> Anfang (Datenbank) bis Ende (Browser).
Das kann ich nachvollziehen, nur müsste ich wissen, wie's richtig geht.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Niels Braczek schrieb:
> Werner Partner schrieb:
>> Stefan Froehlich schrieb:
>>> On Thu, 26 Jul 2007 17:14:09 +0200 Werner Partner wrote:
>>>> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
>>>> umwandeln,
>>> Dumme Frage: warum denn?
>> Weil bei Deklaration von UTF-8 bei allen äs ös und üs '?' auftauchen.
>
> Nö. Es reicht nicht, den String als UTF zu *deklarieren*, er sollte auch
> so *kodiert* sein. ä ist übrigens eine *HTML*-Entity, keine UTF-Entity.
Wie "kodiere" ich ein ä richtig? ich habe da eine deutsche Tastatur, in
die ich die Texte reintippe ...
....
Ich hb mal ein bisschen rumgeschaut. Ich brauche also einen Editor, der
UTF kann. Ich benutze phase5, da kann ich nichts finden, was hilfreich
ist ...
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Niels Braczek schrieb:
>> N=C3=B6. Es reicht nicht, den String als UTF zu *deklarieren*, er soll=
te auch
>> so *kodiert* sein. ä ist =C3=BCbrigens eine *HTML*-Entity, keine =
UTF-Entity.
>
> Wie "kodiere" ich ein =C3=A4 richtig? ich habe da eine deutsche Tastatu=
r, in
> die ich die Texte reintippe ...
Eintippen ist ok, es geht ums Speichern.
> Ich hb mal ein bisschen rumgeschaut. Ich brauche also einen Editor, der=
> UTF kann. Ich benutze phase5, da kann ich nichts finden, was hilfreich =
> ist ...
Richtig. Ich benutze auch Phase5; da hei=C3=9Ft es Suchen und Ersetzen mi=
t
den A-Tilde-Zeichenfolgen (=C3=A4=3D=C3=83=C2=A4, =C3=B6=3D=C3=83=C2=B6, =
=C3=BC=3D=C3=83=C2=BC usw.). Es wird also Zeit,
auf die Suche nach einem zeitgem=C3=A4=C3=9Fen Editor zu gehen.
MfG
Niels
--
| http://www.kolleg.de =C2=B7 Das Portal der Kollegs in Deutschland |=
| http://www.bsds.de =C2=B7 BSDS Braczek Software- und DatenSysteme |=
| Webdesign =C2=B7 Webhosting =C2=B7 e-Commerce =C2=B7 Joomla! Content Ma=
nagement |
------------------------------------------------------------ ------
Re: Nochmal Sprachversionen - knifflige Aufgabe
On Thu, 26 Jul 2007, Werner Partner wrote:
> Das verstehe ich nicht ganz. Bei mir stand im header folgendes:
> meta http-equiv="Content-Type" content="text/html; charset=UTF-8"
Wie schon öfter erwähnt, muss das nichts bedeuten. Aber hier hat es ja
offenbar funktioniert, nämlich dazu, die Umlaute erfolgreich zu
vernichten.
> Danach hatte ich statt ä, ö und ü nur noch "?". Diese Fragezeiczhen habe cih
> wegbekommen durch ä ö und ü
Die Preisfrage ist, was in der Datei steht. Steht dort pro Umlaut ein
Byte, das problemlos als ä, ö oder ü angezeigt wird, wenn als Charset
ISO-8859-1 angegeben ist, dann *kann* es mit UTF-8 nicht funktionieren,
weil das zwei Bytes erwartet, die *zusammen* den Umlaut darstellen; es
erscheint ein Fragezeichen für das falsche Byte oder auch gar nichts.
Stehen dort pro Umlaut zwei Bytes, die problemlos als ä, ö oder ü
angezeigt werden, wenn als Charset UTF-8 angegeben ist, dann *kann* es mit
ISO-8859-1 nicht funktionieren, weil das nur ein Byte erwartet, das
*alleine* den Umlaut darstellt; es erscheinen zwei falsche Zeichen für die
beiden falsches Bytes -- das erste ist meist ein großes A mit Tilde oder
Ring.
Wenn du also konsequent UTF-8 verwenden willst, was eine sinnvolle Lösung
ist, dann musst du es hinbekommen, dass auch alle Texte *nur* in UTF-8
vorliegen, und zwar in der Datenbank wie in Programmtexten.
Dass es mit den Ersatzdarstellungen ä geht, ist klar. Da kommen ja
nur ASCII-Zeichen vor (nämlich &, a, u, m, l und ;), und für die ist die
Darstellung in den beiden Codes gleich. Das wäre auch eine Lösung, solange
keine Daten dauerhaft gehalten und verarbeitet werden -- diese Lösung
hatte ich anfangs für die polnischen Texte vorgeschlagen, *weil* sie
unabhängig von Zeichensätzen funktioniert. Wenn aber diese
Ersatzdarstellungen in die Datenbanken eindringen, kriegst du
möglicherweise andere Probleme: der Herr Müller ist vom Herrn Müller
verschieden, weil sein Name nur 6 und nicht 11 Zeichen lang ist usw.
Solange es nur darum ging, "Schön, dass Sie meine Seite lesen und hier ist
das Inhaltsverzeichnis" auf Polnisch zu sagen, waren die Probleme mit den
Ersatzdarstellungen die kleineren gegenüber denen mit Zeichensätzen. Wo es
aber um Daten in Datenbanken geht, wird sich das umkehren.
--
Helmut Richter
Re: Nochmal Sprachversionen - knifflige Aufgabe
On Thu, 26 Jul 2007 18:08:13 +0200 Werner Partner wrote:
> >>> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
> >>> umwandeln,
> >> Dumme Frage: warum denn?
> > Weil ein ä in ISO-8859-1 (oder -2 oder -15) kein ä in UTF-8 ist.
[...]
> Ich denke, es ist sowieso sinnvoll, Sonderzeichen wie ä,ö,ü,&,€," usw.
> in die ensprechenden Sondercodes umzuwandeln. ich habe da ein bisschen
> geschludert in letzter Zeit.
Nein, ist es nicht - und genau darauf sollte meine dumme Frage abzielen.
Wenn Du mit Zeichenketten sinnvoll arbeiten willst, brauchst Du auch die
echten Zeichenketten dafuer. Wie sich z.B. hier ja gerade zeigt, gibt es
sonst Probleme an verschiedenen Ecken und Enden. Gross-/Kleinschreibung
ist nur ein Thema, es gibt auch noch Probleme mit der Laengenberechnung,
und wenn Du einmal eine (plain text) Email verfassen willst, wird es
mit Entities auch nicht gerade einfacher.
Daher: die gesamte Verarbeitung in _einem_ Zeichensatz (ob ISO-8859-1
bei Dir ausreicht, kann ich nicht sagen, ansonsten halt gleich UTF-8)
und erst zum Zeitpunkt der Ausgabe an den Browser die Umwandlung in das
gewuenschte Zielformat (idealerweise braucht man da auch nur <, & und
" zu maskieren, der Rest wird durch entsprechende Deklaration im Header
kundgetan).
> es macht Sinn, die Sache "richtig" zu lösen.
Eben, "richtig" ist IMHO aber nicht eine konsequente Verwendung von
Entities, sondern eher deren konsequente Vermeidung.
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Stefan - die zarteste Bejahung der Poesie!
(Sloganizer)
Re: Nochmal Sprachversionen - knifflige Aufgabe
..oO(Werner Partner)
>Michael Fesser schrieb:
>>
>> ä etc. ist vergangenes Jahrtausend, Schnee von gestern (in den
>> meisten Fällen jedenfalls). Wenn UTF-8 konsequent durchgezogen wird,
>> dann funktioniert das auch und Zeichenreferenzen braucht's nicht mehr
>> (mit Ausnahme von &, < und ggf. ").
>
>Das verstehe ich nicht ganz. Bei mir stand im header folgendes:
>meta http-equiv="Content-Type" content="text/html; charset=UTF-8"
>
>Danach hatte ich statt ä, ö und ü nur noch "?". Diese Fragezeiczhen habe
>cih wegbekommen durch ä ö und ü
Das deutet dann aber eher darauf hin, daß das Dokument selbst nicht
korrekt als UTF-8 codiert war. Einfach nur "UTF-8" auf ein Paket zu
schreiben, obwohl ISO-8859-1 drin ist, bringt natürlich nichts.
>>> Das Problem ist nur folgendes:
>>> Wenn ich in meiner Tabelle zum Beispiel das Wort 'Verständigung"
>>> stehe habe, passiert folgendes:
>>
>> Sowas sollte eigentlich _nie_ in einer Tabelle stehen. Dort gehören
>> Rohdaten rein, die dann je nach Ausgabemedium angepaßt oder umcodiert
>> werden können.
>
>Das _sind_ Rohdaten, es handelt sich um mein Wörterbuch.
¨ würde ich nicht mehr als Rohdaten bezeichnen, das ist schon eine
HTML-spezifische Codierung.
Nur mal angenommen (ganz allgemein, nicht auf Dein konkretes Beispiel
bezogen), Du würdest solche Datenbankinhalte nicht nur auf einer Website
verwenden wollen, sondern z.B. auch für einen als nackten Text
verschickten Newsletter - dann zerschießen Dir solche Codierungen die
Ausgabe und müssen erst umständlich entfernt werden. Noch schwieriger
wirds, wenn Du die Datenbank nach solchen Begriffen durchsuchen willst.
Micha
Re: Nochmal Sprachversionen - knifflige Aufgabe
..oO(Werner Partner)
>Ich hb mal ein bisschen rumgeschaut. Ich brauche also einen Editor, der
>UTF kann. Ich benutze phase5, da kann ich nichts finden, was hilfreich
>ist ...
Phase5 kann das vermutlich immer noch nicht, was für mich schon vor zwei
Jahren der Grund war, dieses Programm nicht mehr zu verwenden (obwohl es
mir ansonsten recht gut gefiel).
Mittlerweile bin ich bei Eclipse als Entwicklungsumgebung gelandet (für
Dich wahrscheinlich Overkill), für kleinere Editierarbeiten tuts auch
jEdit ganz hervorragend.
Micha
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Ich hb mal ein bisschen rumgeschaut. Ich brauche also einen Editor, der
> UTF kann. Ich benutze phase5, da kann ich nichts finden, was hilfreich
Unter Linux tut's der vi, für Windows benutze ich den kostenlosen
Crimson Editor. Beide können UTF-8 und Syntax Highlighting. Mehr braucht
man als Hacker eigentlich nicht.
Darüber hinaus gibt es auch spezielle PHP-Editoren, die das sicher
ebenfalls können, von denen mir bislang aber keiner so richtig gefallen hat.
Gruß. Claus
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Stefan Froehlich schrieb:
>
>> On Thu, 26 Jul 2007 17:14:09 +0200 Werner Partner wrote:
>>
>>> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
>>> umwandeln,
Nein.
>> Dumme Frage: warum denn?
>
> Weil bei Deklaration von UTF-8 bei allen äs ös und üs '?' auftauchen.
Dann sind die Umlaute nicht in UTF-8 kodiert, sondern vermutlich noch in
ISO-8859-1. Dem kannst Du mit iconv() abhelfen.
Gruß. Claus
Re: Nochmal Sprachversionen - knifflige Aufgabe
Helmut Richter schrieb:
> On Thu, 26 Jul 2007, Werner Partner wrote:
>
>> Das verstehe ich nicht ganz. Bei mir stand im header folgendes:
>> meta http-equiv="Content-Type" content="text/html; charset=UTF-8"
>
> Wie schon öfter erwähnt, muss das nichts bedeuten. Aber hier hat es ja
> offenbar funktioniert, nämlich dazu, die Umlaute erfolgreich zu
> vernichten.
>
>> Danach hatte ich statt ä, ö und ü nur noch "?". Diese Fragezeiczhen habe cih
>> wegbekommen durch ä ö und ü
>
> Die Preisfrage ist, was in der Datei steht. Steht dort pro Umlaut ein
> Byte, das problemlos als ä, ö oder ü angezeigt wird, wenn als Charset
> ISO-8859-1 angegeben ist, dann *kann* es mit UTF-8 nicht funktionieren,
> weil das zwei Bytes erwartet, die *zusammen* den Umlaut darstellen; es
> erscheint ein Fragezeichen für das falsche Byte oder auch gar nichts.
> Stehen dort pro Umlaut zwei Bytes, die problemlos als ä, ö oder ü
> angezeigt werden, wenn als Charset UTF-8 angegeben ist, dann *kann* es mit
> ISO-8859-1 nicht funktionieren, weil das nur ein Byte erwartet, das
> *alleine* den Umlaut darstellt; es erscheinen zwei falsche Zeichen für die
> beiden falsches Bytes -- das erste ist meist ein großes A mit Tilde oder
> Ring.
>
> Wenn du also konsequent UTF-8 verwenden willst, was eine sinnvolle Lösung
> ist, dann musst du es hinbekommen, dass auch alle Texte *nur* in UTF-8
> vorliegen, und zwar in der Datenbank wie in Programmtexten.
>
Ja, das habe ich jetzt wohl verstanden. Ich muss gestehen, dass ich mich
mit dem Thema bislang noch nciht so befasst habe.
Was mir inzwischen auch klar ist, ist, dass, wenn ich im Header UTF-8
angebe, lediglich UTF-8 deklariert wird, dass dies aber nicht zu
bedeuten hat, dass die Codierung UTF-8 entspricht. Logisch ist dann
natürlich, dass besitmmte Zeichen falsch gelesen werden.
ich brauche jetzt nur noch einen Editor, der auch UTF-8 schreibt.
Bis dahin lasse ich lieber iso..
Grüße
werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Michael Fesser schrieb:
> .oO(Werner Partner)
>
>> Michael Fesser schrieb:
>>> ä etc. ist vergangenes Jahrtausend, Schnee von gestern (in den
>>> meisten Fällen jedenfalls). Wenn UTF-8 konsequent durchgezogen wird,
>>> dann funktioniert das auch und Zeichenreferenzen braucht's nicht mehr
>>> (mit Ausnahme von &, < und ggf. ").
>> Das verstehe ich nicht ganz. Bei mir stand im header folgendes:
>> meta http-equiv="Content-Type" content="text/html; charset=UTF-8"
>>
>> Danach hatte ich statt ä, ö und ü nur noch "?". Diese Fragezeiczhen habe
>> cih wegbekommen durch ä ö und ü
>
> Das deutet dann aber eher darauf hin, daß das Dokument selbst nicht
> korrekt als UTF-8 codiert war. Einfach nur "UTF-8" auf ein Paket zu
> schreiben, obwohl ISO-8859-1 drin ist, bringt natürlich nichts.
>
>>>> Das Problem ist nur folgendes:
>>>> Wenn ich in meiner Tabelle zum Beispiel das Wort 'Verständigung"
>>>> stehe habe, passiert folgendes:
>>> Sowas sollte eigentlich _nie_ in einer Tabelle stehen. Dort gehören
>>> Rohdaten rein, die dann je nach Ausgabemedium angepaßt oder umcodiert
>>> werden können.
>> Das _sind_ Rohdaten, es handelt sich um mein Wörterbuch.
>
> ¨ würde ich nicht mehr als Rohdaten bezeichnen, das ist schon eine
> HTML-spezifische Codierung.
>
ich denke, ich habe das jetzt verstanden, jetzt muss ich nur noch sehen,
wie ich die neuen Gefilde komme.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Stefan Froehlich schrieb:
> On Thu, 26 Jul 2007 18:08:13 +0200 Werner Partner wrote:
>>>>> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
>>>>> umwandeln,
>
>>>> Dumme Frage: warum denn?
>
>>> Weil ein ä in ISO-8859-1 (oder -2 oder -15) kein ä in UTF-8 ist.
> [...]
>
>> Ich denke, es ist sowieso sinnvoll, Sonderzeichen wie ä,ö,ü,&,¤," usw.
>> in die ensprechenden Sondercodes umzuwandeln. ich habe da ein bisschen
>> geschludert in letzter Zeit.
>
> Nein, ist es nicht - und genau darauf sollte meine dumme Frage abzielen.
> Wenn Du mit Zeichenketten sinnvoll arbeiten willst, brauchst Du auch die
> echten Zeichenketten dafuer. Wie sich z.B. hier ja gerade zeigt, gibt es
> sonst Probleme an verschiedenen Ecken und Enden. Gross-/Kleinschreibung
> ist nur ein Thema, es gibt auch noch Probleme mit der Laengenberechnung,
> und wenn Du einmal eine (plain text) Email verfassen willst, wird es
> mit Entities auch nicht gerade einfacher.
>
> Daher: die gesamte Verarbeitung in _einem_ Zeichensatz (ob ISO-8859-1
> bei Dir ausreicht, kann ich nicht sagen, ansonsten halt gleich UTF-8)
> und erst zum Zeitpunkt der Ausgabe an den Browser die Umwandlung in das
> gewuenschte Zielformat (idealerweise braucht man da auch nur <, & und
> " zu maskieren, der Rest wird durch entsprechende Deklaration im Header
> kundgetan).
ISO-8859-1 reicht prinzipiell aus, aber da ich jetzt polnische und
demnächst türkische Zeichen habe, ist UTF-8 angesagt. Dies bedingt
aber, dass ich meinen Editor überprüfen muss. Gegebenenfalls brauche ich
einen anderen.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Niels Braczek schrieb:
> Werner Partner schrieb:
>> Niels Braczek schrieb:
>
>>> Nö. Es reicht nicht, den String als UTF zu *deklarieren*, er sollte auch
>>> so *kodiert* sein. ä ist übrigens eine *HTML*-Entity, keine UTF-Entity.
>> Wie "kodiere" ich ein ä richtig? ich habe da eine deutsche Tastatur, in
>> die ich die Texte reintippe ...
>
> Eintippen ist ok, es geht ums Speichern.
>
>> Ich hb mal ein bisschen rumgeschaut. Ich brauche also einen Editor, der
>> UTF kann. Ich benutze phase5, da kann ich nichts finden, was hilfreich
>> ist ...
>
> Richtig. Ich benutze auch Phase5; da heißt es Suchen und Ersetzen mit
> den A-Tilde-Zeichenfolgen (ä=ä, ö=ö, ü=ü usw.). Es wird also Zeit,
> auf die Suche nach einem zeitgemäßen Editor zu gehen.
ich fand phase5 immer ganz toll, aber offensichtlich ist er nicht mehr
weiter gepflegt worden, seitdem sein Autor ihn abgegeben hat.
Wenn ich einen neuen Editor verwende, dann soll er mindestens die
Funktionalitäten mitbringen, die phase5 hat, wichtig finde ich das
Highlighting von Code, vor allem natürlich PHP. Praktisch bei phase5
finde ich, dass das Änderungsdatum immer aktualisiert wird.
Ich würde gerne auf einen entsprechenden Editor wechseln, vor allem,
wenn dieser Editor auch auf Linux läuft.
Was kann die Gemeinde denn da empfehlen.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Michael Fesser schrieb:
> .oO(Werner Partner)
>
>> Ich hb mal ein bisschen rumgeschaut. Ich brauche also einen Editor, der
>> UTF kann. Ich benutze phase5, da kann ich nichts finden, was hilfreich
>> ist ...
>
> Phase5 kann das vermutlich immer noch nicht, was für mich schon vor zwei
> Jahren der Grund war, dieses Programm nicht mehr zu verwenden (obwohl es
> mir ansonsten recht gut gefiel).
>
> Mittlerweile bin ich bei Eclipse als Entwicklungsumgebung gelandet (für
> Dich wahrscheinlich Overkill), für kleinere Editierarbeiten tuts auch
> jEdit ganz hervorragend.
Wie gesaagt, ich fände einen Editor gut, der die Funktionalitäten von
phase5 mitbringt, besseres Highlighting, auch was für Linux.
GRüße
werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Claus Reibenstein schrieb:
> Werner Partner schrieb:
>
>> Ich hb mal ein bisschen rumgeschaut. Ich brauche also einen Editor, der
>> UTF kann. Ich benutze phase5, da kann ich nichts finden, was hilfreich
>
> Unter Linux tut's der vi, für Windows benutze ich den kostenlosen
> Crimson Editor. Beide können UTF-8 und Syntax Highlighting. Mehr braucht
> man als Hacker eigentlich nicht.
Umpf - den vi habe ich schon vor 20 Jahren benutzt, das ist so was für
Puristen. ich benutze den aus Gedankenlosigkeit heute noch, wenn ich im
Linux-Kommandomus bin. ich habe den vi allerdings noch nicht bei
Hightlighting erlebt ;-)
Den Komfort von phase5 würde ich inzwischen doch nciht mehr missen
wollen, <hn>, <p>, Aufzählungen usw. per Knopfdruck finde ich gut und
erleichtert die Arbeit.
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Claus Reibenstein schrieb:
> Werner Partner schrieb:
>
>> Stefan Froehlich schrieb:
>>
>>> On Thu, 26 Jul 2007 17:14:09 +0200 Werner Partner wrote:
>>>
>>>> Wenn ich UTF-8 verwende, muss ich zunächst alle ä in ä usw.
>>>> umwandeln,
>
> Nein.
>
>>> Dumme Frage: warum denn?
>> Weil bei Deklaration von UTF-8 bei allen äs ös und üs '?' auftauchen.
>
> Dann sind die Umlaute nicht in UTF-8 kodiert, sondern vermutlich noch in
> ISO-8859-1. Dem kannst Du mit iconv() abhelfen.
ich glaube, ich hab's endlich verstanden ;-)
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
On Fri, 27 Jul 2007 10:29:59 +0200 Werner Partner wrote:
> Ich würde gerne auf einen entsprechenden Editor wechseln, vor allem,
> wenn dieser Editor auch auf Linux läuft.
> Was kann die Gemeinde denn da empfehlen.
Ich arbeite zwar unter Linux, allerdings verwende ich seit ueber 10
Jahren ausschliesslich den vim fuer alles, was ich schreibe - das wird
nicht ganz dem entsprechen, was Du suchst (wiewohl Syntax Highlighting
vorhanden ist, und auch eine Menge andere Dinge).
Servus,
Stefan
--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Happy mit Stefan, lüstern und verschmiert!
(Sloganizer)
Re: Nochmal Sprachversionen - knifflige Aufgabe
..oO(Werner Partner)
>Wie gesaagt, ich fände einen Editor gut, der die Funktionalitäten von
>phase5 mitbringt, besseres Highlighting, auch was für Linux.
Wie gesagt, bevor ich mit Eclipse anfing, war ich sehr begeistert vom
jEdit. Das Ding ist extrem flexibel und konfigurierbar, schon eine
normale Installation ohne weitere Plugins bietet Möglichkeiten und
kleine Schmankerl, von denen andere Editoren nur träumen können.
Die Einarbeitungszeit ist relativ gering. Zudem ist jEdit in Java
geschrieben und sollte somit prinzipiell auf jeder Plattform laufen.
Einen Blick wert ist er allemal.
http://www.jedit.org/
Micha
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
> Claus Reibenstein schrieb:
>
>> Unter Linux tut's der vi [...]
>
> Umpf - den vi habe ich schon vor 20 Jahren benutzt, das ist so was
> für Puristen.
Gute Programmierer _sind_ Puristen ;-)
Außerdem kannst Du den vi von damals nicht unbedingt mit dem vi(m) von
heute vergleichen. Er lässt sich natürlich immer noch genau so bedienen
wie damals, hat aber mittlerweile doch einiges dazugelernt.
> ich benutze den aus Gedankenlosigkeit heute noch, wenn ich im
> Linux-Kommandomus bin. ich habe den vi allerdings noch nicht bei
> Hightlighting erlebt ;-)
Dann hast Du etwas verpasst.
> Den Komfort von phase5 würde ich inzwischen doch nciht mehr missen
> wollen, <hn>, <p>, Aufzählungen usw. per Knopfdruck finde ich gut und
> erleichtert die Arbeit.
Das kannst Du im vi(m) auch haben. Du musst Dir nur entsprechende Makros
stricken und die auf eine Taste legen. :map ist Dein Freund :-)
Gruß. Claus
Re: Nochmal Sprachversionen - knifflige Aufgabe
Michael Fesser schrieb:
> .oO(Werner Partner)
>
>> Wie gesaagt, ich fände einen Editor gut, der die Funktionalitäten von
>> phase5 mitbringt, besseres Highlighting, auch was für Linux.
>
> Wie gesagt, bevor ich mit Eclipse anfing, war ich sehr begeistert vom
> jEdit. Das Ding ist extrem flexibel und konfigurierbar, schon eine
> normale Installation ohne weitere Plugins bietet Möglichkeiten und
> kleine Schmankerl, von denen andere Editoren nur träumen können.
>
> Die Einarbeitungszeit ist relativ gering. Zudem ist jEdit in Java
> geschrieben und sollte somit prinzipiell auf jeder Plattform laufen.
>
> Einen Blick wert ist er allemal.
>
das stimmt! ich hab mir's mal angeschaut. Trotzdem vermisse ich einiges,
was phase5 bietet.
Gibt es die Möglichkeit, Projekte festzulegen und das aktuelle
verzeichnis in einem Febster links anzuzeigen?
Wie wird denn nun in UTF-8 codiert?
Grüße
Werner
--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de
Re: Nochmal Sprachversionen - knifflige Aufgabe
Werner Partner schrieb:
>Ich würde gerne auf einen entsprechenden Editor wechseln, vor allem, wenn
>dieser Editor auch auf Linux läuft.
Ich nutze Notepad++ [http://notepad-plus.sf.net]. Kann sehr viel und ist
leichtgewichtig, allerdings eine native Win32-Anwendung.
--
Wolfgang Fellger
Re: Nochmal Sprachversionen - knifflige Aufgabe
..oO(Werner Partner)
>>[jEdit]
>
>das stimmt! ich hab mir's mal angeschaut. Trotzdem vermisse ich einiges,
>was phase5 bietet.
>
>Gibt es die Möglichkeit, Projekte festzulegen und das aktuelle
>verzeichnis in einem Febster links anzuzeigen?
Ja, es gibt einen Projekt-Manager als Plugin. Wie das Ding jetzt genau
heißt, müßte ich erst nachschauen, aber die ganzen Plugins lassen sich
relativ bequem direkt im jEdit auswählen und installieren.
>Wie wird denn nun in UTF-8 codiert?
Einmal konfiguriert und dann einfach drauf los. ;)
Micha