1

I recently started using PHP's built-in webserver a lot more.

Unfortunately serving pages through it seems to have an effect on pages that retrieve data from our oracle database containing ÆØÅ.

The first image is when I run the script through Xampps' webserver, the second one is from PHP's built-in server.

from xampp enter image description here

from built-in enter image description here

The unpacked binary value of the 5th key can be seen next to each of the pictures.

Notice how it translates Æ into ã†. This obviously looks like an encoding error, but I'm not entirely sure what to look for. I'm not sure how exactly the built-in server serves pages, but I know the difference between Xampp and PHP is that they are using different PHP binaries and configuration.

Both php.ini files have default_charset="UTF-8" set.

Furthermore, looking at the response headers, both of them states: Content-type: text/html; charset=UTF-8.

Any ideas?

Jazerix
  • 4,729
  • 10
  • 39
  • 71
  • Notice the `b""` ? It's binary literal. Please do the following, show the hexadecimal output of both fieldnames. Please do `echo unpack('C*', $fieldName);`. – Daniel W. Jan 17 '19 at 13:50
  • Thanks for your input @DanFromGermany, I've added it. It's cler that their output is different, I'm just very confused where it's happening :/ – Jazerix Jan 17 '19 at 14:02
  • Ok so, you see two different things but as the second output is represented as a binary literal, there is no bug and no difference. If you show the stuff in HTML, you should not have a difference. Its not advisable to use special characters in field names tho. – Daniel W. Jan 17 '19 at 14:13
  • I agree that it's a bad practice, that's another department's responsibility, so I don't have much of a say. In terms of it not being a bug, it's troublesome when I'm trying to do $data['bemÆrkning'], and giving me an exception that they key doesn't exist. – Jazerix Jan 17 '19 at 14:22
  • Looking at it again very closely, the output of the unpack is different, to be exact, the 4th byte is not the same. Have you tried explicitly setting the [Oracle connection encoding](https://stackoverflow.com/questions/19996077/data-from-oracle-in-utf-8-with-php)? Another thing is, you should be able to tell the other department when their stuff is bad practice and they should change it appropriately. Everything else is not professional. – Daniel W. Jan 17 '19 at 15:50
  • Please also doublecheck which php.ini you are using, as on most platforms there is a seperate php.ini for the webserver sapi and the cli version. Also make sure the file itself is saved in UTF-8. I think you've done that, just double check to be sure. – Daniel W. Jan 17 '19 at 15:55
  • As I know the binary string is already deprecated, so which version of php you are using? – shingo Jan 17 '19 at 16:05
  • And character **Æ** unicode value is U+00C6, and UTF-8 value should be **195 134**, so the second one is right. the binary sequence in the first picture **227 134 114** is not a valid UTF-8 character. – shingo Jan 17 '19 at 16:10
  • @shing nice additional input. The string he put in the question as text (not in the picture) `ÆØÅ` is different from the other two: `195 134 195 152 195 133`. – Daniel W. Jan 18 '19 at 09:55

0 Answers0