30. april 2001 - 23:41Der er
20 kommentarer og 1 løsning
Problemer med tegnet \" i form-felter på preview
Hejsa, Jeg har tidligere spurgt hvordan man skulle lave en preview-side til mit debatforum. Problemet er at man normalt bruger \" i textarea. hvis teksten indsættesi et skjult input-felt er jeg nødt til at skrive <input type=\'hidden\' name=\'btext\' value=\'<% = Btext %>\'>
Jeg kan ikke bruge tegnet \", da den vil tro at sætningen vil stoppe ved et \". D.v.s. man gå glip af resten af sætningen hvis man f.eks. skriver:
I debatforumet \"politik\", vil politik ikke konmme med. Jeg har som sagt løst det med tegnet \', men så må man jo ikke bruge dette tegn i sine sætninger, for så gør den bare det samme. At den tror at teksten slutter der. Det tegn bruger man normalt heller ikke så tit. Bruger man hverken \" eller \' til at omslutte value i indput-felter vises teksten udenfor.
Er der nogen anden løsning, så jeg hverken behøver at \"reservere\" tegnet \" eller \' ?
laver man \" om til 4 tegn kan det jo give problemer med for lange tekster i forhold til felterne i databasen. Jeg syntes bedst om at lave det om til et andet tegn. F.eks. ¤ ´ eller andre \"ubrugte\" tegn. Når det så skal vises skiftes dette tegn tilbage til \"-tegnet.
Nej, stigc. Det giver INGEN problemer. Når du får teksten på serveren på den næste side, er det en smuk og fuldgyldig \" du får fat. Det er kun en kodning for at vise den på HTML-siden (omend i et skjult felt her). Dem, der har lavet HTML har rent faktisk tænkt sig om - i øvrigt er det 5 tegn :)
det er foresten også nærmere i SQL delen af ASP siden jeg bruger dette trick. Her går det jo ikke med en SQL sætning med \"-tegn i. Du har måske også et trick imod det?
det smarteste er jo uten tvil å HTMLEncode *før* du legger noe innhold i databasen. Dermed så slipper du for å utføre mer eller mindre merkelige operasjoner ved utlisting.
Det synes jeg ikke nute. Jeg mener man skal gemme det oprindelige format i databasen, 1) det fylder mindst 2) Man kan lave andre konverteringer senere.
1) er nok ikke så vigtig, men har du et felt med char(20) kan der kun være ganske få tegn, hvis de bliver konverteret, og du risikerer at skære en af, så der kun står &quo - f.eks.
2) Det kan være du senere skal vise indholdet af databasen i et andet format, og så er det lidt træls at skulle konvertere tilbage.
Men, ok, det er lidt ekstra arbejde på serversiden.
Man kan selvfølgelig benytte dette med litt fornuft. Når man oppretter et formular, så vet man som regel hvilke verdier man skal ha i feltene, og utfra det kan man velge om man skal legge HTMLEncodet innhold eller ikke i de tilhørende kolonner.
Med hensyn til: 1) Du har fullstendig korrekt, men dette kan jo f.eks løses ved å begrense mulighetene for inntasting, fra brukeren sin side, til å ta høyde for ". Dette kan selvfølgelig i visse sammenhenger bety at man forkorter et felt med 10 tegn, hvilket er mye, men det er en mulighet.
2) Multipurpose databasemodellering skaper alltid mye debatt, og det blir alltid en spennende debatt. Det ultimate er selvfølgelig å lagre fulltekst i sine databaser sånn at evt. konvertering på et senere tidspunkt ikke er nødvendig.
Jeg er enig med deg e.j, men ville bare komme med noen (mer eller mindre gode) løsninger :)
det var godt...takk ;) men uten morgenkaffe blir den som regel mer sjov, for da opplever mange (iallefall jeg) at man ikke husker noe av det man kan :)
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
