我在各种论坛上发现了许多问题，在这些论坛上，Mac用户locale通过SSH登录Linux系统时抱怨错误，抱怨LC_CTYPE=UTF-8设置不正确。
更详细地讲，MacOS上的外壳程序似乎设置了该值，然后（如果您在Terminal等中启用了该选项）LC_*，则在进行SSH输入时，本地变量将导出到远程系统。
Linux坚持LC_CTYPE需要将其设置为有效的语言环境（有时您可以localegen在Linux系统上以admin身份进行修复），但UTF-8首先不是语言环境。
我的主要问题是，这是MacOS中的错误吗？还是Linux坚持要求将变量设置为完全指定的语言环境名称是错误的吗？
其次，为了能够论证哪个是正确的以及为什么，在哪里指定？
第三，这些Mac用户（包括我自己）是否可以或应该做些不同的事情？
显而易见的解决方法是将类似
LC_CTYPE=en_US.UTF-8
在你的.bash_profile，但这显然只是解决它为您的个人帐户，并会有限制可能会或可能不会与其他一致的值locale设置。
基本问题是
我的主要问题是，这是MacOS中的错误吗？还是Linux坚持要求将变量设置为完全指定的语言环境名称是错误的吗？
并且环境变量的POSIX页面显示了其他人认为macOS配置不正确的原因：
[XSI]如果语言环境值具有以下格式：
language[_territory][.codeset]它是指实现提供的语言环境，其中语言，地区和代码集的设置是实现定义的。
LC_COLLATE，LC_CTYPE，LC_MESSAGES，LC_MONETARY，LC_NUMERIC，和LC_TIME被限定为接受的附加字段@改性剂，它允许用户以一个单一类别内选择的本地化数据的特定实例（例如，用于选择词典，而不是数据的字符顺序）。这些环境变量的语法因此定义为：[language[_territory][.codeset][@modifier]]例如，如果用户想用法语与系统交互，但需要对德语文本文件进行排序，则可以将LANG和LC_COLLATE定义为：
LANG=Fr_FR LC_COLLATE=De_DE可以通过使用@修饰符字段将其扩展为选择字典排序规则（例如）。例如：
LC_COLLATE=De_DE@dict一个实现可以支持其他格式。
如果实现无法识别语言环境值，则行为未指定。
也就是说，他们假设POSIX规定了语言环境设置的语法。粗心的读者会认为POSIX定义了环境变量的允许形式，因此代码集值是可选的，而不是替代语言。但是最后的“可能”打开了一罐蠕虫，实际上是在解释上的这种差异。如果Apple要提供不完全遵循该模式的有效语言环境，Apple可以做任何它想做的事情。
@tripleee建议在“语言环境”页面上提供更好的信息，但这几乎完全是关于语言环境定义的讨论，而不是为互操作性提供指导（即POSIX的表面目标）。
这两个页面都没有解决可用语言环境设置中的差异（例如“ .utf8”和“ .UTF-8”）。如POSIX页所述，这些依赖于实现。这给用户留下了唯一的解决方案，那就是自己确定本地和远程系统上支持哪些语言环境设置，并且（此处的ssh行为）确定如何“兼容”设置远程系统上的那些语言环境设置。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句