Emphasis problem when migrating to PHP7

0

I'm using collation latin1 in the bank columns and iso-8859-1 in the pages, while it was in PHP5 it worked normal, but when migrating to PHP7 the accents started to give problems appearing this instead of each accent.

Has PHP7 changed the way it works with accents compared to PHP5?

    
asked by anonymous 10.04.2017 / 00:23

2 answers

5

Not the coding of documents does not have to be with the language, the language only processes and sends a processed file back to the user, when the connection with the bank is something that by default is configured in the bank and not in PHP.

The configuration of the database depends entirely on what the developer will want to do, here is an answer on the subject, although the photo is PHP in it is valid for any language that is Web-oriented (ie it generates pages):

Note that any version of PHP tries to maintain backward compatibility, so the new features of PHP7 do not necessarily make older scripts incompatible, unless you are using a function or class that has been previously discontinued.

To explain it better, in the case mysqli is an API that makes PHP access the mysql database that can be on a separate port or server, its only problem would be if you have been using functions that start mysql_ because they were part of the older API that was already outdated since PHP 5.5.0 and was only available up to 5.6 because of backwards compatibility. Now in version 7.0.0 + it has been removed and scripts written using it will no longer work.

Configuring the charset in the database

Even if you do this (PDO):

$conn = new PDO('mysql:host=HOST;dbname=BANCO;charset=utf-8', 'USUARIO', 'SENHA');
$conn->exec('SET CHARACTER SET utf8');//Define o charset como UTF-8

Or this (mysqli):

$mysqli->set_charset('utf8')

It does not mean that you are configuring PHP, you are actually sending an instruction to the bank so that it returns how the results were requested.

In the case of banks a traditional php and web page will consist of 4 important things:

  • HTTP Server (apache, nginx, IIS, etc.)
  • PHP language that interprets scripts and returns as a response
  • database
  • Scripts .php you wrote:

All 4 must have the necessary encoding settings:

  • HTTP server: can be resolved in httpd.conf or .htaccess, although you use header('Content-Type: ...'); of PHP itself already solves, that is, you only need to configure for static files (which may actually be optional)
  • PHP language: set header('Content-Type: ...');
  • Database: You should use the statement SET CHARACTER SET ... or $mysqli->set_charset('...') to say what you expect
  • Scripts% w_that you wrote: should be saved with the desired encoding, if it is UTF-8 use "UTF-8 without BOM", if latin1 or similar saves the scripts as ANSI or windows-1252 or iso- 8859-1 or compatible.
10.04.2017 / 00:32
2

Most likely there is a conflict with the environment setting. For according to what he reported, in the previous environment everything was working. What's more, PHP7 does not bring changes that affect encoding / encoding compared to PHP5. however, there may be some function or parameter obsolete or removed in this new version, which your system still uses and may be triggering errors that ultimately affect how the system should handle encoding. If this is the case, there is no way to solve it here because it requires a thorough diagnosis of your system. Nevertheless, there are certain basic and logical points that can solve

MBString

Check out the settings for MBString . You should be aware of these parameters: link

A practical way is to run phpinfo(); and compare information. link

Web Server

Also check the web server's encoding settings. (Apache, Nginx, IIS, etc.).

Database

Obviously, you should also check your database settings, if you have one.

It may have occurred that you migrated to a database containing mismatched settings and caused the data corruption or simply a conflict that can be fixed. In case of corruption has no magic, you will have to redo from a safe backup. I find that unlikely. But it is an option if the previous ones, described above, do not solve.

    
10.04.2017 / 09:12