Tom Worster wrote:
Because, I thought, HTML files were basically just text files with
different file extensions, and that those other characters would not
store or display properly if saved in .txt format. Was I mistaken?
yes. see http://www.w3.org/TR/html401/charset.html
which says that html
The consensus seems to be that the proposed "ifset()" and "ifempty()"
functions are more effort than they are worth. What I'd like to know
is, why "empty()" still exists when every time I turn around, the
mentors I turn to locally tell me not to use it, to use "isset()"
instead. Because empty()
On 4/30/09 6:15 PM, "Reese" wrote:
> Tom Worster wrote:
>
>> why use SGML character entity references in a utf-8 file or stream? can't
>> you just put the character in the file?
>
> Because, I thought, HTML files were basically just text files with
> different file extensions, and that those ot
It'd be a hassle to just remove a function from a language, I suppose...
On Thu, Apr 30, 2009 at 6:15 PM, Reese wrote:
> Tom Worster wrote:
>
>> why use SGML character entity references in a utf-8 file or stream? can't
>> you just put the character in the file?
>
> Because, I thought, HTML files
Tom Worster wrote:
why use SGML character entity references in a utf-8 file or stream? can't
you just put the character in the file?
Because, I thought, HTML files were basically just text files with
different file extensions, and that those other characters would not
store or display properly
On 4/29/09 6:52 PM, "Reese" wrote:
> Tom Worster wrote:
>> On 4/28/09 4:05 PM, "Reese" wrote:
>>
>>> Granted, this isn't a PHP question but I'm curious, how does UTF-8 solve
>>> this display issue?
>>
>> if we're talking about web browsers, they are quite good at automatically
>> choosing font
Tom Worster wrote:
On 4/28/09 4:05 PM, "Reese" wrote:
Granted, this isn't a PHP question but I'm curious, how does UTF-8 solve
this display issue?
if we're talking about web browsers, they are quite good at automatically
choosing fonts that can display the unicode characters it finds in a pa
On 4/28/09 4:05 PM, "Reese" wrote:
> Granted, this isn't a PHP question but I'm curious, how does UTF-8 solve
> this display issue?
if we're talking about web browsers, they are quite good at automatically
choosing fonts that can display the unicode characters it finds in a page.
--
PHP Gene
Tom Worster wrote:
On 4/27/09 4:25 PM, "PJ" wrote:
Exactly what are the advantages of using utf-8? How will it solve my
problem?
actually, i have no idea because i have no idea what problem you are trying
to solve and i apologize for presumptuous. i presumed that you have a php
app with a bu
PJ wrote:
Tom Worster wrote:
On 4/27/09 4:25 PM, "PJ" wrote:
Exactly what are the advantages of using utf-8? How will it solve my
problem?
actually, i have no idea because i have no idea what problem you are trying
to solve and i apologize for presumptuous. i presumed that you have a
Tom Worster wrote:
> On 4/27/09 4:25 PM, "PJ" wrote:
>
>
>> Exactly what are the advantages of using utf-8? How will it solve my
>> problem?
>>
>
> actually, i have no idea because i have no idea what problem you are trying
> to solve and i apologize for presumptuous. i presumed that you h
On 4/27/09 4:25 PM, "PJ" wrote:
> Exactly what are the advantages of using utf-8? How will it solve my
> problem?
actually, i have no idea because i have no idea what problem you are trying
to solve and i apologize for presumptuous. i presumed that you have a php
app with a bunch of data in mysq
Tom Worster wrote:
> On 4/27/09 9:55 AM, "PJ" wrote:
>
>> Since I have to use a number of Western languages that have those
>> annoying accents on many characters, I am already finding some
>> annoyances in my code results; like having to enter the á type of
>> stuff in inputs for searches & queri
On 4/27/09 9:55 AM, "PJ" wrote:
> Since I have to use a number of Western languages that have those
> annoying accents on many characters, I am already finding some
> annoyances in my code results; like having to enter the á type of
> stuff in inputs for searches & queries.
the sooner you quit t
I think you should switch to utf8-general-ci all the way.
haliphax wrote:
On Mon, Mar 30, 2009 at 12:34 PM, Merlin Morgenstern
wrote:
HI there,
I now compiled php with zend multibyte. The trouble with the extra
characters is now gone, but all special characters are now replaced with a
questionmark! The document type shows utf-8, but somehow php seems
On Mon, Mar 30, 2009 at 12:34 PM, Merlin Morgenstern
wrote:
> HI there,
>
> I now compiled php with zend multibyte. The trouble with the extra
> characters is now gone, but all special characters are now replaced with a
> questionmark! The document type shows utf-8, but somehow php seems not to
>
On 3/26/09 11:36 AM, "Nisse Engström" wrote:
> On Wed, 25 Mar 2009 11:32:42 +0100, Nisse Engström wrote:
>
>> On Tue, 24 Mar 2009 08:15:35 -0400, Tom Worster wrote:
>>
>>> strtr() with three parameters is certainly unsafe. but my tests are showing
>>> that it may be ok with two parameters if th
On Wed, 25 Mar 2009 11:32:42 +0100, Nisse Engström wrote:
> On Tue, 24 Mar 2009 08:15:35 -0400, Tom Worster wrote:
>
>> strtr() with three parameters is certainly unsafe. but my tests are showing
>> that it may be ok with two parameters if the strings in the second parameter
>> are well formed ut
thanks for the info.
i'll leave 2-param uses of strtr in my code alone. i have a replacement for
the 3-param version.
btw: i have quite a long checklist of stuff to do when upgrading code for
utf-8, including notes on about 100 functions. do you think it would be
worth putting it on a wiki somewh
On Tue, 24 Mar 2009 08:15:35 -0400, Tom Worster wrote:
> On 3/23/09 2:02 PM, "Tom Worster" wrote:
>
>> i havea general replacement or workaround for every php function in my code
>> that i know to be utf-8-unsafe. except one: strtr().
>
> strtr() with three parameters is certainly unsafe. but m
On 3/23/09 2:02 PM, "Tom Worster" wrote:
> i havea general replacement or workaround for every php function in my code
> that i know to be utf-8-unsafe. except one: strtr().
strtr() with three parameters is certainly unsafe. but my tests are showing
that it may be ok with two parameters if the s
you don't have to have your files in utf-8 for it to work, just the
browser header.
although any utf-8 characters in your files will look funky. it just
depends where the content comes from... you could always use ®
for the (r) registered symbol for example.
i'd be more apt to figuring out how to
the user agents in question are various mobile phones, which as you
might guess are premature technology and have their own ways with
things.
here is an example posting from a Samsung D600 which insists on
posting form data in UTF-8 even though i serve it ISO-8859-1 and it
claims to support all ch
On Jan 8, 2008 1:31 PM, tedd <[EMAIL PROTECTED]> wrote:
> Last night I read a chapter in the book "Core Web Application
> Development with PHP and MYSQL" by Wandschneider who said basically
> that -- a good read, btw.
I'm guess it was his name which comprised the first chapter.
--
Daniel P.
At 11:57 AM +0200 1/8/08, Arvids Godjuks wrote:
To author:
You'r going the wrong way.
Make your page utf-8, all text on it. Set utf-8 encoding and treat all
incoming data as UTF-8. If some agent (definetly not some browser - they all
know UTF-8) doesn't understand that (that could be some "hacke
Olav Mørkrid wrote:
> i specify iso-8859-1 in both header and body:
>
> accept-charset="iso-8859-1">
Have you checked 1) what the webserver sends in the header and 2) what
the browser actually uses? I'm pretty certain I've had issues where
the meta tags were fine, but the server overrode me s
To author:
You'r going the wrong way.
Make your page utf-8, all text on it. Set utf-8 encoding and treat all
incoming data as UTF-8. If some agent (definetly not some browser - they all
know UTF-8) doesn't understand that (that could be some "hacker" writing
it's own bot) - that's his problem. The
Olav Mørkrid wrote:
i specify iso-8859-1 in both header and body:
if two different people post the norwegian phrase "Godt nytt år"
(happy new year), it may appear in the following variations:
[CONTENT_TYPE] => application/x-www-form-urlencoded;charset=iso-8859-1
$_POST["input"] = "Godt nytt
I have to ask... WHY are you forcing ISO-8859-1? If anything, you should be
forcing UTF-8. Then you can send, receive, and store data in UTF-8 ad cover
most human languages without having to change character set.
On Monday 07 January 2008, Olav Mørkrid wrote:
> i specify iso-8859-1 in both h
maybe look at iconv functions
but the content-type is the only thing i set, and it works 100%
fine. all javascripts, forms, etc. inherit it from the looks of it
properly.
On 1/7/08, Olav Mørkrid <[EMAIL PROTECTED]> wrote:
> i specify iso-8859-1 in both header and body:
>
>
>
>
> if two differe
i specify iso-8859-1 in both header and body:
if two different people post the norwegian phrase "Godt nytt år"
(happy new year), it may appear in the following variations:
[CONTENT_TYPE] => application/x-www-form-urlencoded;charset=iso-8859-1
$_POST["input"] = "Godt nytt år"
[CONTENT_TYPE] =>
>
>
> My experience is that this does not affect only the displayed
> characters, but the way the form fields are transported.
>
> But perhaps I am wrong,
> Iv
This works for me as well.
Put in utf-8 and you should be good to go.
You don't -technically- need to even change your database fields
Olav Mørkrid wrote:
hello
does php have any built-in functions to convert post data from
whatever format it arrives in to whatever format i wish?
example:
i use iso-8859-1 internally, and even specify
accept-charset=iso-8859-1 in my html, but some browsers (phones) send
utf-8 anyway.
do i hav
Yes it will, trim() was given the option to specify other characters in
PHP 4.1.0.
Rember that it's a byte function, so single byte characters can be
handled, you just can't use it for multi-byte characters.
~ DM
Naz Gassiep escreveu:
Great! Thanks for the answer, that's very helpful. Will
Great! Thanks for the answer, that's very helpful. Will trim() work if I
specify charlists in the ASCII range? Not that I ever do, but just curious.
- Naz
Daniel Macedo wrote:
Hi Naz,
Any byte function is NOT safe for UTF-8.
trim() works properly with UTF-8 IF you don't specify the charlist
(
Hi Naz,
Any byte function is NOT safe for UTF-8.
trim() works properly with UTF-8 IF you don't specify the charlist
(second argument). This is because all whitespace characters are in the
ASCII range, and therefore it won't corrupt the UTF-8 string.
The explode() function will handle UTF-8 as
I've seen that, there is no mb_trim() that I can see.
- Naz.
adel wrote:
http://www.php.net/manual/en/ref.mbstring.php
On 8/3/07, Naz Gassiep <[EMAIL PROTECTED]> wrote:
The functions trim() and explode() appear to be munging multibyte UTF-8
strings. I can't find multibyte safe versions of t
http://www.php.net/manual/en/ref.mbstring.php
On 8/3/07, Naz Gassiep <[EMAIL PROTECTED]> wrote:
> The functions trim() and explode() appear to be munging multibyte UTF-8
> strings. I can't find multibyte safe versions of them in the manual, do
> they exist, or do I have to make my own?
> - Naz.
>
Naz Gassiep wrote:
The functions trim() and explode() appear to be munging multibyte
UTF-8 strings. I can't find multibyte safe versions of them in the
manual, do they exist, or do I have to make my own?
In what way are they munging the strings? I just tried with a bunch of
UTF-8 characters p
I'm somewhat new to this stuff as well, so take this with a grain of salt...
Someone else was hinting at this, but more directly, try running
utf8_encode() on whatever part of your data that requires utf8 encoding.
In the case of your example, you could just utf8_encode the test get
variable.
nt'l: +7 8362-468693
email:[EMAIL PROTECTED]
> -Original Message-
> From: Curt Zirzow [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 23, 2005 9:02 AM
> To: php-general@lists.php.net
> Subject: Re: [PHP] utf-8 in mysql but not outputting as utf-8 on web
>
>
On Thu, Dec 22, 2005 at 07:01:07PM -0800, jonathan wrote:
> I'm inserting some info into a mysql table which has the charset set
> to utf-8.
>
> When I do a select via the command-line from mysql, it looks like this:
> Clams and mussels with Dijon-cr�me fra�che-saffron sauce
>
> assuming this i
Have you read this article - http://www.phparch.com/sample.php?mid=57 .
jonathan wrote:
I'm inserting some info into a mysql table which has the charset set to
utf-8.
When I do a select via the command-line from mysql, it looks like this:
Clams and mussels with Dijon-crème fraîche-saffron sa
Hello,
why not simply convert the text to html
mb_convert_encoding($string, 'html', 'utf-8');
Best regards,
Kenneth
jonathan wrote:
I'm inserting some info into a mysql table which has the charset set
to utf-8.
When I do a select via the command-line from mysql, it looks like this:
Clam
v0id null wrote:
So, I have to handle data that is UTF-16 encoded. No ifs ands or buts.
Network messages on the service I'm communicating with sends and
recieves UTF-16 encoded strings only.
After taking a look at the Multibyte String functions, I don't know
how much they will help me, though chara
--- Jiøí Nìmec <[EMAIL PROTECTED]> wrote:
> I have problem with encoding UTF-8 and PHP scripts. Scripts send
> information about encoding and this disallow send HTTP headers. Is
> possibility to solve this problem?
I don't understand your question, but maybe this will help.
HTTP is encoded with I
Hello Jiri,
I'm not sure I understand your problem (I had some trouble with your English), but
have
you tried PHP's utf8_encode() and utf8_decode() functions? Check out the PHP manual
in your native language for more information on these functions.
Cheers,
Erik
On 15 Jan 2004 at 12:52, Ji ¡
On Thursday 15 January 2004 19:52, JiÅÃ NÄmec wrote:
> I have problem with encoding UTF-8 and PHP scripts. Scripts send
> information about encoding and this disallow send HTTP headers. Is
> possibility to solve this problem?
If I understand your problem correctly, the solution is to arrange your
There are 2 separate extenssions - iconv and recode
Michael Mulligan wrote:
Hi
So say I have some UTF-8 (not certain, but probably in UTF-8 format, I need
to check some more) encoded text. The text comes in encoded already, so it's
not an htmlspecialchars kind of quick fix. For instance, I get '
On Wed, 22 May 2002, Miguel Cruz wrote:
> For detection of encoding, perhaps you could include a hidden field with
> some shibboleth characters. Research how they are transformed by various
> encodings, and then just look at them to figure out what for that the rest
> of the data is in.
Yes,
For detection of encoding, perhaps you could include a hidden field with
some shibboleth characters. Research how they are transformed by various
encodings, and then just look at them to figure out what for that the rest
of the data is in.
miguel
On Wed, 22 May 2002, Peter Johansson wrote:
>
> Is there any UTF-8 r UTF-32 compatibility in PHP? I want to be
> multinational with the SAME scripts, not a dozen. I haven't tried
> anything yet, just asking
I forgot to mention what you are asking. There is a experimental module called
iconv, I guess it does UTF-8 conversions. Or if you can r
Hello Dennis,
It seems what you need is gettext/recode module to me. How about read PHP manul
for these moduels?
Anyway, XML should use UTF-8 for charset and you should be able to use UTF-8 w/o
any problems in your script and html, too.
> Is there any UTF-8 r UTF-32 compatibility in PHP? I want
54 matches
Mail list logo
