I didn't find this topic in the discussion history ... wonder what's the best practice in MySQL to store numeric numbers with plus minus signs (+/-), times sign such as in 2.328x10-15, such that they can be safely stored, easily handled/recognized by most current programs in perl/php/etc and
shown in modern web browsers.
My problem came from a practice developing a MySQL database since 20 years ago, when such numeric numbers are copied/pasted into MySQL via web forms and displayed well on web when retrieved back then. However in the following years these old data were started to be shown as with black
diamond squares or other types of partial-garbaged number.
Over 10+ years ago when these strange character showed up I can doggle for different character coding methods in a browser to view them. But nowadays all browsers are made "smart" as no longer
to provide these user options.
I understand this came along with different/evolving char coding methods; and the data we curated into the database over different times in history were with changing character (or language) settings. I wonder is there a good solution to bring them all to a current character safe environment, and kept safe for the future?
j
On 4/14/2023 4:22 PM, julian...@gmail.com wrote:Thank you Jerry for the heads up. Perhaps we should consider a catch on web forms for "illegal" characters and suggest fixes. Otherwise it was difficult to expect all to practice the same way.
I didn't find this topic in the discussion history ... wonder what's the best practice in MySQL to store numeric numbers with plus minus signs (+/-), times sign such as in 2.328x10-15, such that they can be safely stored, easily handled/recognized by most current programs in perl/php/etc and
shown in modern web browsers.
My problem came from a practice developing a MySQL database since 20 years ago, when such numeric numbers are copied/pasted into MySQL via web forms and displayed well on web when retrieved back then. However in the following years these old data were started to be shown as with black
diamond squares or other types of partial-garbaged number.
Over 10+ years ago when these strange character showed up I can doggle for different character coding methods in a browser to view them. But nowadays all browsers are made "smart" as no longer
to provide these user options.
I understand this came along with different/evolving char coding methods; and the data we curated into the database over different times in history were with changing character (or language) settings. I wonder is there a good solution to bring them all to a current character safe environment, and kept safe for the future?
jThe SQL standard states a plus sign is optional whereas a minus sign is required for negative numbers. Addtionally, the times sign is not
allowed. Instead, "E" is used, as in 2.328E-15.
This is standard in many programming languages, also.
And of course you store numeric values in a numeric type column.
Also, NEVER copy/paste from a web form when working with ANY database. ALWAYS validate the information before inserting to prevent SQL
injection exploits.
--
==================
Remove the "x"'s from my email address
Jerry Stuckle
stuckle...@gmail.com
==================
On Friday, April 14, 2023 at 5:55:23rC>PM UTC-5, Jerry Stuckle wrote:By the way what would be the way to store numbers with plus/minus sign (N++ or -# or U+00B1 or ±). THANKS!
On 4/14/2023 4:22 PM, julian...@gmail.com wrote:
I didn't find this topic in the discussion history ... wonder what's the best practice in MySQL to store numeric numbers with plus minus signs (+/-), times sign such as in 2.328x10-15, such that they can be safely stored, easily handled/recognized by most current programs in perl/php/etc and
shown in modern web browsers.
My problem came from a practice developing a MySQL database since 20 years ago, when such numeric numbers are copied/pasted into MySQL via web forms and displayed well on web when retrieved back then. However in the following years these old data were started to be shown as with black
diamond squares or other types of partial-garbaged number.
Over 10+ years ago when these strange character showed up I can doggle for different character coding methods in a browser to view them. But nowadays all browsers are made "smart" as no longer
to provide these user options.
I understand this came along with different/evolving char coding methods; and the data we curated into the database over different times in history were with changing character (or language) settings. I wonder is there a good solution to bring them all to a current character safe environment, and kept safe for the future?
jThe SQL standard states a plus sign is optional whereas a minus sign is required for negative numbers. Addtionally, the times sign is not
allowed. Instead, "E" is used, as in 2.328E-15.
This is standard in many programming languages, also.
And of course you store numeric values in a numeric type column.
Also, NEVER copy/paste from a web form when working with ANY database. ALWAYS validate the information before inserting to prevent SQL
injection exploits.
--Thank you Jerry for the heads up. Perhaps we should consider a catch on web forms for "illegal" characters and suggest fixes. Otherwise it was difficult to expect all to practice the same way.
==================
Remove the "x"'s from my email address
Jerry Stuckle
stuckle...@gmail.com
==================
On Friday, April 14, 2023 at 5:55:23rC>PM UTC-5, Jerry Stuckle wrote:
On 4/14/2023 4:22 PM, julian...@gmail.com wrote:Thank you Jerry for the heads up. Perhaps we should consider a catch on web forms for "illegal" characters and suggest fixes. Otherwise it was difficult to expect all to practice the same way.
I didn't find this topic in the discussion history ... wonder what's the best practice in MySQL to store numeric numbers with plus minus signs (+/-), times sign such as in 2.328x10-15, such that they can be safely stored, easily handled/recognized by most current programs in perl/php/etc andThe SQL standard states a plus sign is optional whereas a minus sign is
shown in modern web browsers.
My problem came from a practice developing a MySQL database since 20 years ago, when such numeric numbers are copied/pasted into MySQL via web forms and displayed well on web when retrieved back then. However in the following years these old data were started to be shown as with black
diamond squares or other types of partial-garbaged number.
Over 10+ years ago when these strange character showed up I can doggle for different character coding methods in a browser to view them. But nowadays all browsers are made "smart" as no longer
to provide these user options.
I understand this came along with different/evolving char coding methods; and the data we curated into the database over different times in history were with changing character (or language) settings. I wonder is there a good solution to bring them all to a current character safe environment, and kept safe for the future?
j
required for negative numbers. Addtionally, the times sign is not
allowed. Instead, "E" is used, as in 2.328E-15.
This is standard in many programming languages, also.
And of course you store numeric values in a numeric type column.
Also, NEVER copy/paste from a web form when working with ANY database.
ALWAYS validate the information before inserting to prevent SQL
injection exploits.
--
==================
Remove the "x"'s from my email address
Jerry Stuckle
stuckle...@gmail.com
==================
On Saturday, April 15, 2023 at 4:11:11rC>PM UTC-5, julian...@gmail.com wrote:
On Friday, April 14, 2023 at 5:55:23rC>PM UTC-5, Jerry Stuckle wrote:
On 4/14/2023 4:22 PM, julian...@gmail.com wrote:Thank you Jerry for the heads up. Perhaps we should consider a catch on web forms for "illegal" characters and suggest fixes. Otherwise it was difficult to expect all to practice the same way.
I didn't find this topic in the discussion history ... wonder what's the best practice in MySQL to store numeric numbers with plus minus signs (+/-), times sign such as in 2.328x10-15, such that they can be safely stored, easily handled/recognized by most current programs in perl/php/etc andThe SQL standard states a plus sign is optional whereas a minus sign is
shown in modern web browsers.
My problem came from a practice developing a MySQL database since 20 years ago, when such numeric numbers are copied/pasted into MySQL via web forms and displayed well on web when retrieved back then. However in the following years these old data were started to be shown as with black
diamond squares or other types of partial-garbaged number.
Over 10+ years ago when these strange character showed up I can doggle for different character coding methods in a browser to view them. But nowadays all browsers are made "smart" as no longer
to provide these user options.
I understand this came along with different/evolving char coding methods; and the data we curated into the database over different times in history were with changing character (or language) settings. I wonder is there a good solution to bring them all to a current character safe environment, and kept safe for the future?
j
required for negative numbers. Addtionally, the times sign is not
allowed. Instead, "E" is used, as in 2.328E-15.
This is standard in many programming languages, also.
And of course you store numeric values in a numeric type column.
Also, NEVER copy/paste from a web form when working with ANY database.
ALWAYS validate the information before inserting to prevent SQL
injection exploits.
--
==================
Remove the "x"'s from my email address
Jerry Stuckle
stuckle...@gmail.com
==================
By the way what would be the way to store numbers with plus/minus sign (N++ or -# or U+00B1 or ±). THANKS!
By the way what would be the way to store numbers with plus/minus sign (N++ or -# or U+00B1 or ±). THANKS!
On 4/15/23 23:23, julian...@gmail.com wrote:Thank you Jerry and Aho! It's much appreciated for you to point me to a right direction.
By the way what would be the way to store numbers with plus/minus sign (N++ or -# or U+00B1 or ±). THANKS!You need to see to using the right charset and that it's the same on the front end as in database.
--
//Aho
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 63 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 492975:39:25 |
| Calls: | 840 |
| Files: | 1,301 |
| D/L today: |
16 files (28,385K bytes) |
| Messages: | 264,959 |