DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Het probleem is al opgelost. Ik heb de database geleegd en de auto_increment teller gereset. Toen heb ik alles opnieuw naar de database weg laten schrijven en met Chrome ingelogd op MyPhpAdmin. Met Firefox liep de boel dus vast en gaf 'ie een foutmelding dat ik aan de sizelimit zat.quote:Op zaterdag 3 november 2012 16:10 schreef StM het volgende:
Wat werkt er niet meer (krijg je een error?) en welke database gebruik je?
Wat is de juiste manier om URL's met CodeIgniter te rewriten in htaccess, zonder dat het pad naar m'n CSS-file wordt gerewrite waardoor m'n CSS-file niet correct geladen wordt?
Je kan css bestanden excluden van de mod_rewrite
It was an opportunity to honour our memories and to make room for new ones
Iemand een idee hoe je dit kunt debuggen? Als er nou een query bij zou staan zou het makkelijk zijn. Ik zie ook niks terug in de slow query log.
Ik gebruik ook nooit persistente connecties ofzo.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
De gebruikersnaam 'apache' vind ik raar, gebruik je sql logging voor Apache?
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Oh die gebruiker had ik schijnbaar ook voor mijn applicatie (best slecht). 
Maarja, met een andere user het zelfde probleem, de apache user doet nu niks meer.
Misschien zit er ook wel gewoon iets fout in mijn mysql/apache/php/apc configuratie, maarja, hoe vind je uit wat de oorzaak en wat het gevolg is.
[ Bericht 17% gewijzigd door mstx op 05-11-2012 12:41:14 ]
Maarja, met een andere user het zelfde probleem, de apache user doet nu niks meer.
Misschien zit er ook wel gewoon iets fout in mijn mysql/apache/php/apc configuratie, maarja, hoe vind je uit wat de oorzaak en wat het gevolg is.
[ Bericht 17% gewijzigd door mstx op 05-11-2012 12:41:14 ]
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Ik zou toch eens zoeken naar persistent connections. Juist als je die maar op een enkele pagina gebruikt, heb je grote idle times bij je connections zoals je nu ziet.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
"Sleep" betekent dat de connectie idle is... gewoon een connectie die open blijft staan nadat de query is afgehandeld. Dat hoeft dus helemaal geen probleem te zijn, tenzij de connecties niet goed hergebruikt worden en je op den duur tegen de max_connections limiet aanloopt.
Mja het rare is dus dat er op de hele server geen persistent connection wordt gemaakt (tenzij mysqli dit zelf doet zonder dat ik het aangeef). Ik doe zelfs aan het eind van het script voor de zekerheid nog een close().
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Dat blijkt nu het geval te zijn: Warning: mysqli::mysqli(): (08004/1040): Too many connectionsquote:
tenzij de connecties niet goed hergebruikt worden en je op den duur tegen de max_connections limiet aanloopt.
Alles in de process list zit nu te slapen.
Apache doet nu ook niet veel meer, de meeste connecties blijven op "sending reply" staan
Restart Time: Monday, 05-Nov-2012 13:07:20 CET
Parent Server Generation: 0
Server uptime: 18 minutes 32 seconds
Total accesses: 7409 - Total Traffic: 8.8 MB
CPU Usage: u1070.9 s58.36 cu0 cs0 - 102% CPU load
6.66 requests/sec - 8.1 kB/second - 1247 B/request
188 requests currently being processed, 18 idle workers
WRKCWWWWRWWWWWW.WWWWWWW.WRWWWWCWWW_WW._.K_W.WWW.WRW.WWWW.W_WWWKW
_WWWWWK.WWWWWWWR._WK..WWWWWW.WWWWWW.WWWWWWW_WWWW..WKWWWCWW.W..WK
WWW.WWWWWW..WWWWW._WWWWWW.W.W_WWK.WWKRWWRWWW.WWWWWW.WW.WWW__WWWW
WW.WWW_W..WWW._.WWWWWWWWWK__WW..WW.W._WW.W.KW_.WW.W.WW_W.W......
[ Bericht 19% gewijzigd door mstx op 05-11-2012 13:27:06 ]
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Probeer eens mysql.allow_persistent=Off en mysqli.allow_persistent=Off
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Heb het erin gezet (en mysql opnieuw gestart), maakt geen verschil. Ik krijg na 2 minuten alweer "too many connections".quote:Op maandag 5 november 2012 13:26 schreef GlowMouse het volgende:
Probeer eens mysql.allow_persistent=Off en mysqli.allow_persistent=Off
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Kijk dan eens in apache's server-status of er clients verbonden blijven.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ja bijna allemaalquote:
Kijk dan eens in apache's server-status of er clients verbonden blijven.
Restart Time: Monday, 05-Nov-2012 13:07:20 CET
Parent Server Generation: 0
Server uptime: 30 minutes 42 seconds
Total accesses: 10271 - Total Traffic: 12.9 MB
CPU Usage: u1568.03 s77.94 cu0 cs0 - 89.4% CPU load
5.58 requests/sec - 7.2 kB/second - 1314 B/request
250 requests currently being processed, 0 idle workers
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWKWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWCWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW......
Na het restarten zie je alles langzaam in een W'tje veranderen totdat de max_connections van mysql bereikt is.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Dat is dan een groot probleem want elke W kost veel geheugen van Apache ook nog eens. Je kunt met extended server status nog preciezer zien wat elke W betekent.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik heb het nu zo:quote:
Wat is de juiste manier om URL's met CodeIgniter te rewriten in htaccess, zonder dat het pad naar m'n CSS-file wordt gerewrite waardoor m'n CSS-file niet correct geladen wordt?
<link rel="stylesheet" href="<?php echo base_url() ?>css/stylesheet.css" />
M'n htaccess file rewrite alles met index.php en zet m'n rootmap als base.
Precies wat ik wilde.
Nou ik ben er 5 uur mee bezig geweest, maar eindelijk gevonden waar die sleeping processes vandaan kwamen. 
Het bleek te komen door de manier waarop ik user variables opsloeg in APC. Ik heb bijvoorbeeld nieuwsberichten of forum topics die ik met apc_store() opsloeg om te cachen. Eerst deed ik dit allemaal in één grote array met alle items erin (dus $forum=array(1=>'bericht1', 2=>'bericht 2'), $nieuws=array() etc). Nu heb ik ze allemaal hun eigen variabele gegeven. Nu is mijn script ineens 100x zo snel.
Nu ze allemaal apart staan hoeven ze niet meer op elkaar te wachten als 5 mensen tegenlijk 5 verschillende nieuwsberichten lezen en deze tegelijkertijd gecached worden, dan kan het script meteen verder en de mysql connectie sluiten... best stomme fout als je er zo achteraf over nadenkt.
Het bleek te komen door de manier waarop ik user variables opsloeg in APC. Ik heb bijvoorbeeld nieuwsberichten of forum topics die ik met apc_store() opsloeg om te cachen. Eerst deed ik dit allemaal in één grote array met alle items erin (dus $forum=array(1=>'bericht1', 2=>'bericht 2'), $nieuws=array() etc). Nu heb ik ze allemaal hun eigen variabele gegeven. Nu is mijn script ineens 100x zo snel.
Nu ze allemaal apart staan hoeven ze niet meer op elkaar te wachten als 5 mensen tegenlijk 5 verschillende nieuwsberichten lezen en deze tegelijkertijd gecached worden, dan kan het script meteen verder en de mysql connectie sluiten... best stomme fout als je er zo achteraf over nadenkt.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Pagina's deden er dus daadwerkelijk een halve minuut over om te laden, dat zou je sowieso snel door moeten hebben.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik had het al maanden zo draaien, kun je nagaan.quote:
Pagina's deden er dus daadwerkelijk een halve minuut over om te laden, dat zou je sowieso snel door moeten hebben.
* mstx gaat zich diep schamen
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Zulke dingen kun je via een trace wel snel vinden waarschijnlijk. Htop en s/L zijn je vriend.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
ik weet dat ik hier fout zit maar zou iemand me aub kunnen zeggen hoe ik het volgende bestandje moet downloaden...na de 5sec blijf ik maar wachten
http://www.multiupload.nl/AKATNDA2Q0
http://www.multiupload.nl/AKATNDA2Q0
Chuck Norris threw a grenade & killed 10 people. Then the grenade exploded.
quote:Dit bestand bestaat niet, de toegang tot het volgende bestand is beperkt of het bestand is verwijderd wegens overtreding van het auteursrecht.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Nice dat het gefixt is!quote:Op maandag 5 november 2012 21:56 schreef mstx het volgende:
Nou ik ben er 5 uur mee bezig geweest, maar eindelijk gevonden waar die sleeping processes vandaan kwamen.
Het bleek te komen door de manier waarop ik user variables opsloeg in APC. Ik heb bijvoorbeeld nieuwsberichten of forum topics die ik met apc_store() opsloeg om te cachen. Eerst deed ik dit allemaal in één grote array met alle items erin (dus $forum=array(1=>'bericht1', 2=>'bericht 2'), $nieuws=array() etc). Nu heb ik ze allemaal hun eigen variabele gegeven. Nu is mijn script ineens 100x zo snel.
Nu ze allemaal apart staan hoeven ze niet meer op elkaar te wachten als 5 mensen tegenlijk 5 verschillende nieuwsberichten lezen en deze tegelijkertijd gecached worden, dan kan het script meteen verder en de mysql connectie sluiten... best stomme fout als je er zo achteraf over nadenkt.
quote:Op maandag 5 november 2012 22:13 schreef mstx het volgende:
[..]
Ik had het al maanden zo draaien, kun je nagaan.
* mstx gaat zich diep schamen
Heb je in de afgelopen maanden zo veel meer gebruikers gekregen dat het nu steeds erger werd?
gr gr
Hier meer mensen met een GitHub account en zo ja, kunnen jullie inloggen?
Ik heb me net aangemeld maar als ik in wil loggen blijft de site op de inlog pagina hangen of word ik terug gestuurd naar de homepage zonder ingelogd te zijn. Gebruikersnaam en wachtwoord pakt hij wel want ik krijg geen melding dat ik een fout heb gemaakt bij het intypen. Dus doe ik iets verkeerd of gaat er iets fout aan de kant van GitHub?
Ik heb me net aangemeld maar als ik in wil loggen blijft de site op de inlog pagina hangen of word ik terug gestuurd naar de homepage zonder ingelogd te zijn. Gebruikersnaam en wachtwoord pakt hij wel want ik krijg geen melding dat ik een fout heb gemaakt bij het intypen. Dus doe ik iets verkeerd of gaat er iets fout aan de kant van GitHub?
Whether or not you can become great at something, you can always become better.
And one day you'll wake up and find out how good you actually became, having transcended whatever limits you might have thought you couldn't pass.
Neil Degrasse Tyson
And one day you'll wake up and find out how good you actually became, having transcended whatever limits you might have thought you couldn't pass.
Neil Degrasse Tyson
Ik kan gewoon inloggen.quote:
Hier meer mensen met een GitHub account en zo ja, kunnen jullie inloggen?
Ik heb me net aangemeld maar als ik in wil loggen blijft de site op de inlog pagina hangen of word ik terug gestuurd naar de homepage zonder ingelogd te zijn. Gebruikersnaam en wachtwoord pakt hij wel want ik krijg geen melding dat ik een fout heb gemaakt bij het intypen. Dus doe ik iets verkeerd of gaat er iets fout aan de kant van GitHub?
Ik heb nogal een lastig probleem. Ik weet niet wat de handigste manier is om letters met een accent in m'n database op te slaan, met betrekking op het volgende:
Momenteel is de í (i met accent acute) in de database opgeslagen als een Ã. Nu wil ik graag kunnen zoeken naar een woord met een í, zonder dat ik het accent erbij hoef te typen. Ik wil dus de í kunnen vinden door gewoon een i te typen.
Momenteel is de í (i met accent acute) in de database opgeslagen als een Ã. Nu wil ik graag kunnen zoeken naar een woord met een í, zonder dat ik het accent erbij hoef te typen. Ik wil dus de í kunnen vinden door gewoon een i te typen.
Altijd voor UTF-8 kiezen, je kunt altijd een andere charset kiezen als je op zo'n rare i wilt zoeken.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Je bedoelt UTF-8 in m'n database toch? Ik gebruik nu latin1_swedish_ci:quote:
Altijd voor UTF-8 kiezen, je kunt altijd een andere charset kiezen als je op zo'n rare i wilt zoeken.
Moet ik alles weer opnieuw in de database invoeren of veranderd 'ie alles "on-the-fly"?
Ik heb het nu dus zo: , maar de í staat nog steeds als à in de database.quote:
[..]
Je bedoelt UTF-8 in m'n database toch? Ik gebruik nu latin1_swedish_ci: [ afbeelding ]
Moet ik alles weer opnieuw in de database invoeren of veranderd 'ie alles "on-the-fly"?
Dat vermoedde ik al, ik zal het dus opnieuw moeten invoeren. Moet ik nog iets als utf8_encode() gebruiken bij het invoeren?quote:
Omdat het nu corrupt in je database is opgeslagen
Bedoel je zo?quote:
Je kan beter je hele app van UTF-8 gebruik laten maken. Juiste headers sturen etc.
Ik persoonlijk geef de voorkeur aan
omdat dat soort meta tags als je ze verkeerd (te laat) gebruikt vooral bij oudere IE versies kan zorgen dat hij de pagina 2x moet parsen.
*edit*
Hier trouwens een handige checklist: http://blog.loftdigital.com/blog/php-utf-8-cheatsheet
edit2:
en vergeet
niet, via de adapter die jij gebruikt (Wss MySQLi of PDO)
| 1 2 3 | <?php header("Content-type: text/html; charset=utf-8"); ?> |
*edit*
Hier trouwens een handige checklist: http://blog.loftdigital.com/blog/php-utf-8-cheatsheet
edit2:
en vergeet
| 1 2 3 | <?php mysql_query("SET NAMES 'utf8'") ?> |
(Wss MySQLi of PDO)
Waar plaats ik die regel dan? Gewoon bovenaan m'n php script? Ik ben echt nog een newbie.quote:
Ik persoonlijk geef de voorkeur aan
[ code verwijderd ]
omdat dat soort meta tags als je ze verkeerd (te laat) gebruikt vooral bij oudere IE versies kan zorgen dat hij de pagina 2x moet parsen.
*edit*
Hier trouwens een handige checklist: http://blog.loftdigital.com/blog/php-utf-8-cheatsheet
edit2:
en vergeet
[ code verwijderd ]
niet, via de adapter die jij gebruikt
Gewoon bovenaan m'n header.php die elke pagina wordt geladen?quote:
Headers moet je versturen voor de eerste output. Dus ergens bovenaan of op een centrale plek.
Bv ja, hoewel je voor 1 regel code niet een aparte file hoeft aan te maken Wel kan je iets van een common.php aan maken die je altijd laad waar je dit maar ook andere defaults regelt.
Wel kan je iets van een common.php aan maken die je altijd laad waar je dit maar ook andere defaults regelt.
Ja, dat is dus header.php bij mij.quote:
Bv ja, hoewel je voor 1 regel code niet een aparte file hoeft aan te maken
Hoe krijg ik nu bijvoorbeeld het woord "scène" op de goede manier in m'n database? Ik gebruik een PHP script om alles weg te schrijven.
Codering in m'n editor nu:quote:
Die file ook als UTF-8 opslaan, vaak is dit een optie van je editor.
PHP-script dat de invoer regelt:
Output in m'n browser.
Wat er daadwerkelijk in de database wordt ingevoerd:
De output in m'n browser is dus hoe ik het in m'n database ingevoerd wil hebben.
Waar doe ik dat?quote:
Heb je wel je verbinding op UTF-8 gezet zoals ik had gezegd?
Zo?quote:
Als eerste query SET NAMES 'utf8' uitvoeren
Is dat collatie? Ja, die staat op UTF-8.quote:
Check je het via PHPMyAdmin? Staat de karakterset wel goed? (Dus op UTF-8)
Het gekke is, dat als ik de naam via SQL invoer het wel goed gaat:
UPDATE `table` SET `name`='García Fernández' WHERE `id`=1
Denk dus toch dat er iets fout gaat in het script zelf.
UPDATE `table` SET `name`='García Fernández' WHERE `id`=1
Denk dus toch dat er iets fout gaat in het script zelf.
Dan vermoed ik toch dat de waarden in je file niet echt UTF-8 is. Gooi er eens utf8_encode omheen.
Ik weet wel uit ervaring dat dit soort issues een ramp zijn om te debuggen
Ik weet wel uit ervaring dat dit soort issues een ramp zijn om te debuggen
Metquote:
Dan vermoed ik toch dat de waarden in je file niet echt UTF-8 is. Gooi er eens utf8_encode omheen.
Ik weet wel uit ervaring dat dit soort issues een ramp zijn om te debuggen
| 1 2 3 | <?php mysql_query(utf8_encode("UPDATE `table` SET `name`='García Fernández' WHERE `id`=1")); ?> |
krijg ik dit:
Welke browser heb je? Klik namelijk eens in phpmyadmin rechts en dan naar de pagina eigenschappen wat de karakter set is.
Yes! Gelukt.quote:
Welke browser heb je? Klik namelijk eens in phpmyadmin rechts en dan naar de pagina eigenschappen wat de karakter set is.
Thanks man! . 
Ik moest de query zonder utf8_encode versturen en
| 1 2 3 | <?php mysql_query("SET NAMES 'utf8'"); ?> |
Precies wat je zei dus, maar ik snap niet waarom het nu wel lukt. Nja, nogmaals bedankt.
Weet ik dus ook niet, misschien niet refresht in m'n browser toen ik het script ging uitvoeren.quote:
Hmm waarom werkte het net niet dan?
Nu zit ik nog wel steeds met deze vraag:
Morgen weer een dag. Ik ga slapen nu. 
...maar goed, dat komt morgen wel, ik ben al lang blij dat je m'n probleem met de database hebt opgelost.quote:
Ik heb nogal een lastig probleem. Ik weet niet wat de handigste manier is om letters met een accent in m'n database op te slaan, met betrekking op het volgende:
Momenteel is de í (i met accent acute) in de database opgeslagen als een Ã. Nu wil ik graag kunnen zoeken naar een woord met een í, zonder dat ik het accent erbij hoef te typen. Ik wil dus de í kunnen vinden door gewoon een i te typen.
Morgen weer een dag. Ik ga slapen nu.
Met je collate bepaal je op welke manier hij gaat zoeken. Maar dat is iets te complex om 123 in een post uit te leggen dus ga morgen daar maar eens de manual over lezen Voor wat jij wil is volgens mij een collate die dat kan, maar ik weet niet zo welke dat is.
Voor wat jij wil is volgens mij een collate die dat kan, maar ik weet niet zo welke dat is.
Het is sowieso handig dat ik dat even ga lezen ja. Ik ben echt de basis van het programmeren aan het leren en het lijkt me wel handig om dit soort dingetjes te snappen. Ben in ieder geval al een heel eind dankzij hulp van mensen hier.quote:
Met je collate bepaal je op welke manier hij gaat zoeken. Maar dat is iets te complex om 123 in een post uit te leggen dus ga morgen daar maar eens de manual over lezen
Hehe, al die encoding shit is een van de meest complexe dingen die er zijn. Omdat het er zoveel zijn, en omdat conversie van de ene naar de andere erg lastig kan zijn. De belangrijkste tip die ik je kan geven: gebruik *vanaf het begin*, overal, de zelfde encoding, en gebruik geen latin1 maar utf8. De default collation van mysql is nog steeds latin1 en dat zuigt. De wereld is groter dan West-Europa. In utf8 wordt een letter met accent opgeslagen als een letterbyte + een accentbyte dus dat maakt zaken ook makkelijker.
Goeiedag heren,
Even een klein vraagje met betrekking tot maps/kaarten. Op dit moment heb ik coördinaten en een afstand die moet worden afgelegd tussen 2 coördinaten. Nu moet ik op de één of andere manier zien te berekenen hoe laat een bepaalde bus waar rijdt. Van alle lijnen heb ik een route in polylinevorm met coördinaten beschikbaar. Nu moet ik op de één of andere manier zien te berekenen waar een lijn/bus zich op dat moment bevindt aan de hand van haltetijden.
Iemand die mij hier een tip/tik/schopje over mee kan geven van hoe zoiets het beste te realiseren is?
Even een klein vraagje met betrekking tot maps/kaarten. Op dit moment heb ik coördinaten en een afstand die moet worden afgelegd tussen 2 coördinaten. Nu moet ik op de één of andere manier zien te berekenen hoe laat een bepaalde bus waar rijdt. Van alle lijnen heb ik een route in polylinevorm met coördinaten beschikbaar. Nu moet ik op de één of andere manier zien te berekenen waar een lijn/bus zich op dat moment bevindt aan de hand van haltetijden.
Iemand die mij hier een tip/tik/schopje over mee kan geven van hoe zoiets het beste te realiseren is?
Dat alles standaard in latin1 staat vind ik ook nogal vreemd, daarom heb ik nu alles in utf8, veel universeler inderdaad. Ik ga zo weer aan de slag ermee. Alles staat nu in ieder geval in utf8 in m'n database dankzij StM.quote:
Hehe, al die encoding shit is een van de meest complexe dingen die er zijn. Omdat het er zoveel zijn, en omdat conversie van de ene naar de andere erg lastig kan zijn. De belangrijkste tip die ik je kan geven: gebruik *vanaf het begin*, overal, de zelfde encoding, en gebruik geen latin1 maar utf8. De default collation van mysql is nog steeds latin1 en dat zuigt. De wereld is groter dan West-Europa. In utf8 wordt een letter met accent opgeslagen als een letterbyte + een accentbyte dus dat maakt zaken ook makkelijker.
Het is een server instelling, maar eigenlijk overal is het iets van latin1 tenzij anders gespecificeerd
Raar, maar waar.quote:
Het is een server instelling, maar eigenlijk overal is het iets van latin1 tenzij anders gespecificeerd
Goed nieuws: m'n probleem is opgelost.
Ik heb: | 1 2 3 | <?php mysql_query("SET NAMES 'utf8'"); ?> |
Top, bedankt.
García, zonder accent acute:
García, met accent acute:
Die standaardinstelling van latin1 komt doordat MySQL oorspronkelijk door een chauvinistische Zweed is gemaakt en niemand later de moeite heeft genomen dit aan te passen.quote:
[..]
Dat alles standaard in latin1 staat vind ik ook nogal vreemd, daarom heb ik nu alles in utf8, veel universeler inderdaad. Ik ga zo weer aan de slag ermee. Alles staat nu in ieder geval in utf8 in m'n database dankzij StM.
Ik heb een keer een stuk of 10 databases van meerdere GB's mogen converteren van latin1 naar utf8 hierdoor; vervelende bijkomstigheid was dat de data stiekem al utf8 was maar dan opgeslagen als latin1; bij ophalen van de data uit de db werd alles op byte niveau naar utf8 omgevrot op een nogal ranzige manier. Als je dat niet weet en dus de verkeerde aannames doet kom je echt in een vreselijke encoding-hell terecht...
Mwua of het komt door Monty durf ik eigenlijk niet te zeggen. Je ziet het nog steeds eigenlijk overal. De meeste file editors slaan volgens mij ook nog steeds default in latin1 op en zolang iedereen dat doet zal ook iedereen dat blijven doen. De default van postgresql is dacht ik ook nog steeds latin.quote:
[..]
Die standaardinstelling van latin1 komt doordat MySQL oorspronkelijk door een chauvinistische Zweed is gemaakt en niemand later de moeite heeft genomen dit aan te passen.
Ik heb een keer een stuk of 10 databases van meerdere GB's mogen converteren van latin1 naar utf8 hierdoor; vervelende bijkomstigheid was dat de data stiekem al utf8 was maar dan opgeslagen als latin1; bij ophalen van de data uit de db werd alles op byte niveau naar utf8 omgevrot op een nogal ranzige manier. Als je dat niet weet en dus de verkeerde aannames doet kom je echt in een vreselijke encoding-hell terecht...
Die conversie hell ken ik trouwens ook heel erg goed
Ook een hele leuke: een feed van een externe partij die een soort mix aanlevert. Delen UTF-8 (wat het had moeten zijn en wat ze ook dachten dat het was) en delen latin. Of juist dubbel geëncodeerd. Dan ga je echt blij worden...Dit is een grote reden dat ik er eigenlijk niks mee te maken wil hebben
Gewoon altijd utf-8.
Ik kreeg laatst ook een XML aangeleverd waar in de header stond "Windows-1252" maar de inhoud bleek een andere encoding te zijn. Da's pas lachen.quote:
Die conversie hell ken ik trouwens ook heel erg goed
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
Mijn eerste ervaring met encoding was ook niet prettig te noemen. Gelukkig ging het bij mij om een heel simpel projectje, dus was het probleem ook vrij snel opgelost met een beetje hulp. Ik kan me voorstellen hoe verrot het is als je dit probleem hebt met een database van enkele GB's waarvan je niet weet hoe alles encoded is.
Decrypten is pas een ramp als je niet goed weet hoe het encrypted is
Op dinsdag 9 augustus 2011 23:01 schreef SuperrrTuxxx het volgende:
Ik hou zoveel van jou, ik doe alles voor je! O+
Ik hou zoveel van jou, ik doe alles voor je! O+
Meh, ik ben er nog iets vergeten bij te vermelden. Het berekenen daarvan moet wel in een PHP-script gebeuren. Dit aangezien ik vanuit een OpenLayers-script elke seconde de locaties opvraag.quote:
Goeiedag heren,
Even een klein vraagje met betrekking tot maps/kaarten. Op dit moment heb ik coördinaten en een afstand die moet worden afgelegd tussen 2 coördinaten. Nu moet ik op de één of andere manier zien te berekenen hoe laat een bepaalde bus waar rijdt. Van alle lijnen heb ik een route in polylinevorm met coördinaten beschikbaar. Nu moet ik op de één of andere manier zien te berekenen waar een lijn/bus zich op dat moment bevindt aan de hand van haltetijden.
Iemand die mij hier een tip/tik/schopje over mee kan geven van hoe zoiets het beste te realiseren is?Op woensdag 7 november 2012 13:34 schreef KomtTijd... het volgende:
http://wiki.openstreetmap.org/wiki/Gosmore
Eigenlijk dus gewoon een coordinaat op een polyline, die ik al heb voor elke lijn zodat ik de marker daar naartoe kan verplaatsen (die functionaliteit (verplaatsen) is er al overigens).
