这不算啥，很多用得不频繁的 QQ 小号还强制要你刷脸验证呢？

有 review 总比没有 review 好，有的小公司代码直接都没有 review 环节的。

我编辑了一个较长的帖子，但是发不出来，被吞帖了，IP 还被禁了，我临时换了一个 IP ，还好找回了编辑的内容，所以把内容发在图片上回应诸位，不知道能不能发出来，其中的观点你们不管赞同与否，这是我最后一次回复此问题了，谢谢大家。

@void1900
@liuxu
@rekulas
----
图片中提到的链接：
https://www.baeldung.com/linux/file-mime-types

---

https://i.imgur.com/YT39yXO.png

@InternetExplorer 再补充一点，如果你是在命令行直接调用 php 文件（比如 php hello.php, php hello2.123 <---后缀名不相关，可以任意），那这种情况就跟 MIME Type 没有关系，他就是直接读取源码然后解析<?php ?>包含的代码，只要你把 PHP 文件放到任意的 Web Server 里边，要通过 HTTP/HTTPS 访问，那 MIME Type 就是绕不过去的了，别管你看没看到 Content-Type ，看到的 Content-Type 是啥，Web 服务器在发送结果之前，都按自己内部定义的或者默认的 MIME Type 进行了分析和处理。

@InternetExplorer 是的，你这个表述大部分是对的，但对于 MIME Type 的理解还是限制在了 Content-Type 上，这也不算冷知识了，大家都知道， 早期 PHP 源文件为了区分不同的版本，甚至还使用.php4 和.php5 这样的后缀名呢，这都不影响，MIME-Type 用来指代和归类一类文件，比如 .php4 .php5 .php 都可以统一归为一种 MIME Type ，至于叫什么名字无所谓，你甚至可以把它叫做 application/my-php-file, xxx/xxx 这样的名字也只是一种约定速成的形式。为了 HTTP 统一接口，统一调用而已。

PHP 本身跟 mime 没关系，但是服务器软件要解析和处理 PHP ，就少不了 MIME Type 的掺和了。

不管是什么 Web 服务器（ Apache ，Nginx ，IIS 等）在以文件后缀名作为区别对请求进行分流的时候，Web 服务器内部就已经是通过不同的文件类型来分别做不同的处理了。多个不同的后缀名文件也可以设置归到一个 MIME Type 下，用一种方式统一处理（比如上面举的例子，多个不同的 php 文件的后缀名实质都是 PHP ）。然后，已知的图片类型加图片类型的 Content-type ，文本类型加 text 这一类的头部，经过动态解析的页面，统一都使用 text/html ，接口调用的根据需要显示 json 头部或者 xml 的头部标识。

要注意一点，浏览器的 Content-Type 只是 MIME Type 的应用之一，而不是全部。MIME Type 的存在让 HTTP 类应用各种文件类型前后呼应，功不可没。C/S 架构，B/S 架构少了任何一端配合都不行。

@eason1874 又来一个在这杠，我再强调一次，MIME Type 的应用很广泛，客户端和服务端都有，不是你在浏览器看到的那个 Content-Type 才叫 MIME Type ，你在配置转发的时候，已经认定 PHP 这个类型的 MIME 包括的这一类文件需要后端解析了，居然都解析过了，自然看不到原始数据了。一群人狭隘地认为浏览器里面那个“Content-Type”才叫 MIME Type

突然想起来一个老梗：
如何让一群程序员马上争论起来？
——“PHP 是世界上最好的语言”

-------------

万万没想到，有一天我也变成了这种人，终究还是没躲过。


散了，我克制一点。干正事要紧。

@miencun 又来一个搞笑的。你的两个观点都大错特错。你甚至还不如他 @void1900
引用你的话：
“扩展名和 Mime 毛关系都没有，你以为 php 叫 application/x-httpd-php ，谁定义的？浏览器为什么会暴源码，因为浏览器不认识 application/x-httpd-php ”
----
解答：
1 、扩展名和 Mime 是一一对应的关系，当然了，也可以一对多，一个 MIME 对应多个拓展名。
2 、浏览器暴露源码是因为 Web 服务器处理失误输出了源文件的原始数据（ RAW DATA ），跟你浏览器收到什么 Content-type 没有关系，这个东西很好证明，你可以不用浏览器啊，Linux 有现成的 curl 命令，Web 服务器端配置有问题的话，你用 curl http://xxx 不一样能得到服务器返回的源码吗？跟 Content-Type 有什么关系呢？只跟你服务器输出了什么东西有关系，不止是 Content-Type ，绝大多数的 HTTP 头部信息其实都是可以忽略的，不影响结果输出，绝大部分的头部信息都属于冗余信息，需要用到的时候才拿出来用。

@void1900 对牛弹琴，说了那么多白说了。如果你要好好说话，你可以说 MIME Type 不能和拓展名相关联，只能做描述文件类型用，那这个问题本身就有争议，我可以考虑接受。尽管这个问题有争议，回复了那么多，你也应该知道我要说的 MIME Type 就是 Web Server 根据不同拓展名来处理不同类型文件的意思。而不是杠子眼，为什么我说有争议，是因为这个问题你在 Google 和 Stackoverflow 上都有两个版本，普遍认为 Apache ，IIS 这样的关联比较强（直接写在配置文件里或者配置界面上），Nginx 等代理性质的服务器关联比较弱，但不是代表没关系。

第二个，关于你说的 SetHandle ，那你觉得 Apache 是凭什么东西找到它要 Handle 的对象的呢？

@void1900 语文不好的是你，理解能力差，所以一开始才看不懂别人的回复里面已经约定了很多东西，你视而不见，需要一遍又一遍跟你解释，我说了不急，只要 V2 这站还活着，让时间给你答案。

@miencun CGI 你也得用相应的规则配置去匹配.php 这一类后缀的文件，这还叫没关系。虽然 MIME Type 不全等于文件拓展名（这一点我上面的回复说了，就算我强行关联吧），但 MIME Type 就是为了让 HTTP 服务 C/S 两端前后呼应，用来区分不同文件类型的，想想你用 Niginx 配置代理 PHP 时候怎么写的 location 来匹配呢，用了 php 的拓展名没有？

忘记艾特你了，请看上一楼，专门回复你的。 @void1900

你是不是傻，来，我来一一回复你：

“人家结尾都说了 “并没有在内部 mime 列表中查出一个['php'=>'type/php']这种东西。”。”

——请把我这个帖子的回复连贯起来看，我上面的回复里面说了，并不是要明示“'php'=>'type/php'”这样的东西才叫 php 有 MIME Type ，没定义不代表就没有，MIME Type 是 HTTP 类应用在区分不同文件类型的时候引入的概念，但不是说这类东西只能跟浏览器挂钩，Web 服务也是需要的，比如 Apache 里面是定义了 PHP 的 MIME Type 类型是 application/x-httpd-php ，你可以不加这个名字，叫 application/x-abc 也行，总之是为了区分不同类型的文件； Nginx 默认只定义了所有常见的静态资源类型的 MIME Type ，没去定义任何的动态类语言的 MIME Type （ php ，jsp 等等），是因为 Nginx 常用做前端负载均衡代理服务使用，你要给他一个 PHP 的 MIME 定义，他也没错，Nginx 对不同的文件类型，也同样有自己 MIME Type 概念，其实严格一点说，所有具有后缀名的文件都有 MIME Type ，只要我们需要了，我们就可以给这一类文件定义一个 MIME Type ，Web Server 靠这个东西区分不同的文件类型该做什么样处理。你的问题在于陷入了一个误区，认为只有浏览器的 Content-Type 跟 MIME Type 有关系，其他的地方都没关系。

---

“写正则用的是扩展名，那假如我将整个目录都 proxy_pass 给 fpm 呢？你还怎么扯你的扩展名？”

——你当然可以这样设置，但你这是正常和常规的做法吗？万一你这个路径下边有子目录呢，子目录里面有图片，js
，css 文件呢，你是不是要不管三七二十一统统交给后端去解析，还是说你把所有的子目录一个个分开来设置，不管嵌套几层，统统分开设置，反正就是打死不用后缀名来匹配。顺便建议你，平时在服务器上配置 Nginx 和 PHP 也采用你说的做法，打死不要用 php 后缀名来做正则匹配哦，我会为你鼓掌，你要偷偷用了你就是小狗。

@void1900 还有指明一点，别人的回答你都不仔细看，甚至没弄明白别人说的是什么就率先站出来反对，你看看我在这个帖子下的所有的回复，哪一个兄弟的回复的答案我没看？并且是有人给出自己观点，我都会对照自己的表述一一回应，错了就错了，概念错误，还是逻辑错误，又或者是意思没表达清楚，我都大方承认，就你光在这自说自话，压根不管别人说的是啥，这是一个学习者该有的态度吗？
-----
顺便说一句，V2 发帖的好处是无法删帖无法修改，究竟打了谁的脸，就留给观众老爷们评判吧，让时间说话。

@void1900 你就继续掩耳盗铃吧。你再好好读读楼上那位兄弟的回答，假如你能理解的话。要是读不懂，那我就送你三个字：“你赢了！”，散会

@liuxu 另外说一下，关于第二个问题，Nginx 使用 location 配置 php 时，实际上已经在正则表达式里边传递 php 的后缀名了，所以说成是后缀名匹配也无大的错误。

@liuxu 你的这个回答恰恰说明了 php 会不会暴露源码跟 MIME Type 高度相关，而不是不相关，打了不少人的脸，@void1900 首当其冲，脸都被打肿了。先不讨论你回答的正确性（因为我懒得验证），根据你的回答，我阐述有问题的地方仅有两个：
一. 不是所有的 Web 服务器默认 MIME Type 都是 application/octet-stream ；
二。不能把 Nginx 通过 location 配置 PHP 解析的方式统一叫成后缀名或 MIME Type 识别，它可能仅仅就是一个 URL 路径的正则匹配。

----
当然，现在的我仍然坚持后缀名≈MIME Type 的观点，我不是说他们概念和定义相等，是说他们对 Web 服务器的影响差不多，前后端搭配，不仅是浏览器需要 Content-Type ，Web 服务器本身也需要区分哪些文件需要处理，哪些文件是直接输出。

你说的“但是从 nginx 的角度来看，它就是一个正则字符串，并没有在内部 mime 列表中查出一个['php'=>'type/php']这种东西。”这个问题我上面的回复说过了，不需要输出给浏览器特殊标头（ Content-Type ）的文件，并不需要显式定义，因为不管是 php ，还是 jsp 他们最终呈现给浏览器都是 text/html 而已，但不意味着在 Web 服务器内部没有一个标识来把这些 php 文件统一归类，有可能这个东西不能叫 MIME Type （你可以叫 proxy file group1 ，proxy file group2 或其他），但绝对存在这样一个标识，Nginx 这样的代理服务器也不例外。

综上，结论就是 PHP 爆不爆源码还真的跟 MIME Type 有关系。别吵了。

@void1900 很好，结贴

@void1900 我说的有什么问题，我说的“配置正确”范围很宽泛，不管你配置转发到后端也好，或者配置权限控制也好（密码访问，IP 限制等），哪怕是 Nginx 你这么写 location ~ *.php {deny alll;}，我都都算配置正确。我说的“配置正确”意思就是叫你对这类文件的预期行为进行设置，如果你设置有误，设置成纯文本模式读取的形式（ text/plain,text/css 等），或者没设置设置成未知的类型，那 MIME Type 默认就是 application/octet-stream ，这样 http 访问就会被当成一个附件下载下来了，不管 HTTP header 输不输出这个 Content-type 头，只要 Web 服务器认为这个文件不需要被处理，需要输出原始流，都会导致源码暴露。你才是硬杠，我提这个的东西最初衷的目的就是让题主去了解服务器分文件类型解析和输出结果的过程，然后题主就不会有这样的疑问了，因为 php 这个文件类型已经被约定行为了。你可以说 PHP 文件在 Web 服务器内部不能叫 MIME Type ，我叫错了，但你无法证明我的思路和阐述是错误的，就这样子。