Faire face à et d'autres caractères eacute spéciaux en utilisant Oracle, PHP et oci8

StackOverflow https://stackoverflow.com/questions/2357680

Question

Salut, je suis en train de stocker des noms dans une base de données Oracle et les récupérer en arrière en utilisant PHP et oci8.

Cependant, si j'insère le é directement dans la base de données Oracle et utilise oci8 pour aller la chercher en arrière, je viens de recevoir un e

Dois-je encoder tous les caractères spéciaux (y compris de é) dans des entités html (ie: é) avant de l'insérer dans la base de données ... ou suis-je manque quelque chose

?

Thx

Mise à jour: 1 mars à 18:40

trouvé cette fonction: http://www.php.net/manual/en/ function.utf8-decode.php # 85034 

function charset_decode_utf_8($string) {
    if(@!ereg("[\200-\237]",$string) && @!ereg("[\241-\377]",$string)) {
        return $string;
    }
$string = preg_replace("/([\340-\357])([\200-\277])([\200-\277])/e","'&#'.((ord('\\1')-224)*4096 + (ord('\\2')-128)*64 + (ord('\\3')-128)).';'",$string);
$string = preg_replace("/([\300-\337])([\200-\277])/e","'&#'.((ord('\\1')-192)*64+(ord('\\2')-128)).';'",$string);
return $string;
}

semble fonctionner, mais pas sûr que sa solution optimale

Mise à jour: 8 mars à 15h45

Le jeu de caractères Oracle est ISO-8859-1.
en PHP I ajouté: 

putenv("NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1");

pour forcer la connexion oci8 à utiliser ce jeu de caractères. Récupération du é à l'aide de PHP oci8 maintenant travaillé! (Pour varchars, mais pas CLOBs dû faire utf8_encode pour l'extraire)
Alors j'ai essayé de sauvegarder les données de PHP à Oracle ... et il ne marche pas work..somewhere le long du chemin de PHP à Oracle le é devient ?

Mise à jour: 9 mars à 14h47

Alors se rapprocher. Après avoir ajouté la variable NLS_LANG, des insertions oci8 direct avec les œuvres de é.

Le problème est en fait sur le côté de PHP. En utilisant le cadre ExtJs, lors de la présentation d'un formulaire qu'elle code à l'aide encodeURIComponent.
Alors é est envoyé comme %C3%A9 puis recodé en é.
Cependant sa longueur est maintenant 2 (strlen($my_sent_value) = 2) et non 1. Et si en PHP je tente: $ my_sent_value == é = false

Je pense que si je suis en mesure de ré-encoder tous ces personnages en PHP arrière en longueurs de taille en octets 1, puis de les insérer dans Oracle, il devrait fonctionner.

Toujours pas de chance si

Mise à jour: 10 mars à 11h05

Je continue à penser que je suis si proche (et pourtant si loin).

putenv("NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P9"); fonctionne très sporadiquement.

J'ai créé un petit script php pour tester: 

header('Content-Type: text/plain; charset=ISO-8859-1');
putenv("NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P9");
$conn= oci_connect("user", "pass", "DB");
$stmt = oci_parse($conn, "UPDATE temp_tb SET string_field = '|é|'");
oci_execute($stmt, OCI_COMMIT_ON_SUCCESS);

Après avoir exécuté cette fois loggin dans la base de données Oracle directement je vois que STRING_FIELD est réglé sur |¿|. De toute évidence pas ce que j'étais venu à attendre de mon expérience précédente.
Cependant, si je rafraîchisse cette page PHP rapidement deux fois .... ça a marché !!!
Dans Oracle, j'ai vu correctement |é|.

Il semble que peut-être la variable d'environnement n'est pas défini ou envoyé correctement à temps pour la première exécution du script, mais est disponible pour la deuxième exécution.

Mon expérience suivante consiste à exporter la variable dans l'environnement PHP, cependant, je dois réinitialiser Apache pour que ... donc nous verrons ce qui se passe, nous espérons qu'il fonctionne.

Était-ce utile?

La solution 2

est ce que j'ai finalement fini par faire pour résoudre ce problème:

modification du profil du démon PHP en cours d'exécution pour avoir: 

NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1

Alors que la connexion oci8 utilise ISO-8859-1.

Ensuite, dans ma configuration PHP définir le type de contenu par défaut à la norme ISO-8859-1: 

default_charset = "iso-8859-1"

Quand je suis insérer dans une table Oracle via oci8 de PHP, je fais: 

utf8_decode($my_sent_value)

Et lors de la réception des données d'Oracle, l'impression la variable devrait fonctionner comme ceci: 

echo $my_received_value

Cependant lors de l'envoi que les données sur ajax j'ai dû utiliser: 

utf8_encode($my_received_value)

Autres conseils

Je suppose que vous êtes au courant de ces faits:

  • Il y a beaucoup de jeux de caractères différents: vous devez choisir un et, bien sûr, savoir lequel vous utilisez
    • .
  • Oracle est parfaitement capable de stocker du texte sans les entités HTML (de é). les entités HTML sont utilisées dans bien, HTML. Oracle est pas un navigateur Web; -)

Vous devez également savoir que les entités HTML ne sont pas se lier à un jeu de caractères spécifique; au contraire, ils sont utilisés pour représenter les caractères dans un contexte charset indépendant.

Vous parlez indistincte à propos de ISO-8859-1 et UTF-8. Qu'est-ce que charset voulez-vous utiliser? ISO-8859-1 est facile à utiliser, mais il ne peut stocker du texte dans certaines langues latines (comme l'espagnol) et il manque des caractères communs comme le symbole €. UTF-8 est plus délicate à utiliser, mais il peut stocker tous les caractères définis par le consortium Unicode (qui comprennent tout ce dont vous aurez besoin).

Une fois que vous avez pris la décision, vous devez configurer Oracle pour stocker les données dans un tel charset et choisir un type de colonne appropriée. Par exemple, VARCHAR2 est très bien pour ASCII, NVARCHAR2 est bon pour UTF-8.

Si vous ne pouvez vraiment pas changer le jeu de caractères Oracle utilisera alors que diriez-vous vos données Base64 avant de les stocker dans la base de données. De cette façon, vous pouvez accepter les caractères de tout jeu de caractères et de les stocker sous forme de ISO-8859-1 (parce que base64 affichera un sous-ensemble de l'ensemble de caractères ASCII qui mappe exactement à la norme ISO-8859-1). codage de base 64 augmente la longueur de la chaîne, en moyenne, 37%

Si les données ne sont jamais à être affiché comme HTML, vous pourriez aussi bien stocker les entités HTML comme vous le suggérez, mais sachez qu'une seule entité peut être jusqu'à 10 caractères par caractère non codé par exemple θ est ϑ

Je devais faire face à ce problème: les caractères spéciaux ibéroaméricains sont stockés sous forme de « ? » ou « ¿ » dans ma base de données Oracle ... Je ne peux pas changer le NLS_CHARACTER_SET parce que nous ne sommes pas les propriétaires de bases de données.

Alors, je trouve une solution de contournement:

1) code ASP.NET Créer une fonction qui convertit la chaîne de caractères hexadécimaux: 

    public string ConvertirStringAHex(String input)
    {
        Encoding encoding = System.Text.Encoding.GetEncoding("ISO-8859-1");
        Byte[] stringBytes = encoding.GetBytes(input);
        StringBuilder sbBytes = new StringBuilder(stringBytes.Length);
        foreach (byte b in stringBytes)
        {
            sbBytes.AppendFormat("{0:X2}", b);
        }
        return sbBytes.ToString();
    }

2) Appliquer la fonction ci-dessus à la variable que vous souhaitez encoder, comme ceci 

     myVariableHex = ConvertirStringZHex( myVariable );

Dans ORACLE, utilisez les touches suivantes: 

 PROCEDURE STORE_IN_TABLE( iTEXTO IN VARCHAR2 )
 IS
 BEGIN
   INSERT INTO myTable( SPECIAL_TEXT )  
   VALUES ( UTL_RAW.CAST_TO_VARCHAR2(HEXTORAW( iTEXTO ));
   COMMIT;
 END;

Bien sûr, iTEXTO est le paramètre Oracle qui reçoit la valeur de "myVariableHex" à partir du code ASP.NET.

it helps ... s'il y a quelque chose pour améliorer pls ne hésitez pas à poster vos commentaires.

Sources: http: / /www.nullskull.com/faq/834/convert-string-to-hex-and-hex-to-string-in-net.aspx https://forums.oracle.com/thread/44799

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top