Réduire la sortie HTML finale en utilisant des expressions régulières avec CodeIgniter
Des pages Google vous suggère de rapetisser HTML, c'est de supprimer tous les espaces inutiles.
CodeIgniter n'ont la particularité de giziping de sortie ou il peut être fait par .htaccess
.
Mais je voudrais aussi supprimer les espaces inutiles à partir de la dernière sortie HTML.
J'ai joué un peu avec ce morceau de code pour le faire, et il semble fonctionner.
Ce n'est en effet résultat en HTML qui est sans excès espaces et supprime les autres onglet mise en forme.
class Welcome extends CI_Controller
{
function _output()
{
echo preg_replace('!\s+!', ' ', $output);
}
function index(){
...
}
}
Le problème est que il peut y avoir des balises comme
<pre>
,<textarea>
etc.. qui peuvent être séparés par des espaces et une expression régulière doit les supprimer.
Alors, comment puis-je enlever l'excédent de l'espace sur le HTML final, sans effectuer d'espaces ou de mise en forme pour ces certaines balises à l'aide d'une expression régulière?
Grâce à @Alan Moore eu la réponse, cela a fonctionné pour moi
echo preg_replace('#(?ix)(?>[^\S ]\s*|\s{2,})(?=(?:(?:[^<]++|<(?!/?(?:textarea|pre)\b))*+)(?:<(?>textarea|pre)\b|\z))#', ' ', $output);
ridgerunner a fait un très bon travail de l'analyse de cette expression régulière. J'ai fini à l'aide de sa solution. Bravo à ridgerunner.
source d'informationauteur Aman | 2011-03-15
Vous devez vous connecter pour publier un commentaire.
Pour ceux qui sont curieux à propos de la façon d'Alan Moore regex fonctionne (et oui, il ne de travail), j'ai pris la liberté de commenté de sorte qu'il peut être lu par de simples mortels:
Je suis nouveau ici, mais je peux voir à droite de Alan qui est assez bon dans la regex. Je tiens seulement à ajouter les suggestions suivantes.
<SCRIPT>
élément doit être ajouté à la<PRE>
et<TEXTAREA>
liste noire.'S'
PCRE "étude" modificateur accélère cette regex d'environ 20%.(?:[^<]++|<(?!/?(?:textarea|pre)\b))*+
) est une accumulation excessive de PCRE la récursivité sur les grandes chaînes cibles, ce qui peut entraîner une pile de déborder, provoquant l'Apache/PHP exécutable à silencieusement seg-faute et collision avec aucun avertissement. (La version Win32 de Apachehttpd.exe
est particulièrement sensible, car il ne dispose que de 256 KO de la pile par rapport à l' *nix exécutables, qui sont généralement construits avec 8 mo de pile ou plus). Philip Hazel (l'auteur de la regex PCRE moteur utilisé en PHP) traite de cette question dans la documentation: PCRE DISCUSSION DE L'UTILISATION DES PILES. Bien que Alan a correctement appliqué le même correctif de Philip montre dans ce document (application d'un possessif plus pour la première solution), il y aura encore beaucoup de récursivité si le fichier HTML est grand et a beaucoup de non-sur la liste noire des balises. par exemple Sur mon Win32 boîte (avec un exécutable avoir un 256KB-pile), le script coups avec un fichier de test de seulement 60 KO. Notez également que PHP ne dispose malheureusement pas de suivre les recommandations et définit la valeur par défaut limite de la récursivité trop élevé à 100000. (Selon le PCRE docs cela doit être réglé à une valeur égale à la taille de la pile divisé par 500).Ici est une version améliorée qui est plus rapide que l'original, poignées grande entrée, et gracieusement échoue avec un message si la chaîne d'entrée est trop grande à gérer:
p.s. Je suis intimement familier avec ce PHP/Apache seg-la faute de problème, comme je l'ai été impliqué avec l'aide de la communauté Drupal alors qu'ils étaient en lutte avec ce problème. Voir: Optimiser CSS causes de php en mode cgi pour erreur de segmentation dans pcre de la fonction "match". Nous avons aussi fait l'expérience avec l'analyseur BBCode sur le forum FluxBB projet de logiciel.
Espère que cette aide.
J'ai mis en place la réponse de @ridgerunner dans les deux projets, et finit par frapper certains graves ralentissements (10-30 deuxième fois) dans la mise en scène pour l'un des projets. J'ai découvert que j'avais à définir à la fois
pcre.recursion_limit
etpcre.backtrack_limit
assez faible pour qu'il même travail, mais même alors, il aurait abandonné après environ 2 secondes de traitement et de retour faux.Depuis que j'ai remplacé avec cette solution (plus facile à saisir regex), qui est inspiré par le outputfilter.trimwhitespace fonction de Smarty 2. Il n'a pas de retour en arrière ou la récursivité, et qui fonctionne à chaque fois (au lieu de la situation catastrophique à défaut d'une fois dans une lune bleue):