前言

下面的回答考虑了OP提出的这个（目前已关闭）随访问题...... "How to process price / currency strings in a database safe way?"。
为了绕过OP的ASCII限制，所有货币符号/字符都以unicode转义形式提供，但仅在必要时提供。

方法/解决方案

除了已经提供的另一线程的解决方案之外，还有另一种可能的实现，其使用Map示例以获得更好的查找性能，其中货币值确实用作（查找）密钥。
解析为货币部分和尚未完全验证的数字部分是基于一个正则表达式，该正则表达式部分地利用了unicode转义的Symbol类别以及命名捕获组和alternation，后者支持两种成本-价值变量，即...

• 前导货币值和尾随数字值
• 或者前导数字值和尾随货币值。

模式如下...

/^(?<currency_before>[A-Z]{3}|(?:(?:[A-Z]{2}\s*)?\p{S}))\s*(?<value_after>[\d.,]+)|(?<value_before>[\d.,]+)\s*(?<currency_after>[A-Z]{3}|(?:(?:[A-Z]{2}\s*)?\p{S}))$/u

...并得到described at the related test-page。
以前更严格的模式专门针对货币符号，看起来像这样...

/(?<symbol_before>\p{S})\s*(?<value_after>[\d.,]+)|(?<value_before>[\d.,]+)\s*(?<symbol_after>\p{S})/u

...并得到described at its related test-page。
潜在的数字值可以用逗号作为千位分隔符和一个可选的点作为小数点，或者用一个点作为千位分隔符和一个可选的逗号作为小数点（例如德国的方式）。

/^(?:(?<integer>\d+$)|(?<dot_surrogate>(\d+)?[.,]\d+$)|(?<thousands_dot>\d{1,3}\.(?:\d{3}[.,])+\d+$)|(?<thousands_comma>\d{1,3},(?:\d{3}[.,])+\d+$))/

...其中description can be read at its related test-page.

示例代码

一个三个三个一个