Lösung: erst decodieren, damit bei allen evtl. bereits ersetzten Zeichen das "&" nicht durch "&" ersetzt wird.
decode_entities($a);
encode_entities($a);

[quote=Spider-Mann,17.07.2005, 00:45]Lösung: erst decodieren, damit bei allen evtl. bereits ersetzten Zeichen das "&" nicht durch "&" ersetzt wird.
decode_entities($a);
encode_entities($a);[/quote]
da hebt sich ja (eigentlich) auf.
vielleicht hättest du erwähnen sollen, dass dein unsprünglicher text nur
halbfertig kodiert ist, also offensichtlich teilweise & enthält, aber
auch unkodierte &. dann ist auch klar, warum das fehlschlägt.
wäre es so schwer gewesen, einen beispieltext zu posten, der das problem
demonstriert?

Ich habe drei Beispielzeilen gepostet.

Normalerweise ist der Text unkodiert, da er aber evtl. von Hand bearbeitet wird könnte ja jemand auf die Idee kommen & zu schreiben.

Eine neue Frage:

Wo kann ich eine Liste aller Modifier und Optionen herbekommen? Also was "m" "s" und "tr" bedeuten weiß ich:

=~ m/123/ -> matcht auf 123
=~ tr/[a-z]/[A-Z]/ -> transformiert Kleinbuchstaben in Großbuchstaben
=~ s/\"//g -> entfernt alle Anführungszeichen
Aber was gibt es noch?

=~ m/aBc/i -> "i" matcht unabhängig von Groß/Kleinbuchstaben
=~ s/\"//g -> "g" sucht nach dem ersten Vorkommen weiter
Aber was gibt es noch?\n\n

<!--EDIT|Spider-Mann|1121600163-->

Das Vorgehen mit encode(decode(..)) bewirkt ja, dass man ein (literales) HTML-Entity nicht als Teil des Nick wählen kann, bzw. dass es als HTML-Entity in den Nick eingeht.
Letztlich nur eine Frage, ob man die Erwartung des Anwenders damit erfüllt (idR wahrscheilich schon, IMHO).

Die gesuchten Infos zu den Modifikatoren finden sich unter
perldoc perlop

[quote=Spider-Mann,17.07.2005, 13:34]Ich habe drei Beispielzeilen gepostet.[/quote]
[quote=pq,17.07.2005, 12:16]einen beispieltext zu posten, der das problem demonstriert?[/quote]

Quote

Normalerweise ist der Text unkodiert, da er aber evtl. von Hand bearbeitet wird könnte ja jemand auf die Idee kommen &amp; zu schreiben.

na und? entweder es ist festgelegt, dass du kodierten text hast oder es ist
festgelegt, dass du unkodierten text hast.
mit mutmaßungen, der nutzen könnte ja evtl. auf die idee kommen,
seinen text selbst zu kodieren, kommst du langfristig nicht weit.
möchte ein anderer nutzer tatsächlich aus irgendeinem grund "&gt;"
schreiben, ist er angeschmiert.
also, klare regeln. ohne sie brauchst du künstliche intelligenz.

[quote=Spider-Mann,16.07.2005, 23:04]HTML::Entities macht ja aus einem "&" immer ein "&amp;" also macht es aus einem "&amp;" ein "&amp;amp;".[/quote]
Dann sollte man das vielleicht mal patchen. Ich verwende für sowas



Edit: Eventuell könnte man das noch erweitern auf

\n\n

<!--EDIT|Crian|1121694531-->

[quote=Crian,18.07.2005, 15:45][quote=Spider-Mann,16.07.2005, 23:04]HTML::Entities macht ja aus einem "&" immer ein "&amp;" also macht es aus einem "&amp;" ein "&amp;amp;".[/quote]
Dann sollte man das vielleicht mal patchen.[/quote]
Wieso patchen, denn das Verhalten ist korrekt. Wie sollte man sonst den String "&amp;" verlustfrei transportieren?

don't fix it unless it's broken oder so.

it's not a bug, it's a feature...

Da sieht man mal, es kommt stark auf den Kontext des Programms an. Ihr habt natürlich Recht, wenn man an Eingabefeld -> Verarbeitung(DB) -> Anzeige(HTML) denkt.

In meinem Fall ging es um die Verarbeitung von XML-Dateien, die aus diversen Quellen kommen und wo sicher ist, dass "&amp;" und Kollegen garantiert nicht im Originaltext standen.

Also: Ich nehme alles zurück und behaupte das Gegenteil =)