[Løst] Nedbrud ved æøå i beskrivelse eller kladenavn

Her kan du rapportere de fejl, som du finder ved brug af Saldi.

Redaktører: Agerskov, Peter Rude, Sarah Aagaard

Besvar
nielsrune
Indlæg: 63
Tilmeldt: tors maj 14, 2009 7:04 pm
Kontakt:

[Løst] Nedbrud ved æøå i beskrivelse eller kladenavn

Indlæg af nielsrune »

Jeg er for nylig begyndt at opleve en fejl, hvor Saldi går ned ved indtastning eller opdatering af kassekladden.

I min .ht_modify.log kommer denne fejl:

Kode: Vælg alt

insert into tmpkassekl (lobenr,id,bilag,transdate,beskrivelse,d_type,debet,k_type,kredit,faktura,amount,momsfri,afd,kladde_id,projekt,ansat,valuta,forfaldsdate,betal_id) values ('6', '147', '76', '30-12-2013', 'Hensættelse', 'F', '100', 'F', '300', '', '1.000,00', '', '', '36', '', '', '','','');
-- nrb 2014-01-04 17:26:52: /home/saldi/saldi-3.3.3/finans/kassekladde.php linje 566
-- Fejl!! insert into tmpkassekl (lobenr,id,bilag,transdate,beskrivelse,d_type,debet,k_type,kredit,faktura,amount,momsfri,afd,kladde_id,projekt,ansat,valuta,forfaldsdate,betal_id) values ('6', '147', '76', '30-12-2013', 'Hensættelse', 'F', '100', 'F', '300', '', '1.000,00', '', '', '36', '', '', '','','') | ERROR:  invalid byte sequence for encoding "UTF8": 0xe67474;
Min Apache-log giver denne:

Kode: Vælg alt

[Sat Jan 04 17:26:52 2014] [error] [client 192.168.1.52] PHP Warning:  pg_query(): Query failed: ERROR:  invalid byte sequence for encoding "UTF8": 0xe67474 in /home/saldi/saldi-3.3.3/includes/db_query.php on line 129, referer: https://maria/finans/kassekladde.php?kksort=bilag,transdate

Saldi går ned med den almindelige fejlboks, "Uforudset hændelse...", og kladdelinjen bliver ikke gemt ordentligt. Logger jeg ind igen er den ikke at finde i kladden før jeg trykker gem, hvor den så kommer til syne.

Jeg har lokaliseret fejlen til at relatere sig til brug af æøå tegnene enten i feltet beskrivelse eller i titlen på kassekladden. Bruger jeg i steder for et æ tegnene ae er der ingen fejl, og Saldi virker normalt.

Jeg gætter på fejlen skyldes en opdateret af postgres eller lignende, og jeg er ikke helt klar over, hvor felterne beskrivelse og kladdetitel mon skal encodes i koden.

Er det noget der kan fejlsøges i teamet?

Mit system:
Debian 7.3
PostgreSQL 9.1.11
Apache 2.2.22
Senest rettet af nielsrune søn jan 05, 2014 3:15 pm, rettet i alt 1 gang.
nielsrune
Indlæg: 63
Tilmeldt: tors maj 14, 2009 7:04 pm
Kontakt:

Indlæg af nielsrune »

Efter at have forsøgt en hel del encoding tests, ser det ud til at fejlen opstod på grund af det "f", der tidligere blev sendt ved en fejl i toppen af kassekladde.php:

Kode: Vælg alt

f</script>
<!--
unction goodbye(e) {
Det er rettet i filen, der ligger i "seneste" på saldis server, men er fortsat ikke rettet på trac, som er den kilde jeg primært følger med i. Simpelt hen af den grund, at det er nødvendigt at kunne se, hvad der bliver og er blevet rettet fra gang til gang, når der skal findes fejl.

Jeg har rettet min lokale fil i overensstemmelse med serverversionen, og nu virker æøå tilsyneladende fint igen både i en kladdelinje og kladdens titel.

Så over and out for denne gang.
Henrik
Indlæg: 4
Tilmeldt: lør jan 04, 2014 11:26 pm

Trac er ikke blevet benyttet i over tre måneder

Indlæg af Henrik »

Godt fundet Niels
nielsrune skrev:Det er rettet i filen, der ligger i "seneste" på saldis server, men er fortsat ikke rettet på trac, som er den kilde jeg primært følger med i.
Så vidt jeg kan se, så er Trac ikke blevet opdateret flere måneder. Hvis du kigger på Timeline, kan du se, at der ikke er nogen ændringer de seneste 90 dage, som man højst kan se tilbage medmindre, man ændre datoen, hvor man ser tilbage fra.

Jeg tror det skyldes, at der arbejdes på at skifte til andet system til håndtering af Saldi. Mener at jeg har hørt om Github på et tidspunkt, men den ser heller ikke ud til at være aktiv endnu selvom der har været noget aktivitet på den i sommers.

https://github.com/DANOSOFT/saldi
Mvh. Henrik Bak
nielsrune
Indlæg: 63
Tilmeldt: tors maj 14, 2009 7:04 pm
Kontakt:

Indlæg af nielsrune »

Kære Henrik

Tak for sit svar. Jeg er helt klar over, at trac ikke opdateres konsekvent, når der sker ændringer i /seneste, men synes at "blive samlet op" i ny og næ.

Det skal retfærdig vis lyde, at der i de år, jeg har fulgt projektet, fra udviklernes side altid er blevet henvist til /seneste som kilde, og trac bærer da også præg af ikke at blive brugt til særlig meget. (Mener Peter Rude selv har nævnt dette på et tidspunkt).

Når det så er sagt, så er det, som jeg skrev, primært trac jeg følger med i inden jeg foretager opdateringer i min installation, simpelthen for at kunne gennemse i gennemføre rettelser. Jeg henter dog altid fra /seneste og sammenligner de mest kritiske filer med meld.

Har der ikke været opdateringer på trac i længere tid, kan det dog være nødvendigt at kigge i /seneste, hvilket blandt andet fik mig på dette spor i denne tråd.

Men det er for mig nødvendigt, at der er mulighed for at gennemse ændringer i koden, samt tidligere ændringer, da det letter fejlretning med faktor [mange], hvilket også har været påpeget fra flere andre gennem det seneste år her på forummet

Hvis du ser på trac, er fejlen beskrevet i denne tråd gammel. Den var stadig at finde ved rev611.
Den blev så rettet ved rev613, hvilket også fremgår af "changeloggen" under licensen øverst i filen.
Ved rev617 bliver fejlen imidlertid genindsat i koden. Jeg gætter på, det skyldes, at der er arbejdet ud fra en gammel version og så pushed til serveren som ny version.
Her leve fejlen så i yderligere et lille år, førend den på ny blive rettet 16. december 2013, som det fremgår af den version, der ligger på /seneste.

Forløbet illustrerer ganske godt behovet for at anvende et versioneringssystem både internt og ekstern, så vi andre har mulighed for at hjælpe med fejlsøgning og fejlretning.

At fejlen ikke har voldt mig problemer tidligere undrer mig, men tilskriver dette en mulig ændring af enten database- eller browsersoftwaren til mere striks unicode håndtering.

Fejlen fandt jeg ved at indsætte en slags breakpoint i koden umiddelbart før databaseopdateringen, der genererende fejlen, og her aflæse dels tekststrengens tegnkodning såvel som selve sidens tegnkodning i browseren.

Strengen blev både med og uden danske tegn kodet som utf-8, men browseren tolkede siden forskelligt, alt efter om der var danske tegn i strengen eller ej. Ingen æøå = utf-8; Streng med æøå = windows-1251.

Og som allerede beskrevet blev det løst ved at fjerne det "f", der blev sendt ud øverst i filen.

Med venlig hilsen
/Niels Rune Brandt
Besvar