了解Cocoa用户界面中字符串代码使用

了解Cocoa用户界面中字符串代码使用方法是本文要介绍的内容，iOS的界面前台的展示，有字符和图像都是通过编码来实现的,新的Cocoa的开发者应该通过多看苹果开发文档，熟悉函数及各个事件灵活的使用方法，就能快速提高自己的iOS开发的技能.

在这篇文章中，我将提到在iPhone用户界面上管理和使用的文本字符串的最好程序. 这是一个相当简单的技术主题，但是Cocoa建立作为处理用户界面的字符串的最好的程序例子，新的Cocoa的开发者应该会注意到这点.由于它不可避免会提及，我也提到在你的应用程序使用字符的步骤，但请记住：你应该按好的程序来练习字符串处理技能，尽管你没有打算调整你的应用程序.

Introduction (the wrong way) 

简述(错误的方法)

在一定的技术水平下给用户的界面添加文字字符串并不是难事.在源代码里面填充代码就像添加文字一样简单.

可能就是一个

UI标签

实现字符的

这段代码是iOS的UI的标签代码​

在Mac OS X,你应该设置为

stingValue的属性​

可能是一个

NSTexField的属性

另外的这个步骤是一样的.

虽然这个可以实现功能，但你你不应该用这种方法来设置用户界面的字符串.

B---用字面字符串设置标签(正确的方法)

最完整的把字符添加到你的Cocoa应用程序的用户界面是如下的方法：

someUserInterfaceLabel.text =  
NSLocalizedStringFromTable(  
@"Text to display", // the native language string  
@"SomePageLabels", // the category  
@"Label display string"); // a comment describing context 

这个是相当的繁杂的.它也可以如下的用法：

someUserInterfaceLabel.text = NSLocalizedString(@"Text to display", nil); 

如果你没有做其它的步骤，这个代码也会产生同样错误.

你可以

一直使用这个(NSLocalizedString)

每个用户界面的宏程序都有字符串在你的代码中

但是这个有点不一样

NSLocalizedString这样的代码需要很多的输入，除非你已经做了另外更多的步骤并且程序不需要什么不同的功能?如果我现在不考虑转换我的程序，它们是不是完全无用的呢?

为什么NSLocaliedString是重要的，尽管你不想来使用

明显地，

NSLocalizedString  
[...] functions (and the less common  
[...]功能(比通常​  
CFCopyLocalizedString  
CFCopylocalizedString​　　​ 

[...] 变体​的值是让所有的个功能本地话语言(i.e 让你的程序显示为不同的语言)​

从技术上说，他们甚至不是一种功能——它们只是宏程序的请求

-[NSBundle localizedStringForKey:value:table:]  
-[NSBundle localizedStringForKey:value:table:] 

方法-​你可以用宏程序，并且因为很多的理由你不用调用什么方法​.我会在下部分来讨论语言变换的机制.

然而，尽管你不想让你的程序可以显示更多的语言，你也得使用NSLocalizedString

一直用NSLocalizedString这有几个理由：

1.未来改变的基础 ：NSLocalizedString

2.模型视图控制设计模式：它保持了你的模型层/表示层的详细记录，其中至少有一个不正确的地位从你的控制器源码里面撤出.在某种情况下，你可以简单的该表.strings的文件来为你的程序更新来调整用户的界面，而不用单独去修改代码

3.关注点分离：它清晰地显示了在用户表示层字符串，作为对应字符只供编程使用的.

4.优化冗繁的程序：从你的控制器独立用户界面字符，你不会愿意从用户界面去返回去阅读字符串，或者程序员已经放置好在用户界面上面的放好的字符

未来是很难预测的.你不知道你在以后会想把转化成别的语言.​到时候你要通过你的全部的代码和找出有所有的字符串的目录是很费时间，而且会导致错误.相反得，应该把所有的事情通过使用NSLocalizedString来转化的语言的习惯.​​

这很容易实现，甚至当你在​解码的时候，你就能使用它了.　　​

分离关注点

分离关注点在浏览代码是很有用，并且可以知道动向.考虑下面单独的代码段

[someDictionary setObject:@"value" forKey:SomeKeyNameString];  
[someDictionary setObject:NSLocalizedString(@"value", nil) forKey:SomeOtherKeyNameString]; 

不用知道

什么是someDictionary属性​​

或者是someKeyNameString和SomeOtherkeyName的作用是什么

SomeKeyNameString  
and  
SomeOtherKeyNameString 

属性的含义是，我们知道第二个字符串的是用来在第一个字符串不能直接实现的一个值来表现用户界面的.

这个独立使用的这个属性，对用户界面的显示是很有帮助的，相对someKeyNameString，它在程序当中有更多的用法.

Discourages other bad practices 

优化冗繁的代码

如果你认为NSLocalizedString就像它们的输出是个黑盒子,这个可以帮助你在管理用户界面的元素的时候避免极差的控制器的设计.它可以作为一个概念的工具，让你通过有效的方法来设计，不是以个愚蠢的设计.

你的控制器代码会把用户界面的字符串当作可以被写，但是不会被读.从你的用户界面阅读基本的字符串是很不好受.

在上面的分离关注点的那个例子中，你可以能会认为SomeKeyNameString和SomeOtherKeyNameString

是在这个例子中被定义为全局变量,就是你可以用来定义本地语言的一个变量.在多数情况下，使用国际化的变量的并不好.

我们在全局变量中定义了字典的键，因为有个程序的不同的位置需要使用同样的属性，在多处信息交换的时候就会出现错误.在用户界面的字符串的值，你不应该有另外的变量需要和其中的另一个完全一样的值：你不应该从你的用户界面去回读代码或者与用户界面的协助.一般来说，如果的相同的用户界面需要多次使用，才可以有同样字符串在程序里面.(例如.你在绘制同样的对象)，但是在这种的情况下，代码都是公用的，而这个字符串也只能在代码中出现一次.

如果您需要唯一标识标签或文本显示的类型，测试它所包含的文本是错误的方法.一个更好的方法是使用UIView的标签 /NSActionCell​

tag

value of any  
UIView  
/  
NSActionCell  
and then map the 

然后描述对象的角色和功能的属性值

tag

value onto the object's role or function ( 

tag它是一个指针的值，所以你可以存储非保留对象，而不仅仅是整数.

标签的属性值不保存任何的其它的值，它是由控制器它是由控制器来跟踪用户界面项目和它们的状态。

转化的过程

最终，你可能要翻译你的外文的程序.让我们看看所涉及的步骤.

建立你的.strings的文件

你的程序包含的“.strings"的文件是你所需要翻译的,在默认的情况下，不会有任何”.strings“​的文件(除了InfoPlist.strings文件，该文件是为翻译您的Info.plist文件中的字符串)​

第一步是确保你有一个指定的目录(可能是你项目文件夹资源子目录​).如果是在处理的英文的字符才一个指定的目录应该命名为"en.lproj"，否则你应该用​ISO639-1和ISO639-2 替代​”en​“的标记.​如果需要的话，你可以可以使用脚本和区域标识符作为描述苹果的开发的语言和区域标识符.​　　​

一个文件夹名称的备注：这是很容易见到用“English.Ipoj”代替“en.Iproj”,事实上,如果你获取文件的信息并且选择了生成本地化文件，Xcode3就会自动生成用这个名字生成的那个名字的文件夹.苹果公司表示这些命名已经老了，从MacOSX 10.4以上的版本就倾向于ISO639-1和ISO639-2代号.不要使用旧的“English.proj”类型的名字，用“en.lproj”来替代，如果是自动创建的(是的，如果你改了文件夹的名字需要更新的你Xcode的路径)

现在我们在程序里面，我们能从NSLocalizedString函数自动创建“.strings”文件

NSLocalizedString实现这个功能，他开你的项目的根目录运行终端，然后输入下面的命令：

find -E . -iregex '.*\.(m|h|mm)$' -print0 | xargs -0 genstrings -a -o Resources/en.lproj  
 
find -E . -iregex '.*\.(m|h|mm)$' -print0 | xargs -0 genstrings -a -o Resources/en.lproj 

这些命令会处理你的程序目录层次结构的的所有.m .h .mm的文件和在en.lpoj中创建“.strings”文件(注意，en.lproj的目录必须是已经存在) 这是假定你创建本地化资源目录位于“资源/ en.proj“，相对于你的项目的根目录，很明显，你需要改变这目录位置，如果​​你把它放在别处。

“.strings”的代码可能会有很多的条目就像下面的代码：

"Some UI string %@ to translate %@" = "Some UI string %1$@ to translate %2$@";  
 
"Some UI string %@ to translate %@" = "Some UI string %1$@ to translate %2$@"; 

你的程序翻译功能仅需要对应翻印同样的描述就可以.​注意你的字符串的占位符​已经给出的​次序，这样可以是转换的时候改换原来的占位符，如果​如果你使用占位符，您应该包括注释，解释他们要去秩序.

本土化与国际化：

1.国际版本：你从原来的程序转化过来的

2.原始版本：你翻译程序和转化新的版本

通过那个几个术语,NSLocalizedString的作用

创建和打包“.strings”的文件是国际化的窗口.

一般来说，​创建新的语言的转化版​被称为本地化的过程.实际上，它包括了两个步骤：​

genstrings只能处理静态NSLocalizedString和CFCopyLocalizedString字符串

可以被自动提取的字符是在NSlocalizedString函数里面的：

NSLocalizedString  
[...] and  
CFCopyLocalizedString 

[...]宏指令显然，所有的用户界面文本需要被包含到上面的函数(CFCopyLocalizedString)，也得记住底层的样子

[NSBundle localizedStringForKey:value:table:] 

的方法是不会自动被处理的

为什么你会直接用-[NSBundle localizedStringForKey:value:table:]?它的原因是他会自动生成所需的字符串.

如果程序检测到在本地化的宏程序中有其它的静态的字符串，这个genstrings的命令就会出现错误. 这是恰当的，因为你不希望你的变量名被转化和函数调用(它们只需要转化这些调用的结果)。

你会使用-[NSBundle localizedStringForKey:value:table:]的原因是：那些被转化成本地语言的字符串是那些在代码里面的(或在一个文件不是从代码生成的“.string “),你只需要去寻找它们的变化。

编码的问题

从Mac OS X10.5开始，你可以把任何UTF- 8字符在你的NSLocalizedString函数。在这之前，​ 他们必须是用Unicode转义\\ Uxxxx风格的纯粹的7位的ASCII码的另外方式或者你可以使用带- macRoman命令行选项MacRoman使用MacRoman高ASCII字符。

小结：了解Cocoa用户界面中字符串代码使用方法的内容介绍完了，希望本文对你有所帮助！