联想设备中EditText.setText()方法在RTL语言下的异常Bug

Hey Bob, 我之前在联想定制ROM的设备上也碰到过一模一样的RTL语言字符异常问题，你的描述太精准了——切换到波斯语这类RTL语言后，调用setText()再获取文本，首尾会莫名多出几个字符，这事儿根源其实是联想系统对RTL文本做了额外的双向控制字符插入，但没在getText()时正确过滤掉。

那些多余的字符本质是双向文本控制符（比如LRM/RLM、PDF这类），联想的定制ROM为了保证RTL文本的显示方向正确，自动给文本加了这些标记，却没处理好反向读取的逻辑，导致你拿到的字符串带了冗余内容。

给你几个实测有效的解决方案：

• 方案一：手动过滤双向控制字符（最稳妥）
  写个工具方法把字符串里的双向控制符清掉，这类字符的Unicode范围是\u200E（LRM）、\u200F（RLM）、\u202B（RLI）、\u202C（PDF）等。示例代码：

  public static String cleanBidirectionalChars(String input) {
      if (input == null) return null;
      // 匹配并移除所有双向控制字符
      return input.replaceAll("[\u200E\u200F\u202A-\u202E]", "");
  }
  

  使用时直接套一层：

  String myString2 = cleanBidirectionalChars(myEditText.getText().toString());
  

• 方案二：强制关闭控件的RTL文本优化
  如果你的原始字符串本身是从左到右的（LTR），可以直接给EditText/TextView强制设置文本方向，避免系统自动插入RTL标记：
  XML布局里加属性：

  android:textDirection="firstStrongLtr"
  

  或者代码里动态设置：

  myEditText.setTextDirection(View.TEXT_DIRECTION_FIRST_STRONG_LTR);
  

• 方案三：用SpannableString替代普通字符串
  部分定制ROM对SpannableString的处理逻辑更稳定，试试用它来设置文本：

  SpannableString spannableText = new SpannableString("original string");
  myEditText.setText(spannableText);
  

  这种方式获取文本时大概率不会带出额外字符。

如果你的App需要同时兼容LTR和RTL文本，方案一最靠谱，不管系统怎么折腾都能拿到干净的原始字符串；如果文本固定是LTR，方案二操作起来最省心。

内容的提问来源于stack exchange，提问作者Bob