Php file_get_contents línea por línea
Un problema de UTF-8 con el que me he encontrado es el de leer una URL con una codificación no UTF-8 que luego se muestra incorrectamente ya que file_get_contents() la relaciona como UTF-8. Esta pequeña función debería mostrar cómo solucionar este problema:
Parece que file busca el archivo dentro del directorio de trabajo actual (en ejecución) antes de buscar en la ruta de inclusión, incluso con la bandera FILE_USE_INCLUDE_PATH especificada.El mismo comportamiento que include en realidad.Por cierto, creo que el doc no es del todo claro en el orden exacto de inclusión (ver include). Parece decir que el include_path es la primera ubicación que se busca, pero me he encontrado con al menos un caso en el que el directorio que contiene el archivo incluido era en realidad el primero en ser buscado.Drat.
Si quieres insertar scripts de seguimiento en tu sistema de compras, algunos scripts no soportan la detección inteligente de HTTPS, así que hice un script que puse en el servidor que reescribe ‘http’ a ‘https’ en el script, asumiendo que todo tiene que ser codificado en UTF-8 (como fallback hace una redirección).
File_get_contents(“php://input”)
Siempre que hago esto en un determinado servidor, el resultado está vacío. Cuando lo hago en cualquier otro lugar, el resultado es cualquiera que sea el contenido de la página. Sin embargo, cuando, en el servidor donde el resultado está vacío, utilizo la función localmente – sin acceder a una URL externa (file_get_contents(‘../simple/internal/path.html’);), sí funciona.
Las respuestas anteriores resuelven el problema, pero no explican el extraño comportamiento descrito por el usuario. Esta explicación debería ayudar a cualquiera que pruebe la comunicación entre sitios en un entorno de desarrollo en el que todos estos sitios residen en el mismo host (y en el mismo virtualhost; estoy trabajando con apache 2.4 y php7.0).
Hay una sutileza con file_get_contents() con la que me encontré que es absolutamente relevante aquí pero que no ha sido tratada (probablemente porque está apenas documentada o no está documentada por lo que puedo decir o está documentada en un oscuro documento técnico sobre el modelo de seguridad de php que no puedo encontrar).
Con allow_url_fopen establecido en Off en todos los contextos relevantes (por ejemplo, /etc/php/7.0/apache2/php.ini, /etc/php/7.0/fpm/php.ini, etc…) y allow_url_fopen establecido en On en el contexto de la línea de comandos (es decir, /etc/php/7.0/cli/php.ini), las llamadas a file_get_contents() para un recurso local serán permitidas y no se registrará ninguna advertencia como:
Php file_put_contents
Después de ejecutar la última tarea para reorientar el nuevo symlink se ejecuta el comando cachetool: php bin/cachetool opcache:reset –web –web-path=/var/www/html/example.org/current/public –web-url=https://example.org
También me he dado cuenta de este problema recientemente. Funcionaba bien pero (creo que es desde la actualización a la 6.3), ahora falla bastante a menudo pero a veces funciona. Tal vez sea una condición de carrera. Voy a probar con SymfonyHttpClient. Sin embargo, ese no se puede usar en la 6.3.0 sin un archivo de configuración: #178
¿O es demasiado pronto después de cambiar el enlace simbólico y apache requiere un poco más de tiempo para servir la nueva ruta? En cualquier caso, tal vez un periodo de espera opcional entre la creación y la lectura del archivo podría ayudar, por ejemplo, especificando los segundos de espera como parámetro.
@FireLizard ¿apunta https://example.org a la carpeta /var/www/html/example.org/current/public/? Cachetool no se quejó de no poder escribir el archivo en el directorio, pero el servidor se queja de que el archivo no está allí. Mi opinión es que hay algún tipo de desconexión.
Php file_get_contents imagen url
según php.ini, allow_url_fopen OnXserve- OS X Server 10.6.2- PHP 5.3 (por defecto)Así que… es como si PHP no estuviera respetando la directiva allow_url_fopen en php.ini. Si esa directiva estuviera en Off, todo tendría sentido (los archivos se cargan, las urls no (locales o remotas)).¿Alguien tiene algo que añadir? Si no se ha establecido la directiva “Off”, todo tendría sentido (los archivos y las urls no se cargan).
según php.ini, allow_url_fopen OnMira desde phpinfo() la configuración ya está “On”.Sí, lo sé.Por eso es extraño que la función falle en las URLs.-Lista de correo general de PHP (http://www.php.net/)Para darse de baja, visite: http://www.php.net/unsub.php
