PHP - Getting numbers when reading korean characters - php

I have following url with some Korean characters at end of the url:
http://localhost/example/popular-tags/고양이
Now I am reading 고양이 from url like this which is used in Laravel5 for read data from url string:
$TagName = str_slug(Request::segment(2), "-");
but getting number eab3a0ec9691ec9db4 not 고양이 characters.
Any idea how to get Korean characters.
Thanks.

According to this, str_slug translates to ASCII.

You can't use Laravel's helpers to work with UTF-8 slugs. I've tried it and it has really big problems (in routes, helpers etc). I even wrote my own package to work with UTF-8. You can try it, cause if you want to get URLs like http://localhost/example/popular-tags/고양이 and you don't use !#$# and similar characters in URL, it will work for you. Or you can copy some slug creation code from it and use it inside you own project.
Also, you can simplify things and just use:
Route('example/popular-tags/{slug}' ...`
And in controller:
public function index($slug)
{
$data = Model::where('slug', $slug)->get();

Related

laravel. Replace %20 in url

I have simple problem, I have to replace %20 and other crap from URL. At the moment it looks like this http://exmaple/profile/about/Eddies%20Plumbing. As you can see it's profile link.
Yes I could add str_replace values before every hyperlink, but I have like 10 of them and I think it's bad practice. Maybe there is better solution? What solution would you use? Thanks.
That is not crap, that is a valid unicode representation of a space character. And it's encoded because it's one of the characters that are deemed unsafe by RFC1738:
All unsafe characters must always be encoded within a URL. For
example, the character "#" must be encoded within URLs even in
systems that do not normally deal with fragment or anchor
identifiers, so that if the URL is copied into another system that
does use them, it will not be necessary to change the URL encoding.
So in order to have pretty URLs, you should avoid using reserved and unsafe characters which need encoding to be valid as part of a URL:
Reserved characters: $ & + , / : ; = ? #
Unsafe characters: Blank/empty space and < > # % { } | \ ^ ~ [ ] `
Instead replace spaces with dashes, which serve the same purpose visually while being a safe character, for example look at the Stack Overflow URL for this question. The URL below looks just fine and readable without spaces in it:
http://exmaple/profile/about/eddies-plumbing
You can use Laravel's str_slug helper function to do the hard work for your:
str_slug('Eddies Plumbing', '-'); // returns eddies-plumbing
The str_slug does more that replace spaces with dashes, it replaces multiple spaces with a single dash and also strips all non-alphanumeric characters, so there's no reliable way to decode it.
That being said, I wouldn't use that approach in the first place. There are two main ways I generally use to identify a database entry:
1. Via an ID
The route path definition would look like this in your case:
/profiles/about/{id}/{slug?} // real path "/profiles/about/1/eddies-plumbing"
The code used to identify the user would look like this User::find($id) (the slug parameter is not needed, it's just there to make the URL more readable, that's why I used the ? to make it optional).
2. Via a slug
The route path definition would look like this in your case:
/profiles/about/{slug} // real path "/profiles/about/eddies-plumbing"
In this case I always store the slug as a column in the users table because it's a property relevant to that user. So the retrieval process is very easy User::where('slug', $slug). Of course using str_slug to generate a valid slug when saving the user to the database. I usually like this approach better because it has the added benefit of allowing the slug to be whatever you want (not really needing to be generated from the user name). This can also allow users to choose their custom URL, and can also help with search engine optimisation.
The links are urlencoded. Use urldecode($profileLink); to decode them.
I am parsing the url tha i got in this way ->
$replacingTitle = str_replace('-',' ',$title);
<a href="example.com/category/{{ str_slug($article->title) }}/" />
In your view ...
{{$comm->title}
and in controller using parsing your url as
public function showBySlug($slug) {
$title = str_replace('-',' ',$slug);
$post = Community::where('title','=',$title)->first();
return view('show')->with(array(
'post' => $post,
));
}

Laravel helper function link_to() does not work properly for links with non ascii characters

Say for example I have in my blade file:
link_to('http://domain.com/foo/愛', 'You make my heart go doki doki')
This will actually output the anchor tag but the href will repeat the base domain i.e. href="http://domain.com/http://domain.com/foo/愛. I've tried with something such as ë which will return the same error. Do I need to apply some sort of escaping first for this to work properly or am I just not getting it?
I've dug around the code myself for link_to but I'm just not getting why it would repeat itself (https://github.com/laravel/framework/blob/872bc11f7beb11a309ec41ab2d9f6c19da18acb5/src/Illuminate/Support/helpers.php#L619).
EDIT: Tried doing a urlencode() on the url string, unfortunately same results but the slashes are now html encoded.
Omit the domain part from the $url parameter of the link_to function:
link_to('foo/愛', 'You make my heart go doki doki')
This will generate the following string:
You make my heart go doki doki

PHP: Converting scandic characters to hex unicode

I'm working on a Joomla site with Fabrik and problem is that Fabrik serializes some data using json_encode() but does not take into account the possibility of åäö and such. Now when a database search is made, it tries to find stuff with åäö, but doesn't find anything, because
everything is \u00e4 and \u00f6
and so forth.
I'm not much for digging into Fabrik's code and inserting one flag somewhere and worry about accidentally overwriting it when I update Fabrik. So I figured, since I'm disappointed in Fabrik anyway, I could just write around it completely in a custom template. Easy.
The problem is that I can't find a way or a function like htmlentities() that I can just feed the stuff to to make it match. I could just character replace them, but that's not a good solution.
Paraphrase: I wanna make word Mörkö into -> M\u00f6rk\u00f6. How?
Maybe there's another way but that works as excepted :
$encoded = substr(json_encode('Mörkö'), 1, -1);
json_encode('Mörkö') => "M\u00f6rk\u00f6"
substr() => M\u00f6rk\u00f6

Settings that could influence PHP str_replace behaviour

I am currently working on a replacement tool that will dynamically replace certain strings (including html) in a website using a smarty outputfilter.
For the replacement to take place, I am using PHP's str_ireplace method, which reads the code that is supposed to be replaced and the replacement code from a database, and then pass the result to the smarty output (using an output filter), in a similar way as the below.
$tpl_source = str_ireplace($replacements['sourceHTML'], $replacements['replacementHTML'], $tpl_source);
The problem is, that although it works great on my dev server, once uploaded to the live server replacements occasionally fail. The same replacements work just fine on my dev version though. After some examinations and googling there was not much I could find out regarding this issue. So my question is, what could influence str_replace's behavour?
Thanks
Edit with replacement example:
$htmlsource = file_get_contents('somefile.html');
$newstr = str_replace('Some text', 'sometext', $htmlsource); // the text to be replaced does exist in the html source
fails to replace. After some checking, it looks like the combination of "> creates a problem. But just the combination of it. If I try to change only (") it works, if I try to change only (>) it works.
It might be that special chars like umlauts do not display on the live server correctly and so str_replace() would fail, if there are specialchars inside the string you want to replace.
Is the input string identical on both systems? Have you verified this? Are you sure?
Things to check:
Are the HTML attributes in the same order?
Are the attribute values using the same kind quote marks? (eg <a href='#'> vs <a href="#">)
Is there any other stray HTML code getting in there?
Is the entity encoding the same? (eg vs   - same character; different HTML)
Is the character-set the same? (eg utf-8 vs ISO 8859-1: Accented characters will be encoded differently)
Any of these things will affect the result and produce the failures you're describing.
This was a trikcy problem, and it ended up having nothing to do with the str_replace method itself;
We are using smarty as a tamplating system. The str_replace method was used by a smarty ouput filter in order to change the html in some ocassions, just before it was delivered to the user.
Here is the Smarty outputfilter Code:
function smarty_outputfilter_replace($tpl_source, &$smarty)
{
$replacements = Content::getReplacementsForPage();
if (is_array($replacements))
{
foreach ($replacements as $replacementData)
{
$tpl_source = str_replace($replacementData['sourcecode'], $replacementData['replacementcode'], $tpl_source);
}
}
return ($tpl_source);
}
So this code failed now and then for now apparent reason... until I realized that the HTML code in the smarty template was being manipulated by an Apache filter.
This resulted into the source code in the browser (which we were using as the code to be replaced by something else) not being identical to the template code (which smarty was trying to modify). Result? str_replace failed :)

Problem with cyrillic characters in friendly url

Here's the thing. I have friendly urls like
http://site.com/blog/read/мъдростта-на-вековете
http://site.com/blog/read/green-apple
The last segment is actually the friendly title of the blog article. The problem is when I try to pass that segment to the database, the cyrillic fonts turn into something like %D1%8A%D0%B4%D1%80%D0%BE%D1%81%D1%8 and couldn't match the database record. In the address bar in my browser it looks normal (мъдростта-на-вековете) but if I choose 'copy url location' the last segment again turns into these strange characters. I'm using CodeIgniter and everything is set to UTF-8.
Please help! :(
The text is just being encoded to fit the specification for URLs.
Echo out the data to a log to see what you are actually trying to pass to the database.
You should be able to decode it with urldecode.
The above answers are ok, but if you want to use routing with cyrillic it isn't enough. For example if you have http://site.com/блог/статия/мъдростта-на-вековете you will have to do something like this:
In config/routes.php: $route['блог/статия/(:any)'] = "blog/article/$1";
In system/core/URI.php , in the function _explode_segments(), you can change
$val = trim($this->_filter_uri($val));
to
$val = urldecode(trim($this->_filter_uri($val)));
This will solve the above problem plus controllers and functions.
Actually, Firefox is cheating you here: the URL actually is url-encoded, but is shown as if it wasn't. So copy-pasting and retrieving it on the server will have the URL encoded.
(Not sure if other browsers behave in the same way.)

Categories