Conversion en caractères HTML

Question

Je souhaite convertir une chaîne en entités HTML/caractères spéciaux afin de pouvoir la stocker dans la base de données MySQL. Exemple,

C'est ainsi qu'il est stocké dans la base de données MySQL.
V3008-02, WS1 Drain Fitting 1” Straight w/Silencer

et lorsqu'ils sont rendus sur la navigation, il montre
V3008-02, WS1 siphons 1 ” droite w/Silencer

Mon application intégrée dans le package PHP à l'aide de phpBMS. Je veux convertir le texte rendu en texte original afin que je puisse stocker dans la base de données. Sur la note de côté, quel est le meilleur moyen de stocker des balises HTML dans la base de données?

Est-il

A 'quote' is <b>bold</b&gt

ou

A 'quote' is <b>bold</b>

Cordialement

Answer 1

http://us3.php.net/manual/en/function.htmlspecialchars-decode.php Ceci est la réponse à vos problèmes.

Je ne sais pas comment vous devriez stocker les balises HTML. Évidemment, vous ne pouvez pas les stocker dans leur forme originale, et il est gonflé de les utiliser avec des entités spéciales. Je recommande à la place de lier à un fichier qui peut être consulté qui contient le code HTML.

OK, vous pouvez les stocker en tant que tels, mais vous devez également utiliser cette fonction.

Je ne pense pas qu'il soit efficace de stocker un gros bloc de HTML sur le terrain; Je suppose que cela dépend de la taille.

Answer 2

Je ne recommande pas du tout de stocker des entités dans la base de données. Même pour un champ utilisateur qui devait être traité en texte brut, je l'échapperais immédiatement avant la sortie.

Cependant, ici, il semble que vous ayez une chaîne HTML de confiance (par exemple d'un catalogue). Donc stocker tout comme:

V3008-02, WS1 Drain Fitting 1” Straight w/Silencer 

ou:

A 'quote' is <b>bold</b> 

et le jeter directement à la sortie. Il n'y a aucune raison d'utiliser ” car vous devriez pouvoir l'inclure directement avec l'encodage Unicode de votre choix (par exemple UTF-8).

Answer 3

Le contenu doit être enregistré dans la base de données sous la forme d'origine.Par exemple:

<p>this is a paragraph</p> 

doivent être stockés exactement comme:

<p>this is a paragraph</p> 

Pour faire l'injection SQL impossible échapper simplement les chaînes d'entrée avec une fonction d'échappement appropriée et désinfectez vos données (par exemple, si elle est censée être un entier, faire un cast (int)). Si vous utilisez un framework, cela sera fait pour vous par la couche de base de données. Je faisais aussi mes propres fonctions d'échappement, ce qui est assez facile à faire.

Lors de l'affichage dans une page HTML, il faut utiliser htmlentities (ou par exemple la méthode d'échappement de Zend_View). Il n'y a pas de raison imminente pour laquelle on n'accepterait pas de stocker des caractères spéciaux dans la base de données tant que la base de données les accepte et que le contenu est sorti en toute sécurité pour précéder XSS et ainsi de suite.

L'idée derrière mes arguments est que le contenu devrait être «exportable» pour n'importe quelle plateforme/lieu. Donc si c'est une page HTML, vous allez utiliser htmlentities(), si c'est un fichier CSV, vous allez utiliser des fonctions d'export CSV pour traiter ce texte, etc.