On 07-Jul-01 Michael Collins wrote:
> I understand that any ASCII character can be stored within any of the
> non-numeric type fields. Does this mean just characters 1-255?
>
> What happens if I try to import a non-ASCII character, let say, into
> a VARCHAR field? Is it discarded or will I simply not be able to get
> into a MySQL field in the first place?
>
CHAR & TEXT will store multi-byte characters store just fine once
you quote them.
but select & compare(s) will break if you don't use one of the BLOB types
> In addition, do all of the following need to be escaped before being
> insert into a database?
>
> \0 An ASCII 0 (NUL) character
> \n A newline character
> \t A tab character
> \r A carriage return character
> \b A backspace character
> \' A single quote (`'') character
> \" A double quote (`"') character
> \\ A backslash (`\') character
> \% A `%' character (this is used to search for literal instances of
> `%' in contexts where `%' would otherwise be interpreted as a
> wild-card character)
> \_ A `_' character (this is used to search for literal instances of
> `_' in contexts where `_' would otherwise be interpreted as a
> wild-card character)
>
Note: The wild-cards only have to be escaped in the search criterion
for the select ... where ...
Every possible 256 byte values can be stored.
The input & display of the data is where things get sticky.
In a "raw" interface how do you indicate to the program where to
stop input & start proccessing ?
Is the backspace to be stored, or did you make a mistake ?
And how can you tell there was a backspace if it was stored ?
The \b & 0x8 notation is a convienient way to enter and display,
but not store, the special characters
The lower 32 ASCII values were(are) called control characters
because they control device specific things:
CTRL+H = \b = 0x8 = ASCII BS => back space (&overstrike) 1 char
CTRL+G = \a = 0x7 = BEL => ring the out-of-paper bell.
CTRL+L = \f = 0x0c = NP => top of form to next page.
Very paper & Tty 33 oriented ...
Anyway, what is in the database & how it's displayed is entirely
up to the interface you use.
> In other words, am I correct that none of these characters can be
> stored in a MySQL string field (such as CHAR, VARCHAR, or TEXT)?
No, you are confused about presentation & storage.
Regards,
--
Don Read [EMAIL PROTECTED]
-- It's always darkest before the dawn. So if you are going to
steal the neighbor's newspaper, that's the time to do it.
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
