Variable nach 6 Zeichen mit "..." abtrennen
Hugo Zeiss
- php
0 Thomas Luethi0 Cheatah0 Sven Rautenberg0 Cheatah0 Sven Rautenberg
0 Tom
Guten morgen,
wie kann ich eine Variable nach einer bestimmten
Anzahl von Zeichen mit 3 Punkten abtrennen.
z.B.:
-----
$test = 'diesisteinlangerstring';
PHP_Funkion($test) -> Ausgabe: diesis...
Wer kann mir helfen ... im Voraus schoneinmal DANKE
Gruß
Hugo
Hallo,
Wer kann mir helfen
Hilf Dir selbst und RTFM:
http://www.php.net/manual/en/ref.strings.php
http://www.php.net/manual/en/function.substr.php
http://www.php.net/manual/de/language.operators.string.php
Gruesse,
Thomas
Hi,
wie kann ich eine Variable nach einer bestimmten
Anzahl von Zeichen mit 3 Punkten abtrennen.
mit handelsüblichen Stringfunktionen? Die PHP-Dokumentation enthält ganze Kapitel darüber? Ist Dir übrigens bekannt, dass ich insbesondere Leuten, die derartiges nicht selbständig erarbeiten können, von PHP mehr als dringend abrate.
Cheatah
P.S.: Ist das jetzt eigentlich die neue Zeichensetzungsreform. Ich hoffe nicht?
Moin!
Ist Dir übrigens bekannt, dass ich insbesondere Leuten, die derartiges nicht selbständig erarbeiten können, von PHP mehr als dringend abrate.
Zumindest mir ist das bekannt. Aber Ersatzempfehlungen werden von dir ja auch nicht ausgesprochen, folglich ist dieser Rat mehr als überflüssig.
- Sven Rautenberg
Hi,
Ist Dir übrigens bekannt, dass ich insbesondere Leuten, die derartiges nicht selbständig erarbeiten können, von PHP mehr als dringend abrate.
Zumindest mir ist das bekannt. Aber Ersatzempfehlungen werden von dir ja auch nicht ausgesprochen,
quasi jede beliebige andere serverseitige Technik. Die Liste ist lang.
Cheatah
Moin!
Ist Dir übrigens bekannt, dass ich insbesondere Leuten, die derartiges nicht selbständig erarbeiten können, von PHP mehr als dringend abrate.
Zumindest mir ist das bekannt. Aber Ersatzempfehlungen werden von dir ja auch nicht ausgesprochen,quasi jede beliebige andere serverseitige Technik. Die Liste ist lang.
Ok. Also eine unbegründete Ablehnung von PHP. Aber das wußten wir ja schon. Siehe </archiv/> (das verlinke ich mal sofort, damit du das nicht tun mußt).
- Sven Rautenberg
Hi,
Ok. Also eine unbegründete Ablehnung von PHP.
meine _Ablehnung_ ist begründet, wie Du weißt. Dass ich keine explizite Empfehlung abgebe liegt daran, dass ich nichts empfehlen möchte, sondern von etwas abrate. Ich verstehe Dein Problem damit nicht. Wenn es Dir mehr zusagt: Ich empfehle die Nicht-Verwendung von PHP.
Cheatah
hi,
meine _Ablehnung_ ist begründet, wie Du weißt. Dass ich keine explizite Empfehlung abgebe liegt daran, dass ich nichts empfehlen möchte, sondern von etwas abrate.
wenn du also ins restaurant gehst, und den ober nach seiner empfehlung fragst, dann bist du auch damit zufreiden, wenn dieser dir lediglich vom muscheleintopf(*) abrät, ohne dir etwas anderes zu empfehlen ...?
du musst dann also im zweifelsfalle die halbe karte oder mehr in diesem frage-antwort-spielchen durchgehen, bis du etwas findest, von dem der ober dir _nicht_ abraten möchte. opt-out statt opt-in. nur ob's an der stelle wirklich so angebracht ist ...?
gruss,
wahsaga
(*) siehe fight club ;-)
Moin!
meine _Ablehnung_ ist begründet, wie Du weißt. Dass ich keine explizite Empfehlung abgebe liegt daran, dass ich nichts empfehlen möchte, sondern von etwas abrate.
wenn du also ins restaurant gehst, und den ober nach seiner empfehlung fragst, dann bist du auch damit zufreiden, wenn dieser dir lediglich vom muscheleintopf(*) abrät, ohne dir etwas anderes zu empfehlen ...?
Vor allem in dieser Manier:
"Vom Muscheleintopf rate ich Ihnen ab."
"Warum?"
"Fragen sie die Gäste, die gestern hier waren."
Sehr einfallsreich.
Aber ich habe mir die Mühe gemacht, und das Archiv (trotz deutlicher Bettelei des Servers, noch mehr Spendengeld einzusammeln) nach ein paar Hinweisen durchsucht.
Die einzige Begründung Cheatahs gegen PHP, die ich gefunden habe: PHP erlaubt es, externe Ressourcen per fopen() anzusprechen.
Da frage ich mich allerdings, was daran böse ist? Es ist das klassische Unix-Konzept, alles und jedes als Datei zu betrachten, nicht nur das, was man von anderen Betriebssystemen her als "Datei" kennt.
Beispiele gefällig?
NFS- und SMB-Ressourcen sind selbstverständlich extern, nur über Netzwerk zu erreichen, aber wie selbstverständlich werden sie ins eigene Dateisystem eingebunden.
Ganze Partitionen, die eigentlich gar keine eigenständige Datei sind, sondern ihrerseite ein Dateisystem und viele Dateien enthalten, sind über /dev/hd? erreichbar.
Serielle Schnittstellen, die selbstverständlich auch keine Dateien sind, sondern Hardwareschnittstellen, sind per /dev/tty? ansprechbar.
Die Maus, egal ob nun seriell, PS/2 oder USB, wird typischerweise als /dev/mouse-Datei angesprochen.
Man kann den gesamten RAM-Speicher über /proc/kcore auslesen, eine Liste installierter PCI-Karten gibts über /proc/pci, und alle aktuell laufenden Prozesse sind im Verzeichnis /proc aufgelistet und erreichbar.
Es gibt also dermaßen viele Beispiele für die angeblich so abstruse Taktik, unterschiedliche Ressourcen unter einem einheitlichen Interface verfügbar zu machen, dass es einfach nur lächerlich ist, wenn PHP deswegen böse sein soll.
- Sven Rautenberg
hi,
Die einzige Begründung Cheatahs gegen PHP, die ich gefunden habe: PHP erlaubt es, externe Ressourcen per fopen() anzusprechen.
Da frage ich mich allerdings, was daran böse ist?
selbst wenn, dann könnte man das unter PHP ja recht einfach abschalten, allow_url_fopen = 0.
klar weiss der neueinsteiger nicht sofort um eventuelle gefahren dieser methodik - aber sich zunächst mal ein bisschen über den sicheren umgang mit der verwendeten technik informieren, diese verpflichtung gilt bei jeder anderen serverseitigen scriptsprache wohl genauso.
gruss,
wahsaga
Hi,
Die einzige Begründung Cheatahs gegen PHP, die ich gefunden habe: PHP erlaubt es, externe Ressourcen per fopen() anzusprechen.
wenn das tatsächlich der einzige Punkt ist, den Du gefunden hast, kann ich Deine Einwände verstehen. fopen() mit URLs ist nur eine Ausprägung nur einer der Gründe, weswegen ich Anfängern von PHP abrate, nämlich der Konzeptarmut der Sprache an sich und der daraus resultierenden Fehleinschätzungen der Sachlage seitens ihrer Anwender.
Viel schwerwiegender ist, dass PHP einem mächtige Waffen in die Hand gibt, deren Sicherheitshebel durch die Aufschrift "sicher" ersetzt wurde, während ein interner Mechanismus selbständig entscheidet, welche Munition nun verwendet wird. Der Anwender kümmert sich nicht um sicherheitsrelevante Fragen, er kümmert sich nicht um die zugrundeliegende Mechanik. Er probiert einfach irgendwas aus, ohne sich der Konsequenzen bewusst zu sein, _und wird dank der Leichtigkeit der Sprache in keiner Weise behindert_. Nur allzu leicht resultiert daraus ein PHP-Chat mit einem PHP-User-online-Counter und anderem Quatsch.
Ich war der Ansicht, dies und anderes oft genug klargemacht zu haben, so dass ich davon ausging, die Gründe seien Dir bewusst. Tut mir leid, dass dem nicht so war.
Cheatah
Moin!
Viel schwerwiegender ist, dass PHP einem mächtige Waffen in die Hand gibt, deren Sicherheitshebel durch die Aufschrift "sicher" ersetzt wurde, während ein interner Mechanismus selbständig entscheidet, welche Munition nun verwendet wird. Der Anwender kümmert sich nicht um sicherheitsrelevante Fragen, er kümmert sich nicht um die zugrundeliegende Mechanik. Er probiert einfach irgendwas aus, ohne sich der Konsequenzen bewusst zu sein, _und wird dank der Leichtigkeit der Sprache in keiner Weise behindert_. Nur allzu leicht resultiert daraus ein PHP-Chat mit einem PHP-User-online-Counter und anderem Quatsch.
Wie supersicher dagegen andere Sprachen "von Hause aus" sind, auch wenn sich jemand mit etwas mehr Programmiererfahrung an die Tastatur setzt, zeigen ja in schillernden Farben die ersten PERL-Skripte von Matt Wright. Der Mann war mit Sicherheit kein Anfänger, aber er hat es trotz Abwesenheit von PHP geschafft, unsichere Skripte herzustellen.
Dein Einwand, PHP wäre per se geeignet, unsichere Skripte zu schreiben, andere Sprachen wären da viel besser, stimmt nicht. Auch andere Sprachen machen es ihren Benutzern genauso leicht, unsicheren Blödsinn zu programmieren. Es liegt nicht an der Sprache, sondern am Programmierer und am Programmkonzept.
Dass PHP für Anfänger leichter zugänglich ist, belegen die Benutzerzahlen. PERL kackt da richtig ab, und alle anderen Möglichkeiten der CGI-Programmierung (C, C++, JSP, Python, ...) spielen in diesem Segment absolut keine Rolle.
Wenn du also von PHP abrätst, bedeutet das im Umkehrschluß, du rätst zu PERL (zumindest rätst du davon nicht ab, sondern stimmst bei Nachfragen eher zu). PERL ist genauso scheiße, wie PHP. Also ist dein Rat wenig hilfreich.
Dass PHP konzeptarm sei, kann ich nicht nachvollziehen. PHP ist eine Programmiersprache. Können Programmiersprachen per se ein Konzept haben? Wenn das so ist, dann hat PHP eindeutig das Konzept "Sei eine nützliche Programmiersprache für Webseiten". Und das wird vollkommen erfüllt - die vielen weborientierten Funktionen und Funktionalitäten von PHP beweisen es. Kritiker behaupten sogar, es seien zuviele Funktionen.
Wer gleichartige Funktionalität bei PERL haben will, darf sich auf das Abenteuer "Module" einlassen (bei denen immer das Problem ist, dass sie kein Bestandteil der zu nutzenden PERL-Installation sein müssen), oder den Kram komplett selbst schreiben. Mit extrem zweifelhaftem Erfolg, was die häufige Mißachtung des Moduls CGI (mutmaßlich trotz dessen Verfügbarkeit) und dessen mieserable Ersatzprogrammierung angeht.
Im Grund genommen ist PERL deswegen sogar noch viel schlechter, als PHP. PHP hat wenigstens eine genormte, funktionierende und bekannte Schnittstelle zu GET und POST-Daten. Bei PERL lebt der Wildwuchs.
Und sowas willst du ernsthaft empfehlen...
- Sven Rautenberg
Hi,
wenn du also ins restaurant gehst, und den ober nach seiner empfehlung fragst, dann bist du auch damit zufreiden, wenn dieser dir lediglich vom muscheleintopf(*) abrät, ohne dir etwas anderes zu empfehlen ...?
es hat niemand nach einer Empfehlung gefragt. Der Vergleich würde weniger hinken, wenn der Ober beim Überreichen der Karte oder bei der Bestellung eines Muscheleintopfes von diesem abraten würde. Wenn _dann_ die Frage nach einer Empfehlung kommt, reden wir gerne weiter.
Cheatah
Hello Hugo,
wie kann ich eine Variable nach einer bestimmten
Anzahl von Zeichen mit 3 Punkten abtrennen.
$test = 'diesisteinlangerstring';
PHP_Funkion($test) -> Ausgabe: diesis...
auf die Gefahr hin, dass hier wieder Beschwerden kommen von Oberlehrern[tm]
Du solltest erstmal entscheiden, wie lang der String werden darf inclusive der Punkte:
define("MAXSTRLEN",22); # nur so als Beispiel
$fort = "...";
$langstring1 = "Ich bin lang";
if (strlen($langstr1) > (MAXSTRLEN - strlen($fort))
{
$langstr1 = substr($langstr1,0,(MAXSTRLEN - strlen($fort)).$fort;
}
else
{
## alles so lassen wie es ist
$langstr1 = $langstr1; ## das kann man dann natürlich auch weglassen
}
echo $ langstr1."<br />";
$langstring2 = "Ich bin aber viel länger als der andere";
if (strlen($langstr2) > (MAXSTRLEN - strlen($fort))
{
$langstr2 = substr($langstr2,0,(MAXSTRLEN - strlen($fort)).$fort;
}
else
{
## alles so lassen wie es ist
$langstr2 = $langstr2; ## das kann man dann natürlich auch weglassen
}
echo $ langstr2."<br />";
Also, wenn man weiß, in welchem Format (z.B. RAW ASCII oder HTML) die
Strings vorliegen, ist das alles kein Problem. Aber viele Texte für die
HTML-Ausgabe liegen eben schon als HTML vor. Da können Entities im Text
enthalten sein oder auch Tags. Was tun?
Ich denke, das das Problem es wert ist, dass man genauer darüber
nachdenkt und nicht irgendwelche Manualseiten mit den Stringfunktionen
zitiert.
Liebe Grüße aus http://www.braunschweig.de
Tom