|
|
|
 |
|
|||||||
| Saturday May 19th 2012 Edition — 18th Year |
|
 RSS Feed
|
  |
04:32 AM FRANCE | |||||||
|
|||||||||||
10 most popular:
- This site supports Apple, read 55763 times, exists for 2372 days, read 23.4989 times a day
- Nightmare Creatures 3 : a unique video game !, read 22623 times, exists for 3683 days, read 6.1409 times a day
- Proxy photographie : Votre iBook comme boite à lumière, read 13680 times, exists for 2324 days, read 5.8839 times a day
- Destroy malicious usurpating mail, read 11436 times, exists for 2166 days, read 5.2773 times a day
- Taxonomie, read 10561 times, exists for 2124 days, read 4.9699 times a day
- Un jeu sur 3 CDs, read 9518 times, exists for 2121 days, read 4.4854 times a day
- Francis, le haricot magique, Jour 11, read 8906 times, exists for 2150 days, read 4.1404 times a day
- Vous voulez votre photo sur Google ?, read 8064 times, exists for 2342 days, read 3.4417 times a day
- Flickr.com va plus loin, read 7365 times, exists for 2317 days, read 3.1773 times a day
- S.T.O.R.M.: Looking for Praxilium, read 6999 times, exists for 2413 days, read 2.8993 times a day
10 last posts:
- eBay Security Flaws or How am I supposed to have bought 28 objects in 3 minutes on ebay france, US and italy! created on Sept. 17th, 2006 21:47
- My Pilot License is Taking Off! created on Sept. 3rd, 2006 01:41
- Greek's no longer supported by bbc.co.uk! created on Aug. 31st, 2006 16:55
- Un jeu sur 3 CDs created on July. 29th, 2006 20:18
- A 3-CD-set Game created on July. 29th, 2006 19:51
- Index du Site created on July. 26th, 2006 21:04
- Site Index created on July. 26th, 2006 20:52
- Taxonomie created on July. 26th, 2006 20:44
- Taxonomy created on July. 26th, 2006 13:30
- Mars Special Ops Handbook created on July. 6th, 2006 22:16
10 last updated articles:
- Site Index updated on Sept. 19th, 2006 20:10
- 2002 Publisher Market Share updated on Sept. 19th, 2006 20:09
- Proxy photography: Your iBook as a light box updated on Sept. 19th, 2006 01:50
- eBay Security Flaws or How am I supposed to have bought 28 objects in 3 minutes on ebay france, US and italy! updated on Sept. 18th, 2006 22:45
- My Pilot License is Taking Off! updated on Sept. 8th, 2006 20:51
- Les enfants de la providence - Edition de 1824 updated on Sept. 8th, 2006 01:36
- SonyEricsson Releases it's New J2me Platform JP-7 updated on Sept. 8th, 2006 01:30
- Greek's no longer supported by bbc.co.uk! updated on Aug. 31st, 2006 17:08
- A 3-CD-set Game updated on Aug. 3rd, 2006 12:26
- Un jeu sur 3 CDs updated on July. 29th, 2006 22:37
Mon site PHP support l'UTF-8 en natif !
Del.icio.us — updated on Nov. 22nd, 2005 13:53 exists for 7 years & 6 months ago — Rate:
— — Sorry, this content is not available in english.Initialement, le développement du site s'est naturellement fait à l'aide de caractères latins, le fameux encoding ISO-8859-1. Les accents de la langue française ainsi que les cédilles sont correctement pris en charge. La version anglaise, elle, ne pose aucun problème, évidement.
Cela s'est corsé lorsque l'envie d'intégrer du contenu en grec s'est fait poindre. Force est de constater, que l'unique solution permetant de gérer plusieurs langues, plusieurs alphabets, est l'usage des caractères Unicode; et notament l'UTF-8. Cet encodage offre l'avantage d'être compatible avec l'alphabet anglais, ce qui simplifie grandement la migration des articles déjà existants dans la base.
Plusieurs options s'offrent au développeur, mais celle qui m'avait apparut la plus simple, consistait à stocker les textes en UTF-8 dans la base de données; et lorsque le script PHP les récupérait, il pouvait les expédier directement au browser. Il faut noter que l'encodage des pages HTML doit être positionné sur UTF-8 comme indiqué ci-dessous:
Si cette solution fonctionne certainement, elle présente certaines limitations, et notament, l'impossibilité de mettre du texte UTF-8 directement dans les scripts PHP, c'est-à-dire, pouvoir faire un « print "Καλιμερα"; ».
Comment faut-il procédé pour que le site lui même soit entièrement codé en UTF-8. Il me paraissait que le simple fait de convertir mes fichiers codes sources PHP de ISO 8859 vers UTF-8 devrait faire l'affaire. A l'époque je travaillais encore sous Windows et mon éditeur de texte était Ultraedit.
Hélas, uploader l'ensemble des fichiers PHP une fois convertis, n'a pas créé — à ma grand surprise — l'effet désiré.
Des erreurs liées aux cookies sont apparut immédiatement. En investigant un peu plus, je me rendis compte qu'en réalité, des caractères avaient déjà été expédiés vers le browser alors même que les headers étaient toujours en cours de génération dans mes pages PHP.
Honnètement, ce problème m'a été difficile à comprendre, et de longues recherches sur le net ne m'ont absolument pas aidé à trouver ne serait-ce qu'une piste de résolution.
S'il semble que le support du multi-langues devient une préoccupation montante chez les développeurs, finalement, peu de litterature est réellement disponible.
Certains allant jusqu'à dire que faire tourner des fichiers PHP encodés UTF-8 sous Appache/PHP est en fait impossible, dû a un « bug » de PHP.
Il n'en est rien. La solution finalement est assez simple. Et elle est définitive.
L'encodage UTF-8 est en réalité, une façon de coder les caractères en attribuant moins d'octest aux caractères très utilisés et plus à ceux qui le sont moins. Et pour savoir qu'un fichier text est encodé comme celà, un marqueur est mis au début du fichier : c'est le fameux Byte Ordering Marker (ou BOM). En effet certains processeurs, comme les Intels, intervertisent l'odre des octets dans la mémoire (little endian), d'autres, les gèrent dans l'ordre naturel (big endian).
Hors, il se trouve que la présence de ce marqueur BOM provoque un problème à PHP. Le retirer suffit à régler le problème.
Pour ma part, j'ai depuis switché sous Mac OS X, et je travaille maintenant avec un iMac G5.
J'ai remplacé Ultraedit par TextWrangler. Ultraedit ne supporte pas la sauvegarde de fichiers texte sans BOM (NDLA: depuis, la version 11 le fait). TextWrangler le supporte.
Après avoir sauvé l'ensemble de mes scripts sans le BOM, puis uploadé sur le serveur, le problème fût enfin résolu.
Σδλ
Leave a comment | Reddit!Cela s'est corsé lorsque l'envie d'intégrer du contenu en grec s'est fait poindre. Force est de constater, que l'unique solution permetant de gérer plusieurs langues, plusieurs alphabets, est l'usage des caractères Unicode; et notament l'UTF-8. Cet encodage offre l'avantage d'être compatible avec l'alphabet anglais, ce qui simplifie grandement la migration des articles déjà existants dans la base.
Plusieurs options s'offrent au développeur, mais celle qui m'avait apparut la plus simple, consistait à stocker les textes en UTF-8 dans la base de données; et lorsque le script PHP les récupérait, il pouvait les expédier directement au browser. Il faut noter que l'encodage des pages HTML doit être positionné sur UTF-8 comme indiqué ci-dessous:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr" dir="ltr">
Si cette solution fonctionne certainement, elle présente certaines limitations, et notament, l'impossibilité de mettre du texte UTF-8 directement dans les scripts PHP, c'est-à-dire, pouvoir faire un « print "Καλιμερα"; ».
Comment faut-il procédé pour que le site lui même soit entièrement codé en UTF-8. Il me paraissait que le simple fait de convertir mes fichiers codes sources PHP de ISO 8859 vers UTF-8 devrait faire l'affaire. A l'époque je travaillais encore sous Windows et mon éditeur de texte était Ultraedit.
Hélas, uploader l'ensemble des fichiers PHP une fois convertis, n'a pas créé — à ma grand surprise — l'effet désiré.
Des erreurs liées aux cookies sont apparut immédiatement. En investigant un peu plus, je me rendis compte qu'en réalité, des caractères avaient déjà été expédiés vers le browser alors même que les headers étaient toujours en cours de génération dans mes pages PHP.
Honnètement, ce problème m'a été difficile à comprendre, et de longues recherches sur le net ne m'ont absolument pas aidé à trouver ne serait-ce qu'une piste de résolution.
S'il semble que le support du multi-langues devient une préoccupation montante chez les développeurs, finalement, peu de litterature est réellement disponible.
Certains allant jusqu'à dire que faire tourner des fichiers PHP encodés UTF-8 sous Appache/PHP est en fait impossible, dû a un « bug » de PHP.
Il n'en est rien. La solution finalement est assez simple. Et elle est définitive.
L'encodage UTF-8 est en réalité, une façon de coder les caractères en attribuant moins d'octest aux caractères très utilisés et plus à ceux qui le sont moins. Et pour savoir qu'un fichier text est encodé comme celà, un marqueur est mis au début du fichier : c'est le fameux Byte Ordering Marker (ou BOM). En effet certains processeurs, comme les Intels, intervertisent l'odre des octets dans la mémoire (little endian), d'autres, les gèrent dans l'ordre naturel (big endian).
Hors, il se trouve que la présence de ce marqueur BOM provoque un problème à PHP. Le retirer suffit à régler le problème.
Pour ma part, j'ai depuis switché sous Mac OS X, et je travaille maintenant avec un iMac G5.
J'ai remplacé Ultraedit par TextWrangler. Ultraedit ne supporte pas la sauvegarde de fichiers texte sans BOM (NDLA: depuis, la version 11 le fait). TextWrangler le supporte.
Après avoir sauvé l'ensemble de mes scripts sans le BOM, puis uploadé sur le serveur, le problème fût enfin résolu.
Σδλ
My PHP WebSite natively supports UTF-8
Del.icio.us — updated on Nov. 22nd, 2005 13:54 exists for 7 years & 6 months ago — Rate:
— — Sorry, this content is not available in english.I initially developed my PHP Web Site using latin text encoding—the most famous ISO-8859-1. French accents as well as the cedilla are correctly handled with this encoding. Of course, the english version does not show any issue.
Things did began rude when I wantes to publish greek content —by the way, did I mentionned my ancestors comes from Minor-Asia? It's obvious to state that the best possibly encoding system to use for handling any alphabet is Unicode in general, and UTF-8 in particuliar. UTF-8 offers the unique advantage to be backward compatible with the english language: this greatly streamlines the effort required to migrate existing articles.
At this stage, many options are offered to the developer: To me, the most relevant one would be the one that does not require additional code to send the text to the browser once you fetch it from the database. You must make some intial settings in order for html to appropriately state it is handling UTF-8 content, as follows:
If we simply do that like this, you'll be disapointed, because you'll have to make the extra step to use the encode_utf() functions in your PHP scripts. What I want is to just print my text the same way I was doing in western-latin.
Then, how can we make that? In a first instance, I thought that I had to convert all my PHP files into UTF-8 encoding, and then just re-upload everything to my web server. At that time, I was still working from a windows machine and I was using Ultraedit.
Unfortunatelly, this was surprinsingly not working as expected: Cookie-related error was poping from my pages. Looking to that closer, it appeared that headers was sent to the browser AFTER the body was sent.
Honestly, I did not immediately understood what was the exact issue. I did try to find answers, visiting a lot of articles and mateiral all over the web... But nothing relevant.
I even found wrong explanations, and even one guy stating that it is impossible to do that in PHP because of a PHP bug!
Fortunately, there is a solution. And it is rather simple, I tell you:
UTF-8 encoding is a method of encoding Unicode chartacters depending on the rarety of itselft when compared to others. Most used caracters are coded in less bytes than the ones which appears rarely in texts. In order for computer to handle the resulting list on bytes, a special marker appear as the first two extra bytes in the file, called the Byte Order Marker (or BOM) wich tells what order to use when reading the bytes.
As PHP does not expect those bytes, it tries to render them as actual character, resulting in emitting their interpretaation to the browser. Hence, if you withdraw the BOM, PHP start decoding UTF bytes at the first, actual UTF letter!. This solves the issue.
Since that time, I 've switched to Mac OS X and now work on my iMac G5 with TextWrangler. TextWrangler dos support a special UTF encoding, called "UTF-8, no BOM". This is the perfect encoding pfor my PHP scipts.
In conclusion, once I saved all my files to that encoding, I just had to upload them to the server to finally make it a breathe to natively handle UTF-8 content.
Σδλ
Leave a comment | Reddit!Things did began rude when I wantes to publish greek content —by the way, did I mentionned my ancestors comes from Minor-Asia? It's obvious to state that the best possibly encoding system to use for handling any alphabet is Unicode in general, and UTF-8 in particuliar. UTF-8 offers the unique advantage to be backward compatible with the english language: this greatly streamlines the effort required to migrate existing articles.
At this stage, many options are offered to the developer: To me, the most relevant one would be the one that does not require additional code to send the text to the browser once you fetch it from the database. You must make some intial settings in order for html to appropriately state it is handling UTF-8 content, as follows:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr" dir="ltr">
If we simply do that like this, you'll be disapointed, because you'll have to make the extra step to use the encode_utf() functions in your PHP scripts. What I want is to just print my text the same way I was doing in western-latin.
Then, how can we make that? In a first instance, I thought that I had to convert all my PHP files into UTF-8 encoding, and then just re-upload everything to my web server. At that time, I was still working from a windows machine and I was using Ultraedit.
Unfortunatelly, this was surprinsingly not working as expected: Cookie-related error was poping from my pages. Looking to that closer, it appeared that headers was sent to the browser AFTER the body was sent.
Honestly, I did not immediately understood what was the exact issue. I did try to find answers, visiting a lot of articles and mateiral all over the web... But nothing relevant.
I even found wrong explanations, and even one guy stating that it is impossible to do that in PHP because of a PHP bug!
Fortunately, there is a solution. And it is rather simple, I tell you:
UTF-8 encoding is a method of encoding Unicode chartacters depending on the rarety of itselft when compared to others. Most used caracters are coded in less bytes than the ones which appears rarely in texts. In order for computer to handle the resulting list on bytes, a special marker appear as the first two extra bytes in the file, called the Byte Order Marker (or BOM) wich tells what order to use when reading the bytes.
As PHP does not expect those bytes, it tries to render them as actual character, resulting in emitting their interpretaation to the browser. Hence, if you withdraw the BOM, PHP start decoding UTF bytes at the first, actual UTF letter!. This solves the issue.
Since that time, I 've switched to Mac OS X and now work on my iMac G5 with TextWrangler. TextWrangler dos support a special UTF encoding, called "UTF-8, no BOM". This is the perfect encoding pfor my PHP scipts.
In conclusion, once I saved all my files to that encoding, I just had to upload them to the server to finally make it a breathe to natively handle UTF-8 content.
Σδλ
Comments
Be the first to leave a comment.
Community
|
|||
|---|---|---|---|
|
|||
|
Forums
|
|||
|
|||
|
Projects
|
|||
|
|||
|
Advertising
|
|||
|
|||
|
|||
This site supports AppleLeave a comment | Reddit!Ce site encourage AppleLeave a comment | Reddit! |
Copyright © 1994 ˜ 2012 dsei.biz / Stéphane de Luca — All Rights Reserved
