Unicode U202D 和 U202C 问题总结

最新推荐文章于 2023-12-06 14:36:57 发布
原创 最新推荐文章于 2023-12-06 14:36:57 发布 · 2.2k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#python

在Win10计算器培训中遇到问题，计算结果字符串长度异常，发现存在不可见字符U202D和U202C。这两个Unicode字符导致字符串比较异常，影响自动化处理。通过二进制查看和Unicode查询，了解到其为方向格式化字符，研究其在自动化中的影响。

最近给新人培训的过程中, 在win10的计算器上遇到了一个小问题, 当时本来以为5分钟能给解决, 结果研究了2个小时才找到root cause, 总结一下当时的思路.

环境: Win10 ent x64 21H1

打开计算器, 获取计算结果的文本后, 与预期进行比较, 结果比较总是不会进到 IF里, 明明两个变量都是同样的数字.

刚开始看到这个问题, 我以为是计算器文本中带了 CR/LF/TAB 这类字符串, 便想到了remove前后的特殊字符, 无果.

之后比较了一下获取到的字符串的长度, 明明是一个三位数, 但是string length 竟然是5, 由此便想到放到二进制中查看一下.

 查看发现, 从计算器结果框中取到的值, 多了一个 '- '的字符.

这下就好判断了, 用unicode查看一下取到的变量, 发现获取到的变量中, 是两个不可见字符, U202C 和 U202D.

查了一下这两个字符的用途, 没找到特别满意的答案.不过发现有人跟我遇到了一样的问题.

preview

其实用workaround很容易把这个问题忽略, 但是确实感觉这么一个简单的计算器的automation, 觉得挺有趣的, 就花时间研究了一下. 

字符含义:​​​​​​U+202C Pop Directional Formatting (PDF) Unicode Character (compart.com)

最低0.47元/天 解锁文章
python 路径中出现 \u202a 解决方法
云胡
10-22 9327
概述 今天在用 xlwings 操作 Excel 时候，发现一直出现一个错误，路径的前面老是有 \u202a。 代码 import xlwings as xw wb = xw.Book(r'c:\\Users\\Desktop\\1.xlsx') sht = wb.sheets['Sheet1'] sht.range('A1').value = 'yunhu' 报错信息 FileNotFound...
iOS通讯录复制的手机号码字符串多了奇怪的unicode码\u0000202d-\u0000202c
lnking1992的专栏
05-18 5711
最近项目线上问题，造成问题的原因：应用的用户信息界面需要输入手机号码，该用户就把自己电话簿里的手机号码进行复制(copy)之后，把复制的内容粘贴在我们页面的输入框里，一切都很完美，但点用户击保存后，却显示弹框“请输入正确的手机号”，于是用户就立马截图帮助（投诉了）我们改进bug，还加了句每次必现。分析原因：从用户的截图的显示界面看，输入框里的手机号码完全没有问题，我还打通了。那会是什么原因造成的呢...
注意不可见的Unicode，可能会有极大风险。
weixin_43090594的博客
01-05 1521
Unicode在不同OS中的处理方式，可能会带来严重的后果，不仅仅是乱码！
不可见的unicode字符
深海微澜
05-22 2893
项目中执行到代码如： x = x.encode(encoding) 报错：'latin-1' codec can't encode character u'\u202d' in position 0: ordinal not in range(256)。 可见是编码问题。报错信息显示这个x字符串中含有异常的字符u'\u202d'，奇怪的是这个x对应到我代码中只是一个简短的数字而已，此处为mem后的数字98304，并没有u'\u202d'字符，奇怪了... mem: 98304 于是查了下原来.
Unicode&ASCII中双向控制字符 U+202D和U+202C
亦碎流年的博客
12-16 5729
ASCII编码对照表_911查询 ASCII编码转换，ASCII码在线查询工具 ASCII 在线转换器 ，ASCII码，ASCII 转码—在线工具 Unicode 中的 BIDI 双向性算法 - 掘金 1.场景 今天查询数据库时，字符串确认是存在的，但是根据字符串查询数据库表，无记录。 2.原因和分析 含有隐藏控制字符：6694‬1650 正常字符：66941650 通过sql查询上面两个的长度，发现长度不一致，猜测是有特殊字符 ​ ...
记录一次特殊字符u202D，u202C的坑
u011649691的博客
10-23 6420
接到投诉有用户上传的excel后提示其中的手机号长度不正确的，反复查看上传的文件和提取后的参数，手机号长度都是11位，反复数绝对不可能错。但是将日志中的手机号复制到idea中的时候，首尾出现了/u202D150xxxx4036/u202C（将/换为\，否则显示不出来）。就是这些不可见的特殊字符导致了本次事件。经查： 1、RLO ( Code “\u202E” ; HTML ‮ ) ：开始从右到左的文字； 2、LRO ( Code “\u202D” ; HTML ‭ ) ：开始从左到右的文字； 3、PDF (
java处理提交不显示unicode码\u202c\u202d
qq_35491812的博客
04-09 3304
Unicode的学名是”Universal Multiple-Octet Coded Character Set”，简称为UCS 不可见字符”/u200b”为 Unicode Character ‘ZERO WIDTH SPACE’ (U+200B)，可用于内容标识，不占位数。 从Excel中复制过来的数据，在复制的时候复制了多余的东西。于是试了手写是正常，windows有些版本的Excel复...
Unicode字符之 202A 202B 202C 202D 202E
海燕的博客
03-22 5472
Unicode字符之 202A 202B 202C 202D 202E 这几个字符属于格式字符 202A：从左至右嵌入 202B：从右至左嵌入 202C：退出方向性格式化 202D：从右至左强制 202E：从左至右强制 数字的情况下： 他们单个使用的时候，只有202E有效果 public static void main(String[] args){ String name1 = "123\u202A456789"; String name2 = "123\u202B456
输入input文本框的 U+202D和U+202C是什么
weixin_30790841的博客
06-14 2758
这里看到一个解答，mark下 https://juejin.im/entry/5baa23606fb9a05ce576a28c 转载于:https://www.cnblogs.com/lavin/p/11021756.html
java处理表单提交特殊字符'\u202D'
lai1170137052的博客
08-22 3931
最近两天运营说录入电话号码老是报格式不正确错误，但是电话明明是正常的，我跑去他那里仔细看了看所有的参数都是正常： 找了很久都没有找到原因，参数明明没有问题。细问是怎么操作的，说是从Excel中复制过来的，于是便怀疑在复制的时候复制了多余的东西。于是试了手写是正常，mac电脑复制过来是正常，windows有些版本的Excel复制过来就有问题。本地一调试发现，果不其然，正常手写的手机号是1...
记一次编码导致的问题：\u202d和\u202c
fan3394565的博客
08-27 7812
"\u202d136xxxxx16\u202c", "159xxxxx67","\u202d136xxxxx31"   原因是从excel表格直接复制到input框，然后保存
关于excel导入手机号提取时被自动加上多余空万国码“\U202d” “\U202c“的问题
H.CF的博客
09-21 1387
// 去除excel粘贴自动加上的空万国码“\U202d” "\U202c" StringBuilder currentMobile = new StringBuilder(); if (mobiles.length() > 12) { for (int i = 0; i < mobiles.length(); i++) { if (mobiles.charAt(i) >= 48 && mobiles.charAt(i) <= 57) { currentM
\u202E与\u202D的RLO与LRO (QQ消息后缀 喵！)
热门推荐
qq_45874536的博客
10-15 2万+
\u202E与\u202D的LRO与RLO (QQ消息后缀 喵！) 原理 1. \u202E 的作用是使得后续字符串从右至左读（RLO，即RIGHT-TO-LEFT OVERRIDE)， 如 123\u202EABC 输出后为 123CBA 2. \u202D 的作用是使得后续字符串从左至右左读（LRO，即LEFT-TO-RIGHT OVERRIDE)，，如 123\u202DABC 输出后为 123ABC 举例 在消息列表中，QQ会将昵称、冒号、消息三者进行字符串拼接进行显示。如： 昵称：赵Y
字符串翻转之谜
Time flys
05-27 2713
做内容安全审查时，发现了一个奇怪的case。 明明用户的评论中含有敏感词，但是用关键词匹配却无法匹配成功。就好像like这个匹配方法失效了一样。 sql select '一个敏感词啊' like '%敏感词%' -- 结果竟然为false 用肉眼是无法看出问题的，把评论以文件形式下载到本地，用vim打开，才发现，原来文本的顺序是错乱的！见下图 以这一段文本为例，<202d><202e>耳木<202c><202c>品质差别<202d><202e
关于零宽度隐藏字符
weixin_45376131的博客
07-12 539
这其实是unicode提供的一个功能，有一些unicode是控制字符。\u202e 的含义就是后面的字符翻转显示，\u202c 的含义是翻转控制到此结束。所以，在这两个控制字符之间的内容，全都是从右向左展示。起因是在某一天线上出现了一个问题，在收集手机号短信发送日志时，出现了插入报错，方案一：源头的时候通过判断字符长度来告知用户数据有问题。
字符中包含不显示的控制字符
Sallystar的专栏
10-11 2346
碰到一个unicode字符集的问题，记录一下 拷贝了一个手机号直接粘贴到平台 保存，结果发送短信时该手机号接收不到，网上查了才知道原来拷贝到手机号包含了不显示unicode字符 \u202d 一般用到Unicode 控制字符有： 1、RLO ( Code "\u202E" ; HTML &amp;#x202E; ) ：开始从右到左的文字； 2、LRO ( Code "\u202D" ; HT...
特殊不可见字符Unicode编码
Admans的专栏
12-06 2541
【代码】特殊不可见字符Unicode编码。
php-过滤不可见零宽的字符\u200B
repoman的博客
07-08 5559
今天用户输入了一段文字：（别辜负了今天。 ​​​​），结果触发了业务的产品需求逻辑，不能有四个连续的字符限制，第一眼一看完全没有连续的啊！ 初步猜测是末尾有空格，结果进行文本删除的时候，发现只有一个可见的空格，后面末尾出现了四个不可见的0长度的字符，要连续删四次． 首先先进行问题排查 $content="别辜负了今天。 ​​​​"; $oriJsonContent = json_encode($content); echo $oriJsonContent; -----输出----- "\u522b\
\u202D和\u202c代表什么含义
最新发布
10-10
<think>嗯，用户这次的问题是关于字符编码中的特定Unicode控制字符“‭”（U+202D）和“‬”（U+202C）。结合用户之前询问过的“$memorySize | $ramSize”表达式（其中也包含U+202D/U+202C），看来用户正在排查文本显示异常问题。 用户可能遇到了这类场景：从某个系统（比如PHP读取的文件或嵌入式配置）中获取的文本出现了意料之外的排版错乱，怀疑是隐藏字符作祟。ta特意引用了Unicode不可见字符列表和字符编码原理，说明已有一定技术基础，但需要更落地的解释。 重点需要向用户讲清楚三点： 1. 这两个字符的本质作用：不是“显示符号”，而是像隐形指令一样改变文本方向 2. 实际危害场景：数据解析/代码执行时可能引发bug（比如用户之前遇到的管道符失效） 3. 排查方案：如何检测和清理它们 注意到用户提供的引用材料中有PHP相关示例，可以推测ta可能在处理web或文件解析任务。要特别强调PHP中mbstring扩展的处理方式，因为用户引用[1]提到过GBK编码问题，说明项目可能涉及多字节字符集。 需要警惕的是，这类字符常被用于XSS攻击中的视觉欺骗，虽然用户没提安全需求，但作为专业回应应该隐含提醒。不过根据ta之前的关注点，暂时先聚焦技术解析层面。 对了，用户系统指令要求所有公式用$...$包裹。虽然字符编码问题通常不涉及数学公式，但解释字节序时可以举例：比如汉字‘中’的GBK编码$D6D0_{hex}$在小端序中存储为$D0 D6$。这样既符合规范又直观。 </think>字符编码中的 **‭**（U+202D）和 **‬**（U+202C）是 Unicode 控制字符，主要用于控制文本的**双向排版顺序**（Bidirectional Text）。它们在 IT 领域的核心含义如下： --- ### 1. **字符编码的本质** - 字符编码是将字符（如文字、符号）转换为计算机可存储的二进制数据的规则（如 ASCII、UTF-8）。 - 例如： - 汉字“中”在 GBK 编码中占 `2字节`（`D6 D0`），在 UTF-8 中占 `3字节`（`E4 B8 AD`）。 - 控制字符（如 `‭`）本身不显示，但会影响文本解析逻辑。 --- ### 2. **U+202D 和 U+202C 的作用** | Unicode 码点 | 名称 | 用途 | |--------------|--------------------|----------------------------------------------------------------------| | **U+202D** | `LEFT-TO-RIGHT OVERRIDE` (LRO) | 强制后续文本**从左到右**排列（覆盖默认双向规则）[^2] | | **U+202C** | `POP DIRECTIONAL FORMATTING` (PDF) | **结束**由 LRO/RLO 触发的强制排版方向，恢复默认规则[^2] | #### 典型场景： - **混合语言排版**： 阿拉伯语（从右向左）与英语（从左向右）混合时，用 `‭...‬` 包裹英语文本，确保其方向正确。 ```text "السوق‭ Stock Exchange‬" // 阿拉伯语中的"Stock Exchange"保持左到右 ``` - **防御安全漏洞**： 恶意代码可能用控制字符伪装文件名（如 `exe‭gpj.‬` 显示为 `exe.jpg`），需警惕[^2]。 --- ### 3. **IT 领域的实际问题** - **乱码与解析错误**： 若程序未正确处理双向控制符，会导致： - 文本显示错乱（如 `"123‭ABC‬"` 显示为 `"CBA123"`） - 数据解析失败（如 JSON 中包含 `‭` 可能被误判为非法字符） - **解决方案**： ```php // PHP 示例：过滤控制字符 $clean_text = preg_replace('/[\x{202A}-\x{202E}]/u', '', $raw_text); // 移除U+202A到U+202E字符[^1] ``` - **编码兼容性**： 通信时需统一编码（如 UTF-8）并转换字节序，避免乱码[^1]。 --- ### 4. **与其他控制字符的关联** - **字节顺序标记 (BOM)**： `U+FEFF` 用于标识文本的字节序（如 UTF-16），但可能引发解析冲突。 - **零宽空格**： `U+200B` 可分词但不显示，常用于网页排版。 --- ### 总结 | 字符 | 角色 | 影响领域 | |-----------|--------------------|-----------------------| | **‭ (U+202D)** | 强制左到右排版 | 国际化文本、安全防御 | | **‬ (U+202C)** | 结束强制排版方向 | 数据解析、编码一致性 | **核心建议**： - 在开发中显式处理文本方向时使用这些字符（如多语言 UI）。 - 在数据清洗、通信协议中主动过滤它们，避免副作用。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值