Où puis-je trouver un bits UTF8 à la table char pour convertir par exemple « Ã ± » dans « ñ »?

Question

Je suis à la recherche semblent bien à travers le Web et je ne peux pas trouver une table avec ce genre de conversions. Ceux que je trouve avoir des erreurs et ne sont pas trop fiables, donc je l'ai cherché une table officielle ou similaire, mais malheureusement je n'ai pas .. si je suis ici ..

Comme mentionné dans le titre, ce que je veux faire est par exemple, savoir ce que signifie « Ã ± » représentent (ce que je sais déjà .. « ñ »), mais pas seulement pour les caractères espagnols, mais d'autres ( Je connais déjà les polonais).

Le principal problème est que j'ai une chaîne en PHP qui peut parfois venir comme par exemple « EÑE » (ce qui est ok) et d'autres comme « Ea ± e » .. et dans le lattest je devrais être capable de le changer pour " EÑE » il est donc facile à lire .. mais si elle est ok, je ne veux pas changer. Pour ce faire, j'utilisais fonction utf8_decode, mais dans le cas où la chaîne est lisible, il sera toujours changer le « ñ » à « ■ » (mais le blanc) .. c'est pourquoi je ne peux pas toujours décoder la chaîne, et si j'utilise la fonction mb_detect_encoding, je reçois toujours « UTF-8 » comme une réponse .. et ce n'est pas utile ..

Une fois que je connais tous les caractères de bit utf8 écrit comme par exemple « Ã ± » pour « ñ », « A¹ » pour « Z », etc., je prévois de faire une fonction qui remplacera essentiellement un à l'autre. . qui est un peu la même chose que le fait utf8_decode .. à moins que quelqu'un ici a une meilleure solution!

Merci d'avance! Salutations!

Answer 1

Pourquoi voulez-vous faire? Voulez-vous récupérer des données corrompues ou alors?

Il est vraiment ne pas être fait dans le cadre du flux habituel de code d'entreprise. Tout ce que vous devez faire est de faire en sorte que toutes les couches de votre webapp utilise UTF-8 correctement. La source de PHP, l'en-tête de réponse HTTP et le corps, la table de base de données, la connexion DB, et cetera. Voir aussi PHP UTF-8 antisèche.

Si vous en fait voulez faire cela comme une tâche unique de récupérer des données corrompues, alors il est bon de savoir que les données corrompues dans votre question indique que les données UTF-8 qui est mal ENREGISTRÉ ou affiché comme ISO-8859-1. Il vous suffit de lire les données comme ISO-8859-1 et écriture en UTF-8. Une fois. Ensuite, faites de la bonne façon.

En tant que preuve, le ñ ( Unicode Caractère « LATIN SMALL LETTRE N TILDE »(U + 00F1) ) sont disponibles dans Unicode ( UTF-8 , un codage multi-octets) d'octets 0xC3 et 0xB1. Lorsque ces octets sont codés en utilisant un codage à octet unique comme ISO-8859-1, le 0xC3 devient Ã et le 0xB1 devient ±. Voir aussi la ISO-8859-1 codepage mise en page.

Answer 2

Le problème est qu'une fois que vous avez Mojibake , il n'y a pas fiable pour le convertir à ce qu'elle était censée signifier. Voir ce paragraphe sur Wikipedia pour une explication du problème:

  

Considérons un fichier texte contenant le mot allemand für dans l'encodage ISO-8859-1. Ce fichier est maintenant ouvert avec un éditeur de texte qui suppose l'entrée est UTF-8. Comme le premier octet (0x66) est dans la gamme 0x00-0x7F, UTF-8 correctement l'interprète comme un f. Le deuxième octet (0xFC) ne soit pas une valeur juridique pour le début de tout caractère codé UTF-8. Un éditeur de texte pourrait donc remplacer l'octet par le symbole de caractères de remplacement pour avertir l'utilisateur que quelque chose a mal tourné. Le dernier octet (0x72) est également dans la plage de code 0x00-0x7F et peut être décodé correctement. maintenant toute la chaîne affiche comme ceci:. f�r

     

Un éditeur de texte mal mis en œuvre pourrait enregistrer le remplacement sous forme UTF-8; les données de fichier texte ressemblera alors à ceci: 0x66 0xEF 0xBF 0xBD 0x72, qui sera affiché dans la norme ISO-8859-1 à nouveau comme f�r. Le remplacement détruit également l'octet d'origine, ce qui rend impossible de récupérer ce caractère était destiné.

Vous devez éviter d'interpréter correctement le texte en utilisant le mauvais encodage depuis le début. Fixation quand il est cassé est trop tard.

Answer 3

Votre problème est un problème d'interprétation plus transcoder. Sur un ordinateur moderne, est normalement ñ entrée comme 0xc3b1 binaire, car il est son code UTF-8. Si vous interprétez que (sans transcoder) dans l'ancien code iso-latin-15, vous obtiendrez 0xC3 = Ã suivie 0xB1 = ±. C'est la raison pour laquelle il n'y a pas de « table »:. Il est un problème d'affichage

La meilleure chose à faire est d'éviter entièrement iso-latin. Il vous fera beaucoup de problèmes. La vraie façon de fixer votre programme. Utilisez uniquement utf-8 partout, il vous permettra d'économiser beaucoup de temps et des maux de tête

En attendant, si vous voulez vraiment aller chercher l'équivalent chaîne iso-latin-15 à votre entrée utf-8 (que vous ne le faites pas, si vous avez le droit ci-dessus), vous pouvez passer votre chaîne à un code convertisseur, lui demandant de convertir utf-8 à iso-latin-15 . Une chose que vous devez faire attention est double transcoder. Si vous aviez une chaîne utf-8 et mistakingly demandé une conversion de iso-Lating-15 à utf-8, alors vous une chaîne utf-8 qui dit en fait à ±, qui est 0xc383c2b1 binaire. Pour revenir la chaîne utf-8 correct, le anwser est le même: demander de convertir votre chaîne mutilée de utf-8 à iso-latin-15, qui se fera un plaisir de prendre 0xc383 et le convertir en 0xC3, puis 0xc2b1 et le convertir en 0xB1, vous donnant une chaîne utf-8 correcte contenant un bon ñ.

En particulier pour les applications PHP et Web, rappelez-vous que de nombreux ordinateurs (et de plus en plus à l'avenir) vous enverra utf-8 par défaut.