document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-03 23:40:14 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2690 from royaso/master

Browse Source 
校对的不错！辛苦啦。
This commit is contained in:
Xingyu.Wang 2015-04-29 14:10:15 +08:00
commit 0ba1fe5942
2 changed files with 457 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

444
sources/tech/2015-04-29 web caching basics terminology http headers and caching strategies.md Normal file
View File

@ -0,0 +1,444 @@
Web Caching Basics: Terminology, HTTP Headers, and Caching Strategies
=====================================================================
### Introduction
Intelligent content caching is one of the most effective ways to improve
the experience for your site's visitors. Caching, or temporarily storing
content from previous requests, is part of the core content delivery
strategy implemented within the HTTP protocol. Components throughout the
delivery path can all cache items to speed up subsequent requests,
subject to the caching policies declared for the content.
In this guide, we will discuss some of the basic concepts of web content
caching. This will mainly cover how to select caching policies to ensure
that caches throughout the internet can correctly process your content.
We will talk about the benefits that caching affords, the side effects
to be aware of, and the different strategies to employ to provide the
best mixture of performance and flexibility.
What Is Caching?
----------------
Caching is the term for storing reusable responses in order to make
subsequent requests faster. There are many different types of caching
available, each of which has its own characteristics. Application caches
and memory caches are both popular for their ability to speed up certain
responses.
Web caching, the focus of this guide, is a different type of cache. Web
caching is a core design feature of the HTTP protocol meant to minimize
network traffic while improving the perceived responsiveness of the
system as a whole. Caches are found at every level of a content's
journey from the original server to the browser.
Web caching works by caching the HTTP responses for requests according
to certain rules. Subsequent requests for cached content can then be
fulfilled from a cache closer to the user instead of sending the request
all the way back to the web server.
Benefits
--------
Effective caching aids both content consumers and content providers.
Some of the benefits that caching brings to content delivery are:
- **Decreased network costs**: Content can be cached at various points
in the network path between the content consumer and content origin.
When the content is cached closer to the consumer, requests will not
cause much additional network activity beyond the cache.
- **Improved responsiveness**: Caching enables content to be retrieved
faster because an entire network round trip is not necessary. Caches
maintained close to the user, like the browser cache, can make this
retrieval nearly instantaneous.
- **Increased performance on the same hardware**: For the server where
the content originated, more performance can be squeezed from the
same hardware by allowing aggressive caching. The content owner can
leverage the powerful servers along the delivery path to take the
brunt of certain content loads.
- **Availability of content during network interruptions**: With
certain policies, caching can be used to serve content to end users
even when it may be unavailable for short periods of time from the
origin servers.
Terminology
-----------
When dealing with caching, there are a few terms that you are likely to
come across that might be unfamiliar. Some of the more common ones are
below:
- **Origin server**: The origin server is the original location of the
content. If you are acting as the web server administrator, this is
the machine that you control. It is responsible for serving any
content that could not be retrieved from a cache along the request
route and for setting the caching policy for all content.
- **Cache hit ratio**: A cache's effectiveness is measured in terms of
its cache hit ratio or hit rate. This is a ratio of the requests
able to be retrieved from a cache to the total requests made. A high
cache hit ratio means that a high percentage of the content was able
to be retrieved from the cache. This is usually the desired outcome
for most administrators.
- **Freshness**: Freshness is a term used to describe whether an item
within a cache is still considered a candidate to serve to a client.
Content in a cache will only be used to respond if it is within the
freshness time frame specified by the caching policy.
- **Stale content**: Items in the cache expire according to the cache
freshness settings in the caching policy. Expired content is
"stale". In general, expired content cannot be used to respond to
client requests. The origin server must be re-contacted to retrieve
the new content or at least verify that the cached content is still
accurate.
- **Validation**: Stale items in the cache can be validated in order
to refresh their expiration time. Validation involves checking in
with the origin server to see if the cached content still represents
the most recent version of item.
- **Invalidation**: Invalidation is the process of removing content
from the cache before its specified expiration date. This is
necessary if the item has been changed on the origin server and
having an outdated item in cache would cause significant issues for
the client.
There are plenty of other caching terms, but the ones above should help
you get started.
What Can be Cached?
-------------------
Certain content lends itself more readily to caching than others. Some
very cache-friendly content for most sites are:
- Logos and brand images
- Non-rotating images in general (navigation icons, for example)
- Style sheets
- General Javascript files
- Downloadable Content
- Media Files
These tend to change infrequently, so they can benefit from being cached
for longer periods of time.
Some items that you have to be careful in caching are:
- HTML pages
- Rotating images
- Frequently modified Javascript and CSS
- Content requested with authentication cookies
Some items that should almost never be cached are:
- Assets related to sensitive data (banking info, etc.)
- Content that is user-specific and frequently changed
In addition to the above general rules, it's possible to specify
policies that allow you to cache different types of content
appropriately. For instance, if authenticated users all see the same
view of your site, it may be possible to cache that view anywhere. If
authenticated users see a user-sensitive view of the site that will be
valid for some time, you may tell the user's browser to cache, but tell
any intermediary caches not to store the view.
Locations Where Web Content Is Cached
-------------------------------------
Content can be cached at many different points throughout the delivery
chain:
- **Browser cache**: Web browsers themselves maintain a small cache.
Typically, the browser sets a policy that dictates the most
important items to cache. This may be user-specific content or
content deemed expensive to download and likely to be requested
again.
- **Intermediary caching proxies**: Any server in between the client
and your infrastructure can cache certain content as desired. These
caches may be maintained by ISPs or other independent parties.
- **Reverse Cache**: Your server infrastructure can implement its own
cache for backend services. This way, content can be served from the
point-of-contact instead of hitting backend servers on each request.
Each of these locations can and often do cache items according to their
own caching policies and the policies set at the content origin.
Caching Headers
---------------
Caching policy is dependent upon two different factors. The caching
entity itself gets to decide whether or not to cache acceptable content.
It can decide to cache less than it is allowed to cache, but never more.
The majority of caching behavior is determined by the caching policy,
which is set by the content owner. These policies are mainly articulated
through the use of specific HTTP headers.
Through various iterations of the HTTP protocol, a few different
cache-focused headers have arisen with varying levels of sophistication.
The ones you probably still need to pay attention to are below:
- **`Expires`**: The `Expires` header is very straight-forward,
although fairly limited in scope. Basically, it sets a time in the
future when the content will expire. At this point, any requests for
the same content will have to go back to the origin server. This
header is probably best used only as a fall back.
- **`Cache-Control`**: This is the more modern replacement for the
`Expires` header. It is well supported and implements a much more
flexible design. In almost all cases, this is preferable to
`Expires`, but it may not hurt to set both values. We will discuss
the specifics of the options you can set with `Cache-Control` a bit
later.
- **`Etag`**: The `Etag` header is used with cache validation. The
origin can provide a unique `Etag` for an item when it initially
serves the content. When a cache needs to validate the content it
has on-hand upon expiration, it can send back the `Etag` it has for
the content. The origin will either tell the cache that the content
is the same, or send the updated content (with the new `Etag`).
- **`Last-Modified`**: This header specifies the last time that the
item was modified. This may be used as part of the validation
strategy to ensure fresh content.
- **`Content-Length`**: While not specifically involved in caching,
the `Content-Length` header is important to set when defining
caching policies. Certain software will refuse to cache content if
it does not know in advanced the size of the content it will need to
reserve space for.
- **`Vary`**: A cache typically uses the requested host and the path
to the resource as the key with which to store the cache item. The
`Vary` header can be used to tell caches to pay attention to an
additional header when deciding whether a request is for the same
item. This is most commonly used to tell caches to key by the
`Accept-Encoding` header as well, so that the cache will know to
differentiate between compressed and uncompressed content.
### An Aside about the Vary Header
The `Vary` header provides you with the ability to store different
versions of the same content at the expense of diluting the entries in
the cache.
In the case of `Accept-Encoding`, setting the `Vary` header allows for a
critical distinction to take place between compressed and uncompressed
content. This is needed to correctly serve these items to browsers that
cannot handle compressed content and is necessary in order to provide
basic usability. One characteristic that tells you that
`Accept-Encoding` may be a good candidate for `Vary` is that it only has
two or three possible values.
Items like `User-Agent` might at first glance seem to be a good way to
differentiate between mobile and desktop browsers to serve different
versions of your site. However, since `User-Agent` strings are
non-standard, the result will likely be many versions of the same
content on intermediary caches, with a very low cache hit ratio. The
`Vary` header should be used sparingly, especially if you do not have
the ability to normalize the requests in intermediate caches that you
control (which may be possible, for instance, if you leverage a content
delivery network).
How Cache-Control Flags Impact Caching
--------------------------------------
Above, we mentioned how the `Cache-Control` header is used for modern
cache policy specification. A number of different policy instructions
can be set using this header, with multiple instructions being separated
by commas.
Some of the `Cache-Control` options you can use to dictate your
content's caching policy are:
- **`no-cache`**: This instruction specifies that any cached content
must be re-validated on each request before being served to a
client. This, in effect, marks the content as stale immediately, but
allows it to use revalidation techniques to avoid re-downloading the
entire item again.
- **`no-store`**: This instruction indicates that the content cannot
be cached in any way. This is appropriate to set if the response
represents sensitive data.
- **`public`**: This marks the content as public, which means that it
can be cached by the browser and any intermediate caches. For
requests that utilized HTTP authentication, responses are marked
`private` by default. This header overrides that setting.
- **`private`**: This marks the content as `private`. Private content
may be stored by the user's browser, but must *not* be cached by any
intermediate parties. This is often used for user-specific data.
- **`max-age`**: This setting configures the maximum age that the
content may be cached before it must revalidate or re-download the
content from the origin server. In essence, this replaces the
`Expires` header for modern browsing and is the basis for
determining a piece of content's freshness. This option takes its
value in seconds with a maximum valid freshness time of one year
(31536000 seconds).
- **`s-maxage`**: This is very similar to the `max-age` setting, in
that it indicates the amount of time that the content can be cached.
The difference is that this option is applied only to intermediary
caches. Combining this with the above allows for more flexible
policy construction.
- **`must-revalidate`**: This indicates that the freshness information
indicated by `max-age`, `s-maxage` or the `Expires` header must be
obeyed strictly. Stale content cannot be served under any
circumstance. This prevents cached content from being used in case
of network interruptions and similar scenarios.
- **`proxy-revalidate`**: This operates the same as the above setting,
but only applies to intermediary proxies. In this case, the user's
browser can potentially be used to serve stale content in the event
of a network interruption, but intermediate caches cannot be used
for this purpose.
- **`no-transform`**: This option tells caches that they are not
allowed to modify the received content for performance reasons under
any circumstances. This means, for instance, that the cache is not
able to send compressed versions of content it did not receive from
the origin server compressed and is not allowed.
These can be combined in different ways to achieve various caching
behavior. Some mutually exclusive values are:
- `no-cache`, `no-store`, and the regular caching behavior indicated
by absence of either
- `public` and `private`
The `no-store` option supersedes the `no-cache` if both are present. For
responses to unauthenticated requests, `public` is implied. For
responses to authenticated requests, `private` is implied. These can be
overridden by including the opposite option in the `Cache-Control`
header.
Developing a Caching Strategy
-----------------------------
In a perfect world, everything could be cached aggressively and your
servers would only be contacted to validate content occasionally. This
doesn't often happen in practice though, so you should try to set some
sane caching policies that aim to balance between implementing long-term
caching and responding to the demands of a changing site.
### Common Issues
There are many situations where caching cannot or should not be
implemented due to how the content is produced (dynamically generated
per user) or the nature of the content (sensitive banking information,
for example). Another problem that many administrators face when setting
up caching is the situation where older versions of your content are out
in the wild, not yet stale, even though new versions have been
published.
These are both frequently encountered issues that can have serious
impacts on cache performance and the accuracy of content you are
serving. However, we can mitigate these issues by developing caching
policies that anticipate these problems.
### General Recommendations
While your situation will dictate the caching strategy you use, the
following recommendations can help guide you towards some reasonable
decisions.
There are certain steps that you can take to increase your cache hit
ratio before worrying about the specific headers you use. Some ideas
are:
- **Establish specific directories for images, css, and shared
content**: Placing content into dedicated directories will allow you
to easily refer to them from any page on your site.
- **Use the same URL to refer to the same items**: Since caches key
off of both the host and the path to the content requested, ensure
that you refer to your content in the same way on all of your pages.
The previous recommendation makes this significantly easier.
- **Use CSS image sprites where possible**: CSS image sprites for
items like icons and navigation decrease the number of round trips
needed to render your site and allow your site to cache that single
sprite for a long time.
- **Host scripts and external resources locally where possible**: If
you utilize javascript scripts and other external resources,
consider hosting those resources on your own servers if the correct
headers are not being provided upstream. Note that you will have to
be aware of any updates made to the resource upstream so that you
can update your local copy.
- **Fingerprint cache items**: For static content like CSS and
Javascript files, it may be appropriate to fingerprint each item.
This means adding a unique identifier to the filename (often a hash
of the file) so that if the resource is modified, the new resource
name can be requested, causing the requests to correctly bypass the
cache. There are a variety of tools that can assist in creating
fingerprints and modifying the references to them within HTML
documents.
In terms of selecting the correct headers for different items, the
following can serve as a general reference:
- **Allow all caches to store generic assets**: Static content and
content that is not user-specific can and should be cached at all
points in the delivery chain. This will allow intermediary caches to
respond with the content for multiple users.
- **Allow browsers to cache user-specific assets**: For per-user
content, it is often acceptable and useful to allow caching within
the user's browser. While this content would not be appropriate to
cache on any intermediary caching proxies, caching in the browser
will allow for instant retrieval for users during subsequent visits.
- **Make exceptions for essential time-sensitive content**: If you
have content that is time-sensitive, make an exception to the above
rules so that the out-dated content is not served in critical
situations. For instance, if your site has a shopping cart, it
should reflect the items in the cart immediately. Depending on the
nature of the content, the `no-cache` or `no-store` options can be
set in the `Cache-Control` header to achieve this.
- **Always provide validators**: Validators allow stale content to be
refreshed without having to download the entire resource again.
Setting the `Etag` and the `Last-Modified` headers allow caches to
validate their content and re-serve it if it has not been modified
at the origin, further reducing load.
- **Set long freshness times for supporting content**: In order to
leverage caching effectively, elements that are requested as
supporting content to fulfill a request should often have a long
freshness setting. This is generally appropriate for items like
images and CSS that are pulled in to render the HTML page requested
by the user. Setting extended freshness times, combined with
fingerprinting, allows caches to store these resources for long
periods of time. If the assets change, the modified fingerprint will
invalidate the cached item and will trigger a download of the new
content. Until then, the supporting items can be cached far into the
future.
- **Set short freshness times for parent content**: In order to make
the above scheme work, the containing item must have relatively
short freshness times or may not be cached at all. This is typically
the HTML page that calls in the other assisting content. The HTML
itself will be downloaded frequently, allowing it to respond to
changes rapidly. The supporting content can then be cached
aggressively.
The key is to strike a balance that favors aggressive caching where
possible while leaving opportunities to invalidate entries in the future
when changes are made. Your site will likely have a combination of:
- Aggressively cached items
- Cached items with a short freshness time and the ability to
re-validate
- Items that should not be cached at all
The goal is to move content into the first categories when possible
while maintaining an acceptable level of accuracy.
Conclusion
----------
Taking the time to ensure that your site has proper caching policies in
place can have a significant impact on your site. Caching allows you to
cut down on the bandwidth costs associated with serving the same content
repeatedly. Your server will also be able to handle a greater amount of
traffic with the same hardware. Perhaps most importantly, clients will
have a faster experience on your site, which may lead them to return
more frequently. While effective web caching is not a silver bullet,
setting up appropriate caching policies can give you measurable gains
with minimal work.
---
作者: [Justin Ellingwood](https://www.digitalocean.com/community/users/jellingwood)
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
推荐：[royaso](https://github.com/royaso)
via: https://www.digitalocean.com/community/tutorials/web-caching-basics-terminology-http-headers-and-caching-strategies
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出

26
translated/share/20140804 Group Test--Linux Text Editors.md
View File

@ -8,7 +8,7 @@
得益于能向它们注入足以抗衡其它类型的以文本为中心的应用程序能力的插件，一些简单的文本编辑器甚至超过了它们的设计目标。它们能胜任一个源代码编辑器的任务，甚至是一个集成开发环境。
Emacs和Vim是两款最流行和强大的纯文本编辑器。但是，由于一些原因，我们在这个组测试中并没有包括它们。首先，如果你使用它们中的任何一个，那么恭喜你：你不需要更换了。其次，它们都有陡峭的学习曲线，尤其是对于那些对有面向图形用户界面的桌面系统的替代能力更有兴趣的用户。
Emacs和Vim是两款最流行和强大的纯文本编辑器。但是，由于一些原因，我们在这个组测试中并没有包括它们。首先，如果你使用它们中的任何一个，那么恭喜你：你不需要更换了。其次，它们都有陡峭的学习曲线，尤其是那些熟悉了桌面环境的用户:他们很更愿意投入其他有图形界面的文本编辑器。
### 目录: ###
@ -54,9 +54,9 @@ Emacs和Vim是两款最流行和强大的纯文本编辑器。但是，由于一
除了Gedit和jEdit以外的所有工具，都是通过推荐的安装方法安装在Fedora和Ubuntu上。前者已经兼容默认的Gnome桌面，后者仍然固执地反对安装在Fedora上。由于这些是相对简单的应用程序，他们没有复杂的依赖，唯一例外的是jEdit，它要求要有Oracle Java。
得益于Gnome和KDE持续的努力，不论他们运行的桌面环境，所有编辑器看起来很好，功能也很正常。这不仅是作为环境评价的标准，也意味着你不再受制于要找到和你的桌面环境兼容的工具。
得益于Gnome和KDE持续的努力，不论他们运行的桌面环境，所有编辑器看起来很好，功能也很正常。这不仅是作为评价的标准，也意味着你不再受制于要找到和你的桌面环境兼容的工具。
除了它们老派的功能，我们也对所有候选者测试了通用文本编辑功能。然而，它们并没有被设计为模仿现代字处理器的所有功能，我们也不以此评判。
除了它们奇特的功能，我们也对所有候选者测试了通用文本编辑功能。然而，它们并没有被设计为模仿现代字处理器的所有功能，我们也不以此评判。
![Kate能搭建为功能丰富的集成开发环境](http://www.linuxvoice.com/wp-content/uploads/2014/08/kate-web.png)
@ -64,7 +64,7 @@ Kate能搭建为功能丰富的集成开发环境。
### 编程语言支持 ###
UltraEdit 能进行语法高亮，代码折叠以及拥有项目管理的能力。这也有一个罗列源文件中所有功能的功能列表，但并不适用于我们任何的测试代码文件。UltraEdit也支持HTML5，有能添加常用HTML标记的HTML工具栏。
UltraEdit 能进行语法高亮，代码折叠以及拥有项目管理的能力。这也有一个罗列源文件中所有函数的功能列表，但并不适用于我们任何的测试代码文件。UltraEdit也支持HTML5，有能添加常用HTML标记的HTML工具栏。
即使Gnome的默认文本编辑器Gedit，也有几个面向编码的功能特性，例如括号匹配，自动缩进以及为包括C, C++, Java, HTML, XML, Python, Perl, 以及许多其它编程语言进行语法高亮。
@ -74,15 +74,15 @@ UltraEdit 能进行语法高亮，代码折叠以及拥有项目管理的能力
正如Komodo IDE，Sublime也可滚动浏览显示完整的代码，这对于长代码文件导航和在文件中的不同部分跳转很方便。
Sublime最好的功能之一就是能在编辑器内部为特定语言，例如C++, Python, Ruby等运行代码，当然假设在你的电脑上安装有编译器以及其它系统工具。
Sublime最好的功能之一就是能在编辑器内部为特定语言，例如C++, Python, Ruby等运行代码，当然假设在你的电脑上安装有编译器以及其它系统工具。省时间而且不用再开终端.
你也可以用插件在Kate中开启构建系统功能。另外，你可以为GDB调试器添加一个简单的前端。Kate能和Git，Subversion以及Mercurial版本控制系统一起工作，也提供了一些项目管理的功能。
除了能为超过180中语言进行语法高亮，它支持所有的这些辅助功能，例如括号匹配，自动补全和自动缩进。它也支持代码折叠，甚至在一个程序中包括有错误的函数。
除了能为超过180中语言进行语法高亮，它支持所有的这些辅助功能，例如括号匹配，自动补全和自动缩进。它也支持代码折叠，甚至在一个程序中折叠函数。
jEdit是唯一的遗憾，它声称自己是一个程序员的文本编辑器，但它缺少其他的基本功能，例如代码折叠，它甚至不支持补全功能。
唯一的遗憾的是jEdit，它声称自己是一个程序员的文本编辑器，但它缺少其他的基本功能，例如代码折叠，它甚至不能提示或者不全函数.
**Verdict:**
**评分:**
- Gedit:3/5
- Kate:5/5
@ -98,7 +98,7 @@ jEdit是唯一的遗憾，它声称自己是一个程序员的文本编辑器，
高级文本编辑器用户希望能完全通过键盘控制和操作，一些应用程序甚至运行他们的用户自定义快捷方式的键盘绑定。
你可以轻松的使用Gedit的扩展键盘快捷键。这里有编辑文件，为普通任务，例如对一个文档进行拼写检查，唤起工具的快捷键。你可以获取应用程序内部的一系列默认快捷键，但并没有图形化的方式去自定义它们。相似的，在Sublime中自定义键绑定，你需要修改他的XML键映射文件。Sublime由于缺少定义键盘快捷键的图形化界面而饱受批评，但长期使用的用户已经支持当前的基于文件的机制，这给他们更多的控制能力。
你可以轻松的使用Gedit的扩展键盘快捷键。这里有编辑文件，为普通任务，例如对一个文档进行拼写检查，唤起工具的快捷键。你可以获取应用程序内部的一系列默认快捷键，但并没有图形化的方式去自定义它们。相似的，在Sublime中自定义键绑定，你需要修改他的XML键映射文件。Sublime由于缺少定义键盘快捷键的图形化界面而饱受批评，但长期使用的用户支持当前的基于文件的机制:这给他们更多的控制能力。
UltraEdit为它"一切都可自定义"的座右铭感到自豪，这也包括键盘快捷键。你可以自定义菜单导航的热键，以及定义你自己的访问大量函数的多键键映射。
@ -148,7 +148,7 @@ UltraEdit的用户界面是高度可配置的 — 你可以正如改变其它许
Gedit有很普通的外观。通过最小化菜单和按钮有一个简单的界面。但这也是一种双刃剑，因为有些用户可能不会发现它真正的潜能。
应用程序可以通过在窗口中能重排和移动的选项卡打开多个文件。用户可以通过使用一个插件选择性地启用旁边或者底部用来显示文件浏览和工具输出的面板。这个应用程序会检测到被其它应用程序更改的文件并可以重新加载这个文件。
Gedit可以通过在窗口中能重排和移动的选项卡打开多个文件。用户可以通过使用一个插件选择性地启用旁边或者底部用来显示文件浏览和工具输出的面板。这个应用程序会检测到被其它应用程序更改的文件并可以重新加载这个文件。
为了适配Gnome，在应用程序的最后一个版本中考虑了大量的用户界面。然而它还并不稳定，尽管包括了所有的功能，和菜单交互的一些插件还需要升级。
@ -232,7 +232,7 @@ jEdit拥有最令人映像深刻的插件设施。该应用有超过200个插件
### 纯文本编辑 ###
尽管它们强大的额外功能甚至可能会取代几个流派完全成熟的应用程序，有时候可能只需要使用这些庞大的文本编辑器读写或者编辑简单的纯文本。虽然你可以使用它们中的任何一个输入文本，我们通过普通文本编辑的方便性平均它们。
尽管它们强大的额外功能甚至可能会取代几个流派完全成熟的应用程序，有时候可能只需要使用这些庞大的文本编辑器读写或者编辑简单的纯文本。虽然你可以使用它们中的任何一个输入文本，我们通过普通文本编辑的方便性评价它们。
Gnome的默认文本编辑器Gedit，支持取消和重做机制以及搜索和替换。它可以对多种语言进行拼写检查，并能通过使用Gnome GVFS库访问和编辑远程文件。
@ -303,7 +303,7 @@ Kate为能快速响应你的需要而设计，它的界面并不会使你茫然
随你发行版发布的默认文本编辑器也能帮助你一些高级任务。例如KDE的KWrite和Raspbian的Nano。得益于KDE的katepart组件，KWrite继承了一些Kate的功能，得益于在树莓派上的可用性，Nano也开始重现风头。
如果你希望跟随Linux大师的脚本，你总是可以尝试崇高的文本编辑机Emacs和Vim。想尝试Vim强大的用户首先可以考虑gVim，它通过图形界面展现了Vim的强大。
如果你希望跟随Linux大师的脚步，你总是可以尝试崇高的文本编辑机Emacs和Vim。想尝试Vim强大的用户首先可以考虑gVim，它通过图形界面展现了Vim的强大。
除了jEdit和Kate，这里还有其他模仿例如Emacs和Vim之类的老派高级编辑器的编辑器，比如JED 编辑器和Joe's Own Editor，这两者都有Emacs的模拟模式。另一方面，如果你在寻找轻量级的代码编辑器，可以看看Bluefish和Geany。他们的存在是为了填补文本编辑器和全面集成的开发平台之间的空隙。
@ -313,7 +313,7 @@ via: http://www.linuxvoice.com/text-editors/
作者：[Ben Everard][a]
译者：[ictlyh](https://github.com/ictlyh)
校对：[校对者ID](https://github.com/校对者ID)
校对：[royaso](https://github.com/royaso)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](http://linux.cn/) 荣誉推出