PEAR und UTF-8

Moin NG,

durch die Diskussion in "Guter Programmierstil - Standards?" bin ich
gerade über die Dateiformate-Seite[1] in der PEAR Doku gestolpert. Darin
wird vorgeschrieben, dass Dateien
> mit dem Zeichensatz ISO-8859-1 kodiert werden.

Da ich meine Projekte alle in UTF-8 kodiere, stellt sich mir gerade die
Frage, ob sich das nicht mit PEAR beißt. PEAR nutze ich eigentlich recht
selten, daher habe ich mir über Zeichensätze in dem Zusammenhang noch
gar keine Gedanken gemacht. Ist ja schon ein bisschen blöd bzw.
inkonsistent mit mehreren Zeichensätzen in einem Projekt.

Kann es denn zu Problemen kommen wenn ich in einem UTF-8 Projekt PEAR
verwende?

[1]http://pear.php.net/manual/de/standards.file.php

Gruß Jacob

Re: PEAR und UTF-8

Jacob Hayn wrote:

> durch die Diskussion in "Guter Programmierstil - Standards?" bin ich
> gerade über die Dateiformate-Seite[1] in der PEAR Doku gestolpert. Darin
> wird vorgeschrieben, dass Dateien
> > mit dem Zeichensatz ISO-8859-1 kodiert werden.

Entschuldige meine Ausdrucksweise aber PEAR ist halt typischer
"Ami-Shit" der noch dazu hoffnungslos veraltet ist.
Also ich kenn z.B. keine pear-Klasse die in PHP5 geschrieben ist.

Nix gegen deren Coding-Guidlines, die einen guten Startpunkt für eigene
Standards darstellen. Abe PEAR selbst verwende ich schon seit langen
nicht mehr freiwillig.

MfG, Ulf

Re: PEAR und UTF-8

Ulf Kadner
> Also ich kenn z.B. keine pear-Klasse die in PHP5 geschrieben ist.

Was wohl an der zwanghaften Abwärtskompatibilität von PEAR liegen
dürfte ...


Gruß,
Habbo


--

I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo

Re: PEAR und UTF-8

Jan Habbo Bruening wrote:
> Ulf Kadner
>> Also ich kenn z.B. keine pear-Klasse die in PHP5 geschrieben ist.
>
> Was wohl an der zwanghaften Abwärtskompatibilität von PEAR liegen
> dürfte ...

Korrekt. Halt hoffnungslos veraltet.

MfG, Ulf

Re: PEAR und UTF-8

Am 10. April 2008 schrieb Ulf Kadner:

> Jacob Hayn wrote:
>
>> durch die Diskussion in "Guter Programmierstil - Standards?" bin ich
>> gerade über die Dateiformate-Seite[1] in der PEAR Doku gestolpert. Darin
>> wird vorgeschrieben, dass Dateien
>> > mit dem Zeichensatz ISO-8859-1 kodiert werden.
>
> Entschuldige meine Ausdrucksweise aber PEAR ist halt typischer
> "Ami-Shit" der noch dazu hoffnungslos veraltet ist.
> Also ich kenn z.B. keine pear-Klasse die in PHP5 geschrieben ist.

D.h. also, dass es etwas was du nicht kennst, gar nicht geben kann?

Gruß
Mark

--
Jan-Age Fjörtoft: "Magaths Training ist wie ein Zahnartztermin. Man
fürchtet sich vorher, aber danach fühlt man sich besser!"

Re: PEAR und UTF-8

Mark Wiesemann wrote:

>> Also ich kenn z.B. keine pear-Klasse die in PHP5 geschrieben ist.
>
> D.h. also, dass es etwas was du nicht kennst, gar nicht geben kann?

Wenn Du denkst...

Re: PEAR und UTF-8

Ulf Kadner wrote:

Hallo,

> Jan Habbo Bruening wrote:
>> Ulf Kadner
>>> Also ich kenn z.B. keine pear-Klasse die in PHP5 geschrieben ist.
>>=20
>> Was wohl an der zwanghaften Abwärtskompatibilität von PEAR liege=
n
>> dürfte ...
>=20
> Korrekt. Halt hoffnungslos veraltet.

Wie wäre es mit hoffnungsvoll zukunftsorientiert?

Chapter 4. PEAR2 Coding Standards
http://pear.php.net/manual/en/pear2cs.php

The minimum PHP version supported will be the earliest version
that supports namespaces, most likely PHP version 5.3.0.
This RFC will be updated as soon as the exact version is
known.


tschuess
[|8:)

Re: PEAR und UTF-8

Sven Drieling wrote:
> Ulf Kadner wrote:
>> Korrekt. Halt hoffnungslos veraltet.
>
> Wie wäre es mit hoffnungsvoll zukunftsorientiert?

Sicher nicht.

>
> Chapter 4. PEAR2 Coding Standards

Naja es ging ja nicht um PEAR2. Natürlich stimme ich Dir für PEAR2 zu
aber der OP fragte nach PEAR und nicht nach was, was im Moment noch
nicht nutzbar ist.

MfG, Ulf

Re: PEAR und UTF-8

Am 10. April 2008 schrieb Ulf Kadner:

> Sven Drieling wrote:
>> Ulf Kadner wrote:
>>> Korrekt. Halt hoffnungslos veraltet.
>>
>> Wie wäre es mit hoffnungsvoll zukunftsorientiert?
>
> Sicher nicht.

Die Forderung nach E_STRICT-kompatiblem Code für *alle* neuen
PEAR-Pakete ist also nicht zukunftsorientiert?

Gruß
Mark

--
Mario Basler: "Ich lerne nicht extra französisch für die Spieler, wo
dieser Sprache nicht mächtig sind."

Re: PEAR und UTF-8

Mark Wiesemann wrote:

> Die Forderung nach E_STRICT-kompatiblem Code für *alle* neuen
> PEAR-Pakete ist also nicht zukunftsorientiert?

Du hast es recht gut raus alles mögliche vollkommen aus dem Zusammenhang
zu reisen. Was macht dieser kleinkram besser an veraltenen PHP4 Klassen?

Re: PEAR und UTF-8

Am 10. April 2008 schrieb Ulf Kadner:

> Mark Wiesemann wrote:
>
>> Die Forderung nach E_STRICT-kompatiblem Code für *alle* neuen
>> PEAR-Pakete ist also nicht zukunftsorientiert?
>
> Du hast es recht gut raus alles mögliche vollkommen aus dem Zusammenhang
> zu reisen. Was macht dieser kleinkram besser an veraltenen PHP4 Klassen?

Deine pauschalen Urteile sind nun mal Unsinn. Und von was für einem
Kleinkram redest du hier?

Und natürlich muss PHP 4-Code nicht veraltet sein, es gibt durchaus
einige Fälle, in denen man auf seinen Code PHP 4-kompatibel halten muss.

Gruß
Mark

--
Glenn Hoddle: "Wenn wir meinen, die Spieler haben es nötig, dann lassen
wir ihre Frauen und Freundinnen hierher holen, um die Jungs wieder hoch
zu kriegen."

Re: PEAR und UTF-8

Jacob Hayn schrieb:
> gerade über die Dateiformate-Seite[1] in der PEAR Doku gestolpert. Da=
rin=20
> wird vorgeschrieben, dass Dateien
> > mit dem Zeichensatz ISO-8859-1 kodiert werden.
>=20
> Kann es denn zu Problemen kommen wenn ich in einem UTF-8 Projekt PEAR=20
> verwende?

Da dies noch keiner beantwortet hat: Nein.

Gruß
Carsten

Re: PEAR und UTF-8

Mark Wiesemann
> Deine pauschalen Urteile sind nun mal Unsinn. Und von was für
> einemKleinkram redest du hier?

Die Frage ist wohl eher, warum man die Produktion von fehlerfreiem
Code als Feature herauskehrt. Ich halte das nicht für einen Vorteil
einesFrameworks, sondern für die Grundvoraussetzung seiner Benutzung
...

Mit Zukunftsmusik hat das schon gar nichts mehr zu tun, fehlerfreies
Programmieren war mit PHP 3 und kleiner auch möglich oder?


Gruß,
Habbo

ps: Ja doch, ich halte es auch für gut, dass PEAR sich diesem
"Standard" stellt :)


--

I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo

Re: PEAR und UTF-8

Mark Wiesemann wrote:

> Deine pauschalen Urteile sind nun mal Unsinn.

Na DU musts ja wissen.

> Und natürlich muss PHP 4-Code nicht veraltet sein

PHP4 ist veraltet. Es gibt keinen Grund sowas noch zu verwenden.
Wer es bis jetzt (PHP5 gibts schon ne halbe Ewigkeit) noch nicht
geschafft hat seine Anwendungen ordentlich nach PHP5 zu migrieren hat
aber wirklich Probleme in seiner Entwicklungsstrategie.

Und bevor Du hier mit Pauschalisierung um Dich wirfst zeig mir doch mal
ein Beispiel mit realen Hintergrund der Deine These notwendig machen würde.

Re: PEAR und UTF-8

Am 10. April 2008 schrieb Ulf Kadner:

> Mark Wiesemann wrote:
>> Und natürlich muss PHP 4-Code nicht veraltet sein
>
> PHP4 ist veraltet. Es gibt keinen Grund sowas noch zu verwenden.
> Wer es bis jetzt (PHP5 gibts schon ne halbe Ewigkeit) noch nicht
> geschafft hat seine Anwendungen ordentlich nach PHP5 zu migrieren hat
> aber wirklich Probleme in seiner Entwicklungsstrategie.

Das Problem ist nicht, dass man es nicht schafft, seine Anwendungen zu
migrieren, sondern dass man Kunden hat, die noch PHP 4 installiert
haben. Da mag es noch so viele schönen Sachen in PHP 5 geben, man kann
sie einfach nicht einsetzen, weil sie beim Kunden nicht laufen werden.
Ich werde hier keine Namen nennen, aber ich spreche hierbei nicht von
irgendwelchen Hinterhoffirmen als Kunden.

Deine Aussage "PHP4 ist veraltet. Es gibt keinen Grund sowas noch zu
verwenden." ist also falsch.

Gruß
Mark

--
Helmut Schulte (als Manager vom FC St. Pauli): "Vor der Saison haben
alle gedacht, dass wir gegen Bayern kleine Brötchen kochen müssen. Aber
wie man sieht, backen die auch nur mit Wasser."

Re: PEAR und UTF-8

Mark Wiesemann schrieb:
>> Mark Wiesemann wrote:

> Das Problem ist nicht, dass man es nicht schafft, seine Anwendungen zu
> migrieren, sondern dass man Kunden hat, die noch PHP 4 installiert
> haben.

Ich kenne keinen Fall - auch nicht bei Massenhostern - wo die Umstellung
auf PHP5 nicht (schon seit mindestens einem Jahr) problemlos möglich
wäre. IdR ein Aufwand von 2-3 Minuten.

> Da mag es noch so viele schönen Sachen in PHP 5 geben, man kann
> sie einfach nicht einsetzen, weil sie beim Kunden nicht laufen werden.

Bei neuen Projekten setze ich generell PHP5 voraus. Updates bei
Altkunden mache ich nur noch, wenn auch auf PHP5 umgestellt wird. PHP4
ist tot. Wer das (als Kunde) nicht akzeptiert, ist nicht mein Kunde.

> Deine Aussage "PHP4 ist veraltet. Es gibt keinen Grund sowas noch zu
> verwenden." ist also falsch.

PHP4 ist nicht nur veraltet. PHP4 ist tot (+5.2.2008).
http://www.gophp5.org

MfG
Niels

--=20
| 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: PEAR und UTF-8

Am 10. April 2008 schrieb Niels Braczek:

> Mark Wiesemann schrieb:
>
>> Das Problem ist nicht, dass man es nicht schafft, seine Anwendungen zu
>> migrieren, sondern dass man Kunden hat, die noch PHP 4 installiert
>> haben.
>
> Ich kenne keinen Fall - auch nicht bei Massenhostern - wo die Umstellung
> auf PHP5 nicht (schon seit mindestens einem Jahr) problemlos möglich
> wäre. IdR ein Aufwand von 2-3 Minuten.

Es geht weder um Hinterhof- noch um Massenhoster, sondern um große
Konzerne. Dort ist es etwas schwieriger, solche Umstellungen machen zu
lassen.

> Bei neuen Projekten setze ich generell PHP5 voraus. Updates bei
> Altkunden mache ich nur noch, wenn auch auf PHP5 umgestellt wird. PHP4
> ist tot. Wer das (als Kunde) nicht akzeptiert, ist nicht mein Kunde.

Es gibt aber eben auch Kunden mit Wartungsverträgen. Denen kann man
nicht mal eben sagen, dass das eigene Produkt nächste Woche nicht mehr
funktionieren wird, weil es plötzlich PHP 5 voraussetzt.

Langfristig (= im Laufe der nächsten Monate) wird das aber trotzdem
passieren, denn gerade jetzt bietet sich das Supportende von PHP 4 an,
um auch solchen Kunden das PHP-Upgrade schmackhaft zu machen.

>> Deine Aussage "PHP4 ist veraltet. Es gibt keinen Grund sowas noch zu
>> verwenden." ist also falsch.
>
> PHP4 ist nicht nur veraltet. PHP4 ist tot (+5.2.2008).
> http://www.gophp5.org

Das letzte Release ist gar nicht so lange her, "veraltet" passt also
nicht. Und es gibt eben doch noch Gründe, "sowas noch zu verwenden".

Und nur weil Code kompatibel zu PHP 4 ist, muss er nicht schlecht sein.

Gruß
Mark

--
Sachbücher-Bestseller-Liste im Spiegel 42/2006:
Platz 1 | Hape Kerkeling | Ich bin dann mal weg
Platz 2 | Joachim Fest | Ich nicht

Re: PEAR und UTF-8

Mark Wiesemann schrieb:
> Am 10. April 2008 schrieb Niels Braczek:

>> PHP4 ist nicht nur veraltet. PHP4 ist tot (+5.2.2008).
>> http://www.gophp5.org
>=20
> Das letzte Release ist gar nicht so lange her, "veraltet" passt also
> nicht. Und es gibt eben doch noch Gründe, "sowas noch zu verwenden".
>=20
> Und nur weil Code kompatibel zu PHP 4 ist, muss er nicht schlecht sein.=


Das sagt ja auch keiner - steht übrigens auch auf goPHP5. Es geht nicht=

darum, dass Code nicht mehr unter PHP4 laufen können soll, sondern dass=

man als Entwickler keine Rücksicht mehr auf Altlasten nehmen soll, Es
ist legitim, PHP5.2 vorauszusetzen - das gibt's immerhin schon
anderthalb Jahre. Guter[tm] PHP4-Code läuft auch auf PHP5 - siehe
Joomla. Joomla hat es allerdings leider nicht geschafft, PHP4 mit der
1.5er Version hinter sich zu lassen. Die Argumentation der
Kernentwickler ist traurig: Weil die meisten Installationen mit PHP4
laufen...

MfG
Niels

--=20
| 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: PEAR und UTF-8

Mark Wiesemann wrote:
> Am 10. April 2008 schrieb Ulf Kadner:
>
>> Mark Wiesemann wrote:
>>> Und natürlich muss PHP 4-Code nicht veraltet sein
>> PHP4 ist veraltet. Es gibt keinen Grund sowas noch zu verwenden.
>> Wer es bis jetzt (PHP5 gibts schon ne halbe Ewigkeit) noch nicht
>> geschafft hat seine Anwendungen ordentlich nach PHP5 zu migrieren hat
>> aber wirklich Probleme in seiner Entwicklungsstrategie.
>
> Das Problem ist nicht, dass man es nicht schafft, seine Anwendungen zu
> migrieren, sondern dass man Kunden hat, die noch PHP 4 installiert
> haben.

Also meine Kunden besitzen mit jeder gekauften Anwendungslizenz ein
Anrecht auf meinen Service zur Migration auf die nächste volle
PHP-Version. (Kostenlos natürlich)

Ich betreue nicht nur kleine Webseiten sondern auch Firmennetzwerke mit
mehr als 300 Clients. Alle haben von mir Rechtzeitig mit genügend
Vorlauf bescheid bekommen und eine Migration war vollkommen Problemlos
möglich. Dauert ja nun wirklich nur nen paar Minuten.

> sie einfach nicht einsetzen, weil sie beim Kunden nicht laufen werden.

Dann hast Du eindeutig Deine Pflicht zur rechtzeitigen Benachrichtigung
nicht wargenommen. Na das ist ja nun wirklich kein Argument pro
PHP4-Altlasten.

> Ich werde hier keine Namen nennen

Das ist auch nicht nötig...

> Deine Aussage "PHP4 ist veraltet. Es gibt keinen Grund sowas noch zu
> verwenden." ist also falsch.

:-)

Re: PEAR und UTF-8

Hi Ulf,

> Also meine Kunden besitzen mit jeder gekauften Anwendungslizenz ein
> Anrecht auf meinen Service zur Migration auf die nächste volle
> PHP-Version. (Kostenlos natürlich)

Wenn man die Anwendung selbst geschrieben hat und bereits unter PHP4
drauf geachtet hat das eine Migration auf Folgeversionen problemlos
möglich ist mag das gehen. Bei Übernahme von Altprogrammen von meist
dummen Programmierern eine kostenlose Migration zu machen ist schon fast
ein Todesurteil weil meist jegliche Dokumentation des ganzen fehlt und
so nicht abgeschätzt werden kann welche Probleme bei einer Migration auf
einen zukommen.


> Ich betreue nicht nur kleine Webseiten sondern auch Firmennetzwerke mit
> mehr als 300 Clients. Alle haben von mir Rechtzeitig mit genügend
> Vorlauf bescheid bekommen und eine Migration war vollkommen Problemlos
> möglich. Dauert ja nun wirklich nur nen paar Minuten.

siehe oben.


> Dann hast Du eindeutig Deine Pflicht zur rechtzeitigen Benachrichtigung
> nicht wargenommen. Na das ist ja nun wirklich kein Argument pro
> PHP4-Altlasten.

Finde ich schon, zumindest wenn man nicht von dem Punkt "Neuentwicklung"
sondern von dem Punkt "Wartung eines bestehenden Systems" ausgeht. Da
finden sich auch bei mir etliche dieser Projekte in denen wie oben
beschrieben jegliche Doku fehlt und so die Benachrichtigung das man
migrieren muss einfach überhört wird, da dies in den meisten Fällen zu
einer kompletten Neuentwicklung führen würde und das kein Kunde bezahlen
will.

Ciao Markus

Re: PEAR und UTF-8

Am 10. April 2008 schrieb Ulf Kadner:

> Ich betreue nicht nur kleine Webseiten sondern auch Firmennetzwerke mit
> mehr als 300 Clients.

Schön für dich. Ich schrieb aber was von "großen Unternehmen".

Mark Wiesemann wrote:
>> sie einfach nicht einsetzen, weil sie beim Kunden nicht laufen werden.
>
> Dann hast Du eindeutig Deine Pflicht zur rechtzeitigen Benachrichtigung
> nicht wargenommen.

Es sind nicht meine Kunden. Und die Ankündigung / Bitte gab es schon vor
längerer Zeit. Wirkliche Taten kann man aber nicht so leicht erzwingen.
Das Problem ist also die Updateunwilligkeit der Kunden. Die Anwendung
selbst läuft natürlich unter PHP 4 und 5.

Gruß
Mark

--
Christoph Daum: "Man muss nicht immer die absolute Mehrheit hinter sich
haben, manchmal reichen auch 51 Prozent."

Re: PEAR und UTF-8

Carsten Wiedmann schrieb:
> Da dies noch keiner beantwortet hat: Nein.

Klingt vielleicht etwas naiv, aber warum denn nicht?

Wohl gemerkt bezog sich meine Frage auf die Verarbeitung durch PHP. Dass
man sich durch falsche Einstellungen in der IDE unter anderem sämtliche
Umlaute zerschießen kann ist schon klar.

Re: PEAR und UTF-8

Jacob Hayn wrote:
> Carsten Wiedmann schrieb:
>> Da dies noch keiner beantwortet hat: Nein.
>
> Klingt vielleicht etwas naiv, aber warum denn nicht?
>
> Wohl gemerkt bezog sich meine Frage auf die Verarbeitung durch PHP. Dass
> man sich durch falsche Einstellungen in der IDE unter anderem sämtliche
> Umlaute zerschießen kann ist schon klar.

Das PHP-Script benutzt eh nur Keywords welche Zeichen enthält die unter
allen Kodierungen richtig interpretiert werden sollten (7bit ASCII).

Was Variablennamen angeht ist PHP ziemlich zäh so, dass auch beim
Wechsel der Codierung und zerschossen Variablennamen das PHP-Script
keine Fehler produziert hat (jedenfalls bei den zwei Fällen von fremden
Code wo ich die Kodierung gewechselt habe und jemand unbedingt Umlaufte
in Variablennamen benutzen musste).

Zeichenketten sind jenachdem sowohl in dem Script wie auch in der
Ausgabe zerschossen.

Joe

Re: PEAR und UTF-8

Danke für die Erklärung.

Joe Scylla schrieb:
> ...jedenfalls bei den zwei Fällen von fremden
> Code wo ich die Kodierung gewechselt habe und jemand unbedingt Umlaufte
> in Variablennamen benutzen musste...

Oha, ich hätte nicht gedacht, dass Umlaute in Variablennamen überhaupt
funktionieren. Auf was für Ideen Manche kommen, seltsam. Aber gut zu
wissen, dass PHP so "robust" ist.

Gruß Jacob

Re: PEAR und UTF-8

Jacob Hayn schrieb:

> Oha, ich hätte nicht gedacht, dass Umlaute in Variablennamen überhaupt
> funktionieren. Auf was für Ideen Manche kommen, seltsam. Aber gut zu
> wissen, dass PHP so "robust" ist.

Offensichtlich verhält sich PHP hier genauso wie Java: alles, was
außerhalb des ASCII-Zeichensatzes liegt, wird einfach als Buchstabe
betrachtet.

So seltsam ist das übrigens gar nicht. Manche Programmierer,
insbesondere aus dem asiatischen Raum, dürften sich gewaltig freuen über
die Möglichkeit, ihre Programme in kyrillischen, arabischen,
chinesischen und japanischen Schriftzeichen zu verfassen. Irgendwo hatte
ich so etwas auch schon mal gesehen.

Gruß. Claus

Re: PEAR und UTF-8

Claus Reibenstein wrote:
> Jacob Hayn schrieb:
>
>> Oha, ich hätte nicht gedacht, dass Umlaute in Variablennamen überhaupt
>> funktionieren. Auf was für Ideen Manche kommen, seltsam. Aber gut zu
>> wissen, dass PHP so "robust" ist.
>
> Offensichtlich verhält sich PHP hier genauso wie Java: alles, was
> außerhalb des ASCII-Zeichensatzes liegt, wird einfach als Buchstabe
> betrachtet.
>
> So seltsam ist das übrigens gar nicht. Manche Programmierer,
> insbesondere aus dem asiatischen Raum, dürften sich gewaltig freuen über
> die Möglichkeit, ihre Programme in kyrillischen, arabischen,
> chinesischen und japanischen Schriftzeichen zu verfassen. Irgendwo hatte
> ich so etwas auch schon mal gesehen.

Aus Interesse hab ich mal chinesische Schriftzeichen getestet und kann
bestätigen das man diese ohne Problem für Variablen und Funktionsnamen
verwenden kann (auch wenn Eclipse/PDT Fehler anzeigt).

z.B.:


function 简体中文网页($视频)
{
echo $视频;
}

$所有网页 = "test the west";
简体中文网页($所有网页);


Joe