@CB ? - Re: - get auf Umlaute geht generell nicht ??? - baseportal Forum - Web-Anwendungen einfach, schnell, leistungsfähig!
baseportal
English - Deutsch "Es gibt keine dummen Fragen - jeder hat einmal angefangen"

 baseportal-ForumDie aktuellsten 10, 30, 50, 100 Einträge anzeigen.  

 
 Ausgewählter Eintrag: Zur Liste 
    Beitrag von hempelr (1976 Beiträge) am Sonntag, 8.Februar.2004, 11:37.
    @CB ? - Re: - get auf Umlaute geht generell nicht ???

      mhm - diese Idee hatte ich auch schon, ist aber nicht realisierbar, weil die DB auch als csv-Datei bearbeitbar bleiben muss - wird ggf. vom Kunden/Nutzer per Link auf den Lokalen Rechner importiert und dann per Formular wieder eingelesen, entweder im append- oder im Überschreibmodus (das Rückschieben muss erst noch fertiggebaut werden...)
      Und da kann man von den Sachbearbeitern nicht verlangen, dass sie beachten, dass Umlaute als _e_Buchstabenduos geschrieben werden....

      Die Suche nach Umlauten mit Volltextsuche funzt, das ist nicht das Thema - das Thema ist Umlaute am Anfang (oder auch innerhalb) eines Skalars, der als Vergleichswert an das get übergeben wird. (oder do_all oder was auch immer als Baseportal-interne Filterfunktion)

      Das ist m.E. ein Gesamt-Design-Problem und macht perfekte Anwendungen im deutschen Sprachraum zumindest fraglich (gut, wen es nicht stört, dass bei ner Fach-Stichwortdatenbank mit 5.000 Stichwörtern 250 nicht angezeigt werden, weil sie Umlaute haben, der sieht das vielleicht anders...) - ich weiss, man könnte das mit einigen Zeilen Programmcode evtl. umgehen, aber da kann man dann nicht mehr auf solch schöne und sinnvolle Statusvariablen wie $_amount_query und $_range und $_range_length zugreifen.
      Bei ner Volltextsuche ist das kein Problem - da bietet man halt keinen Blätterlink an und gibt auch nicht die Anzanhl der tatsächlichen Treffer an - aber bei ner "richtigen" Datenfilterung ist das schon problematisch - man muss ja zwangsläufig einen Ausgabebereich festlegen, und ohne die vorgen. Variablen ist das eher nicht trivial umzusezten....

      Das was ich wissen möchte ist einfach nur, wie die Umlaute in baseportal-datenbanken abgespeichert werden, als HTML-Pendanten jedenfalls nicht....und da es bei der Volltextsuche funzt muss es doch auch beim get machbar gemacht werden können.....
      Die Volltextsuche sortiert es irgendwo "hinten" ein, aber das ist erst mal egal, hauptsache es wird überhaupt angezeigt - man könnte ja einfach eine if/elsif/else - Kette machen und dann die Umlaute zum Stammlaut mit filtern lassen, also in etwa so:
      ----schnipp
      if ($fbez eq "A"){
get "bezeichnung~=A bezeichnung~=aumlautcode","db";
} elsif ($fbez eq "O"){
get "bezeichnung~=O bezeichnung~=oumlautcode","db";
} elsif ($fbez eq ("U"){
get "bezeichnung~=U bezeichnung~=uumlautcode","db";
} else {
get "bezeichnung~=$fbez","db";
}
      ---schnapp

      Danke für zusätzliche Hinweise oder Denkanstöße....
      Ruben


    Ihre Antwort:

    Name: EMail: EMail bei Antwort? WWW:
    Titel:
    Text:

    Neuer Eintrag


 Alle Einträge zum Thema: Zur Liste 
    Beitrag von hempelr (1976 Beiträge) am Freitag, 6.Februar.2004, 12:21.
    Umlautproblem - hat jemand ne Idee? (Umlaute in Register)

      Hallo,
      bin auf ein blödes Ding gestossen - ist offensichtlich noch niemandem aufgefallen oder?
      Wenn man ein Register nutzt (Buchstabenindex - wird bp-intern mit dem Parameter indexfield=feldname erzeugt) werden alle Feldinhalte, die mit einem Umlaut beginnen nicht mit angezeigt ;-(((((

      Bei selbst gebautem Register (for (a...z)...) ist es genauso - sinnvoll wäre ja _ä_ bei _a_ abzudecken, _ö_ bei _o_ und _ü_ bei _u_, bloss hab ich wieder mal absolut keine Plan, wie das hinzukriegen wäre.

      meine get-Zeile sieht wie folgt aus:
      get "feld~=$fbez range=$ra,$ra_l", "$db_daten";
wobei $fbez entweder auf _*_ gesetzt ist oder aber als Parameter rein kommt (der Link zum Aufruf sieht für bspw. _a_ folgendermassen aus:
<a href=$_link&fbez=a>A</a>)

      Hat da jemand ne Idee, wie man das machen könnte, damit die Datensätze, die mit einem Umlaut dazu beginnen, mit abgedeckt werden?

      Danke für Tipp
      Ruben

     Antworten

    Beitrag von hempelr (1976 Beiträge) am Freitag, 6.Februar.2004, 13:05.
    !!!!!Ergänzung - get auf Umlaute geht generell nicht ???

      Hab grad mal versucht ein "hartes" 
      get "feld~=ä","db";
      zu machen, das wird komplett ignoriert - es wird kein Datensatz angezeigt ;-(((((((((((((((((

      Hat da jemand (CB?!) nen Workaround zu?

      Danke Ruben

     Antworten

    Beitrag von Christoph Bergmann (8110 Beiträge) am Freitag, 6.Februar.2004, 21:15.
    Re: !!!!!Ergänzung - get auf Umlaute geht generell nicht ??? 

      get "feld=&auml;", "db",

      müsste gehen...

     Antworten

    Beitrag von hempelr (1976 Beiträge) am Freitag, 6.Februar.2004, 22:56.
    Re: !!!!!Ergänzung - get auf Umlaute geht generell nicht ???

      nee - leider nicht , hab ich auch schon probiert, da filtert er überhaupt nich mehr und zeigt gleich mal alles an :-o
      Also ich hab alle mir bekannten Mitte getestet, es geht nix.
      Man müsste doch die Umlaute irgendwie zu fassen bekommen, als ASCII-Zeichen oder sowas - mhm, da ist dann wieder der Zeichensatz der Knackpunkt...ich werd noch wahnsinnig....brauche das aber auch ganz dringend für nen Kunden...

      Fällt dir nix dazu ein? - ich weiss, das ist nicht trivial - aber muss man doch irgendwie hinkriegen....

      Danke für Tipp
      Ruben

     Antworten

    Beitrag von Mattias (110 Beiträge) am Sonntag, 8.Februar.2004, 00:57.
    Re: !!!!!Ergänzung - get auf Umlaute geht generell nicht ???

      Bin auch schon öfters über das Problem gestolpert. Sobald ein Umlaut im Suchbegriff ist, geht gar nix mehr. Löse es mit Suchen und Ersetzen von Regulären Ausdrücken:

      $eingabe = "Ägäis";

      $eingabe =~ s/ä/ae/g;
      $eingabe =~ s/Ä/Ae/g; usw. auch für die anderen Umlaute...

      [Feldinhalt = "Aegaeis"]

      get "feld~=$fbez range=$ra,$ra_l", "$db_daten";

      $fbez =~ s/Ae/&Auml;/g;

      [Ausgabe = "Ägäis"]

     Antworten

    Beitrag von Sander (8133 Beiträge) am Sonntag, 8.Februar.2004, 01:14.
    Re: !!!!!Ergänzung - get auf Umlaute geht generell nicht ???

      is bloß blöd, wenn einer nach goethe sucht ;-)

     Antworten

    Beitrag von Mattias (110 Beiträge) am Sonntag, 8.Februar.2004, 04:19.
    Re: !!!!!Ergänzung - get auf Umlaute geht generell nicht ???

      Der ist doch selber schuld, mit so einem Namen! ;-)

      Nuja, für den internen Gebrauch könnte man auch sowas wie

      G_oe_teborg

      $text =~ s/_oe_/&ouml;/g;

      basteln, das würde im Prinzip auch für das ß taugen. Muss man halt den Suchbegriff auch entsprechend zurechtstutzen:

      $eingabe =~ s/ö/_oe_/g;
$eingabe =~ s/&ouml;/_oe_/g;

      ... oder einfach nen Alert ausgeben: "Bitte keine Umlaute verwenden!"

     Antworten

    Beitrag von Friesecke (245 Beiträge) am Sonntag, 8.Februar.2004, 06:17.
    Re: !!!!!Ergänzung - get auf Umlaute geht generell nicht ???

      Hallo Sander,

      es geht hier um Umlaute.
      Das Prob tritt also nicht bei goethe auf, höchstens bei blöd.
      Gruß an den perl-prof : es geht hier um Datenbankprogrammierung. Da löst man das über den Index ähnlich wie Mattias das geschrieben hat.

     Antworten

    Beitrag von hempelr (1976 Beiträge) am Sonntag, 8.Februar.2004, 11:37.
    @CB ? - Re: - get auf Umlaute geht generell nicht ???

      mhm - diese Idee hatte ich auch schon, ist aber nicht realisierbar, weil die DB auch als csv-Datei bearbeitbar bleiben muss - wird ggf. vom Kunden/Nutzer per Link auf den Lokalen Rechner importiert und dann per Formular wieder eingelesen, entweder im append- oder im Überschreibmodus (das Rückschieben muss erst noch fertiggebaut werden...)
      Und da kann man von den Sachbearbeitern nicht verlangen, dass sie beachten, dass Umlaute als _e_Buchstabenduos geschrieben werden....

      Die Suche nach Umlauten mit Volltextsuche funzt, das ist nicht das Thema - das Thema ist Umlaute am Anfang (oder auch innerhalb) eines Skalars, der als Vergleichswert an das get übergeben wird. (oder do_all oder was auch immer als Baseportal-interne Filterfunktion)

      Das ist m.E. ein Gesamt-Design-Problem und macht perfekte Anwendungen im deutschen Sprachraum zumindest fraglich (gut, wen es nicht stört, dass bei ner Fach-Stichwortdatenbank mit 5.000 Stichwörtern 250 nicht angezeigt werden, weil sie Umlaute haben, der sieht das vielleicht anders...) - ich weiss, man könnte das mit einigen Zeilen Programmcode evtl. umgehen, aber da kann man dann nicht mehr auf solch schöne und sinnvolle Statusvariablen wie $_amount_query und $_range und $_range_length zugreifen.
      Bei ner Volltextsuche ist das kein Problem - da bietet man halt keinen Blätterlink an und gibt auch nicht die Anzanhl der tatsächlichen Treffer an - aber bei ner "richtigen" Datenfilterung ist das schon problematisch - man muss ja zwangsläufig einen Ausgabebereich festlegen, und ohne die vorgen. Variablen ist das eher nicht trivial umzusezten....

      Das was ich wissen möchte ist einfach nur, wie die Umlaute in baseportal-datenbanken abgespeichert werden, als HTML-Pendanten jedenfalls nicht....und da es bei der Volltextsuche funzt muss es doch auch beim get machbar gemacht werden können.....
      Die Volltextsuche sortiert es irgendwo "hinten" ein, aber das ist erst mal egal, hauptsache es wird überhaupt angezeigt - man könnte ja einfach eine if/elsif/else - Kette machen und dann die Umlaute zum Stammlaut mit filtern lassen, also in etwa so:
      ----schnipp
      if ($fbez eq "A"){
get "bezeichnung~=A bezeichnung~=aumlautcode","db";
} elsif ($fbez eq "O"){
get "bezeichnung~=O bezeichnung~=oumlautcode","db";
} elsif ($fbez eq ("U"){
get "bezeichnung~=U bezeichnung~=uumlautcode","db";
} else {
get "bezeichnung~=$fbez","db";
}
      ---schnapp

      Danke für zusätzliche Hinweise oder Denkanstöße....
      Ruben

     Antworten

    Beitrag von hempelr (1976 Beiträge) am Sonntag, 8.Februar.2004, 12:25.
    sorry - es geht - war get auf Umlaute geht generell nicht ???

      sorry - ich hatte wahrscheinlich weiter nix als einen logischen Denkfehler gemacht...
      get "feld~=Ä" bringt erwartungsgemäss alle Werte, die mit _Ä_ beginnen
get "feld~=Ä feld~=A" kann natürlich n i c h t alle Werte die mit Ä und mit A beginnen bringen, da hier wieder mal die Umgangssprache und die Computerlogik querlaufen -
      es muss heissen
      get "feld~=Ä or feld~=A" denn es sollen ja auch die Werte die mit _A_ oder mit _Ä_ beginnen angezeigt werden.

      *Mitderstirnaufschlagundalleszurücknehmunddasgegenteilbeaupt*

      Ruben

     Antworten


     
 Liste der Einträge von 32101 bis 32251:Einklappen Zur Eingabe 
Neueste Einträge << 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | Neuere Einträge < Zur Eingabe  > Ältere Einträge | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 >> Älteste Einträge

Zurück zur Homepage

© baseportal.de. Alle Rechte vorbehalten. Nutzungsbedingungen



powered in 0.06s by baseportal.de
Erstellen Sie Ihre eigene Web-Datenbank - kostenlos!