Be Excellent To Each Other

Someone explain why I keep getting the result:



For this bit of code?!



I have no idea.

What's your array look like? I just replicated that with this code:

And it complained about not recognising the panel ID (as I expected) but everything else was fine.

Right? My array looks like what you'd expect (it's being output in the default switch, after all):

It can't be encoding, can it?

Don't your array elements need to be strings?

They are, it's just the way they're output.

Anyway, this is php, where

Re-writing them just before the switch (ie:
Makes it work.

They're actually coming from a CSV, so it has to be encoding, somehow. I'll force them all to UTF8.

Everyday is a school day. I know fuck all about php

But it certainly should still work.

Re-encoding everything doesn't help. I'm proper confused.

I'm going to try re-encoding the original file.

Let me know if you need me to sort this shit out bud. I'll be right there.

The csv file is currently encoded with UTF-16. That's got to be the issue.

Yup, that was it.

I hate encoding. Why can't we all just agree to get along?

Cunt

Who the hell uses UTF-16 in this day and age?

Right? Right?

Huh, well blow me - apparently Windows uses it for all of it's OS text encoding. I don't think I've ever come across UTF-16 "in the wild."

Excellently, I just found this in a page I wrote a couple of months ago (during my "insane busy" phase):

I added

PHP really is shit isn't it?

No, it's pretty much as good as any other language (although the naming conventions bother me).

Unfortunately, the majority of PHP programmers are shit.

Hello!

Actually, I think I've come to realise that I don't want to get heavily into any kind of programming - this year it's been a case of Frameworks, SVNs and database diagrams. I just want to arse about with a bit of code that somehow works.

the ridiculous type conversions and operators are shocking, and then it can't even convert one string to another for comparison. It's shit compared to c, c++, java, perl, JavaScript and c# in those regards, to name the ones I know. Christ, even BASIC. I'm a bit shocked your blaming the workman when it's very clearly the tool, from this example that's affected you.

I hate the random sprawl of inconsistent functions/naming, too.

But I can happily ignore it, so it's fine really. Carry on.

Edit: actually, scratch c(++), because the traditional c runtime is easy to confuse, even if the more recent object and typed stuff isn't.

, although I'm probably one of them.

I know the encoding would have affected Java and Javascript in the same way, and I can't see the others managing too well. Simply, the strings were different - but the browser rendered them "correctly", so it was hard to tell.

If any language nobbed about converting strings without me wanting it to I think I'd be a bit upset - you'd end up with all different types of encoding stored, and when you tried to display them all at the same time you'd end up with a big old page of junk.


Right?

I actually asked Rasmus Lerdorf why the Hell that had happened once, and the answer was basically "If I changed it all now, millions of people would cry." Which is probably true, but - you know - fuck'em.

Also, array sorting all happens in place, which is inconsistent with every other function PHP has. And it has a function called `mysql_escape_string()` which is no good, and has been superseded by the excellently-named `mysql_real_escape_string()`. Oh yes.

The things that wind me up the most about it are the inconsistent order for parameters - like, for example, in array_search, it's needle then haystack, but in strstr/stristr, it's haystack then needle. Pain in the ass to remember.

That and the functions that operate on the original, like the array sorting functions and shuffle. And why ksort() instead of array_keysort() or something?

Java would complain at compile time, like the other compiled.languages (expect the ols-fangled pointer arithmetic ops in c) id expect Perl not to fuck it up silently. JavaScript interpreters tend to error at the drop of a hat!

But there was no error, remember. I was asking it to compare two different strings, which it did. They were different, but they looked the same as the ones in my code when output by the browser.

I've spent much of the last few weeks of work having to find various encoding issues - and that's where all strings are internally UTF16 and only converted on boundarys. Not having an enforced encoding throughout the code makes my head hurt with the potential for issues.

Yes, there was no error. But there should have been. Or it should have done a thread-locale conversion then compare.

Instead it did something insane, which appears to be the PHP modus operandi.

Eh? He compared a UTF-8 string to a UTF-16 string and PHP told him they were different. How is that not correct behaviour? It's not up to the language to sanitise your inputs.

Thank God they eventually turned off magic quotes by default.