php-general Digest 11 Oct 2009 14:42:06 -0000 Issue 6385

Topics (messages 298830 through 298835):

Re: Native support to MS SQL Server
        298830 by: Raymond Irving

utf8_decode() and mixed character sets
        298831 by: James Colannino
        298832 by: Andrew Ballard
        298833 by: James Colannino

Re: How do YOU set default function/method params?
        298834 by: Stephan Ebelt

PHP function unpack
        298835 by: Gabriel Hahmann

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------
--- Begin Message ---

--- On Fri, 10/9/09, Ashley Sheridan <a...@ashleysheridan.co.uk> wrote:

Would this be a good time to troll about the virtues of MySQL over
MSSQL? :p

I would like to tell some clients and users to switch to MySQL but the problem 
is that they have already invested in MSSQL and have other systems that are 
built with MSSQL.

It would be wise of MS to make compatible drivers that works with PHP as more 
and more apps are being built for MySQL. The lack of a proper  (PDO) driver can 
cause devlopers to not build software solutions for MSSQL.


--- End Message ---
--- Begin Message ---
Hey everyone.  I'd been troubled for a while by the fact that inserting
cut-pasted special characters such as &auml; caused truncation when passed to
MySQL, then discovered that it was because I was cutting and pasting unicode
values into non-unicode Latin-1 strings.

Since Latin-1 also has equivalent values, I was hoping that filtering my mixed
unicode/non-unicode string through utf8_decode() would solve the problem, but
instead, where the unicode character used to be, I now get a '?', followed by a
few characters being taken out of the middle.  I'm guessing that this is because
utf8_decode() assumes the whole string is unicode and therefore removes a bunch
of extra bytes from the string and corrupts it.  At least, that's my guess.  I
could be very wrong (I have pretty much no experience with different character
sets...)

My question is, what's a good way to translate unicode characters in a
non-unicode string to their Latin-1 equivalents?  I need to be able to do this
in order to sanitize a fairly common form of input.

Thanks!

James

--- End Message ---
--- Begin Message ---
On Sat, Oct 10, 2009 at 11:40 PM, James Colannino <ja...@colannino.org> wrote:
>
> Hey everyone.  I'd been troubled for a while by the fact that inserting
> cut-pasted special characters such as &auml; caused truncation when passed to
> MySQL, then discovered that it was because I was cutting and pasting unicode
> values into non-unicode Latin-1 strings.
>
> Since Latin-1 also has equivalent values, I was hoping that filtering my mixed
> unicode/non-unicode string through utf8_decode() would solve the problem, but
> instead, where the unicode character used to be, I now get a '?', followed by 
> a
> few characters being taken out of the middle.  I'm guessing that this is 
> because
> utf8_decode() assumes the whole string is unicode and therefore removes a 
> bunch
> of extra bytes from the string and corrupts it.  At least, that's my guess.  I
> could be very wrong (I have pretty much no experience with different character
> sets...)
>
> My question is, what's a good way to translate unicode characters in a
> non-unicode string to their Latin-1 equivalents?  I need to be able to do this
> in order to sanitize a fairly common form of input.
>
> Thanks!
>
> James
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Have you tried iconv or mb_string? Is it a  option to update the
database to use UTF-8?

Andrew

--- End Message ---
--- Begin Message ---
Andrew Ballard wrote:

> Have you tried iconv or mb_string? Is it a  option to update the
> database to use UTF-8?

I'll look into those functions.  And, I suppose I could in fact convert my
database to use UTF-8 if necessary.

James

--- End Message ---
--- Begin Message ---
On Mon, Oct 05, 2009 at 05:48:32PM -0700, Jim Lucas wrote:
> Here is a problem that I have had for years now.  I have been trying to come 
> up
> with the perfect solution for this problem.  But, I have come down to two
> different methods for solving it.
> 
> Here is the problem...

[...]

> 
> Now, we all have a function or method like this floating around somewhere.
> 
> My question is, how do YOU go about setting the required entries of the 
> $headers
> array() ?
> 

[...]

> 
> END of examples...
> 
> Now, IMO, the last one is the simplest one and for me, I think it will be the
> new way that I solve this type of problem.
> 
> But, my question that I put out to all of you is...
> 
>       How would you solve this problem?

I have use this array_merge() approach mentioned in other posts for
quite some time but found that it introduced many bugs when fieldnames changed.
Ie. if the defaults come from a database table and I changed the schema it
caused undefined values during the merging and - worse - sometimes messed up the
inner workings of functions...

Then I heard of the "value object" approach somewhere and found that much more
solid. One would basically define a class where default values are represented
by its properties. Ie:

class vo_email extends vo {
        public $to = '';
        public $from = '';
        public $subject = '(no subject)';
        public $body = '';
        ...
}

the constructor can make sure that absolutly necessary values are required and
set properly - and could complain if something is not right. There could be
methods that add() or set() or change() things. These could also be inherited
from a very generic class "vo" so that this stuff is written once and applies
to all sorts of defaults in the program.
In my app the inherited constructor accepts arrays as parameter and assigns
their elements to the object properties and - by that - overwrites the default
settings. If elements do not match with the defined properties it will trigger
a very visible call trace.

A function like sendEmail() would then require a object of type vo_email as
parameter and would work with its properties internally and can rely on it as
the vo's constructor should have catched anything bad.

If additional logic for the input values is required, it can be added easily:

class dao_email extends vo_email {
        ...
        public function encode_body() {
                ...
        }

        public function sanitize_mail_address() {

        }
        ...
}

sendEmail() would then require a dao_email object (dao=data access object) as
input.

stephan

> 
> TIA
> 
> Jim Lucas
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php

--- End Message ---
--- Begin Message ---
Hi,

I'm new to the list and I've search internet and didn't find an answer
to my problem.

I'm converting a perl script to PHP and I've done almost everything.
The only part of the code that I didn't get working on PHP was:

(PERL CODE)
foreach ($b_length,$b_mac,$b_crlf,$b_crlf,$a_body) {
        $d_checksum += unpack("%16n*", $_);
}

The idea is to make a 16-bit checksum of all elements
($b_length,$b_mac,$b_crlf,$b_crlf,$a_body).

I'm tried translating the code to:

$arr_checksum = array($b_length,$b_mac,$b_crlf,$b_crlf,$File_Content);

$d_checksum = 0;
foreach($arr_checksum as $check_elem){
        $d_check = unpack("n*", $check_elem);
        for ($i=0;$i<4;$i++){
                $d_checksum += $d_check["$i"];
        }
}

But the result is different. I know that unpack in perl and php are
different, but I cant find a way to translate the format %16n* of perl
to php and generate a 16-bit checksum.

Any help will be appreciated.

[]'s
Gabriel.

--- End Message ---

Reply via email to