Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.databases.mysql > #7651 > unrolled thread
| Started by | "julian...@gmail.com" <juliani.moon@gmail.com> |
|---|---|
| First post | 2023-04-14 13:22 -0700 |
| Last post | 2023-04-15 21:08 -0400 |
| Articles | 8 — 3 participants |
Back to article view | Back to comp.databases.mysql
store numeric numbers with plus minus signs "julian...@gmail.com" <juliani.moon@gmail.com> - 2023-04-14 13:22 -0700
Re: store numeric numbers with plus minus signs Jerry Stuckle <stuckle.jerry@gmail.com> - 2023-04-14 18:54 -0400
Re: store numeric numbers with plus minus signs "julian...@gmail.com" <juliani.moon@gmail.com> - 2023-04-15 14:11 -0700
Re: store numeric numbers with plus minus signs "julian...@gmail.com" <juliani.moon@gmail.com> - 2023-04-15 14:23 -0700
Re: store numeric numbers with plus minus signs Jerry Stuckle <stuckle.jerry@gmail.com> - 2023-04-15 21:15 -0400
Re: store numeric numbers with plus minus signs "J.O. Aho" <user@example.net> - 2023-04-16 12:00 +0200
Re: store numeric numbers with plus minus signs "julian...@gmail.com" <juliani.moon@gmail.com> - 2023-04-20 08:20 -0700
Re: store numeric numbers with plus minus signs Jerry Stuckle <stuckle.jerry@gmail.com> - 2023-04-15 21:08 -0400
| From | "julian...@gmail.com" <juliani.moon@gmail.com> |
|---|---|
| Date | 2023-04-14 13:22 -0700 |
| Subject | store numeric numbers with plus minus signs |
| Message-ID | <e25c8a41-7cc3-410b-89b6-317b11694eacn@googlegroups.com> |
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
[toc] | [next] | [standalone]
| From | Jerry Stuckle <stuckle.jerry@gmail.com> |
|---|---|
| Date | 2023-04-14 18:54 -0400 |
| Message-ID | <u1clkn$1n7lt$1@jstuckle.eternal-september.org> |
| In reply to | #7651 |
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? > > j The 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 stucklex.jerryx@gmail.com ==================
[toc] | [prev] | [next] | [standalone]
| From | "julian...@gmail.com" <juliani.moon@gmail.com> |
|---|---|
| Date | 2023-04-15 14:11 -0700 |
| Message-ID | <8fefe2ed-82c9-4684-aa5d-6ba4ebdc071bn@googlegroups.com> |
| In reply to | #7652 |
On Friday, April 14, 2023 at 5:55:23 PM UTC-5, Jerry Stuckle wrote: > 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? > > > > j > The 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 > ================== 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.
[toc] | [prev] | [next] | [standalone]
| From | "julian...@gmail.com" <juliani.moon@gmail.com> |
|---|---|
| Date | 2023-04-15 14:23 -0700 |
| Message-ID | <14f4e80d-b7e6-47fa-85d6-0a17026c8fe0n@googlegroups.com> |
| In reply to | #7653 |
On Saturday, April 15, 2023 at 4:11:11 PM UTC-5, julian...@gmail.com wrote: > On Friday, April 14, 2023 at 5:55:23 PM UTC-5, Jerry Stuckle wrote: > > 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? > > > > > > j > > The 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 > > ================== > 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. By the way what would be the way to store numbers with plus/minus sign (� or ± or U+00B1 or ±). THANKS!
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <stuckle.jerry@gmail.com> |
|---|---|
| Date | 2023-04-15 21:15 -0400 |
| Message-ID | <u1fi9g$289hf$2@jstuckle.eternal-september.org> |
| In reply to | #7654 |
On 4/15/2023 5:23 PM, julian...@gmail.com wrote: > On Saturday, April 15, 2023 at 4:11:11 PM UTC-5, julian...@gmail.com wrote: >> On Friday, April 14, 2023 at 5:55:23 PM UTC-5, Jerry Stuckle wrote: >>> 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? >>>> >>>> j >>> The 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 >>> ================== >> 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. > > By the way what would be the way to store numbers with plus/minus sign (� or ± or U+00B1 or ±). THANKS! You need to ensure your database uses a charset that accepts those characters. -- ================== Remove the "x"'s from my email address Jerry Stuckle stucklex.jerryx@gmail.com ==================
[toc] | [prev] | [next] | [standalone]
| From | "J.O. Aho" <user@example.net> |
|---|---|
| Date | 2023-04-16 12:00 +0200 |
| Message-ID | <ka1vaqF1d6eU2@mid.individual.net> |
| In reply to | #7654 |
On 4/15/23 23:23, julian...@gmail.com wrote: > By the way what would be the way to store numbers with plus/minus sign (� 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
[toc] | [prev] | [next] | [standalone]
| From | "julian...@gmail.com" <juliani.moon@gmail.com> |
|---|---|
| Date | 2023-04-20 08:20 -0700 |
| Message-ID | <c2ad92fa-cda6-49bb-8a83-1fcf4fd6a50an@googlegroups.com> |
| In reply to | #7657 |
On Sunday, April 16, 2023 at 5:01:02 AM UTC-5, J.O. Aho wrote: > On 4/15/23 23:23, julian...@gmail.com wrote: > > > By the way what would be the way to store numbers with plus/minus sign (� 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 Thank you Jerry and Aho! It's much appreciated for you to point me to a right direction.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <stuckle.jerry@gmail.com> |
|---|---|
| Date | 2023-04-15 21:08 -0400 |
| Message-ID | <u1fhsi$289hf$1@jstuckle.eternal-september.org> |
| In reply to | #7653 |
On 4/15/2023 5:11 PM, julian...@gmail.com wrote: > On Friday, April 14, 2023 at 5:55:23 PM UTC-5, Jerry Stuckle wrote: >> 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? >>> >>> j >> The 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 >> ================== > 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. You should ALWAYS validate ALL data before allowing it to be used in a SQL statement. Failure to do so is a major security exposure. And you can set rules so that everyone does it the same way. -- ================== Remove the "x"'s from my email address Jerry Stuckle stucklex.jerryx@gmail.com ==================
[toc] | [prev] | [standalone]
Back to top | Article view | comp.databases.mysql
csiph-web