abonnement Unibet Coolblue
pi_118922283
quote:
0s.gif Op woensdag 7 november 2012 02:35 schreef StM het volgende:
Check je het via PHPMyAdmin? Staat de karakterset wel goed? (Dus op UTF-8)
Is dat collatie? Ja, die staat op UTF-8.
pi_118922331
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.
pi_118922340
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 :X
pi_118922376
quote:
0s.gif Op woensdag 7 november 2012 02:43 schreef StM het volgende:
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 :X
Met
1
2
3
<?php
mysql_query
(utf8_encode("UPDATE `table` SET `name`='García Fernández' WHERE `id`=1"));
?>

krijg ik dit:

pi_118922401
Welke browser heb je? Klik namelijk eens in phpmyadmin rechts en dan naar de pagina eigenschappen wat de karakter set is.
pi_118922444
quote:
0s.gif Op woensdag 7 november 2012 02:48 schreef StM het volgende:
Welke browser heb je? Klik namelijk eens in phpmyadmin rechts en dan naar de pagina eigenschappen wat de karakter set is.
Yes! Gelukt. :) Thanks man! ^O^. ;)

Ik moest de query zonder utf8_encode versturen en
1
2
3
<?php
mysql_query
("SET NAMES 'utf8'");
?>
voor de query die de naam invoert.

Precies wat je zei dus, maar ik snap niet waarom het nu wel lukt. Nja, nogmaals bedankt. _O_
pi_118922458
Hmm waarom werkte het net niet dan? :P Dat had je net toch ook?

*edit*:

Ok :)
pi_118922467
quote:
0s.gif Op woensdag 7 november 2012 02:53 schreef StM het volgende:
Hmm waarom werkte het net niet dan? :P Dat had je net toch ook?
Weet ik dus ook niet, misschien niet refresht in m'n browser toen ik het script ging uitvoeren. 8)7
pi_118922488
Nu zit ik nog wel steeds met deze vraag:

quote:
0s.gif Op woensdag 7 november 2012 01:18 schreef pascal08 het volgende:
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.
...maar goed, dat komt morgen wel, ik ben al lang blij dat je m'n probleem met de database hebt opgelost. :D Morgen weer een dag. Ik ga slapen nu. :W
pi_118922520
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.
pi_118922577
quote:
0s.gif Op woensdag 7 november 2012 02:59 schreef StM het volgende:
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.
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. ;) ^O^
pi_118925630
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.
pi_118933046
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?
pi_118936469
quote:
0s.gif Op woensdag 7 november 2012 09:23 schreef Farenji het volgende:
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.
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. ^O^
pi_118936718
Het is een server instelling, maar eigenlijk overal is het iets van latin1 tenzij anders gespecificeerd :)
pi_118936971
quote:
0s.gif Op woensdag 7 november 2012 14:53 schreef StM het volgende:
Het is een server instelling, maar eigenlijk overal is het iets van latin1 tenzij anders gespecificeerd :)
Raar, maar waar. :D

Goed nieuws: m'n probleem is opgelost. *O* Ik heb:
1
2
3
<?php
mysql_query
("SET NAMES 'utf8'");
?>
ook de regel boven m'n zoek-query geplakt en alles wordt nu weergegeven zoals ik het wil. Ook zijn alle vage tekentjes weg. Eigenlijk dus precies zoals jij en Farenji zeiden: "alles in dezelfde coding".

Top, bedankt. ^O^

García, zonder accent acute:


García, met accent acute:
pi_118937472
quote:
0s.gif Op woensdag 7 november 2012 14:47 schreef pascal08 het volgende:

[..]

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. ^O^
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... ;(
pi_118938151
quote:
0s.gif Op woensdag 7 november 2012 15:13 schreef Farenji het volgende:

[..]

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... ;(
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.

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 :P Gewoon altijd utf-8.
  woensdag 7 november 2012 @ 15:37:31 #295
91039 mstx
2x1/2 = 1/2 x 1/2
pi_118938472
quote:
0s.gif Op woensdag 7 november 2012 15:29 schreef StM het volgende:
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...
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. :Y
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.
👾
pi_118938499
Ook een geniale ja 8)7
pi_118939284
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. 8)7
  woensdag 7 november 2012 @ 19:17:54 #298
178193 Juicyhil
Bekende FOK!ker
pi_118947114
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+
pi_118948571
quote:
0s.gif Op woensdag 7 november 2012 13:28 schreef Xanland het volgende:
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?

14s.gif Op woensdag 7 november 2012 13:34 schreef KomtTijd... het volgende:
http://wiki.openstreetmap.org/wiki/Gosmore 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.
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).
pi_118953078
er vanuit gaande dat het vaste routes zijn, zou ik dan gewoon per been (of per 100m ofzo) de benodigde tijd berkenen en dan de marker op het dichtstbijzijnde punt zetten.
abonnement Unibet Coolblue
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')